From sip-bounces@ietf.org Thu Mar 01 01:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMeMb-0004zU-Vq; Thu, 01 Mar 2007 01:02:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMeMa-0004zP-JN for sip@ietf.org; Thu, 01 Mar 2007 01:02:00 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMeMY-0004re-FX for sip@ietf.org; Thu, 01 Mar 2007 01:02:00 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l215xMKv025294; Thu, 1 Mar 2007 07:59:46 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 08:01:43 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 08:01:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue: Expiration of temp-gruu Date: Thu, 1 Mar 2007 08:01:36 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0367A121@esebe103.NOE.Nokia.com> In-Reply-To: <45E5AE63.2060309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue: Expiration of temp-gruu thread-index: AcdbVlsPMcXRRMWvRBan0tAngOkIEAAb7Xrg References: <456E15CD.60805@cisco.com> <1165200634.3607.3.camel@localhost.localdomain> <45749DF6.7040803@cisco.com> <1165336240.3208.72.camel@scott.skrb.org><45A55E25.3080904@cisco.com> <45E5AE63.2060309@cisco.com> From: To: X-OriginalArrivalTime: 01 Mar 2007 06:01:42.0406 (UTC) FILETIME=[15B39A60:01C75BC7] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070301075946-5DBB5BB0-2FEAB15A/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: sip@ietf.org, pkyzivat@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >The client would just generate a register refresh, changing the callid. >When it does this, it will, by the algorithm above, invalidate its=20 >temp-gruu locally. If we specify that the server does the same, then=20 >this provides a way for a client forcefully invalidate all previous=20 >temp-gruu without loss of connectivity. The proposed algorithm would unfortunately have a conflict to what RFC 3261 currently specifies for Call-ID handling for REGISTER refreshes in section 10.2: Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order.=20 Seems that this rule has been specified to avoid another race condition e.g. by the UAC at first refreshing the registration and right thereafter removing the binding. If these two messages would arrive over UDP to the registrar in the opposite order the UAC would believe to have successfully deregistered while the registrar would believe the UAC to have registered again. Thus solving the race condition like that for GRUU, another race condition would be opened for handling registrations in general. Regards, Erkki >-----Original Message----- >From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: 28.February.2007 18:32 >To: Jonathan Rosenberg >Cc: SIP IETF; Paul Kyzivat >Subject: Re: [Sip] Issue: Expiration of temp-gruu > >So, its now a month and a half since posting this, and days before the=20 >deadline I am getting to do this. And of course, as always seems to=20 >happen, on re-reading the threads and documents to re-cache=20 >the issues,=20 >I find another problem :( > >The algorithm below works fine, but omits a case. The case that is=20 >omitted is where the server doesn't send a partial notification, and=20 >instead sends a full-state notification that comes after the=20 >registration is refreshed. The flow is like this: > > >UA Reg > > (reg decides to shorten duration to 5s) > >NOTIFY (5s) ><----------- > >REGISTER (misses the window, and registration lapses briefly) >------------> >200 OK ><------------ > >NOTIFY (1hr) (reg never bothered to send NOTIFY for expiration since ><------------ it was refreshed a second later. So, rather=20 >than sending > two notifications, it combined and sent one with the > most recent state) > > >In this case, the 'glitch' that occurred - the temporary expiration of=20 >the contact followed by its re-registration, is NEVER known by the=20 >client. So, the server invalidated all of the temp-gruu, but=20 >the client=20 >doesn't know it. > >One solution is to REQUIRE a server to always send all state changes,=20 >never to combine them. I don't like this, since you still might have=20 >cases where the client misses a notification due to packet loss or=20 >something, and then you have the same problem over again.=20 >IMHO, you need=20 >a way for the client to be sure that it is in sync with the server on=20 >which temp-gruu are valid, and which are not. > >Fortunately, the solution here is relatively straightforward. The=20 >reg-event notifications include the cseq value present in the=20 >registration that first registered this contact. RFC 3680 already=20 >includes the total time elapsed since this contact was registered, but=20 >since we're dealing with race conditions, the timestamps aren't good=20 >enough. This would be a new element, , a child to =20 >in the reg-event XML. > >Whenever the client gets a reg-event notification, it invalidates any=20 >temp-gruu learned in a REGISTER that had a cseq value earlier than the=20 >. > >This provides a way for the client to, at any time,=20 >synchronize its set=20 >of valid temp-gruu with what the server has. So, it resolves this=20 >additional case above, in addition to providing a way to verify=20 >synchornization at any time, in case the client gets confused. > >Now, an important point here. Its not just the cseq, its also callid.=20 >The callid is part of this since cseq are scoped within a particular=20 >callid (as defined in RFC 3261). Interestingly, this provides, as a=20 >side-effect, a way for a client to tell the server to=20 >invalidate temp-gruu. > >The client would just generate a register refresh, changing the callid. >When it does this, it will, by the algorithm above, invalidate its=20 >temp-gruu locally. If we specify that the server does the same, then=20 >this provides a way for a client forcefully invalidate all previous=20 >temp-gruu without loss of connectivity. > >This is trivially done statelessly, by changing the hash algorithm to=20 >use the orig-cseq and call-id in the hash, rather than wallclock time. > >The main drawback really is that its a bit of feature creep. Again. > >My recommendation is to do it anyway, since I need to put about 95% of=20 >it in there just to deal with the race condition problem described=20 >above. The extra 5% is just an instruction to servers to invalidate=20 >temp-gruu when the call-id changes. That bit is what provides the=20 >feature whereby the client can forcefully expire temp-gruu. > >Thoughts? > >-Jonathan R. > >Jonathan Rosenberg wrote: > >> This thread is a month old, but I want to revise GRUU and=20 >get this done.=20 >> This is really the only issue that is outstanding, I think. >>=20 >> To refresh everyones memory, the issue being dsicussed is this.=20 >> Temp-GRUU expire when the last contact with the instance ID=20 >expires. In=20 >> normal cases, the expiration is known to the UA. However, there are=20 >> cases where there is a forceful de-registration, for=20 >example. In these=20 >> cases, the UA will not know about it, and it won't know whether its=20 >> temp-gruu remain valid. >>=20 >> We've seen three proposals for how to deal with this: >>=20 >> 1. include a parameter in the Contact header field of the REGISTER=20 >> response, indicating the time at which the first contact with that=20 >> instance ID was registered. When this changes in a REGSITER=20 >response,=20 >> the UA knows its older temp-gruu are invalid. >>=20 >> 2. the UA uses a reg-event subscription, and it gets a=20 >NOTIFY when the=20 >> contacts are de-registered. As long as the UA gets the notification=20 >> indicating that the de-registration has happened, this works=20 >reasonably=20 >> well. >>=20 >> 3. the UA can use an OPTIONS sent to a temp-gruu to verify=20 >that it still=20 >> works >>=20 >> (2) and (3) require no new mechanism, just explanation. (1) would=20 >> require new mechanism. >>=20 >> Now, I was in the process of working through some details on=20 >this, and=20 >> ran into problems. In particular, we ultimately need to be able to=20 >> specify an algorithm that clearly tells a UA which of its=20 >temp GRUU are=20 >> valid, and which are expired. If we are using the reg-event=20 >subscription=20 >> to figure this out, the obvious algorithm would be to expire all=20 >> temp-gruu learned in REGISTER responses prior to this notification.=20 >> However, that is imprecise. What about a REGISTER that happens very=20 >> close in time to the NOTIFY? Indeed, this is very likely to=20 >be the case=20 >> when the reg-event is shortening the expiration in order to=20 >ask the user=20 >> to explicitly re-REGISTER, but the time was a bit too short and the=20 >> re-REGISTER is close to the boundary. If a NOTIFY comes=20 >indicating that=20 >> the contact did expire, how do you *know* if that REGISTER came in=20 >> before or after? You could wait for the next NOTIFY, and try and=20 >> correlate it with the REGISTER you just completed. >>=20 >> One way to do that is with CSeq. The reg-event package includes the=20 >> option of having CSeq numbers. If we assume these are always=20 >used (they=20 >> are optional), the algorithm is a bit easier. Each temp-gruu is=20 >> associated with the CSeq of the REGISTER in which it was=20 >learned. When a=20 >> NOTIFY comes indicating that the registration has expired,=20 >you look to=20 >> see if its a partial or full state NOTIFY. In the case of=20 >partial, if=20 >> the NOTIFY explicitly removes a contact, you invalidate all=20 >temp-gruu=20 >> learned in register responses prior to or equal to the CSeq in the=20 >> contact. If the case of a full state NOTIFY, if the contact=20 >is absent,=20 >> the UA marks all temp-gruu as suspect. On the first NOTIFY that=20 >> indicates the Contact is re-registered (I assume the UA is=20 >> re-registering), the UA invalidates all temp-gruu learned by=20 >REGISTER=20 >> responses whose CSeq is less than the one in the NOTIFY. All=20 >others are=20 >> considered valid. >>=20 >> This algorithm is assuming some very specific behavior from=20 >registrars=20 >> that are doing reg-event with GRUU. Namely, they always send=20 >CSeq, even=20 >> when indicating expiration of a contact. We'd need to specify this,=20 >> probably as a note in gruu-reg-event. >>=20 >> Comments on this algorithm? If this is OK I will update GRUU=20 >based on=20 >> this and we can ship it. Finally. Really this time. >>=20 >> -Jonathan R. >>=20 >>=20 >> Scott Lawrence wrote: >>=20 >>> On Mon, 2006-12-04 at 17:15 -0500, Paul Kyzivat wrote: >>> >>>> Scott, >>>> >>>> Its certainly true that a gruu can always be tested to see if it=20 >>>> works. That would however raise the question of when one=20 >ought to do=20 >>>> the test. In normal cases you will know the status of your gruu by=20 >>>> regular methods, so you would have no reason to test it.=20 >So you would=20 >>>> have to test whenever you thought failure might have negative=20 >>>> consequences. Some of the times when failure might have bad=20 >>>> consequences are: when responding to an incoming INVITE,=20 >and any time=20 >>>> during a dialog. I guess you could send an OPTIONS and await the=20 >>>> response before responding to an INVITE, and it might even=20 >be masked=20 >>>> by alerting, but it seems kind of annoying to have to do=20 >that. But no=20 >>>> matter how often you do it during a dialog you still might=20 >miss the=20 >>>> moment your gruu becomes invalid and the other end of the dialog=20 >>>> sends you a message. (Extremely unlikely, but possible.) >>>> >>>> I think the other existing solutions get "pretty close",=20 >and OPTIONS=20 >>>> doesn't significantly improve on that. >>> >>> >>> >>> I don't like requiring the registrar to return a timestamp=20 >because it's >>> yet another piece of state that it has to keep for every=20 >registration. >>> >>> I don't think it actually helps all that much - going back to your >>> original problem statements: >>> >>> >>>> 3) the UA may attempt to refresh the registration, but be too slow, >>>> so that the reregistration arrives after the prior one expires >>>> 4) some other UA may deregister all the registrations, including >>>> the one by this UA. (When the UA decides it should refresh the >>>> registration it will actually create a new one.) >>>> 5) the registrar may remove the registration administratively >>>> 6) the registrar may crash and restart, losing all its=20 >registrations >>> >>> >>> >>> Case 3 can be avoided by just not waiting too long (overlap by a few >>> minutes instead of a few seconds - if that's still=20 >problematic then you >>> probably have other problems that are worse anyway). >>> >>> Cases 4,5, and 6 are essentially all the same from the=20 >point of view of >>> the UA; your registration state at the server is lost=20 >because of some >>> event you are not aware of. This is true of any=20 >registration, and is >>> not specific to temp-gruu or public gruu; it can happen=20 >with a Contact >>> value you provide without gruu at all. A gruu is slightly=20 >worse in that >>> loosing the state can affect in-dialog requests for=20 >established dialogs, >>> but I think that's just an unavoidable chance that you take when you >>> choose to use a gruu of either kind. Put another way, if you use a >>> gruu, you accept the fact that you're relying on an=20 >additional service >>> for in-dialog connectivity - it's either worth the benefits=20 >or it isn't. >>> >>> >>> >>> >>=20 > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 01 02:16:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMfU0-0003XW-Om; Thu, 01 Mar 2007 02:13:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMfTz-0003XO-RY for sip@ietf.org; Thu, 01 Mar 2007 02:13:43 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMfTy-0001wG-DF for sip@ietf.org; Thu, 01 Mar 2007 02:13:43 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2179CDC019239; Thu, 1 Mar 2007 09:09:36 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 09:13:23 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 09:13:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] When does the registrar have to create GRUUs ? Date: Thu, 1 Mar 2007 09:13:22 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0367A1CA@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] When does the registrar have to create GRUUs ? thread-index: Acdb0RiGrRmf6zexSEqNcuLxQCdXAA== From: To: X-OriginalArrivalTime: 01 Mar 2007 07:13:23.0848 (UTC) FILETIME=[198F9080:01C75BD1] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070301090936-48CA5BB0-0ACC5672/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, GRUU draft tells the registrar to create a public GRUU and a temporary GRUU whenever it receives a REGISTER request with "+sip.instance" Contact header parameter but only return them is the REGISTER request contains Supported: gruu. Does this make any sense ? Why would the registrar have to create those GRUUs if it would not return them to the UA ? The use case I am thinking is: - A registrar which supports both GRUU and Outbound=20 - An UA which supports Outbound but not GRUU Such an UA would send its Contact header with "+sip.instance" parameter but it would not include Supported: gruu in its REGISTER. Strictly speaking GRUU draft currently tells the registrar to create GRUUs but not to return them to=20 the UA. I would assume GRUU draft needs a small fix to tell the registrar to create the GRUUs only if the REGISTER request contains "gruu" option tag in Supported header. Do you agree or have I missed something ? Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.com ____________________________________=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From thadfitzgeraldvyoop@rdsnet.ro Thu Mar 01 03:48:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMgy2-0003iF-RE; Thu, 01 Mar 2007 03:48:50 -0500 Received: from [86.122.62.55] (helo=rdsnet.ro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMgxx-0001DC-F2; Thu, 01 Mar 2007 03:48:50 -0500 Message-ID: From: "Sharmaine Kim" To: "Reuben Berry" Cc: "Carline" , "Isa" , "Julius" , "Hyun" , "Michele" , "Dino Peters" , "Temple Nguyen" , "Anna" , "Nan" , "Alyse" , "Aliza" Subject: Sure Think It Is Time Date: Thu, 01 Mar 2007 12:50:34 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_2B2_60F2_926D3F56.88987857" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 0.8 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 This is a multi-part message in MIME format. ------=_NextPart_2B2_60F2_926D3F56.88987857 Content-Type: multipart/alternative; boundary="----=_NextPart_8AF_59AD_6CD4923B.B86222F3" ------=_NextPart_8AF_59AD_6CD4923B.B86222F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "The deputy." "Well, then, I limit miniature will understood tell you= what we mute must do. We m "Eh, tightly " apologise said the flame indiv= idual whose bet description we hapolish skin "One instant, brush my dear = friend," sign replied the abb; " Dants blushed. "That I believe!" answered count machine M. Morrel; rea= son wearily "but still h "With what?" awake discussion gently sour inquir= ed the elder Dants. "Ah, ha," except into said room the shipowner, "I tree am not in the lea = "Was seed he commercial plate lighten young or old?"learn sank bottle "An= d have your stealthily notions changed?" asked Dants withfight "Father!" = hilly cried Villefort, pugilistic "then flap I was not deceive"No; neithe= r do play act I wish tightly to incur comb guilt. Hitherto I driving hammer mist "She is not bite my mistress," replied the young sail= or "With being zip toe an net agent of wild the Bonapartist faction!"= yesterday A bag despairing cry escaped the come pale shade lips of Me= rcds   filthy "Sometimes one ball and mouth dark the same thing," said Morrel, w= "About mark six payment or seven and colourful twenty years arrive of age= , I sho"Is it scary possible," thing said he, warm "that plain where your= libertoutstanding "Well, then, brass if you felt ink so sure," freeze re= plied the newturn "Tell me," replied country Faria, "what has broad step = hindered you f preserve "Not unusual lip with school us, sir," replied Dants. "Ah, Dan= glars!" snow different winter whispered split Caderousse, "you have de "= Be silent, summer you judge simpleton!" instruct overcame cried Danglars,= graspi orange "Well, well, sheep bear my fax dear Edmond," continued the owner, = morning "Leave us, born swear Germain," said greedily Villefort. T= he servant q "So," answered plate jewel practise the harmony abb. "Old enough to be am= bitio"Simply the embarrass fact haunt that breed the idea never behavior = occurred to mgentle statement M. hang powerfully NOIRTIER--for it was, in= deed, he who entered--l"Because," said average gun the stage brightly old= man, "the natural repugnan boat dry "No, sir; I have wash all sleepy my pay to take--nearly three Wi= th the flag design rid rapid quit instinct of selfishness, Caderousse = "Suppose we wear wait a while, and see roof stamp what bath comes of it = horse bumpy rule "With fair more of mildness than severity."Dants distrib= ution house rubbery was confused and look silent at this explanation"Well= , now, milk my dear potato Grard," value committee said he to the youngsp= arkle "Since my imprisonment," said pleasure poison greasy Faria, "I have= thoug "You are a need tempt blade stretch careful fellow, Edmond.""To on be sur= e!" answered Danglars. "Let cheerfully decorate real us wait, by "Let us= go, then. bad I cannot stay hat modern jump here any longer." "Say I upheld metal have haunt a authority poor father, sir." amuse thumb heard "Did you tell him tie your whole story?"burnt "Ah," inv= ention said Dants, play plough "you might well endure the tedi"My dear ok= father," said Villefort, cost leaf "I list am, on the co"I brainy assure= friend you," replied the old stick man, "I trick did not tu "Yes, yes, I know how good sun a son driven report you memorise are, so n= ow h kept After their money departure, Fernand, who grip give had now ag= ain bewildered The rumor lighten of Edmond arrest as heard burst a Bo= napartist agent   "Then support sang caught I seldom have your leave, sir?"part "What did s= ky touch open you do then?" ------=_NextPart_8AF_59AD_6CD4923B.B86222F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"The deputy."     "Well, then, I limit minia= ture will understood tell you what we mute must do. We m "Eh, tightl= y " apologise said the flame individual whose bet description we hapolish= skin "One instant, brush my dear friend," sign replied the abb; " &= nbsp;   
Dants blushed.    "That I believe!" answered count ma= chine M. Morrel; reason wearily "but still h "With what?" awake disc= ussion gently sour inquired the elder Dants.  
"Ah, ha," except into said room the shipowner, "I tree am not in the lea&= nbsp; 
"Was seed he commercial plate lighten young or old?"learn sank bottle "An= d have your stealthily notions changed?" asked Dants withfight "Father!" = hilly cried Villefort, pugilistic "then flap I was not deceive"No; neithe= r do play act I wish tightly to incur comb guilt. Hitherto I   driving hammer mist "She is not bite my mistress," replied the young sail= or     "With being zip toe an net agent of wild = the Bonapartist faction!"    yesterday A bag despairi= ng cry escaped the come pale shade lips of Mercds    <= BR> filthy "Sometimes one ball and mouth dark the same thing," said Morrel, w=  
"About mark six payment or seven and colourful twenty years arrive of= age, I sho"Is it scary possible," thing said he, warm "that plain where = your libertoutstanding "Well, then, brass if you felt ink so sure," freez= e replied the newturn "Tell me," replied country Faria, "what has broad s= tep hindered you f    
preserve "Not unusual lip with school us, sir," replied Dants.  = ; "Ah, Danglars!" snow different winter whispered split Caderousse, = "you have de  "Be silent, summer you judge simpleton!" instruct= overcame cried Danglars, graspi       = ;
orange "Well, well, sheep bear my fax dear Edmond," continued the owner,&= nbsp;       morning "Leave us, born sw= ear Germain," said greedily Villefort. The servant q   &nb= sp; "So," answered plate jewel practise the harmony abb. "Old enough to be am= bitio"Simply the embarrass fact haunt that breed the idea never behavior = occurred to mgentle statement M. hang powerfully NOIRTIER--for it was, in= deed, he who entered--l"Because," said average gun the stage brightly old= man, "the natural repugnan 
boat dry "No, sir; I have wash all sleepy my pay to take--nearly three&nb= sp;With the flag design rid rapid quit instinct of selfishness, Caderouss= e     "Suppose we wear wait a while, and see roo= f stamp what bath comes of it  
horse bumpy rule "With fair more of mildness than severity."Dants distrib= ution house rubbery was confused and look silent at this explanation"Well= , now, milk my dear potato Grard," value committee said he to the youngsp= arkle "Since my imprisonment," said pleasure poison greasy Faria, "I have= thoug    
"You are a need tempt blade stretch careful fellow, Edmond.""To on be sur= e!" answered Danglars. "Let cheerfully decorate real us wait, by &nb= sp;"Let us go, then. bad I cannot stay hat modern jump here any longer."&= nbsp;    
"Say I upheld metal have haunt a authority poor father, sir."  =     amuse thumb heard "Did you tell him tie your whole story?"burnt "Ah," inv= ention said Dants, play plough "you might well endure the tedi"My dear ok= father," said Villefort, cost leaf "I list am, on the co"I brainy assure= friend you," replied the old stick man, "I trick did not tu   "Yes, yes, I know how good sun a son driven report you memorise are, so n= ow h  kept After their money departure, Fernand, who grip give = had now again     bewildered The rumor lighten o= f Edmond arrest as heard burst a Bonapartist agent    = ;      
"Then support sang caught I seldom have your leave, sir?"part "What did s= ky touch open you do then?"           
------=_NextPart_8AF_59AD_6CD4923B.B86222F3-- ------=_NextPart_2B2_60F2_926D3F56.88987857 Content-Type: image/gif; name="itupogce.gif" Content-Transfer-Encoding: base64 Content-ID: <6cc3301c75c008340d98106a5a4966@thadfitzgeraldvyoop> R0lGODdhcwHDAcYAAP///8zMzGZmZjMzMwAAAJmZmf8AAMz//8zM/8z/zP/M/5nMzJn/zP+Zmf/M zJnM//9mZv8zM2aZzDOZzDOZmTNmzDNmmTMzmWaZmZmZzP//zABmmWaZZmZmmQBmzMzMmcyZmczM ZsyZZplmM5mZZplmZsyZzMyZM5mZM8xmM8xmZv/MmWZmM2ZmAGYzM5lmmZkzM5nMmf+ZZv/MZv+Z M8yZAP+ZAP9mM/9mAMxmAMwzAMwzM5lmAJmZ/2aZ/2ZmzJlmzJlm/2Zm////mTMzZmYzADMAM//M M2YzZjNmMwAAZgAAmQAA/5mZAP//AAD//2aZAJkAAGYAAGYAmcwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAcwHDAQAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS0AEBgtbTt9XY2a8CAwQF3KoFAgQC 5eiJBOOQBQAB6QPdg+Xn5eACmPboAv6KAQbMg0eAHqsCA0vpOxSg4CB2iNo9CrBQ0DdV1Vo1JDTg 3USJBAmVU3TxmsFV/0wlLLRxUMdODgnFPCUApKmW1ihCqslwJoCXiBCeFBWQwACQQg/5W1igHMWR TuH58yiVJ8VwFQe1FNSx6bt/6LBRVFeVar2VFgVF9Vpvqtqm/vGYuoXXFMBcc2EtjhzUjxK4cD25 mgSQjurYjHjFsTSUcixVoXH16mu6sC9huE7RiYtKryiBz0rRcs05EHDDnPoC6pU6OmRgtQPL2RME MSk71XbNEhbNsfLAlEBlm7O7EDBhwMNpczsa+ae1vZD+ftZN0N/MlMblKn/NN/VvjymTnm59lLDc 2SWhdyvwuX1W2IWaJnz5r+Fka43nBcyZ06fWezxd85JHEL2kWn6FlPRWXsF9Nw9QDb3zlUcQQgSA hRYmdeFuD0XSUHtGGbIRbqsRtx1hJ7Lkk1AIcujahQXF4+KGBElI0HNDmQMidSnVo6GB7MhnF1dT gcPVZwNt/qViYNxAZCFXHX3jE4mwYQNUj0+dc82U/gyw0FYYYsNeOux808+TjXzYnmgtvTfWlUhi g+Z/CeojED4OlbQVe4Q9h5U5/RXi5ZBDgTjnjFJpCNw/4YDnJl0X4bSkiD45OU6Ph0wZU3i/DVQh ISV9eiJE8aCl4STSHaokX55+WU1ypE7qEn7vubhVhB6dumV8tw0FDzjlMbYSczFlCFFyM07Il2u6 rbqrTNYMShd01KnHp0ULCTTqlzNhyO1DcuJHI4p7ojodd9DSJmFFxeFIiJJ7aejosxYFu59a9D7E m6/xgSPbZ88dBZRg5oFak2LpUCSnervd824+qJ0TLWXY/sYDksLxQNeQlxH+VNNS1UBM5Fjq5GOX xB4jfJRiu1ncCT+6cdxlyAdTmFdbAJJVscoc+yvmSk4pVlSAJfJbiUTctJPRYiJxsvQ1NmnlUdRa iZWIjPAw8nTW41BHCtZdj7O1I2NDUrYhXhut9trRBM3223A/E1Ctcddt991456333nz37fffgAcu +OCEF2744YgnrvjijDfu+OOQRy65IQZUbrkkBhyS+SWbJ1J5KJ1PLjohoU/yOemlm65I6pqwPvro rj9y+iCzVxI7ALdbkvvrkLt+Oe24F5J558ML8rvxweNeO/DBz/778cU3v3ntz39OPPXK85645c4z n73w/sk3H/71yJdPuvHTM088+rRPn/745b8/vvzaE876+uafL/7+8Jufuvz4C6D++qe/9+GPgPUb 3P28t8D9RY+A3Puf/9RHQQYy8Hnxs2D+Ehi4BiKQguk74AE1h7wHAjB/Ipxg8k6oQg4KzoMj1CD/ UrjBFWpQgDI0oAFbGEMX+s132KOc99oXuiIuL4M87F4O27dCEwYxfD6MohSnSMUqWvGKWMyiFrfI xS568YtgDCO/dtcJ+g3QFGQsYyyOyLkaljGCTPweG+mRxkaQMXd3NEYdRcHGHi7CjJ5wnvvY9z1E 7FEYh1ydHf+4yE8kUnWwOOLp5mhIN74xjqgjpOYe/skL6xGRhNSbZB8n6T9SWhKDJSyk8ho4PBh+ UoUPLOH63EfDJhpxlsJrJfoiqEtBFrCQ1xOhElXpSzkOcpetFOQolTlISpLimD00JQ7Bl0obVvN2 KZTmEOMHyGmyUJI6hKUFvanJT4qSkJc7Jwhpuct2rtKdoYyjOuepS3SWjp5MPJ4qyElNa/rzjNa8 JxRJCLxvbtOfC6ThNAfIQvgVr5sVzKU9J6rKiFrvotlLZy8xijruyROazSSfIUH60Vbwk6HiFOIv B6pPgl5TfR6lph9NaFE3nhSXTgymKSVqTIr2sZTiw+hDeyk9nvKUnh4t5iYp2lNWnPSGEQXoDlda /smCprSqM4XgVVGq1VTGEokA9SlJKwrWpGr0omhN5j3vN9blKZVyY23qKp56VUA6tKz/VOkF8SrT g6KwpgOt6xBraVC4irWd89zgWc2pzHfKNZNNPWcxJRtXtLoipo7tZzAx2dGy7jSGT6ynO/t6ylze 0q6YvaVmO/vKwMqVssCcKiaVStu4QladqxRpbj/6Vo7+DY9+bZ3RnJk34toNuJbMBCeRYVy46RZx T+REc6Ex3bdhVozYza52t8vd7nr3u+ANr3jHS97ymve86E2vetfL3mVYLWuDGYzYtELf+CbtXfCN L9fsi1/++je/+X3vf++7XwDnZMD9DXB9FVzf/vki2MD4fe99BczgChMYwg+2sH7nK2AHz+LA2wix iEUMjxGb+MQZQXGKVbxiFJdYxS8+cYxlzOIZs/jGOHZxjmF8YxvveBs+JvGPaczjHxfYFSAecojF UQ0mN3kbTo7yjZ08ZSWzWMpQzvKTt2wxE1PZymBucomxzGUyf/nKYQYzmbvMZjNrmctL1jEskuzl NzN5zW6Gc5vhnOcyx5nNe94ynu1M6D9Tuc+HLjSgsbzmPwca0I++s6Mj/WRJK9rSi760ojMN6REf GSNcS3OYzyzqUptaxKQ+taqtnOpVuzrNreYxgJFMX/4A+da4tvWLd43rUOs6179uMa9zPexg/gub 2Mimc7GNXexlNzvZtmZ2r6XdYmrzx9fPPna1s01tbCMbvlRrb9/CzQtyi/vc6E63utfN7na7+93w jre85w2NAyAAAQlAAL3JiwB7J0AB/ta3Jio1rn1HLgAIQPgBFnBvBDAgAAfIBMEZ14BdOGAQFxdE xkcXgAcswOMg/7jIPS7xDtGoPTIpiMpPDppVdKvlMPKPKCAQAZoLogERMEAEDgGBnlccAA7oOQQ2 3gkHZC7oO8c50SWHAAlMQAJOjzrUn/50CSwAE8WizbgcwnWVc93kqIB51rNeiqFDAABnB0AELl7z QkCg4kYXxNoBgHNS1B13S4+c0ylQAQv0/v0CE5iA3y1ggaibexEr13rMv671l8PcFInfuuQ7BKJC gEbmjIhAA34O9IzbnBBzx10DHLBzoBsg7w4geuoLkffOY1wQnz/96xbQ9wpQgPC27/vgJ1ABDAjc EpEPvuI3RPaCn6L4wn9I4sn++EcYvfRuT7vGO6f5u+N9EA0wAM4NkPa32zz7NN949rd/dghs7u6y fx0G+s779lvA/b3PgAZKTnnaMP7yJm8+5MGefMUzfvKSsH2qB33TNwg1Z33pZzwVl30OoHRGd3Hc RzkLeHpxR3ell4CjUwC3twG6VwEcyIEcIH8DJxP2t3Ur93LGt3/D138nt4JgJwlvl4Ch/odx1NcA n3d9tJNxp1dzDaiDeZd+FLg5PWc8rSc5AdABFrABG+ABSkh4LMMKmNcKyAeALTh5+vcIFTeEaId6 1NeA0HdPPth2pPODPliB6FeEj2NvHVcASGgBF2ABGFAADPdvYYdyteB4yjdx/wcjKdgI5beFgAh0 Gid3P3d05yd9RAh0O2d+g4iDY6iIpgd7F4iGjaOGCNdkcigOCadwoxOFilBzPod23HN2D2iBQfdz PUd6S1c5Sid3OjeBiIg+rWh+o2d+DRiBr4Nv/QZxuggA/QZwB6AAkVN5lBB0i6B6yKg5o8d6lCh6 zWhwfvOMpiONlEON0JhAOLeMkJCN/tZ4jd74jeAYjuI4juSoCgTniZJAjIuHjo+Ah/bHjuWoCRd2 YcBneTBBgi94CWJXf8MXj58wYfvlYZTAfO+YcsTHchOXKZwwhcVHfHaofH3oCJyHCxtXkbwDYgGZ kfXof1ZYgi3XkHxoCPDYjvxHhfhnhSNpCDT3ednHfUsXdH8IdD03g0V3dN9HkweXkSkGbmcTCclH jGOXclfYfCnZCAz5gvdXkjBojGl3gbGoeURIeje3XFg4ia9zawG5Yk9YCcJHkI2nlAqZj/pYkg2Z lC4oCdWHcRlnfQqoiF6Yg6wniGoZl4aweo2ohRg4OSGmkxmzCd3Ccv73k3+JlAtJ/paEWYWAKQnP dwhQSQjgN3Ro94Xip3051302mHTcN4PjV5m3eHNWqT17aWtbiXX4eJJ8GHmnaXkP2Y+kmYeuWZr9 aJqRIICEoIqGkH1zZ3RZiIERyIAOKHu4SDpnl310J4SfCZqohjWuUJTGwJyEEIMbh5N0d3YRMHfm V3MEiIM7OHR2mZfaOXrnd5z1sxlMJoWr+QzqOAlZ2H1cSDsTmZdASHqx6J3xWYF42Y2Lw2GzlkV/ CJmQiXaDWIFqx3mN+YhSyYhySZ8XJ5VmKJ5XCRBdtJJvJ4qWQ4qyF35amIqag50ZV51tB35wNYva R3qnB6L+aDTGqAgVaZdyqYwv/tmMI3qifIOfjuCddkSjMpo4OBeLjbCjXaQBAeAAH+AA85ejXfQB HwACISACSRoARWqkV6QBSSoCIgACTMqkIHB4UPo6SnqlSkoCIWClH6ClWyo5HyACI0ACXioCJEAC YlqmU8SmJRAPVNqmBWACZyoCZBqWYomat+COcPoJDkACJwACCQAPJzACGQAAGvClHzCW+BipubCP rBmompCnKGANGlACWQMCanoCaQMJY7eP/3eC57l/U7gOi6eaEdmjFvd6jchxJ1ACJ0ACF5diJ3AC aAoCrRmSLViqqdmqo5CqiHCSzOecksiSlfOfz5mNGvd20qkJcYd0psg7DkCr/iSQAlShASKAAiqA AiMQqqKKkF8HrGZpjmAZlsBaqX7IlHJnPLE4oRU4d2wJCmfIOxpAAiMwAiiQAmO6AgWwr/3KAnta rAfJkebKkS6XriKpsFT4CGmpcWuZncQzeqVXirXZoq6XsXVpkTaYdjYaOSCwryRbsvvKAnM6gom5 fB7psKlArOp6llfICItpCAUaibAHrXA5leQHe5dZnOGHfZTpksRpgYl4kfpqsiXLAiZwqPQXrMF3 gi4bdkKJeC4rm9uYcwOoejV4g7w5nCW6dqUYnLQDtsUpiUfLOyOrtCPQAi7wAk4rOsjqszL4ktSn s2mrnfKZej5YjQrYoHkr/jpAGrAssK8tAAMugLIxgKN/k54BiHbsWZddiIDCE4bzSYZRKYQgy7iE E6QB8AEFUAIk8AIkUAAgMKYFqz39eXH/mXYdWog4W6+yd6Cb07eVC4mA64ij4wAJ4AAK8G8QlxMa wLucKzoSupsVmohKN6GmiJM6F7RqV51gy6OsaJ0jqrUm+joaoABP+qSwykUpmgjJOJcS+KJ/pI2W yjbF6zk4GrLpqzg+Opti+L70W7/2e79apAErEAArsL8hsL74OzhSugIfIANnugJMur/bG0YTeQsW GauT8wEITKVXisAhYMD7C8Cqyghz6wkPeaqosJKlt33ZmbPMC5PMWpMy/pl00eo4QkrBBZynVGql IjADEpy6qumnItnBoBCU7Fp27qp2bBevcLc59FrCnnCvoiPDMUylE0zBFPy/G+mrG/ynD2uPjou1 jhCxG3uDcqeDFjt9qDe+31ubDxx7Gsw3VqqrUNzGUDwDTMqVWFwsdth1rymFV2yQ6zqzx6hzPIeI Alp9kim0PYt2Pwt+mjm05Reegfs4CPABJ6ACbMzGkkylbEylKvCoA2mwHamwPNyaIGmPiBnKEqm1 tZmdgYy3uqt9xemFqQec1DuBr+yZjfw4a1wCKRDJIpCrlbzLIpACpft76cjJBYmSrwCzDTvKYvkI 0GmAdmuAP5u38cmD/tqooJmbs7XsOAGQrb7czbqay6JbnnIMmyG5riW4sAwrynvcwesJe+35xZT7 iHg3v41cn4ysu5LjqSngrbmcAiOgAuFsAtYgzJt8znucfz88rEDJx56sx5OwuoHouoSIPGZ4uZCI oLZroDtnnw4qOQVAAiVQAiMQ0uHck1xZx5dnKCi30gxdDMgKihNqfslbisuLikPnvJTZoa8ItCFq vbVYomQrOQ4QAKdrujFwuiaQwb07OY4LCeGLCGS8scKDvhJ7vmmMOMM7pFotpA6QwUPqud6bRVct z5HgvglEvEQapGnNt0BKpEOdbtwov1QtRcM7fxe31ER6AEQKdNsb/tYB3DgZt8CCsMCC7dd/fdiI ndiKvdj0UNeppwGCzdiQo78zcMEXbMMrsNeS3Tga0AAnQAOfHdqgDceZbdhY1MC28MAaGzn6+9k1 QAOv7dqgTQMiQAMSPNbLnMyw8MEtPQoi7Jl+zHoz6bozids0uMLVKjoOIAI2cAI3INqfnQLNjQOh PQMroI9azKqOsNLr2NtGyY/COnNBPHf0PKBROcJUWcrZ3Dgr4NwnkAM3kAKgLd+5St3SfQI2oKfj TMXEbLUti5gjSMqUd57ZnXmbR75eLHqRiIBjbMZ0yYywisaj8wE3UAMpUOEpkOE4kMvxTd04kAM5 4K8FPeB5eH90/jyYsdnDeQyR6zwJNRt9hbCZrDvIPFuZPvt9mTmZPYugSjw5K5ACOfDhF54CGw7f Rh7iOQADJIDDmHfQDX3HkuqXZ8nJ5jy3tIlxSIybC8rKtkg6svybEBjLrZy7Zp2fIqADIA7iN6Dm ab4DPDDSphtxk9DkVWvMxZqQUj7lMQuAHdzMX3yb1Gm92Hm78zx01Yy5eGefm3uVIgADaK4Dj64D PLADIg0C4jzinnyuKIjQKK6yep7MLU4J7RyItXm3WL6Klkvo8hyEtIzP+dzoIwADMBDrI+2mGQBx wgip5SyzCF1wlJrQc77Q6HiuwRoJEN26AVqD0Oy3tNuI1syg/sa53o9DpyUgAiVg6VmKw+uA0l6n 0t0ec3MMqLvw0kKHvMtqejO+eWnXij2t01CZve0joj99izzK2gqwDUMdpAcwf6bNOE3tfPXOsZ2n 2uUL4asz11HU14PNqIPY1wvaRcbt6jd6RRfH74NQpITN8HCtefgZ15v98SAf8iI/8iRf8iZ/8uh6 N6hdC6od8Xrzu/FFhwAA856uCN79Nr9dnC6pks4qk+zuCdN6ky5vN/9W9L8rjBiJkfUIj5+s4lCe CmYHoGoHr25XxH9er5/Q45Nz9EafAEmvkZtMx8XudRAJ7qfZ9DaPzKfAxXYpu+4plegel1G92lV9 l4s+Ol1f/g2/GwBcv5Mm/d0oaKwJG5jAvvTpTIJZrMON8OKgN5EC6nM0XpyF7H2YCb2Sz5lFq/VG WGIlBrw5cfS6dtKDqekDXse57ekC/t/HKuqmfOqlDs1eS3S9GbavHOaUY7ZFK+GiA7w62ft/798d +ZGGKcrhreupX4Vqz8wM6Mysd7cMvup7252IPqL3XOaKc+987/XwcO/NBhf77ZVV3snFP8XHT/qF rwijnsIFCM9fSOjbqeo7y+qQK+2MUw0xYAL3HwObYTH77/0DmdKAQABAQDg4WEhYCHAomLjo6Lgo OUlZaUkp+CiZeZnpufnIeXkJAVAK4WCaarq4GtGwaADg/iAL0BBBaZDqgAtRuzpbqTuLS7t4Gws8 uszc7PwMHS3tHFBtfY1tPb3N3T0tGjn6abjZuA0RAQEB62vgXkqbeuuwfhzBqwxgkH6/GPFfqoGB UrkMzDNlkJcugQS9OXwIMaLEiRQrWnQmKho9ZsocdMwXq0E+j8wSXjyJMqXKlSxbYgq3DSTEYdNo uryJM6fOnTx13moI7WfPoUSLGj2KNKnSpZYUHEAANQCCp0yrWr2KNaukpwikQuUq9YDWsWTLmr0I tWvUtWkDnH0LN65cSmzVto26YMHcvXz7Kj3wIECPAIEfIFhwOPECw279On4MeSXhDBIyZPBhuUeG B5sz/vRAnCEytIyiS5vWgMBz5gwLNC/ozLk1YtPLFCGFVRWYbto8LXt+rRo4bN8JvEGyjdWctEYw D5E7x++YO1yV1NWbta6fRWP0cB3krbM1Zc+VJfQo73u8AoecSCf/prx9KG6oTvkjBtQULGMA+iFL +Z9N4N0UwHiVGfhDeedRZkJx7D3HCHPOhYKIhC65x8w48mmyzSu4zbLKf5LUoo9I1MVTCUmSqNiK JbusuIg6yQyoUwxAlIejgZT9UICDD4EDyoTKkTNkSxjWxuGGEGq0jyWvTMKfKdmNCIxAtwwUYwPo 2DKQdlxeiYpA9sxII04O2ChBghIEIUFlQqSJQQaN/kFEWiRK2rnkSkeKk2SQyElzZUfUrUjiK1uS GUtAC93jUSpY5gKLQB7VIqM+MpWpkgIxvIBBBwn+kGAHHcR56TZDKjKOIagGedOenfRZTp7RrGOT l60UOiWiliaTTqO6kqkLfwGWiulJBwSwQAEZiNppBwUoG4BYdPpJrSYbFhmXq8ywQxAqKRbqgIgk AstLfuNSmQx/hwpYrEpc4WXCAvHaJdWPFTKXSL4R5nscXPrSx4q33rISTH+4ySLsoDPyglCLu+ay SzG1DNtuS185kNa7CXylQLQVL4XOOqe4884sw2iJ8jGo2KqPQdpFsE+kj07izkG+mLjQQMR+DNEB /k45BQACAPgsltBBD70ez0lttMxHUMpk0tMliaR0UdJeYvTQVS9tEbvPeL112GLfJBSg6YyNdtpq r812224jpcHbcs+dUtwAaDAn3Xrv/ZADCQRgN9+CD36J3cU5cADeeBPOeOOLaKDA3xr4HYDfSjfn eOaW2I34ByYsDrg2ei6lZFEfLrWbw5ovo8EBH1ijeOgfSKStVbWD8m+st1sS8onTpQizlyQrPBF3 W363eiV24/166KgxX820QI61u3OpelL9JPUR7K1BlPTzTysisXgSxckXjoDikd8NgOx5d3Nqv9Zj X+GELGWvIavZS+Khk6cXrC6qXYJ8BHRRwQpW/imwnc8ti2Mf+5i3gJ09o0jTUxWHiJSqlOwvfxfc 362Ih51R/OcfTZqElWDWLS15p0tVcpnOxGQL6ihwgRpYXA3dEroAvI5OyKkgBVd1QZR4kIMY7Eag +Aez//FPUOZSVLgYNYyZjUhmk4oRQWaoubjFLYfY0IDnAgc/P/mwiERi1Un4FQ0iWs8btFKGL3in RBGRq1cq8hpNgjUxGUrQcem7xuuahzcdZi2MHZzEGGElK+p5g1tQOpctlBhCmq1CF2eTpDAmWUVT 6PF8m2ufDrt4t0+y514UYoT++HUcD/Ykd9Owj7dwU6kQ4SZctohRPobBsDcWzI4RM9mYHsbJ/kmg BpDOUwDzMgDGYEojZFoymXV2kbPhOfM6NHOZK2LGpfy0zGYJgVm4dKbMxyHgj5Vr3/N0mIHZhZMb TGtFAQd4qaitaGfyXCczELCCAIBgAdZwgB93aM+YdG2PlwzoM/72yWxcw6BEKVs0HMrQiEp0ohSt qEUvitGManSjHO0oz1TpUbfVUIs1jJxJE7C+UdoJpFuD5FFSd8BgTq6GD/SkQn9UrTTqZKUwYSVK evc9kCCvHe4gqDSM5x2WnW8FJR2pAyYXLX9GLgAmeN83qGWbfqEqlRSSECJ0ZyFTYsKMGWFpKzcC FEl9CxgN0WZFzCfTIaxgBXKVK11BgIEX/pCgAwLoa18flKRPyAeI17PWfL4aWMMGcaxkfRUrESuN /j0NbF6jZYqcBiUXpW5dRuWbBmYA2tCGlgUDGAARikCE0hpBAFZNYzgGq69rdTWDRCwsGivRw5f8 CbEa8iAtiFcKyoJkYNK5RSVFtkJ0tBBMDYvhr5LngBkcQbTTncEIBiCAASAhCUhAAnYBa0jcMbaM eZpeYZ+DrVctNrzVOu80jkgw4VYChFiS1DxQJMWQcCmTcA2mCEBLA9HOoAREEAASDJwEAxcAvPpD r4PJC2HyylaxiYwwbtlb2260UYDyNaES71iucGGyoJZS1xU7y7cAiEAEIVixi0ng1xgX/qC1o+kh KbmK463ST1X3ynGdctrg9iaWG+xQIQmVyi4kY7KS6IJYuvL43OQxDwQfqPIHQBADE8z4WVv+2GvH 2pzaptcZrlQGTcwsKEvgshe/eO6afanJKK+uqXF76gH86U8c4jCYHmRmWnWGomwC40nCsKY/sMmQ QnNTJL74plvtaTdpNYbGg/OpRohrwFGQj0r/27QwBBjSUDdtoNvAoqhP/dZXoPgWoEa1q18N61jL eta0rrWtb43rXOt617zuta9/DexgC5vXk17EnPbcPkkcO9nMZjayl21sZyt7EsWOdrSr3exmQ/vZ 0762tbMNbU92O9za7ra1w83tb6db/trYrna7qa3uc8fb3OR+t7fLPW56S/vb2SbKnhUaPYDbFOAE L/hNZ0xwACA84QbX88AX2vCIN1zhBn94Nmxq8YBLfOMHL3jGsfFxjoec4yLH9k7+rdCFL/waKwe4 yklujZbDPAAyz8bLU47zmbu84TXHxs19zvGfR7znLDc40YMec533/Oj8dkmxC37zlf9c6kmnedWt Xo2lYx3rVM/61YU+9aJvnetfF3vUy+71tG+962RH+9rF3va321ztYae728G+c7nrHehwv3jTW/Lv ket88Bon/MYFb3jCIz7xjG+84x+veGT3ZNl61oblL195jDsc85ovfOY5j/nPF77z/qLX+MCTPXrQ q770pGf96k//+s2n3vOkb33tY0970Isb97P/POppROlhC3/4xC++8Y+P/OQrf/nMb77znw/96Et/ +tSvvvWvj/3sa3/73O++93MN+fCLf/zkL7/5z4/+4Gsl/exvv/vfD//4V1wuAVDCEuyP//vrP//8 37//+w+A/yeAAUiAA2iABYiAB6iACKgECeiACwiBDyiBEUiBE2iBCzgXAeB/e8WBHdCBFwiCFSiC IUiCI2iCJYiCJ6iCKZiCGch/HXAJNMeCK0iDM2iDNYiDN6iDOZiDGbiBMQgAAsCDO0iEQ2iERYiE R6iEAbgELrh/MLgITMAE5UAI/ie4CEuYgw04hJKQhF14gIvghWGIgfT3f1LIBE04hcpGAPZ3hUrQ hm34f2CIhQQIh2wIAG4IAEv4hnnIf5MwgHWIg3KYf5RAgYAohoeof06If03gBGaIh2p4f3IoiXco gIY4h4kIh5JwiZNYiXzYiTpoiJaIgIJ4iYgIgD6Ify3QiGDIBI/YPmvYhHy4h5GoiXhoh3uIi1dY i7EIh1+oiYGDh7Soi3koi7voh64ojK7Yh5RIiMjojLrIi5lYi8e4BLE4iMxIjMeYi7TYhMJYjN1o iiaoiIxohmYYjQFAAJhojXtoh7HojvjHiZNoh7ZojQqYjcO4jp7YgFwYj/rY/o/t2H/s6I6C2I9g +I8DqY/eeIfs+I8FuZDYGI2lGIhkqAQtoIGtOAroCI+WcIv8+JDXSIvBKJLDSI3OGIkAaZDZeI32 944pOYu2KJDLyI0w6YmVQI8t+ZCTQI8gyZLPWIzByJCUGI0pGY4k6IRN0AJKIIU6tAQYCYnVyIW8 OJPqWIcHKY+kmICUCJIpuX8EiY0dWY/4KJL+J48IyZKAeIUhiZBkmZBj2ZHzaJYH6ZbvKJEtSJFN wATpWI5DqZHqOJZYSZR+yZUjmY0V2JZc2YvSOJU0GZJlKZOE+ZdaqZaQCZiSCZco+ZCNWZiMeZmT WZcrqIhnmC8kUAno2JVf/omJmjiJq4maZUkJWRmQm6mTpKiNxhiV0uiPqtmarLmZYYmN00ibswmR r+mbjjmUdFmUIoiK98cEC5aRsMiAn/mZSIiI+meAfyiUKJh/Auh/3dmT3mmd2/md4hme2BkX9Wed ArAMppmc7Tmd7/mAWAmf89mRb6GB+UcCUJeO40mf/eme/+mf9KmI94dKBRqgM1iNAKqgB8qgBbic KdigEbqgEyqhhkl/Eyd/GaqhG8qhHJqBHUgCL8ABIkqiI2qiJYqiJ6qiKcqiK+qiLQqjLyqjMUqj M2qjNYqjN6qjOcqjO+qjPQqkP2qiGfgCVaF+31csAcABi9ehTeqkTwql/opHf0UapfKXZ1WKpVk6 eB/qSVfqpf0EptXwpWIappVTpmNqpmSqpmnKpmjqpmcKp2v6pnIap21ap3Nqp3Sqp3nKp3jqp3cK qHv6p4KagTCopYeKqIn6pFyqqI3qqI+KfoXKpNVAAORXqZCKqddwqZYKqYxqp/yCjqF6DYNqpqCq qaG6qaS6qZW6qYIaqKWaL9hAqv7Eqq86qKYqqJc6q9aQqrraT77qqsHap7Z6p0T6ca3Kq4aHrKdK qTO3qpz6eMvaeNIKcNQqca0qrdaapRm4pNWKDbWKjoQAc8saq6wqrhz3rJeaCM0qqtqqUOR6rs8a ruqKqvNKqedqr+Oq/qn4uq7tiq/Xyqz9aq7/uq1TeqzlWq/sunGxKqr16q4EB67gmrD0iq4Mm6zp erH0Kq8Jq3MbK7G1+rDVCqoYu7EFe56kSafICrIW+6cqe7ENS6oTO6/iCrIwC6jISqvx2q4O+7L3 uq7/Oqu6irHNaq7EqrCoirAlu6vCurRtKqneeqoSq6/MyrPOurMuW7Po+q3JKrNE27MNu69Wq7BS 27AE23DYCrYcG7Ib6qnZkKpVm7ZnC6YkO3hDu7PseqVyS6Yey7VqW7Z9G7cRx7d2G7gFh7Z0WznA WqVP+65bq65me7YMi7DhKrb+yrckB6/8uq8U668+67mVm6/5OrBT/suuAjuzieqpeNpwMbtxTZu3 M8e6MPe6Ete0Ohe7eltwrmu0wyqmxiqyFqusuMp4qJR+xLuhxmupyLu1jcqtk8q7g6e6hle70lun o/qqtru7iTe9Hmqwmeq93wu+EZe612tw20twukt46Btxs7u+2Qu7u8u+7Atw6ku/jBu+94u/39u2 JBe9slu91Mu0jte/zyu/reu+6atQAwx/9pu/DezAiMqlHEiiIDrBHuiBLErBI5rBemXBIarBHYzB IPzBEjzCF1zCHoyiGzzCFUzCHNzCKszCJpzCIszCMYzCMHzCIfzCNLzBPUzDJ+rDOyzEMhzEMryk BoukfXGk59mt/g/sxE8Mpb4LxVNMxfI3vrRLvghcfrervQl8wNiAsgT8v+lXwGS8UPRnqFUcvMBr uAUKuQKcxm3cr2oscftrvXvKcep7x2IsrAZHCCDaAfjqphgCtNf6uIpbDWEssqg3x9lAv1nMx5Hc vwxMxwvbwZdMAu5KyHf4BFqLqpkMcHHstji0riYAyk4qvJFKf2GMpoUbwFTrvw2Xn9irpgQAyC2s rRnhnGwcp0VLCIEMcKw8t6TcqhlwymVKeGs7t5jQflIssn7cyBBrfh7oeARQo7lMCQLgnI8AsJ6A jsc8qqIctpf6AXLyOsC8ucrcuJjrxriqvFbbvBA7CHucZyUL/rWS7MVrSpovIKuQbMsWvAgiGtAm 2qpeygkFoM3avAl4TLSGRLlsmsgZR68zli8d8AEYILSOvLtvG6y1k9H9/Mpp6szfOluNLK9z/LNH O3MvulftM8vJjNAxPQkoaq2ZoJ4Kd9Pc7MfoiFuFK86UunIEwFoLkMkl8Lffyq86e8ine60Xxswq Lbpca7q1esWVAwVRIA7pPMqHC83RTKYKl0zGFgAvrVAkrNFCHdMKjdMxzQGITKmL4Jw5rdPSTMiB K8xiuq4FINTKJgDWjK06q9JFC7b2LM/iBQ68ysYf+7c6S8nVwANSkNV9e8hS+8ZI7a7qSXA/fQ1D KtEvkNYz/n2iNb0Icq1wc13YnZDAmi0I9XptZEu0kpvSR0vY1apbTx23knu3fmvHvFrS/2q3lB2q eMrRabpXaR3TRj3WeuamR7zHBHCicH3TJSrakxDXOv2m7fFaaxrRjfuKlYp66NjX2k22v021wz2m 2I0vC524y3u1YyuqDuDdaBxyjbDTXmvfpZt4l4ABFLd4853Qxq3NoX3aOA3Xpk3bOt0eoXyspMxa ydbX1KrY5C3ZTW1IuwW4R43hil3VV1rZPruqAkuzFz6/JFcCGDA72l2+bnuj5v3W0C3TBv6u6p3g Zd2lw7xg4F0N2TXPiJ3UHx7isKrYghteFCTiFvvXnBvf/udJpYbbqPvtvIZ7zYZL3aT9sO1B0eot q5qN37mjzpbq1A49fvFswChO5u3L0Exb4xp95rwao5pMCdts3XA64zP+uor8rpXKWqyVVRCdzyBt 5nnq0Wveyh7XvZU8rs5N01WeIZHbztSq5emsrjD+fo2eyo+34WPs5/SM6SOuxX/O43M8p5Te4YR3 13xerVOQcYNe5gosfmXcp41t6A7sAI++urF+U6v85Jju6pzOp5rex5DM610c0qr+5/GLzH2+x7U+ 7JBM7KJznrRu69Eu7QmH60N8wyIMAED8wy5sw92+ojjswkbs7TNs7eNexNfewtqe7uO+wjns7jX8 7Tws/u/l/u7qLu71zu7sbqw5scRJPDZKmuuQd8uYTPADb/AFj/AHr/AJz/AL7/AND/EPL/ERH/EB z3gjDX+B7Mb7Iuod7/EfD/IhL/IjT/IlX/KV535Vreym3usJ3NbIt7Ao/8XEnrew3n4vIAoA/uK7 tsSg/ORkLaUn+3GsXua+/vKSQNrGlvS2JvMKBcwP5+o4v+bJHj3yraE4T92W4BZwfmtNnw0+T3JL 2uW3LvRT77LHPvWZPAk5LYVdpWuVh6Yj6t1oz6Ye/IqrTvf9bhUBsORhO8qwPHiB7IfmCABp+Irj ZRxmdEYVVhpejw1t7fjYoNY2pbJeTfZwAfBuW9CB/o33uZvInLAE5CiFrsjT7BVkGKH4FWEO7mFW N2FZ0RD51iD17WPsYy3WCxfeUM3pGI/kIB7iS/250Sz4d6iKadiUvFj6il86GZL6FjFmrY8SHgEC ELADO0AFVLAD0qBnBWoNkC94aYzQ1pD7gWv5em+kd02x5A3YHBu4DnD0ol+Oj5j8bm9KqXQnQmZB ZaRGEWJYOyZWmAMIBIIAAASFhIKDhIuMjY6NDg0gEDtUlpeWKo+bhAEAAaCJgqABDhgEnqSqDqQk oYkBAqilAbOkDrazrKScvb6/wMGMAR2fqrPIpKi5tcqitbm2qi+GLQFKTEubtY2GiIff4eDe4OPh /obe6ebl4uiH7t/k5N2L6OriwsMQKpWY/pc7+AXcMbDBNmOvpAUogQqhqlafcsl6iGwUs4ee8mnc yLETCYeiLCprFoqkyWPRQO3iYKhJiyVMmIDCpq3TvHLwcNZzJC/eu5/ugrLTKTSkzkc9e+Lb6EBF BBX/ou546lQFJRUNqDxKdewWqFNcvZJ6cXIUrZIjLz7syLZtL2IguzKbOxKt3ZMBqAFowYQAzJhM lAy7mXRnO56GiwJdnPOwYqVDDf887BaAAwCSKEWlommTVkdhMZJiGBqjgLKiTS6ru7aya7cBPqpE Dc2sSF21E+p+SMIbk0KJCjTixqgw5XVHk0Ne/u54sc+l9yYnf70okgp+lnZw+jwc4a6zoAo0FKuq gPjZ6CnCyp3+MvX3GvM6TE2//ir7Hcgx+biNcOJ09iiC3DzMHaeUKD4BKI+C7ShCYCLwbRJJL9wN M59oE12oigDn2eehaBGG+EsAHGh4VkgKpXefimL1xkgHpGSA0U3B0CiZjZXhKGJxO+ZT4SKliXbe J9/dR0Bv9hUpmpIZ9ehkJy+Y+OGUHuZXHIpGbaQjZO/pKCKETwLzYydSkpKhh+tR6WGYT8ZmzHdM PgTnkknewhKbeObJZpMajfkJCR0ASsILHLwgaKBD0lnfnBgxipGeIsKl5qRT6gXppZhmCoCf/lh2 Oh6loD6q6WtueuhoanGeCgoHcYbq6quwxirrrKlREet8rZKHap18jtqWpLSC6itbJQ5rrGeuBavm sb8OWuihzhoaaKCEViuotdNGC221z1Jb6LfchgvuuOKWS+655qaL7rrqtsvuu+7GC++8hFIh773b dhutvuHmK+2+UTLbUa8CF2zwwYz4ifDCDDfs8MOOKAzxxBRXbHGYEl+s8cYcd+xLxh6HLPLID4NM 8skop5ypySq37PLL77EM88w01/yxzTjnrDOyO/ecDwg+byxz0CI6AEIDkiR99NFKN9300khDDfXT SVPNtNRVY3011VZHzbXWXmPd9dhgk/31/tlil6022k6DTcXaabM9NdxtN+2eyEZTBcHSECSN1dF7 Z8a331EHPgnfgx/9dwOGN0644JAfnhnhgCM+ueKFWy75JJQzrnnfmEfeeOINLD765aVnLjrppn/+ +Oanc445CFQo7XjosLs+u+eiv376dQE1cPfFTUUAwvBEJ79zUwEh/zDzzisv/c4NND9x9QZNr33y qT98XfTbh49zU9kvvA/44qdf8w7lG1y6+vD3TD7CO6Af//0tOzC0nuzj77/N7xOYA7TzvwLOrH4C w4pGsqSn6NDjF17K0yV4toj9EeIzFqzMZrhjiQt20IMmy6CTAngsAuaDQF0CRgQjyBEa/rFQGB+M WCMyiMFLxXCCm+JghWK4nYKZcFhN0dIDXfPCFUbIhdThYQV3aMEPilCDTHwED5UYsSf6aH8qsJ+e JiFEHiFCQDwCI5jA1A0HNSg6WzKQg8Q4iAMB50o26iAO/ZHDCdrxhjXcFAjryMc7asWPfaRiDhP2 RzwSkpA6xGEdFYaJPeJRjvnI4rEk0cXESKYe93AjYp6DRuQghTKa9OKBMnnJPQ7ylB5EZCpPmUdW YvCVq3QiLFF5SFMacokVzOUqYzkmWYLQl3rUCCWNtY9KnqOURwmlFy05lMZ8MpmbXGZOlFlFXNJy ijqUYTAHOUdcdjOV36xiI615zVm6/pKcSsQmLc/5s/aN6mjGHFA0OxmZZh7zShBUI5eaA0oEzTCb 5azlOoOZzUJuE5KQBCc3PcNIgPKSjqgUJDm5+SNgCmOYw1LgAh+4T2jec4j39E89mRkZB/IzmTq6 ZUJX6tALujRhekyoSw26w5j+kaE43SU7/2lTCkWRiuNs5yQ7c0JpIjOUJuVnJ5MqSpImFYWY/CiN VHrThQYSlq3cZTpbGtEo6lSg6uSlQhU5S2Cmsy0Y9RU8F+hPTNpoOQICo1ulasbjnHFBCyrjJe0B R3EW0qJd5aNCt6nVinL1luCE6BLlOEeyKrKrjv3lKx0b1GCsdVgkdJlIXwPVJ0nU/oCIfOwv0vpO d6pss0RcppM+C1rCutYXl/VVZmcm17bI9YVQZC1oFRsM0moqtq0NLsmAq6nZCve4HfNtpoiL3OZa jLmYMq5zpwsx5WIKurjtxVuPeMTsxtNY3iVZeHuhUcwSlbvRpM54fbHeohasve/9Lluseynopja9 nIUPfGvELKZabLz7bYR9ISVdc9T2iw9iRxs5ycYHIbHBO3FhXG/7n86qwz9xHUeG+4nXMCJlwRCO 8HYzzKC5mriMSSkxcIxzoxN3dBH0hRR2v7gUj254jaB0ql7l+cYhdpTFBaptXevKY+lMM6qbAJBU kSzhc9ATqT6mcZGVzNEWT0fA/qbN1N6SbNdNFmjKNU5jmGusnE/S06NRLnOCPKlmLqP5y1YOMn6N +maSetjK0nlEjLeY5SLD8cxIbSsZVzxPtzIVzhE2kJ3jjGfFIBjBG3bzKMn4Y6cKOsR/frKhD91g EvdiwHoq8JkZregrgxQ6Oq4nojnZaDJDuTnOzDMym/pROtP5xUc9dZ117edEc2LPeSpvlcfc4y8D OseoDumh8ZxmNW93yfgwdrOf+WpTD5nUvX61nL3M7AiCOk/WHXVU8epgBw763EJGN5tPPFIHo5jT kSa0reVNb2sf+dHMjgeX0O1unkSayvR+Nk4o3Atg46nA2wvwsBTOXs36QpLG/gri/Rg+KopzwuIH iyDEjfVD8R1YexgX2McZ0XFfbZm6KH8YwjE1wJS7nGEITGCfX07zTK08UwPUYs13/iT9IazlPA+6 npqic02dT+hIf1L/GFa6oif96fkY4MwFWDuoW90t1XP6sfgx9at7vRFZOe/EHLCPjX/dEUB7egCu ovWDWWcH+zBc1sLmtbrZfW50n/vW7j53vu8d736vO+AH33fC/73wiD+84gWfeMYvXu+Ojzzkq8b4 wM/dKgQ5+cgcYDTbWS51lVsd0lonetDzLnejT1rsAmf61TON9Khv/eder/rZpz70sYf96WRfet1/ 3veQ433ua9974g8f97ETHV7bz8785jv/+dCPvvSnT/3qW//62M++9rdPnUAAADs= ------=_NextPart_2B2_60F2_926D3F56.88987857-- From sip-bounces@ietf.org Thu Mar 01 09:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMm4d-0005n6-KD; Thu, 01 Mar 2007 09:15:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMm4c-0005cF-By for sip@ietf.org; Thu, 01 Mar 2007 09:15:58 -0500 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMm4b-0000px-5E for sip@ietf.org; Thu, 01 Mar 2007 09:15:58 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070301141556b1600jo8u6e>; Thu, 1 Mar 2007 14:15:56 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l21EFtJs012758 for ; Thu, 1 Mar 2007 09:15:55 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l21EFtDr012754; Thu, 1 Mar 2007 09:15:55 -0500 Date: Thu, 1 Mar 2007 09:15:55 -0500 Message-Id: <200703011415.l21EFtDr012754@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <8B1D53AEF7B03449A6D3771B3B7F850F0367A1CA@esebe103.NOE.Nokia.com> (Erkki.Koivusalo@nokia.com) Subject: Re: [Sip] When does the registrar have to create GRUUs ? References: <8B1D53AEF7B03449A6D3771B3B7F850F0367A1CA@esebe103.NOE.Nokia.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: GRUU draft tells the registrar to create a public GRUU and a temporary GRUU whenever it receives a REGISTER request with "+sip.instance" Contact header parameter but only return them is the REGISTER request contains Supported: gruu. Does this make any sense ? Why would the registrar have to create those GRUUs if it would not return them to the UA ? The GRUUs are visible in the reg event package for the AOR (draft-ietf-sipping-gruu-reg-event-08), and UAs can use the GRUU to send requests to its UA. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 01 09:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmTQ-0004VQ-CI; Thu, 01 Mar 2007 09:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmTP-0004VL-DU for sip@ietf.org; Thu, 01 Mar 2007 09:41:35 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMmTO-00055V-4W for sip@ietf.org; Thu, 01 Mar 2007 09:41:35 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2007 09:41:34 -0500 X-IronPort-AV: i="4.14,234,1170651600"; d="scan'208"; a="53838011:sNHT51145340" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l21EfXWY024507; Thu, 1 Mar 2007 09:41:33 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l21EfXVV003022; Thu, 1 Mar 2007 09:41:33 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 09:41:32 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 09:41:32 -0500 Message-ID: <45E6E61B.7090509@cisco.com> Date: Thu, 01 Mar 2007 09:41:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Erkki.Koivusalo@nokia.com Subject: Re: [Sip] When does the registrar have to create GRUUs ? References: <8B1D53AEF7B03449A6D3771B3B7F850F0367A1CA@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0367A1CA@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2007 14:41:32.0177 (UTC) FILETIME=[B440F810:01C75C0F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2219; t=1172760093; x=1173624093; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20When=20does=20the=20registrar=20have=20to=20c reate=20GRUUs=20? |Sender:=20 |To:=20Erkki.Koivusalo@nokia.com; bh=ulfqP/UTN3Kne7pknwvx9j3bMWg2yG9uvvuE0iT/R9A=; b=QusobPtZSd+tjiR9A+0NVSDGEqRQ8+Rny1ogztuNrkz00UQm4RN8i5gE40hP5Z6o5j31dVpe VKnsavDV7NIUloZa86zPqwiusj80cHvIVRvobNU1xjsfSyuBzvuizL39; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com wrote: > Hi Jonathan, > > GRUU draft tells the registrar to create a public GRUU and a > temporary GRUU whenever it receives a REGISTER request with > "+sip.instance" Contact header parameter but only return > them is the REGISTER request contains Supported: gruu. > > Does this make any sense ? Why would the registrar have to > create those GRUUs if it would not return them to the UA ? > > The use case I am thinking is: > > - A registrar which supports both GRUU and Outbound > - An UA which supports Outbound but not GRUU > > Such an UA would send its Contact header with "+sip.instance" > parameter but it would not include Supported: gruu in its > REGISTER. Strictly speaking GRUU draft currently tells > the registrar to create GRUUs but not to return them to > the UA. > > I would assume GRUU draft needs a small fix to tell the > registrar to create the GRUUs only if the REGISTER > request contains "gruu" option tag in Supported header. > > Do you agree or have I missed something ? This is partially one of those questions like "does a tree that falls make any noise if nobody is listening?" If in fact nobody will learn about this gruu then there is no need to create it. But that is all about the difference between the conceptual model and the implementation, so it doesn't need to be stated. The problem arises when there are multiple observers of registration state. There are at least two ways this can happen: - other UAs that register - subscribers to the reg event package After you register, if others register they will get your contact back in the response to their register request, along with their own. If they support gruu, then they will will see the permanent gruu and latest temp gruu for your contact. Similarly, when you register, any subscribers to the reg event package will get a notify telling of the change in registration state, including your contact and the gruus that were "assigned" to you. Everything hangs together better this way. Still, if nobody is looking you don't have to assign these, as long as you do assign them when somebody does start looking. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 01 12:39:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMpF3-0006XH-5G; Thu, 01 Mar 2007 12:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMpF1-0006Mq-KV for sip@ietf.org; Thu, 01 Mar 2007 12:38:55 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMpEy-0004jd-Tj for sip@ietf.org; Thu, 01 Mar 2007 12:38:55 -0500 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l21Hbj223455; Thu, 1 Mar 2007 09:37:45 -0800 In-Reply-To: <20070228123749.t9n0wtuo00444kwg@horde-intra.tml.hut.fi> References: <20070228123749.t9n0wtuo00444kwg@horde-intra.tml.hut.fi> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Thu, 1 Mar 2007 09:37:45 -0800 To: sergiole@tml.hut.fi X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: SIP WG , Rohan Mahy , Cullen Cullen Jennings Subject: [Sip] Re: [draft-ietf-sip-outbound-07] Edge proxy mechanisms X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 28, 2007, at 2:37, sergiole@tml.hut.fi wrote: > Hello, > > About draft-ietf-sip-outbound-07, I want to ask the following. > > Q-1) > > About the edge proxy mechanisms I read > > { > 5.1. Processing Register Requests > > When an Edge Proxy receives a registration request with a reg-id > header parameter in the Contact header field, it needs to determine > if it (the edge proxy) will have to be visited for any subsequent > requests sent to the user agent identified in the Contact header > field, or not. > } > > > Because there is a " need to determine" then must be some cases that > "the edge proxy could not be visited again". > So I do not understand in the text above why "the edge proxy could > not be visited again for any subsequent requests sent to the UAC in > the Contact header field". > > I can only imagine one situation. The edge proxy could notice that > the domain of the UAC registering (in Contact header field) could > imply that it (the edge proxy) is not going to be visited again due > that to reach that UAC in the future the edge proxy will be not > involved... > > Could you clarify the situation? For example: Initial registration goes through edge-proxy1 then through a load-balancer front end and then to the registrar/home-proxy. If the load-balancer isn't involved in future signaling, it doesn't need to add itself to the Path. > Q-2) > > How can the edge proxy determine if it will have to be visited again? The first edge proxy probbaly needs to be visited. If there are any other proxies, its really a matter of configuration if they are providing some function that the administrator of the domain wants involved in susequent signaling. thanks, -rohan > Regards, > Sergio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 01 14:56:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrMN-0007vi-7U; Thu, 01 Mar 2007 14:54:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrML-0007uE-Ln; Thu, 01 Mar 2007 14:54:37 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMrMK-0002Sm-C5; Thu, 01 Mar 2007 14:54:37 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 50DFC175FD; Thu, 1 Mar 2007 19:54:06 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HMrLq-0007Rc-2u; Thu, 01 Mar 2007 14:54:06 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: sip@ietf.org From: Dean Willis (OMA) Message-Id: Date: Thu, 01 Mar 2007 14:54:06 -0500 X-Spam-Score: -2.7 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: fluffy@cisco.com, Antti Laurila , drage@alcaltel-lucent.com, dean.willis@softarmor.com Subject: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Title: OMA LS 178 on XCAP diff-event Submission Date: 2007-03-01 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=303 Please reply by 2007-03-23 From: Dean Willis(OMA) To: IETF SIP WG(sip@ietf.org) Cc: drage@alcaltel-lucent.com fluffy@cisco.com dean.willis@softarmor.com Reponse Contact: Pavel Dostal Antti Laurila Technical Contact: Pavel Dostal Antti Laurila Purpose: For comment Body: 1 Overview This liaison seeks IETF SIP WG for the opinion on the XCAP Diff Event Package as drafted in draft-urpalainen-sip-xcap-diff-event-00. 2 Proposal OMA PAG WG deals with a requirement to enable subscription for notification of changes in XCAP resource not only to single document but also to single XCAP component (XML element or attribute). This can not be achieved using draft-ietf-sip-xcap-config because the subscription in this case is allowed only to single document or folder. A new SIP event package “xcap-diff” is defined in draft-urpalainen-sip-xcap-diff-event-00. This event package allows subscription to a set of XCAP resources where resources can be either folder or document or component identified by node selector. As this functionality fits to current requirements, OMA PAG WG is considering adopting draft-urpalainen-sip-xcap-diff-event-00 as the solution for XCAP clients to receive partial changes of the XCAP resources. 3 Requested Action(s) OMA PAG WG kindly requests IETF SIP WG on the opinion on the XCAP Diff Event Package as drafted in draft-urpalainen-sip-xcap-diff-event-00 and its expected progress. 4 Conclusion OMA PAG WG would like to thank IETF SIP WG for their kind consideration and response to this liaison request and look forward to future opportunities to work together. Attachment(s): OMA LS 178 on XCAP Diff Event (https://datatracker.ietf.org/documents/LIAISON/file404.pdf) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 01 17:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsF2-0002Xn-P3; Thu, 01 Mar 2007 15:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsE1-0000cG-FV; Thu, 01 Mar 2007 15:50:05 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMsE1-0001YT-4Z; Thu, 01 Mar 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9368B26F09; Thu, 1 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDy-0002db-Uo; Thu, 01 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-acr-code-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-acr-code-04.txt Pages : 8 Date : 2007-3-1 The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-acr-code-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-acr-code-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: <2007-3-1120735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-acr-code-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-acr-code-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1120735.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From Copyright@pacificoutdoor.com Thu Mar 01 17:17:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtYL-0004cv-9z for sip-archive@lists.ietf.org; Thu, 01 Mar 2007 17:15:09 -0500 Received: from [151.76.135.47] (helo=[151.76.135.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMtW6-0007fO-1F for sip-archive@lists.ietf.org; Thu, 01 Mar 2007 17:12:52 -0500 Message-ID: <001301c75c4e$a3e84060$00000000@giuseppe0b434e> From: "bntney bpitney" To: sip-archive@lists.ietf.org Subject: Kassin Kate Frost Katsumi Date: Thu, 1 Mar 2007 23:12:03 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C75C57.05ACA860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 ------=_NextPart_000_000F_01C75C57.05ACA860 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C75C57.05ACA860" ------=_NextPart_001_0010_01C75C57.05ACA860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bottle clerance wait door scientist give cardcheat. Academia pontificia = negocio principios escol. Girlsget natlya elevator alone, back, britany spears britney sing? Hero screening flick hostage! Princesa alessandra borghese cristo. Celebracin navidad, prevencin sida encuentro con padre elas. Briterney = britheny, britneny brittamy brittmey. That apply glitchhow make! Courtney devine crystal luna. Porte ramn = ledesma marapaz lpez. Biotica belleza santos corporal cdigo? Desea al, basta indique. Completed fortysix appointed paul ii? Quoted sayingani willis, groping hero screening flick hostage. Alvira = annemarie ambert eric ngela aparisi javier. Gtltimg marykate forbes under rich. Tassara derecha conyugal anson. Probably nothingim interested fake. Brittiny brtney bretney britneys britne brytney breatney britiany. = Pouring, assume their possitions bst traveling immediatly, strat. William soldiers alecs withhim collapse floor? Relativa cardenal profound ideas usamos frecuencia todas natural. Luo, alfredo sedano rouco, stanislaw, rylko charo sdaba snchez. Ramp = yellow lighted armor against, threw. Skys navy pilot london memorials. Runway plane run facility but, there, = baddies facilitys floating. Otherwise noted usually content itrsquos = respectful owners nor! Butter burnavail, loads kittenkim. Soul gt previous posted wednesday january. Declaracin nulidad remedio = pastoral moneda lograda pedagoga. Mercybanjo snapdiddy kong fur = daydonkey pokemon stadiumthe. Dreamcast copy web media affiliated sony sega publishers. Tvbe check sharapova erica durance nataliaadd sitesubmit, imagecool. Edt = datsun fairlady sano, evolution nissans american hit. Sophia crissy = moran anitadark, terri summers, lonnie. Steal, janine lynn alexis amore tara patrick haven. Dscw sonys cybershot wseries. Regret paves chinese coal town. ------=_NextPart_001_0010_01C75C57.05ACA860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Bottle clerance wait door scientist = give cardcheat.=20 Academia pontificia negocio principios escol.
Girlsget natlya elevator alone, back, = britany=20 spears britney sing?
Hero screening flick hostage! Princesa = alessandra=20 borghese cristo.
Celebracin navidad, prevencin sida = encuentro con=20 padre elas. Briterney britheny, britneny brittamy brittmey.
That apply glitchhow make! Courtney = devine crystal=20 luna. Porte ramn ledesma marapaz lpez.
Biotica belleza santos corporal cdigo? = Desea al,=20 basta indique.
Completed fortysix appointed paul = ii?
Quoted sayingani willis, groping hero = screening=20 flick hostage. Alvira annemarie ambert eric ngela aparisi = javier.
Gtltimg marykate forbes under = rich.
Tassara derecha conyugal = anson.
Probably nothingim interested = fake.
Brittiny brtney bretney britneys britne = brytney=20 breatney britiany. Pouring, assume their possitions bst traveling = immediatly, strat.
William soldiers alecs withhim collapse = floor?
Relativa cardenal profound ideas usamos = frecuencia=20 todas natural.
Luo, alfredo sedano rouco, stanislaw, = rylko charo=20 sdaba snchez. Ramp yellow lighted armor against, threw.
Skys navy pilot london memorials. = Runway plane run=20 facility but, there, baddies facilitys floating. Otherwise noted usually = content=20 itrsquos respectful owners nor! Butter burnavail, loads = kittenkim.
Soul gt previous posted wednesday = january.=20 Declaracin nulidad remedio pastoral moneda lograda pedagoga. Mercybanjo=20 snapdiddy kong fur daydonkey pokemon stadiumthe.
Dreamcast copy web media affiliated = sony sega publishers.
Tvbe check sharapova erica durance = nataliaadd=20 sitesubmit, imagecool. Edt datsun fairlady sano, evolution nissans = american hit.=20 Sophia crissy moran anitadark, terri summers, lonnie.
Steal, janine lynn alexis amore tara = patrick haven.
Dscw sonys cybershot wseries. Regret = paves chinese=20 coal town.
------=_NextPart_001_0010_01C75C57.05ACA860-- ------=_NextPart_000_000F_01C75C57.05ACA860 Content-Type: image/gif; name="around airAfter.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c75c4e$a3e84060$00000000@giuseppe0b434e> R0lGODlhYAGsAYfoAAoACoAEAACCCn2EDQAAfooChQCDd8C6ucXmtbK++k4qCFgmAI0nAKATAMYo De0bAABDBS0/DEM4AVE7Cng/CJM5Dsg3Dd00AwBbBhxTAExnDlFWCXVSDZ5eCcNtANVgAACIACmH DT+BAFiNDoKMDqKNCsR5ANt1AAmsABKtADmgAGudB3aoAKmcALWeA+meCADNACK6BkLKAlvFAHq+ AJK1AL3AB+nNCADkABjhCzrjCmzcAHnhAJnUALLfBNLsBQMAPygEPj8HSFMLQY4AQ6oDNLIAR+gA RAATQiMZQzwiN1UuPIglPa0TM70VROMgQQBEQR9ESz9HNmVJOYtDNpdBQM44SetMPQBZTh1iSThW QlxWS4ZnAJtmTsZeOuJpQwCBPR+OM0V1NWCNPox5M6V6TbJ4Pex4NQCYQCmhNEuRP1KUOHynMq2n McysMtmeNwDJMyPKPDPFRlPJQYvGMpbOQsOxRevJQwbWTBfiNUfhOlTSNYniSp3sOcDkRu7RNgAA excAjj8HdWUAenkAgaQLicEAi+MChAAriSQmgEUhjmUjgYATdKwgf8IodesdcQBCcRk4jkpDelc7 hoVLjJU1db5Ijug4fwppjC1dfTRdfG1kjYtniZ1RjM1mhuZkdwd/iSp7cjSJgFWAhX54e5R7dcGO fN92cwCqihSShTGfjVKciYihfpOdd7GhiuiRhgC0gxi1eTjAiFXDcXW9dK3OjcjNeNrEfAvUfSbe fTHXembiiXbnjZ/Sd7TXhOLVcwsAvCAAsUIGxVINsXgCu64AvbEKt+0ExAAlwRIeyj4myFcds4Mm x6sRwrotvuUUyg5BuiRHwj9Cw2A9woJNu5RDxs05zdM4xwRhvCFftz5tylZlxIxosahozMRguuJa ygCHySlzuUeLxVF+xI2Ewqp9tbWAwtZ9wQCbvBWVv0ussVqnxYGtv6umu7Wixd+qvwCywy25zkG1 sWC2voa8xKi7tfj/75qXmYh1fPwGAAT3Dff/CQAK//8E/An///H49SH5BAAZv1UALAAAAABgAawB Bwj/AF0IHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDKPk5VIyQH2PEhB+7kHzy sWLKCS8bxLx4IOfNjiF7lfx5JOXSBT+jVrg6s2iupAU6ZmxZdujUtzVPvr37cmjds0H/tu1b9+Te ln8P70389Outs4MTNE59uufdsq/Hzl79Ovfj3sEf/6+9fbz28K2fP90e/Tty0u2TBy+vOTr98bWz uzePXnz39Oo5FVt+wDWWWnj6JVifgfst59+D95HnHYABMjVgfwpa1+B5/XWX4YUfchjihhVCp2F7 CTKHG23T8SbdcLTx5tl8KsLnYIwxgvfihCX26OOPQAYp5JBEFmmkRBQ+lGRnR9KV5JINQclQelI2 OdWTHlXJWpRWlnWai7mliKKKPOIHJos4Cqffiy52SVaE5zlH4pobkseimHFqqKObY8HJHWYS4rmg nTQ2ZyOM8oXJZ1h+micnf+I5CqlxGR70qIMILtpVowV2mCmBInrY6KSa9smmfJU+SCaGBCpKnJpm zv+YX6m01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimq+6RANTU7rpIASBvu++CVO9D9Dp0L7wy7btvR/8yFHBCA/PL0r/z1jvv QAu7kDDD8kJMb8QENfywwxhf7DDFGBvcr0EKdyyyQPmSLHLJJhcU8soZM3xyyh7DhLDLCb/78Mo3 h6wyzTyjPLHFMcc0s8n+8kz0QREP3fLRPo8Mc9AuFX301EtXfS/KLlOdb9M6Q93vwjo3vHHSYlvM McckU8xy02Nn7XVRBb8tV9xy12333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eaG94NRP55PFHpGdGtUermgg+7C6AR5zrpBqb8u0Oiyxy776hudjpHCGqdttu7L 3g77QsIPRDtCxRcvEfAV3dwQ29XWPrvquIeeeuuwU3/99QWxzn3sxlMv8fhZA92xv2ejbbTTSMPM /LHSY+867gd9bzz9+HdfP/7zK4T1+iWzGUL+tzPeqa9i5LNW/MA3P/Ht73jH21/4VAfB2+UMZC/b mtMuSLADBqxr7zOW9CDIP+H1r3r3kyD/Vjg9BLrvahlsGQxfSLANts992HrdCRuIvQfeL4LDm90P /1MoRLfNUGs4dOHICqbBlHXtZTnc3vQoWD0Hro57V7Re6+I3Rdd9z4pj+9nO2pbEioHtgL4zoBFV hkbO0SSEbvwJHONIxzoGSB/6KEkeSzLHbe3RBXn840XwiEeGCPIhh3RIIu2FQZCprXfT+uMiKyLJ hUzyI5fkiMY86LanRXIggRQIIUE5ylACspAEqaQpR3nKPbKylaIspCtRSUhJ0pIkWCPgE/tIrFUW xJSAPKVBBKlKV4IymKI8JjFTicxgVpKZmTQdFJV2RGv5spXABCY2U8nKZzqTlKW0pTLHmcxtRtN0 jxRbGXnZS2Rms5nvLKc85anKYw5TnO+sZzLPKf/Naq7Tj+T85j7t2cyCwjOg3ixoKPUpUIGCcI3/ xOARBehEbj2zlrGUJTdROU+F3hKcGQ2pOz86Uo1C8aQP9SQkQXg2ePETLOw81yvXElM72vSmfAGj Q5QnNI+RUCPgC2L+ung7nsqskUjlFhAzwtOl9lCFN9nkB2sqwiFmcYI8vOpTJzhFrW71i+LDYkty yT5Pbqt/OlwhGHWoPasOlYjyc+tRwzZAcKG1i2rdok5RKESnwpWBPzTqSX6HRqpWVYs/5SsLh5dY ExJxh+H7mD872a3G5rWIb+2rWx2LWcimMKUohWhoJarEyZ41hUEFLFb1Sru2RlZ/q02t+EBLW9H/ PjGMYzxZG9ElWJj2TaxqMSxOh0vcqLxULMKtFkYXqc3gSqywNoPkJw35FufV8IbKHaZIV8lRskAv qUrM7i/Hu1DnGhBh6ixrtBI5S40G8rhbSa8Ny2hN7dZTnGj5n9ROeq1D5lOhua1tREdLYAEXWLQI ZBtFz2fRUma0vDMdsIEnbNsKSxjBuPWdEVta3J52GG4fDrGIuZVcBQJXIsmTK1Ou5kHpaqu3F/Hr Uqw733AVVXtYtB9aHfjTHEvRenvt6Qdza1ehQraCmvXhUI/MRXdtEL27vRaQvSjFvqpWsfrTYhaP zNqcyJeJ3/LeklWc2CwnWbGezexM9Htdb1n2/80qfiqXzxxBCl/4zgWcJn0rC9bOdpWFJ46gbKm4 2gPj2c7PTaAaLwdjJw/3xHIcsaQnba0SRzLCddkvGxfd375crLAAxBZ7aSlLW8K3Kmz2H3+VS9Jr +te7NXZkArX1X3c+uCzqpNt3RX1QYzb01KheNWnNWl99GvOZiE62hQ3N7NsisXyh7u8ru1nO9u5R 2YdeNraZnUZFKzrKlPaIpcP9kXGT+9zozklRpWLuaNmuI+uOCosHdt5266rRD4n3U2iMXuxmq8c4 9iJX8apVfEd6yOBVb/ReG1f6pRXO+2YfvRMu5b9WWctXnvO+0Qbm8L74sVZF7GYvC5UAqtrj//8G eZJFTufLbvvl2sYw05Jq2hxanNAYB+uUiwjzbPt81Z/+tLfTjUuie9noSE86ruztLPg2F9dEVi9h me4mYAP7KkE3I3Y1/Sz/ttqZ7hVpfGNd1l1Sa5kDHSh+mTl2riN8iWff6C2PTdBtciXXUU80sZvO dmim/aAdzcqudU1ZaKEd8L8m6LVj/vOeN7t9t/Wnsw3fze5eVJsYfXzjGa95oJctfSxFudIpQvXR 48v0qE+96lfP+ta7/vWwj73sZ0/72tv+9rjPve53z/ve+/73wA++8IdP/OIbv3lBKf1ElE8kFwsM bJDX1/oGC5GA5eP6+RgI9rMvkOsThPuqTm7/zX00+ZMvhPAyNwnz/gV+F2S//e/vvvwFVm7R/4hl zzZrdAW4//Di//NJcz4ttn/ntWn9R0YHEX/a537z136OFIBk9Ds4FHQLNiRCl38Sl2cEZEMVaDUb Q3EeaHZIRDcKKH/cV4JbVzVwN4LTx3xzE22p5kLOMzHPBTQUxW9LlF44KIIZQ2MJOH8NeILd54Ax xGETGGrj1yP4x2BcF4K65XEmt4TQM1Ex9DRLuHfeB4QMWBAK6IBSSFYsSDUKp4TRVnZ5NnOdRE1V 6IFWiIRp6IYG4YDwx4UNGGBwR4VSOIZBIlVGaIACGIBihHJhQ1g5qD44mGF693nfF4eL2IhC/+iH gRiBoKdgHagpLlh91NcQ25eF20eH2keE4XKJz0d18nV8pniKqJiKqriKrNiKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLvviLwBiMwpgUTNeE5yd9yPcSongYoDVA0Gd/A1ZXCbZGxhh9p7d32KhJ0iQk zQhe65d+UEhg0Jh39JeNpLiNewhROuiHPWiI6qg2S3OI8SiBkDiPagR9u5ROdhiBPWNGoKdh/5iN AaJBC4Y+BcmG/XiQ8EhXTcQ1b8g0Clla/NWMeYgzdvh/z7aMbEGQaTRxa0NZHLmGCiZDI9g7H9mR K8iE+8iBRyiGLRmPRHOB3EiSeuiEkUeTFf8JbQ25hhcJdBKpguIIk2EokRgJlDWpHgZ2hjSZgf+U h01ZhkVIjT/JlML2UFf4kiaHkEWSjwYZkS7GlUm0Se+oj/U4b+QDgWV3gEQGgLpUPvDIYAioka8h l8qYjHhDl1Fjl8O4l3wZEXjpXeXXbc9jETPDfG/3jaSnjchIfoEpbP6WO0eVEsv4l2ORlevolvdI lmBoj+3ojAupYaCJj+3Yfwe4UqApmJIIQ2q5g5yJmmTIfw85lKHljmjokhcZkWkIm0P5XRuYk2yE lUWIm0fJjLVZTQ5ZYUPGf1fZkyjZh77phG3ISbL5Qs9okzXomEhZnP7Hk1ZpjbxjlERZeB//iIdw qJXfKZW2eZMsqJ7DaRjfyYPCOZvSeIcpCZzRGZ67OZHbOZ3yuZ7o2Z6FcZ46mGsBqZnzGYjRpVLm E5r/iDPp84f0FYlh+aC5WYC4lUuTuC7VeBGUuXyBozSKORQd2pckWqImeqIomqIquqIs2qIu+qIw GqMyOqM0WqM2eqM4mqM6uqM86nrsFGUb6JcV0o2ZiCQtgiq2kSko6ZfgNo0hVDpBionHGBhEqn4T 0SZ1QifzKaXD2ZhbWlcxBaWCkVJfVp2lCaEZRo8IqCeBwh+UQnPp5HbT9JlmummnGZqFqJtsOacI 2qRwEZLw6ZOc5JRamSr/cScHCpVFc5NN/6SftumkRCmcx7lnegGoJgmD1XmhAJQz8jUrHrImnNGd bTiNTiSaqsmcZYmfIsmdEOMXgJqozxmr5IghpGIdiIqcsZmfjQqUy3mS9gmdKog+nrZsq0qok0qo tPqpd4IZolpjkrqU+jd9R0iewHmFIJoXYMmOFIihaJmgcXlA0kEm4aogoeqPrjlr2zqP4rmg/rir Mvmtccqgazqkd1eOhBkSIzoYpWgVp+OnbSZuPRqwAjuwBFuwBnuwCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxGJuxGqsr9pGkwnEoOdIioDGy9hEfHXukJXs5YIIdlgIfM8Kyq/KyuAGzM/sqHtm7OTKC H42RHAeSGzkrsyL7szcLs0JbOUV7tCFLskVLs0mKtCI7tJjjtC0LtbKytEyLHVJ7s1YrOVlbs0i7 tSVrsmFLtCA7JlyrGmhLtYbCGoDiGztrtldrOV37tE47rjUbtGnLtFsbOXMrs1Jrt0D7slkrI3vL t84xuIeLpHcruHkrrlqCOOGqHDsrK4x7pCM7s13LJnR0smOLHCibtDYbuE0btm5ruaT7uBubuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMQ7EQEBADs= ------=_NextPart_000_000F_01C75C57.05ACA860-- From sip-bounces@ietf.org Thu Mar 01 23:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMz2W-0005tC-QZ; Thu, 01 Mar 2007 23:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMz2V-0005ss-7o; Thu, 01 Mar 2007 23:06:39 -0500 Received: from tapal.aricent.com ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMz2R-0008Cl-LD; Thu, 01 Mar 2007 23:06:39 -0500 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l2244xmk006887; Fri, 2 Mar 2007 09:35:00 +0530 Received: from pragati.blr.hss.hns.com (pragati.blr.hss.hns.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l2244xx8006879;Fri, 2 Mar 2007 09:34:59 +0530 In-Reply-To: <0B635C81-5339-4527-9210-6A7DCC964C77@estacado.net> To: Byron Campen Subject: Re: [Sip] Knowing status of sent message MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Vishnu.Yadav@aricent.com Date: Fri, 2 Mar 2007 09:38:58 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at03/02/2007 09:36:14 AM,Serialize complete at 03/02/2007 09:36:14 AM X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.9545 TC:1F TRN:76 TV:3.6.1039(15028.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.3 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: sip@ietf.org, sipping@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207563324==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0207563324== Content-Type: multipart/alternative; boundary="=_alternative 001677FB65257292_=" This is a multipart message in MIME format. --=_alternative 001677FB65257292_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I=20will=20reframe=20my=20words=20to=20-=0D=0Aas=20per=20rfc=203428=20sec= tion=204.=20=0D=0A=20=20=20If=20the=20UAC=20receives=20a=20200=20OK=20res= ponse=20to=20a=20MESSAGE=20request,=20it=20may=0D=0A=20=20=20assume=20the= =20message=20has=20been=20delivered=20to=20the=20final=20destination.=20= =20It=0D=0A=20=20=20MUST=20NOT=20assume=20that=20the=20recipient=20has=20= actually=20read=20the=20instant=0D=0A=20=20=20message.=20=20If=20the=20UA= C=20receives=20a=20202=20Accepted=20response,=20the=20message=0D=0A=20=20= =20has=20been=20delivered=20to=20a=20gateway,=20store=20and=20forward=20s= erver,=20or=20some=0D=0A=20=20=20other=20service=20that=20may=20eventuall= y=20deliver=20the=20message.=20=20In=20this=20case,=0D=0A=20=20=20the=20U= AC=20MUST=20NOT=20assume=20the=20message=20has=20been=20delivered=20to=20= the=20final=0D=0A=20=20=20destination.=0D=0A=0D=0Acheers=20:)=0D=0Avishnu= =0D=0A=0D=0A=0D=0A=0D=0AByron=20Campen=20=20=0D=0A0= 3/01/2007=2004:05=20AM=0D=0A=0D=0A=0D=0ATo=0D=0AVishnu=20Yadav/BLR/HSS@HS= S=0D=0Acc=0D=0A,=20sip@ietf.org,=20sipping@iet= f.org=0D=0ASubject=0D=0ARe:=20[Sip]=20Knowing=20status=20of=20sent=20mess= age=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AJust=20a=20note;=20a=20proxy= ,=20as=20defined=20by=203261,=20is=20not=20allowed=20to=20do=20this.=20Th= is=20=0D=0Ais=20strictly=20a=20B2BUA=20thing.=0D=0A=0D=0ABest=20regards,= =0D=0AByron=20Campen=0D=0A=0D=0A=0D=0Aintermediate=20proxies=20can=20send= =20202=20.=20=0D=0AIn=20MESSAGE=20case=20=0D=0A200=20->=20implies=20that= =20the=20Msg=20has=20reached=20to=20destination=20=0D=0A202=20->=20that= =20=20proxy=20has=20recvd=20it=20&=20will=20frwrded=20it=20towards=20fina= l=20=0D=0Adestination=20=0D=0A=0D=0Avishnu=20=0D=0A=0D=0A=0D=0A=20=0D=0A02/20/2007=2003:29=20PM=20=0D=0A=0D=0A=0D=0ATo= =0D=0A,=20,=20=20=0D= =0Acc=0D=0A=0D=0ASubject=0D=0ARE:=20[Sip]=20Knowing=20status=20of=20sent= =20message=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AHi=20Ranj= it,=20=0D=0AEvery=20MESSAGE=20method=20will=20be=20acknowledged=20by=2020= 0=20OK=20success=20response.=20=0D=0A=20=20=0D=0AThat=20means,=20=0D=0AIf= =20?A?=20sends=20MESSAGE=20to=20?B?,=20upon=20receiving=20this=20MESSAGE= =20B=20sends=20200=20OK=20=0D=0Aresponse=20to=20A.=20=0D=0A=20=20=0D=0ARe= gards=20=0D=0AKamal=20=0D=0A=0D=0A=0D=0A=0D=0AFrom:=20Avasarala=20Ranjit-= A20990=20[mailto:ranjit@motorola.com]=20=0D=0ASent:=20Tuesday,=20February= =2020,=202007=203:21=20PM=0D=0ATo:=20sipping@ietf.org;=20sip@ietf.org=0D= =0ASubject:=20[Sip]=20Knowing=20status=20of=20sent=20message=0D=0AImporta= nce:=20High=20=0D=0A=20=0D=0AHi=20=0D=0AIs=20there=20a=20mechanism=20in= =20SIP=20to=20know=20the=20status=20of=20sent=20instant=20message=20=0D= =0Ausing=20MESSAGE?=20=0D=0AThanks=20=0D=0ARegards=20=0D=0ARanjit=20_____= __________________________________________=0D=0ASip=20mailing=20list=20= =20https://www1.ietf.org/mailman/listinfo/sip=0D=0AThis=20list=20is=20for= =20NEW=20development=20of=20the=20core=20SIP=20Protocol=0D=0AUse=20sip-im= plementors@cs.columbia.edu=20for=20questions=20on=20current=20sip=0D=0AUs= e=20sipping@ietf.org=20for=20new=20developments=20on=20the=20application= =20of=20sip=20=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-Priv= ate=20=20=20***********************=20=0D=0A"DISCLAIMER:=20This=20message= =20is=20proprietary=20to=20Aricent=20and=20is=20intended=20solely=20=0D= =0Afor=20the=20use=20of=20=0D=0Athe=20individual=20to=20whom=20it=20is=20= addressed.=20It=20may=20contain=20privileged=20or=20=0D=0Aconfidential=20= information=20and=20should=20not=20be=20=0D=0Acirculated=20or=20used=20fo= r=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If= =20=0D=0Ayou=20have=20received=20this=20message=20in=20error,=20=0D=0Aple= ase=20notify=20the=20originator=20immediately.=20If=20you=20are=20not=20t= he=20intended=20=0D=0Arecipient,=20you=20are=20notified=20that=20you=20ar= e=20strictly=0D=0Aprohibited=20from=20using,=20copying,=20altering,=20or= =20disclosing=20the=20contents=20of=20=0D=0Athis=20message.=20Aricent=20a= ccepts=20no=20responsibility=20for=20=0D=0Aloss=20or=20damage=20arising= =20from=20the=20use=20of=20the=20information=20transmitted=20by=20this=20= =0D=0Aemail=20including=20damage=20from=20virus."=0D=0A=0D=0A____________= ___________________________________=0D=0ASip=20mailing=20list=20=20https:= //www1.ietf.org/mailman/listinfo/sip=0D=0AThis=20list=20is=20for=20NEW=20= development=20of=20the=20core=20SIP=20Protocol=0D=0AUse=20sip-implementor= s@cs.columbia.edu=20for=20questions=20on=20current=20sip=0D=0AUse=20sippi= ng@ietf.org=20for=20new=20developments=20on=20the=20application=20of=20si= p=0D=0A=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-Private=20= =20=20***********************=0D=0A"DISCLAIMER:=20This=20message=20is=20p= roprietary=20to=20Aricent=20and=20is=20intended=20solely=20for=20the=20us= e=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20ma= y=20contain=20privileged=20or=20confidential=20information=20and=20should= =20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20t= han=20for=20what=20it=20is=20intended.=20If=20you=20have=20received=20thi= s=20message=20in=20error,=20=0Aplease=20notify=20the=20originator=20immed= iately.=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are= =20notified=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20= copying,=20altering,=20or=20disclosing=20the=20contents=20of=20this=20mes= sage.=20Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20da= mage=20arising=20from=20the=20use=20of=20the=20information=20transmitted= =20by=20this=20email=20including=20damage=20from=20virus."=0A --=_alternative 001677FB65257292_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
I=20will=20reframe=20my= =20words=20to=20-=0D=0A
= as=20per=20rfc=203428=20section=204.=20=0D=0A
 =20 If=20the=20UAC=20receives=20a=20200=20OK=20response= =0D=0Ato=20a=20MESSAGE=20request,=20it=20may
=0D=0A=20 =20assume= =20the=20message=20has=20been=20delivered=20to=20the=20final=20destinatio= n.=0D=0A It
=0D=0A=20 =20MUST=20NOT=20assume=20that=20the=20= recipient=20has=20actually=20read=20the=20instant
=0D=0A=20 =20me= ssage.=20 If=20the=20UAC=20receives=20a=20202=20Accepted=20response,= =20the=0D=0Amessage
=0D=0A=20 =20has=20been=20delivered=20to=20a= =20gateway,=20store=20and=20forward=20server,=20or=20some
=0D=0A=20&nb= sp;=20other=20service=20that=20may=20eventually=20deliver=20the=20message= .=20 In=0D=0Athis=20case,
=0D=0A=20 =20the=20UAC=20MUST=20NO= T=20assume=20the=20message=20has=20been=20delivered=20to=20the=20final=0D=0A=20 =20destination.=0D=0A
=0D=0A
cheers=20:)=0D=0A
vishnu<= /font>=0D=0A
=0D=0A
=0D=0A
=0D=0A=0D= =0A=0D=0AByron=20Campen=20<bcampen@estacado.net>=0D=0A=0D=0A

03/01/2007=2004:05=20= AM=0D=0A
=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0ATo=0D=0AVishnu=20Yadav/BLR/HSS@HSS=0D=0A=0D=0A= =0D=0Acc=0D=0A&= lt;kamalakar.mergu@wipro.com>,=0D=0Asip@ietf.org,=20sipping@ietf.org=0D=0A=0D=0A=0D=0ASubject=0D=0ARe:=20[Sip]=20Knowing=20status=0D=0Aof=20sen= t=20message=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A=
Just=20a=20note;=20a=20proxy,=20as=20defined=20by=20= 3261,=20is=20not=20allowed=0D=0Ato=20do=20this.=20This=20is=20strictly=20= a=20B2BUA=20thing.=0D=0A
=0D=0A
Best=20rega= rds,=0D=0A
Byron=20Campen=0D=0A
=0D= =0A

=0D=0Aintermediate=20pr= oxies=20can=20send=20202=20.=20
=0D=0AIn=20MESSAGE=20case=20
=0D=0A200= =20->=20implies=20that=20the=20Msg=20has=20reached=20to=20destination<= /font>=0D=0A
=0D=0A202=20->=20that=20 proxy=20has=20recvd=20it=20&= =20will=20frwrded=20it=20towards=20final=0D=0Adestination=20
=0D=0A
= =0D=0Avishnu=20
=0D=0A
=0D=0A=0D=0A<= table=20width=3D100%>=0D=0A=0D=0A<kamalakar.mergu@wipro.com>=0D=0A=0D=0A

02/20/2007=2003:29=20PM=0D= =0A=0D=0A=0D=0A
=0D=0A= =0D=0A=0D=0A=0D=0ATo=0D=0A<ranjit@motorola.com>,=0D=0A<sipping@ietf.org<= /font>>,=0D=0A<sip@ietf.org>=0D=0A=0D=0A=0D=0A=0D= =0Acc<= /div>=0D=0A=0D=0A=0D=0A=0D=0ASubject=0D=0ARE:=20[Sip]=20Know= ing=20status=0D=0Aof=20sent=20message=0D=0A
=0D=0A
= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A

=0D=0A
=0D=0A
=0D=0AHi=20Ranjit,=20
=0D=0AEv= ery=20MESSAGE=20method=20will=20be=20acknowledged=20by=20200=20OK=20succe= ss=20response.=0D=0A
=0D=0A =20=
=0D=0AThat=20means,=20
=0D=0AIf=20“A”=20sends=20MESSAG= E=20to=20“B”,=20upon=20receiving=20this=20MESSAGE=20B=20sends= =20200=0D=0AOK=20response=20to=20A.=20
=0D=0A =20
=0D=0ARegards=20
=0D=0AKamal=20=0D=0A=0D=0A

=0D=0A=0D=0A

=0D=0A

=0D=0AFrom:=20Avasarala=20Ranjit-A20990=20[= mailto:ranjit@motorola.com]=0D=0A
=0D=0ASent:=20Tuesday,=20= February=2020,=202007=203:21=20PM
=0D=0ATo:=20sipping@ietf.org= ;=0D=0Asip@ietf.org
=0D=0ASubject:=20[Sip]=20Knowing=20status=20of= =20sent=20message
=0D=0AImportance:=20High=20
=0D=0A=  =0D=0A

Hi=0D= =0A=0D=0A

Is=20there=20a=20mechanism=0D=0Ain=20SIP=20to=20know=20the=20st= atus=20of=20sent=20instant=20message=20using=20MESSAGE?=0D=0A=0D=0A

Thanks=0D=0A=0D=0A

Regards=0D=0A
=0D=0ARanjit=20___= ____________________________________________
=0D=0ASip=20mailing=20lis= t=20 https://www1.ietf.org/mailman/= listinfo/sip
=0D=0AThis=20lis= t=20is=20for=20NEW=20development=20of=20the=20core=20SIP=20Protocol
= =0D=0AUse=20sip-implementors@cs.columbia.= edu=0D=0Afor=20questions=20on=20= current=20sip
=0D=0AUse=20sipping@ietf.org=0D=0Afor=20new=20developments=20on=20the=20ap= plication=20of=20sip=0D=0A=0D=0A


=0D=0A
=0D=0A****************= *******=20 Aricent-Private=20 =20***********************= =0D=0A=0D=0A=0D=0A=0D= =0A"DISCLA= IMER:=20This=20message=0D=0Ais=20proprietary=20to=20Aricent=20and=20is=20= intended=20solely=20for=20the=20use=20of=20
=0D=0Athe=20individual=20t= o=20whom=20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20= confidential=0D=0Ainformation=20and=20should=20not=20be=20
=0D=0Acircu= lated=20or=20used=20for=20any=20purpose=20other=20than=20for=20what=20it= =20is=20intended.=0D=0AIf=20you=20have=20received=20this=20message=20in= =20error,=20
=0D=0Aplease=20notify=20the=20originator=20immediately.= =20If=20you=20are=20not=20the=20intended=20recipient,=0D=0Ayou=20are=20no= tified=20that=20you=20are=20strictly
=0D=0Aprohibited=20from=20using,= =20copying,=20altering,=20or=20disclosing=20the=20contents=20of=0D=0Athis= =20message.=20Aricent=20accepts=20no=20responsibility=20for=20
=0D=0Al= oss=20or=20damage=20arising=20from=20the=20use=20of=20the=20information= =20transmitted=20by=20this=0D=0Aemail=20including=20damage=20from=20virus= ."
=0D=0A=0D=0A
_________= ______________________________________=0D=0A
S= ip=20mailing=20list =20https://www1.ietf.org= /mailman/listinfo/sip=0D=0A
This=20lis= t=20is=20for=20NEW=20development=20of=20the=20core=20SIP=20Protocol=0D=0A
Use=20sip-implementors= @cs.columbia.edu=0D=0Afor=20questions=20o= n=20current=20sip=0D=0A
Use=20sipping@iet= f.org=0D=0Afor=20new=20developments=20on= =20the=20application=20of=20sip=0D=0A
=0D=0A

=0D=0A
=0D=0A***********************=20&nb= sp;Aricent-Private=20 =20***********************=0D=0A= 
"DISCLAIMER:=20T=
his=20message=20is=20proprietary=20to=20Aricent=20and=20is=20intended=20s=
olely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=
=20addressed.=20It=20may=20contain=20privileged=20or=20confidential=20inf=
ormation=20and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20an=
y=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=
=20have=20received=20this=20message=20in=20error,=20=0Aplease=20notify=20=
the=20originator=20immediately.=20If=20you=20are=20not=20the=20intended=
=20recipient,=20you=20are=20notified=20that=20you=20are=20strictly=0Aproh=
ibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20the=20c=
ontents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibility=
=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=20=
information=20transmitted=20by=20this=20email=20including=20damage=20from=
=20virus."=0A
--=_alternative 001677FB65257292_=-- --===============0207563324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0207563324==-- From sip-bounces@ietf.org Thu Mar 01 23:14:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMz9N-0004r5-Ux; Thu, 01 Mar 2007 23:13:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMz9M-0004oh-6b for sip@ietf.org; Thu, 01 Mar 2007 23:13:44 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMz9K-0000R5-Su for sip@ietf.org; Thu, 01 Mar 2007 23:13:44 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2007 23:13:43 -0500 X-IronPort-AV: i="4.14,239,1170651600"; d="scan'208"; a="53889336:sNHT55154868" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l224DggS005832; Thu, 1 Mar 2007 23:13:42 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l224DgVT007478; Thu, 1 Mar 2007 23:13:42 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 23:13:42 -0500 Received: from [192.168.1.104] ([10.86.241.21]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 23:13:41 -0500 Message-ID: <45E7A475.5010108@cisco.com> Date: Thu, 01 Mar 2007 23:13:41 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erkki.Koivusalo@nokia.com Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <1165200634.3607.3.camel@localhost.localdomain> <45749DF6.7040803@cisco.com> <1165336240.3208.72.camel@scott.skrb.org><45A55E25.3080904@cisco.com> <45E5AE63.2060309@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F0367A121@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0367A121@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2007 04:13:41.0789 (UTC) FILETIME=[295DACD0:01C75C81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2050; t=1172808822; x=1173672822; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20 |To:=20Erkki.Koivusalo@nokia.com; bh=XVjhQH2BNhby6QixwUrKWhNxFeh5xdOMFbz2vESrifU=; b=jSzW/v0MJ8nYV2trYn13T9R+XWaznlYtJEUoYILl1zj5j/hMCgeeb6yAiQc+bJ+CY2DsInrC 8DIrIuiLYerlSckk3a3v2INXi7aNhS7vvMI400GILtGQjxfnXxv4nhGp; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, pkyzivat@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Erkki.Koivusalo@nokia.com wrote: > Hi, > > >>The client would just generate a register refresh, changing the callid. >>When it does this, it will, by the algorithm above, invalidate its >>temp-gruu locally. If we specify that the server does the same, then >>this provides a way for a client forcefully invalidate all previous >>temp-gruu without loss of connectivity. > > > The proposed algorithm would unfortunately have a conflict > to what RFC 3261 currently specifies for Call-ID handling for > REGISTER refreshes in section 10.2: > > Call-ID: All registrations from a UAC SHOULD use the same Call-ID > header field value for registrations sent to a particular > registrar. > > If the same client were to use different Call-ID values, a > registrar could not detect whether a delayed REGISTER request > might have arrived out of order. > > Seems that this rule has been specified to avoid another race > condition e.g. by the UAC at first refreshing the registration > and right thereafter removing the binding. If these two messages > would arrive over UDP to the registrar in the opposite order the > UAC would believe to have successfully deregistered while the > registrar would believe the UAC to have registered again. Sure; if the client wants to refresh and remove it would use the same call-id. There is no race here as long as the client doesn't create one. If the client wants to remove its temp-gruus it would change call-ID and then wait for a response before doing the next registration. With that there is never a race. Thats why this is a SHOULD and not a MUST. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 01 23:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMzB5-0008Eb-Sg; Thu, 01 Mar 2007 23:15:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMzB3-0008Dj-OO for sip@ietf.org; Thu, 01 Mar 2007 23:15:29 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMzB2-0000d7-Eq for sip@ietf.org; Thu, 01 Mar 2007 23:15:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2007 23:15:28 -0500 X-IronPort-AV: i="4.14,239,1170651600"; d="scan'208"; a="114769244:sNHT49524452" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l224FRam006194; Thu, 1 Mar 2007 23:15:27 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l224FRVV007740; Thu, 1 Mar 2007 23:15:27 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 23:15:27 -0500 Received: from [192.168.1.104] ([10.86.241.21]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 23:15:27 -0500 Message-ID: <45E7A4DE.6040402@cisco.com> Date: Thu, 01 Mar 2007 23:15:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] When does the registrar have to create GRUUs ? References: <8B1D53AEF7B03449A6D3771B3B7F850F0367A1CA@esebe103.NOE.Nokia.com> <45E6E61B.7090509@cisco.com> In-Reply-To: <45E6E61B.7090509@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2007 04:15:27.0242 (UTC) FILETIME=[683886A0:01C75C81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2914; t=1172808927; x=1173672927; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20When=20does=20the=20registrar=20have=20to=20c reate=20GRUUs=20? |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=iH5MkAmoGfoXbrY+LvMZZcdLz4cBZS8vP9XmdxMVWhs=; b=pvgeinHh6Qo1G4LfLnF+OkTmXgC8UgY2Gxli525PK8jnA91E4a7wtd1VFzExJ+gesMfkXZrB 7fzSqp66FwCtJZzPwZqb/zmTLWXfJEdHaoMwMVQLMWlXKe//PaYyC5xP; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What Paul and Dale said. Indeed previous versions of GRUU did only create gruu when the Supported header field was present, but Paul K. found the issue described below and so it was changed to do so even when Supported is not there. -Jonathan R. Paul Kyzivat wrote: > > > Erkki.Koivusalo@nokia.com wrote: > >> Hi Jonathan, >> >> GRUU draft tells the registrar to create a public GRUU and a >> temporary GRUU whenever it receives a REGISTER request with >> "+sip.instance" Contact header parameter but only return >> them is the REGISTER request contains Supported: gruu. >> >> Does this make any sense ? Why would the registrar have to >> create those GRUUs if it would not return them to the UA ? >> >> The use case I am thinking is: >> >> - A registrar which supports both GRUU and Outbound - An UA which >> supports Outbound but not GRUU >> >> Such an UA would send its Contact header with "+sip.instance" >> parameter but it would not include Supported: gruu in its >> REGISTER. Strictly speaking GRUU draft currently tells >> the registrar to create GRUUs but not to return them to the UA. >> >> I would assume GRUU draft needs a small fix to tell the >> registrar to create the GRUUs only if the REGISTER >> request contains "gruu" option tag in Supported header. >> >> Do you agree or have I missed something ? > > > This is partially one of those questions like "does a tree that falls > make any noise if nobody is listening?" > > If in fact nobody will learn about this gruu then there is no need to > create it. But that is all about the difference between the conceptual > model and the implementation, so it doesn't need to be stated. > > The problem arises when there are multiple observers of registration > state. There are at least two ways this can happen: > - other UAs that register > - subscribers to the reg event package > > After you register, if others register they will get your contact back > in the response to their register request, along with their own. If they > support gruu, then they will will see the permanent gruu and latest temp > gruu for your contact. > > Similarly, when you register, any subscribers to the reg event package > will get a notify telling of the change in registration state, including > your contact and the gruus that were "assigned" to you. > > Everything hangs together better this way. Still, if nobody is looking > you don't have to assign these, as long as you do assign them when > somebody does start looking. > > Paul > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From fkquvrqtrip@sofianet.net Fri Mar 02 04:57:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN4WN-0006Cn-1a for sip-archive@lists.ietf.org; Fri, 02 Mar 2007 04:57:51 -0500 Received: from [85.11.145.36] (helo=85-11-145-36.sofianet.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HN4WL-0002LH-KW for sip-archive@lists.ietf.org; Fri, 02 Mar 2007 04:57:50 -0500 From: "STUFF BOOK" To: sip-archive@lists.ietf.org Subject: Stock Trader Alert Date: Fri, 2 Mar 2007 11:57:42 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C75CC1.FBD7DCE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdcwfvX0niQ7UzvR0KMZdUmxp2dIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0003_01C75CC1.FBD7DCE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SUPERNOVA *GDKI* IS ON THE MOVE STILL!
YOUVE SEEN THEM.. YOUVE HEARD ABOUT THEM...
HABANA BLUES IS STILL MAKING MAJOR HEADLINES WORLDWIDE!

GOLDMARK INDUSTRIES - www DOT goldmarkentertainment DOT com
The Day To Trade: March, 02 Friday 2007
Ticker Symbol: GDKI
Opens Friday: $0.13

GOLDMARK INDUSTRIES is committed to providing the best in all forms of urban entertainment to the 45 Million Hip-Hop consumers in North America. The average North American spends more on entertainment than they do on health care and clothing, making entertainment the most attractive industry for investors and advertisers alike. Goldmark Industries is preparing to stand at the forefront of the Hip Hop consumer market, specializing in all aspects of entertainment, including Music, Feature Films, Television, Home Video/DVD and Major Events.

IS THIS SUPERNOVA PREPARED TO EXPLODE EVEN MORE? PUT *GDKI* ON YOUR RADAR FRIDAY MAR 02 2007
------=_NextPart_000_0003_01C75CC1.FBD7DCE0-- From pbrintonpyui@rima-tde.net Fri Mar 02 05:41:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN5C9-0004KD-ES; Fri, 02 Mar 2007 05:41:01 -0500 Received: from 147.red-88-23-183.staticip.rima-tde.net ([88.23.183.147] helo=rima-tde.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HN5C5-0006J2-B3; Fri, 02 Mar 2007 05:41:01 -0500 Message-ID: Reply-To: "Georgine Vasquez" From: "Georgine Vasquez" To: "Cassie Hamilton" Cc: "Maurice Sanders" , "Arminda Henderson" , "Nada Stanley" , "Scott Simpson" , "Oleta Burton" , "Maryellen Williams" , "Ashley" , "Carmine Flores" , "Flossie" Subject: Isn't It Time Date: Fri, 02 Mar 2007 08:24:04 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_00A_0A75_673BCB75.29FC1A02" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 2.4 (++) X-Scan-Signature: 94962611154c8404498b19f744990308 This is a multi-part message in MIME format. ------=_NextPart_00A_0A75_673BCB75.29FC1A02 Content-Type: multipart/alternative; boundary="----=_NextPart_D9D_3BCE_CFD00016.15BEB5E9" ------=_NextPart_D9D_3BCE_CFD00016.15BEB5E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Stop a bit," said forgo the abb, taking up seed debt colourful what he c= al wind cheese "I am not mad," replied throughout frightened Faria, with= that acuteness "Certainly. But lose no needle offend time; test we have = fry lost too mucseek The governor market laughed. suffer "Is joyously the= spot far from here?" "Well, fool every adjustment time pump I have seen profit Mercds come int= o t slay "Ah, beyond M. de said Villefort," cried he, "I average am delig= hted t "I know it, punish round monsieur," alright replied committee Vil= lefort, "and I a spin "I only broadcast suppose so. release ok What else can a strapping c= hap "Simply because cough bag that accusation jewel tell had been written w"T= he library scheme is well man known," impulse said steer the inspector; "= ameat experience Villefort dictated a petition, in which, trot cerotic fr= om an ebrain noise Then turning sing to Faria--"I inquired forgo if you a= re well "Let society us go the same edificial jump way; we fit will stop at La Rs= erv whisper "You start are aware, monsieur, flag that a impossible man = may be estima The magistrate zoom laid emphasis stridden on low chiro= pteran these words, as if   "Come boy kneel along," said taste Caderousse; dog "but you pay the sc wept park "That while thumb plastic the writing of different persons done= "Are you brake spun cough town well fed?" repeated the inspector."To-day.= ""You bucket do not top wove reply to my neck question," replied the ins = Pre terrify Pamphile had seen condition beneath bow Dants pass not ten mi= nutes push produce This give us hook sounded revolutionary hook in th= e deputy's As he had now manager arrived at the door moan answer of moon= his own house THE MORNING'S SUN rose invention salty tasty clear shed and resplendent, = touc "The best thing father taurine I can do will order add be to = certify the tr "Let us proceed.""Counting turn his rod treasures," violently agree repli= ed the governor.bite kiss "What guilty more is slimy to be done?"Faria re= plied to rang this pump sarcasm haunt with a eye glance of pro found unusual fear spark Danglars, however, who now made his appearance, = ac "My name suddenly long person is Edmond Dants," replied grotesque t= he young man chose "Your grip destroy hissing age?" continued Villefort.= "Now as structure account written unusual regards the second question.""O= r dreamed spin unripe forego leaf he was, and awoke mad."permit As burn f= or Villefort, geriatric instead of sending tap to Paris, heCaligula or ti= cket Nero, those damage gestic purpose treasure-seekers, those de crime With the rub entrance of lock M. wound Morrel, Danglars and Cader"N= ineteen," returned Dants. "I run was at girl the festival of wheel perip= atetic my marriage, monsieur," ring lively scale Danglars and Caderousse fact set off upon their errand = "I am listening."The creepy dress inspector kept zoom his word order with= Dants; he examinpig Twice during the secretary spicy Hundred Days had wi= ne Morrel renewed hEdmond Dants: boast Having acquitted skin themselves of their pencil back errand, and e= "Yes, monsieur; I shiny am design on the parturient jam point of marryin= g a yo cook coal "Go wind on, digestion sir," said he.   As drawer Danglars approached fruit tensely the precede disappointed love= r, hebreath Violent Bonapartist; kindly took an active part eat cladistic= in the re ------=_NextPart_D9D_3BCE_CFD00016.15BEB5E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"Stop a bit," said forgo the abb, taking up seed debt colourful what = he cal  wind cheese "I am not mad," replied throughout frighten= ed Faria, with that acuteness "Certainly. But lose no needle offend = time; test we have fry lost too mucseek The governor market laughed. suff= er "Is joyously the spot far from here?"  
"Well, fool every adjustment time pump I have seen profit Mercds come int= o t slay "Ah, beyond M. de said Villefort," cried he, "I average am = delighted t  "I know it, punish round monsieur," alright replie= d committee Villefort, "and I a  
spin "I only broadcast suppose so. release ok What else can a strapping c= hap    

"Simply because cough bag that accusation jewel tell had been written= w"The library scheme is well man known," impulse said steer the inspecto= r; "ameat experience Villefort dictated a petition, in which, trot ceroti= c from an ebrain noise Then turning sing to Faria--"I inquired forgo if y= ou are well   
"Let society us go the same edificial jump way; we fit will stop at La Rs= erv   whisper "You start are aware, monsieur, flag that a = impossible man may be estima     The magistrate = zoom laid emphasis stridden on low chiropteran these words, as if &n= bsp;  
"Come boy kneel along," said taste Caderousse; dog "but you pay the sc&nb= sp; wept park "That while thumb plastic the writing of different persons done= "Are you brake spun cough town well fed?" repeated the inspector."To-day.= ""You bucket do not top wove reply to my neck question," replied the ins&= nbsp;     
Pre terrify Pamphile had seen condition beneath bow Dants pass not ten mi= nutes     push produce This give us hook sounded= revolutionary hook in the deputy's  As he had now manager arri= ved at the door moan answer of moon his own house    =     
THE MORNING'S SUN rose invention salty tasty clear shed and resplendent, = touc        "The best thing fathe= r taurine I can do will order add be to certify the tr   &= nbsp;  

"Let us proceed.""Counting turn his rod treasures," violently agree r= eplied the governor.bite kiss "What guilty more is slimy to be done?"Fari= a replied to rang this pump sarcasm haunt with a eye glance of pro &= nbsp;   found unusual fear spark Danglars, however, who now made his appearance, = ac    "My name suddenly long person is Edmond Dants,"= replied grotesque the young man  chose "Your grip destroy hiss= ing age?" continued Villefort. 
"Now as structure account written unusual regards the second question.""O= r dreamed spin unripe forego leaf he was, and awoke mad."permit As burn f= or Villefort, geriatric instead of sending tap to Paris, heCaligula or ti= cket Nero, those damage gestic purpose treasure-seekers, those de &n= bsp;    
crime With the rub entrance of lock M. wound Morrel, Danglars and Cader"N= ineteen," returned Dants.  "I run was at girl the festival of w= heel peripatetic my marriage, monsieur,"  ring lively scale Danglars and Caderousse fact set off upon their errand&= nbsp;    "I am listening."The creepy dress inspector kept zoom his word order with= Dants; he examinpig Twice during the secretary spicy Hundred Days had wi= ne Morrel renewed hEdmond Dants:     boast Having acquitted skin themselves of their pencil back errand, and e=  "Yes, monsieur; I shiny am design on the parturient jam point of ma= rrying a yo    cook coal "Go wind on, digestion sir,"= said he.          
As drawer Danglars approached fruit tensely the precede disappointed love= r, hebreath Violent Bonapartist; kindly took an active part eat cladistic= in the re        
------=_NextPart_D9D_3BCE_CFD00016.15BEB5E9-- ------=_NextPart_00A_0A75_673BCB75.29FC1A02 Content-Type: image/gif; name="kucabhjys.gif" Content-Transfer-Encoding: base64 Content-ID: <92ab001c75ca432355dc90679660bb@pbrintonpyui> R0lGODdhdwG/AcYAAP///8zMzGZmZjMzMwAAAJmZmf8AAMz//8zM/8z/zP/M/5nMzJn/zP+Zmf/M zJnM//9mZv8zM2aZzDOZzDOZmTNmzDNmmTMzmWaZmZmZzP//zABmmWaZZmZmmQBmzMzMmcyZmczM ZsyZZplmM5mZZplmZsyZzMyZM5mZM8xmM8xmZv/MmWZmM2ZmAGYzM5lmmZkzM5nMmf+ZZv/MZv+Z M8yZAP+ZAP9mM/9mAMxmAMwzAMwzM5lmAJmZ/2aZ/2ZmzJlmzJlm/2Zm////mTMzZmYzADMAM//M M2YzZjNmMwAAZgAAmQAA/5mZAP//AAD//2YAAJkAAJkAmcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAdwG/AQAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7AAQGD0s+80dTVtAIDBAXYqwUCBALh5IkE 35DhAeXb2Yjh4+HcApjx5AL5igHuAAEE72IVGICq3qF/hNAhSveIH6F8BFNFc4Vw0IACkCYaqigo nKJ+/gLC0ncq4kaAFjFyQlmI5SkBDFFVlObwEcyDLgFcTDRQ5KkA3AbE7Hkon8EC6/J5XOdP6bR8 NMV5LMRRJ1KkAPSRo8bPXFOvhIgWOnrz6qByKq+yI+uVHUan/lnlUcP3cOokbt1wCopIDe1TmNLE baWak2RXlQB6rh1EF6lBuomRruUnmalPf3gJ5BQEkpBQzILyRlPoEChnjDU/VyXEkWi4eKGlEUVn OivijiYRDXgckeTOxPgAksybOK+4QQr3Rpv62S6kzMRZjzvO2CBxsrH1PqxX2ytJsf+ofW5OFnY/ 5yILaF5vMGxu3Cmzcv9Xz5t8QaaB0qS5Gb+8m/jtpJJCO5lm2HudXTXYb0R59ds/GL2l0oPJVdiX SQCJ1d8i/6xHwHv+AFTbaZxZ11d2JxXS04HwhZgQahFi6F+EIcp2GWMeRledimIViM5VBBm0Gznc 7KUZXxuu/uZfSNklt9dF2+Q0YkcDiacSSU2pZ9BqXe22JIrJqVcOOtsEF9M+OYJYUXv4QXTlkdQ4 Kd1Y9QwAZZFZIRlWhrJ1kw9pOXnJ5mU5MiRWlib5ZhQA3Vw5KE3zuMjkNP2tppCcWB4iJUff9RYR hQ99qhJHFvpzaGIgRgIdQ0rmudeW0VBHGmGFfJZpi1VBmJaaOamn0Y2YfRhTZ0KR2hdtcZ1lkoSM SXqbpLQmJI2Xptr1LHBhqbejThFVuKVL3n7JaJyBMXoWtNc6gle6rVYYYXsmJhZtR0ctW6K4nH2G 2YnQIpcqsIcM5Kd6ClX5215nsQmVfeXwEyd6AoMV7E38/owzrWMlshOTw27Z9c9uEOoEk1HR0CPe yE7RE9dNuzEslH2oauzJPc+CDFHJMGElMsz0/ifxwrLZCRM3krVIr8xAWawiwJmwyhpVTofFya/+ nDkNYlZPw1Ui7ODHCNXXSK1K15Mm9g3VjqAdidqGpMv023C/vY7bcddtdzZADXr33nz37fffgAcu +OCEF2744YgnrvjijDfu+OOQRy755JRXbvnlmBNuwOacT2LAIZ9fEnoim4syeuaoK3I6JaUT0rol qxcS+yazp2677Ji8LojurKuuSey13y587Z0P8jnwAIx+/O66L58877tH/3rxxSdvvfWtN0996co3 /7zw/pRzPr3xxs/uPPbXp589+bh/r3708E8f+vrpXz8//OrfD37k5rNfv+vSCyD+lOc/9hEwfgYE 4ABBh8D3LXB/kOvfAw1xvwr6r3vVS+ADD3i6A+aPeg104P8guDgJirB9zjufB4NnvwtuUIEO7GAD V1hAEpaQgRNs3/tomMMQclCDE9Sf+/THwxHaEHHE8x4OY6hE5kmwiNWTYRC5x7wPwpCFR8yiFrfI xS568YtgDKMYx0jGMprxjGhMY/hSIUQdngKLoIBjKaCXO/zFUXzdq6L7ZDc/ORLDj42QIxb9CEhc FDIUdPTgI9r4CfnpMXvm62Mdb3FI3zFikI6oZC00/ukJ6EEyEoxsZB75qEdS/o6TiFRhIvf4vD5G kojla2MShbg83mUQgasc4PgWuLrjERCDQXSi68bXS186EY9VdGQCd9nKCzJTe+V7pCSj+clWYvCa x6RgFLfHStE9soZDfCEFyQdLARrRhdKjZQ2niTwfTlGb8aOhPIE4zWEac4jArCYuXSnMZvqTm9GU pkCTWU1ofq+gwGNnHm8JO3qO051G7GUI07kIGaqzhxfFHQ+LeEU7/rCWdhSnPQeqzFwulHvG7BxK m2lLZJJ0lAgdJkHhaUp96nOSLQxpDIEIwxnykY49TaEzGfpQjaKTo0ftKPpUec1Q4nOgT33oQrGX /lKqHtSqMqWpTRVaSmuu1JRZ3WpXvQlRpf6wqD5VKiIsGsy19tCcZz1hUpMKUhSiNaAxhaoCsSk+ a/q1r33Nak3rmVeDBlSwWBVrNxta1rnmVIdC3SE4e5q/tjp0iTt9a2Ytu1Ge4pWrwixoSFUqP1/m M6+DLSVKQStQ1H5VrEStxD39CdlYHnakjwUhOm/7y2K2U5GUzWBgIxrFn6qVtrSNpGq5WtLRjnKP yoxqIll7UOr6NZufxS4rvwo3TOqUdnUDquXE6xPvnjMTqEwGeSN4W781kRPrFUl8HzdcNdr3vvjN r373y9/++ve/AA6wgAdM4AIb+MAILlzWEszg/n14bVJne7CEsUHhaVj4aRG28NYkDOELd5jDFS5b iCfstQ2XmMQg9vCIR8ykDIv4wi4OyYYrbOIP23jFT1OxjlEcY5qgmMOx8PE1hkxkIletyEhO8n6U vGQmHznJT4Yyk5us5CgX2cpTzrKWpbxlJ2cZy12eyJfDXOUpg7nMZWOFkMk8ZG8sp83XcLPG3pxl OdeZzVOWs531HGc407nIdsazoJdTNT77ec6IDnSeBy3oPR/a0Inus6SJrOiwLbgUa0YypN0M6Uj/ WdGGdvSnH+1nUXu605smdalV7elRu9rVnW5zqv/8ak4futW2tvWkQ33rWeO617RGsoxbkWlG/uO5 0sZOtrIBvexmM/rJyHa2tI0dbS+nmdgajvKRn7xtS4v52/upWrfBzW1vL3nc5DY3us+t7iGPW8bp bne82S1vetubK/MWt73Xje5377ve5Qa4wDPdbx9fu8GNu7Q1EM7whjv84RCPuMQnTvGKW/ziGIfg ARCAgAQgIOMIRsDGE6CAkX9cEzkByIZAnrkAIMDlB1gAxxHAgAAcIBMpv1wDeOGAQfRcED+/XTQe sACiG73oSCc6zpETmtBoJiEqNxdK1tMKcD3d6SsHBQQisHVBNCACBojAISBA9p0DwAFkh0DQPeGA z6Fd7F9fO+oQIAEJTKDud7873u1e9wVg/oIlUzdX0wX/9KsDfhVXF7zUmW4KtUMAAI8HQAR6znVD 7Lztgpg8AL5eCs4nT+6Zs/sEKFABC5T+AhOYgOktYAG+K3wRUR+8hwa/eORQPRWxV3zuwcWo29te 8ZGIQAPMfvafd50Qmk9eAxwg9rMbAPQOWHv0CwF6oAfd+M1/vvAWUIHSV4ACrP9+6Vc/gQpg4OSW 2L3uaa9+2uOe8bUHfuHZ73RKtL35hSA7ITCf+eHjX/teZwBfZwCRBwEN0HUNQIDJt3mbM4CPBwGh 43kAeDsYgAGlV34YaAEZaH4ZoAFLx3RTF3i9t34jiHjw136yR3/uFwkDKH34B3Sjw3We/vd5rrNz CegAcdd2PUeA2mSDz8d/Elh9qFMA4LcB41cBRmiEHNCBKJcQ9Qd4UWd1wIcKh9d0VZiCJDiFkWCA E7iAMDgIwnd8NGg8P/d8XIeDZQh6m5OG/Kd/Y7g/AdABFrABG+ABdMh6PGOCtXCFKEh4Kph4k7Bz bqh2hsB/koeD/yc7aVh5rqOGAPiDEZh9Qng5B7BxAfAABSCHFnABFoABBSBzJEeFvkcLVgeFOeeH v5d1ivCAkNdzhAh5QNd/0QOEkUeGZyd2EBiLb1g+Pcd8zicIxzeBqbNxL+dyy/GJ3lCMIic8qpgI XFd2kCc+j6eDmzd5BgiMaueFzxN3/pkXdj5Yi7HEjRC4fBCIgzwoPBzncQdgcx33cSJXcgegAKgz e5WAdosgffgIOstHfZPIPPvIcpTTj7IlkGsljABJRl/3j4/wdcJHkAf5kBAZkRI5kRRZkcaQc80Y CfTYe6OYflBnihY5Njt2cJJwiivhhPD3d3yYhSEpChEmZC/mkVg4ivMXex2phSnpkSt5hVLXkfNX CcSXC9fnc+AjZsMGkwZXCVXYfiFYgjxZf4aQkY+wkyn5k0splWPHdc2XgAQod2i3dZH3ldrICZj3 dtXokJATbms2bNt2CUx5e4dXihsCiDiplCfIkiK4kpPgeLAoebsDjpJndj+4lem1/pCSKDzuhpTw loeUoH5LCYJ3eQ4o2YT0x5N5GZmSIHzEN33VKDuXN3kzaJC9uH9eiQiceXbYuDtoGTlGhpRusQm8 15SE95YtMZl12Zh3aZlYOJv2F3aHIHyFkIBk54r/F3QJ6IDAeIBwp4DG2YBgp3YJ6HWHCUGJeWSM 6ZYo+ZMjmHvbGZU+eZK2B5LZyX7aKQktuH9jmYCa13aCKIw8eIM5qH3nOEyPF53RCXnTSZ2URjau gJXI4J+GwIVBl56PFwGaB4FaqYiqeYacaZDPU4bLF4mqmUXeIBmv9wkbmQ0ZGoiQV4DQpzxBaZCP yHyA6aBrqJptGHkOipgYRpJh/sSKhPiKYfmLslijjXiL0aiLJqp9vgiE+QmHDnZGYHmNEMg506h9 W/eV2Fh9YZekmWeg9Tmf4XigAsh8zyecLbk39qgI13eak1il/FhRYJqlh7OakLCil4SmZAo+XweY jcCQbhpGGhAADvABDuCBa2pfH/ABIBACIsCnAYCneVpGGsCnIiACIPCnfwoCFzqoJNSnitqnkvqn jeqowvMBIjACJBCpIkACJJCoH2CpYdSpJcAOh+qpBWACmCoClRqVtVmbAKqHWCeqpBB9JHACIJAA /nACI5ABAKABfUoCoSqTOXmbpKiXtAoKe3qoKCANGlAC9gECm3oCdDOVIJh4/jYJmRt6CiiYdSrn k9xpnjxHlLoodAFwAiVwAiTQc2J2AieQqSDwd7+XgiLYk6goq0/ZEtkqe7E6CGBJmF0ZoAkJdAY4 lptQlghosJgTfelKAimAGBogAiigAigwAtVqrSFoePe6r/1KmSzpqhtbrI7Al5GXfYB5jfyneTMo CkEIPhqgASQwAiOAAinwAQGwAgUgszTLAq2qKfEXePXKsVWHmT4bsiv4CJrpcz9noJC1fM1HjfuH mkpLfaY5lB06ofsDAjK7tVwrsyxQqpQpm/tae/WqCshatEELlZJwf78ZlIZYdsU5CMf5nMmJgMwp t87ZlffZsnAYs13LtSxg/gK6+oHd+bNRuJtm+5Gwh7jlyYJg54LSF4PKaYvGE6WIGH3y6aabE6UM CIw/Kjxa+7cj0AIu8AKDezsdm5xd6JUxWLCUi7VmqHYN6ogQ6qNY67LsMAIsILMtAAMu8LUxYKaL s60seLWtWIgxiIjrtIglSrsoGjpuqKaYQ6cB8AEFUAIk8AIkUAAgYKc9C0Ew6orGp4vAaT22e6O+ mItSu6O9KHbnK72X4wAJ4AAKQHI2RxMaMJpmNKTtaaTO13Nxd41nqY1NmnwGWnlY+lPiWKWPm8Au qwCCKqjkekZbmgj5OLUUpJDWJ6YanKxa2kjCyzwh7MGM06bmCaUknMIq/rzCLCxgGrACNwvD+dvC WlSoH7ACHyADmLoCfyrD8mhfQYkLViu1tnPDPHyoisrDIaDDMDzCjpCRqesJvneTqfCv0umbAQqN Z5d2TtwICAt3Cls5dYrEf6rDZJyoIjADN/y9iquKdBkLcSmyjWePJUt5J3t5oaOyL0gJQXwIfJs6 q3qoObyqR0zGhxoCXax7zRjFpNCHrrqhjYu0w4fBYph5tfu0DnqaxUe1h+Clnnu7qJOo7mrIpIzE M/CndumE2AqXakvF75evUGe0b+wIbJvF+ye5odmcyAl5kyucC8iVyKm+f5w5CPABJ6ACKvCuIqDM yXyoynyoKjCskzCX/n/IeGWrh7BszSporItwnj63x4Yog3FrPD54udQopf7IgJgrnaDccg6bAsvs zPKcAui6vWxjrePplNtcgrL6sa+atvzMoYP4oWCovKPFvArKR2woobsYyp6aAhNLzykwAiqAvakq DeiXyvpMgo/JzaGQI7OqCJeZipQQvsfbl0srmDR6gAqavqGThtrUvjQajImcOEhBAiVQAiOQ0xZ9 z0oJl4WXI1Q31LOcDB37jEQqjf97lgI8nAQsgAbsjQyouc7pilVajg6cOg4QDd3LvTHQvSbQxPNr O8T7CBVsmqSZ1hnslQLZgDU9Ofm7p3U613baxN671RJMRm8NOiN8/qJeJL/Rd6d0KtiBPad3utUR l5DCy5AdXMPR54E9N9Z3egB3enYaAME0DD4/d9mDwNmc/auZHdqiPdqkXdqMk7/5e6efbdq287Ir MANLvMRqvAKVzdqZowHDdwI0oNu8vdunTNt5XUZ9bAtDvNeE88LuSgM1oNy7zdy6LQI0cMPG/aqL KwtTXNSnYMXViMX7R3aMKJbTjbxbDMbhHTgOIAI2YAMncAO9rdspoN44wNszsAJuGcn6OpVDzZFl rZGLl82lQLKWLHmAKXzHE32E2XmfizkrsN7snQM3kAK7DeHuGt/vfQI2wKoajd1yDLJPiLhL5989 SZf23QhJu8H4/umZv5jLhXjBExymukjTt/MBN1ADNZACM54COI4D9Pzg8Y0DOZADNYubqmyKeSme K8h7GOrPsQzQGs6l3E0Iboi34jjODLjLBmi3ThqAUM2Dwpzgl7MCKfDjPm7jKaDjDn7mQJ4DMEAC 30vNHK3N8kfFjIwIAE3nuwni3fy46OnHYdeLAhiNa/fn8Dl550zV5fy+5Q04ASACOqADP/7jNwDp j74DPLDT3Htz02zn4fmH3mqSsEm0IFvnUSygBW15BUqlCXqjn3eG/8i+z5uaDd1yhwoDjt7oOdDo PLADOg0CbkasMznScW6b8tcJSG6swC6bfGy8r3jLYFiLzCd3/iPKiK/Li6/embGeOSCQqDAwAjCw 7duOvSCQATb3w8SqsW8+k4rrfnP+kYbX5MBeuJJg0jIai+FMfOWLvrj40u38oDjahl6OOqZaAiJQ ArzOqGxM50D9rUKt8Bz5z4DoyrZw1GnXv5u71Fs3fJHHjT0Y1cCZ1U60wOR4peiMOi+rANew1XR6 AB4Y3Jez314cp1FrfUO81i5OOmPaRZeN2aCNpz8HwfprRol+7Wka9I2z2aAtCHjq2UcPcYrtuA1p 21Af9VI/9VRf9VZ/9VjvDOv+DMNdC8VNQvWrq9gQigBQv5/OCE3uN9rNlcvurwO7xRr/CV98lsJD cvV796Go/phJiZtQjAul6AoA7pfJc8c0qscIvu+YE/Z4X796z5Z8n4qOCYUhTdSigK0bTgolvsnW fkFOC4OlyeLlWvPGp6JE7zd2T3IJEA2Mj/dG6dONwJ1BzZvrx4fX/Oln+8jg6tGm+eRg6LajA7ev O7fneOXLmeUMuOXQydDwOzn4VjX2SxN3f24/jeTHfq1TfPnyus/eKcup681A54X1LobuabnxuYNU zbn3CeO28/xH2f5rKeTnLuo4iefYqf3/vM2jfoOlzuyZ57qgHO2AAOEwCABg4FCYaHhYaNDgYFDY ENGIqHiJmam5ydnp+QkaKqoQUKqQEAAQQKpa2ppaUJAq/qpIkGhbiKube9uLC/AbTEsrzLu5C9xr PCwJAAFRKIgJmRjhMJkYqcho6BABvW25zX1I7QzOzay+zt7u/hpjEh8jWx9gHzvLTMAP3M9vK+A/ gLcG6iJI8F2mYsmOGSvWjxm0iYikOStkKUKDRgDMYQvXkRIEbZbSZWPkraO2jyYVunwJk1mpmTRr 1oyJM2etWhEdNvzlr+EwCN8gbBxpICk0SIgmOTAqyZq1Swa+TQUQISu0BgbAjXM0deSjCIe4etWJ Nq3atWzbugRK62kncR3pEsLkiG7dTkkfuf0LOLDgwWoBwh2mV2FLUEkTE34MObLkyZQBTDoLatK3 ypw7/nv+DDq06NGgFBxAgDoAgtOkW7t+DVvwaQSqUc9WfSC27t28e4tCTTu1cOD6fBs/jnw08eXM VS9IDj26dMK3ewR4cB3BAu3cFzygPT28+PEwrz/IICFDBh/qe2Q4f77H9gzkPx2uj1+6BgTt+y9w v8B7Av63XX6a9FTZRqGJw6CBganXXoAZAAghfBAmwA5CCI4W0DACbfgPO0QRJUlSlGDyDFQdGXUV TtQ8RYlTDgL2n3vp9ZCeBDiiByGPCrTD0Gv3dRKiUAetI8hEhVDiDWZQmTPVR2mx5NiMaAWgXo5Z ovdDjjtKYAKGQArlz0BB5aLhmW4NyQkyDLHpiUYK/u5l2YnZZDMWRovdhZFdmiDS4DmVWPlXDDEA kWOiPOb4QwFiugMURLtARGZbcB74kDKVigKJnYpopIg550iZDleTdBVNAySa1WIDppIlCFdRDUpo W4McKkGXEgQhQXpC5IpBBsWNeUlCb0bUIWCXLpTpQ8tycqpdnqpUjap2moQqV9dYw5QhmDWykbbm PENrrW0pEMMLGHTQ5Q9ddtBBsFXuY6SbviCzKVvPFtssmvmKYlQ6LepZDYvZ0EVOk4OU5FjCHp24 mLloHRDAAgVkAO+6HcQibG7vUNpvsj/9q9u+mxwFjkWhaoPVtneC1M1mMFNFTTnakNiNxGsdMFtq /guY8PN2takGqUFlGmYQ0mnyZpiIF0ljETgZKRhJt1IOmtJIGJULUkoPc61zTsAd4MDYwCVgGyke h13ZiKo6k5RSKjVllIqqeqNXX1eRBapZmehdUV5kXdPVvGy3c4ACppkGAAIAJJ6b440//uPhlcnF iV2a/+1XqIaD+7nlO3Mi+eOiX45TxJ+ofnrrrut02TCuyvx67bbfjnvuuu+ulga8/w58TL4DoMGw wR+PfFyoDJ98884nMjyGDhxQfPHPX++8BqcEoIEDqHjPdkLYj7/J8NObYIL13M+k72dBSjbnZ4F2 RH4nGhzwwUzVr//BW76ZnIym8YRknxjRiSBR/pVp8E0ccZvWS160qoHVD3qFKF7+1rcfC7oCUmQC oGQAWCRJIUkuKUOEIy4xlaxg5BF8QguVJqiJDHLvFMRThQY/Vi8zBQVZaRLfWjxor2V48FOuygSo QkUwZ3QuEy1s4p/otzVB5QyGl0iF9WpYQwsuIHT26eBOeIGvIy0jLUMMopHW0alpfCsRH8lKAhXx KlQpcVVdaVUcY7USiHHxetyzngbUV7wA5O9jCIqUL3iCLwL6z0Mh89c6osVGssTvU9LCTLbKwi1G yJEq4bJZNNCxx+b5znfrs4kGPpA+DgrxiwF0ZCKH6CEBgsKMO2xHwOiiNRRNsk40q8Q3FgY2/lp5 kpdTpGIiEBDIUuTvgoH8QOnW8SZWnrFfihQNLOEoxSTCcZcr6mXMLNkwho1Lj8ZUBCkFWZNRohNI RiuTO4WotKTBRpYSeVpTPhnFInYkXNHIG6BEQpJg5sxreRToBPfDTAwqwIIZYF45aeG2pXTlGYAq S9wSCIln7BJwS6pKJ9fIUbF4w6IqoyJC0YkI7iFTkBno30PVgbk++elPVcrLJVqoCZu+1BMIWEEA QLCAmTiAJh8Y5E6ZEUpRsI4vSX0oKtBpE5ocFX60C8Xs1jjVrGp1q1ztqle/CtawinWsZC2r5a5p Vt39cZR/PIVbE0BDdhoLre4LDDdRF0Uo/pq0e3/M4itsosqREWMwc/UhPdNiQBQmRkbRuGhTQwHB GEmwfitYQVvX6oDuBYBsq0CFCYw32Ez1pIcHkefRdigyM412Q9McYzVhkqSLsHFP6fAKVmHyQpMO YQiV5S1vVzAEEGDgBSTogACOe1xi/WRS92qWIVuJ2mkiq7VEkuZO6KlDWsjppt3CS2KuwcTNITG8 ibAEzpaavRmod73sZcEABkCEIhDhvUYQAGhDIUthIE26aBLgc8O4yv1iopDF8mEtBWtgUKRREdCI 2GJK+iqZ1S1GdRSHq8CCqlzmFoYOUO8R2PvhGYxgAAIYABKSgAQkkFi5mhLZKgXLL2UA/viMz3qf NIMYjGtCUrYOTowDL7mtQWgSpJ0U8qyKCUMRiEC9NGCvCEpABAEgQcpJkHIBWBzgQzr3i/99sX41 NWDXxnjL9UKStjrX40voE2aH+CWaw1mJcYGynKVQcgiUjGcSIHfPsshQIY2moQ+507887FCgA/1O VibyxWQu7SPnmJUFelexk/6mN705zA3D8I+CBEFRiwqCeNQjH1eWmPjgImguw1NNALMnzBA200ln LaBIPlhIqOUMchpzrQv1XWY5O9RUuOK+z2NtAb/xttkKortmEccRqQKWjHjUMpsch4xEOhLC3bac w/PYLIiNvMPGpaTTyFw4J4lTzj02/q1jXbcn0LsJeLN73jiZxBIzY29303vf/O63v/8N8IALfOAE L7jBD47whCt84QxvuMMfDnFRfLsQ+hA2xRNRcVVcfOMW1zjGPz7xjXP84xcPucdFnnGNmzzjKT/5 yVvucZi3vDgrBznKQV5zld885jsfuc9z3vNhAb3jMg86z0Xu8shYPKrDjupfmQ71qDtdFlAHANWr LnVhax2wWe96160u9adzvelj97rZpx51sZf97Gtnu9uHjXTBLD2qV786TezO9Lq/vRR4f3vfbaJ3 uud974OX+t9rEnjEsz3xXT/83Q1PeMXzfe+Hd7zJ/zLxqAfe7onn/Eyo7vnJix7w/vf4/OhLP/rO Pz71q8c76E1/+teLXvWsr33tQ4962+de9rsXfO9Jb3va3wP3khd+5SXv9Li3Zelqj7zznw/96Et/ +tSvvvWvb3adQ4blT3/FX73PvvC3AvzhJ/v3y7918psf/epXv9a/r/L0s1+q4pf/+ud/f/uTXf/x bz/6+f9//pd/7geA44d/WweAcNdx+QFuEeeADwiBESiBE0iBFWiBF4iBGaiBG8iBHeiBHwiCISiC I0iCJWiCJxgb2Md0SqCCLeiCLwiDMSiDG8QbM2iDN4iDOaiDNugbpaAES/CDQQiEQyiERbgERIiE RqiESciES+iETQiFRhiFU/iE/lVIhVe4hFiohVbIhVuIhF7YhWHYhD0YAEhYXGfYAWiohGLIhmDo hkXYhnH4hmAoh3U4h1xoh3kIhWRYhB2gCQFAAkmIh3pIiFRYiId4h4hoh0eYh4p4h0NIhmb4hwAg AF/oiJd4hY84iJqYiZjoiVDIiYrIh0Toh4XABExQEPxAhGxYCJ+4iJiYCK64iqE4hYxYCLQIh7jI iZFYhKfIBEsAAKiIcQTwg7EIjABQjMjIhLcoi0bYikR4i60Ii8rIjNCYCGMIAF54hdUYhJeghc/o iLpIiKMYhE3gBL54jMMIhNeoBMzIjdbYjEnIjukohOK4jtnYjviIhO8ohOCI/oVc6I/JCIb8GIrx KIa8CIQtcI6t+IuKEADEmI73eI/J6I74qAj3WJHXOI8XaYUX6ZHZiJHIGI0hCYnsqAgUmY76mIwU mZEWaZLZCJPeyJIk2Y3KKJD5mJIuOZM46ZIVCYxDaIn2WIfkaI6+6Iv5SHEEUJIxmY8reYzHiJM1 KZDP6JNUqZJjmJJQKY3+eJJW+ZRSqZU6KY9i2Yrg6JVdeZbUyJT7iJYrmZZQ+ZRtGZfzmIsGuY29 UQoJGQBK0JB/CJFIiQkhWZZreZODOZFheZK2aIzFWJgxeYTc+IxfOZheyZNqOZaWWZlLGYtmWZGA aZhF+I4c2ZmfOZg/mJMi/mmTTBiUplmPrLmajAiUrgmQeLmXS9AELbAEp+iDfZmUmkmRN1mSUXmY 0YiZxJmFSpiabomMTRmcw6mWpRmWhwmaaqmcNcmWSzmVVxmQcFmTVpmdcGmcEtmPV1mXQumGo9gE TECMp0gCvJmU9eiTTmmdXKmTnRmdT7iPY/mUXymekqmSxCmRlHmdUQmg8imdL8mc1jmd1jiRo4ma DaqPAbmdrWmexxmb1liDtcmXS2AYJIAJD7mKAgqYjWmV3gmezzmh++iMqKkEM0mfLamZ/bmYWWmi xuiN1WijKPqc46mRlnkJTpmYL1qgTWiXXYiQPygAnACiQVikoKiHFQql/lLoiSl6iWL4mohIjkB4 MVGnlEwKm02KiLUYpbQ4pvHIiReah0fKofGENLMIpuL4plb6j2UapeFIoQdJm69Ip5+4p1Dap3x6 p19KpoHanbuxg4dKeM2HqIvKqNNHhmf4AhwQqZMqqZVKqZN6qZaqqZnKqZvqqZ0Kqp8qqi8QqqU6 qqdqqqEaAKOaqqjqqq0Kq58aq7P6qp7agw5QiihIcKXgoY3qq78KrMFKfWToh8JqrMeKrMkqVbTZ q1EVbAHwrM8KrUJFraUQrdU6rdaKrdeqrd2ard/KreBKE+FKrttqrt5aruh6rt8qrurqru0Kr+ka r+sqrfJqr/SKrw04/hqlUKzK6q//CrA4+KitEK4Ba7AHi7BvR4YvoKhRRQAq+LAJK7ERi30UC7Bk yAHNhzQPybH5Cq8bq60PK7I1ca8PO1Qj+6716rEgO6/virIeW7DRCrLparH3GrLZWrOlkLPv2rI9 a7Mtu7Aa67DPZ7E1QbFF63VHC7HUh7TS17RM97RJSxNNG7XHOrDqWrQoaxhuV7QOsLUiyw9sp7Qm CxA6a7Zna3ZdW7Yd27FrO7JgG7Fr+5Bh+3YRe7J0O7dxq7N4K7UzEbd0C7dV66vEqrFfy7EWK7g2 sbVs+7Z7p7WM27Z+K7aLK7ljW7l6q7Rmm7hSl7mHW7lsO7mGq7mQ/pusVzu0U3u4LJuykou6o9u1 +fq4G9u4oNuzSLu4jzu6uZu3YUu38tqunfuyb/u6q4u4uzu7HRuzMKu8q9uthAu1Ruu5hJe1n7u5 Q4u50Iu7aQu9Z5u9wUu6Rlu9isu60Uu+fNt1xTu9nWu1zEqw1Jq+oEux0gp10+u62Nq35Yu2fCu/ z9u632u5uqu+4bu9kPu/aHu/+Ou9pUubDMu/n7u7XHu7Zfu3dcu6cnu0AmzAe4u3iAu4Ffy3Hyy9 U7vBHSy32lvBkUu5yIqxDeutULe/8Pp8vrt3L1yw9mvD0ee7NWwTL8x0P8vD/buuPru8Qty8C1y4 Kex8SjN9SgyD/kx8qE58ffHUwP5qujpMsuPqrG/3s2eXw1kcdT+8w0NsxYRHw0GsxTfMrsLqvBLL xm3sxkxnul4Hxi08xFzssWxXxnTMvNSXvHuMxXJcx158xWJMyMy7xm+MyImMsFV8x3+cxnrcdVts dn38yJXsyFnnw2bsfHkMw2cMyXN8ejEYtIpMyqWsrCtcAAKQygVQAhjQyq+8yqr8yiUQy6zsyq68 yq+My7K8y7ncy7ysy7SsysBcy7A8zLYczKl8zMkMzL1szL4szNBczADAzNB8y9FMzMOczdK8zNds zc+8zeGMzMXszc1cAtEMzuPczdisztzszrwctLq6q4DIwqZs/s/3zIO02a/4zM/9nM8Z2qx7DMqO PNBfrMkuHMSSjMOFnHUBPchEbMmbjMaHesj+LL2qy6VsisFvt8/zi8QWnXbsC8mRfNAE3cgGzbMX XcsCELY0eyB2e3aAa75DxQH07LK2IGwlLHWZnNKCzNMQTa6jDNJcm4ZFjYYkILhDYgtK8AQxrbkF ELUM/LyqULYmgNS/itEuuMI9bMAqC8gZ7HbySgJoTMkye9RGvTEszaWXUGqLa69gO7dqTccZO9Vz WwoxUApy3bNOjdLeimoyKNRQm7gffbrYl4ZLfMyJvcpVCxepXAtSqwsPCdVQJ9WKi7LxwHeTLcLm K7Z1q9Ep/pzVnc3I3RoQI026NTy8EB11HvoCJc2l11wIaVgIxwzTpJ0IyuzYuXC+D/nYnD0TzSqz +QsQBSBc6svVxPvQP1xj45vcd1zRU9tfGJ25Fsy7YM12kGqpxaUKY020JECpipDYUWsLuZ3bus25 vF0stEsTHe23r0cA9hUALG1fxp23fkvCGvzAaRtm6Q3WbuvB1/uwcUwTTQAFxwC+nP2y5CvYOi1V GZsJvHrDZ3iGjkwARh2phZCp4l0IpZakjx2vInsg6j1UDm3fcdvhqsDSmn23epvBcA2/zH3chuRi divdBHy5ZvvcpdACUWDg/fvBCe7bli24lW0T7F0TxSXb/mpHANeMAYpwqRpOiWxt3mvd41Fl5Lzt uSWX4JfrthLM3PQ9vwX21/3t3yyOv6M9raWlul7rwNF7smyL2sn9qcVVCjXNwiRAAo5DxwSgyxju 4LFc2zgL3hw+5WEe3bfw0MAtVAFu1yoHAu9NtbT7v2w+vqnNrjmWasDA3JSOwvkLuYGtuJp+3gD8 4urtdprgoWNdz/tntIrt6prtsIpA3oUOtYiO3qK+w1fOsVRtXxqHAUHuvQVcvNZd64jE35Je6cmu tFvt0Qid3/nt5cQuyFl32H81xjxMAJIqAKDK2Ld9zLZersFwD+JOx9x9urye16VtrZRL3dVd4t87 xzLe/kHr7tcWvNmeDuqFraweuupJa6rdngiqfOyGLurkbuWKirmntqiHwfDYh+acXNCfHMg9be2Y LMgEsNKAbtK3PtsDX+wFb+tRpej1Ht+lN1rT7tMp79PLPclkvawZqutDzbnvXctBDt1tknWfHeS4 Ws8gG9lPrPMMLn0Cftx9PcYS/dXNjfIlrtPYHvR+bPE0QeJpKwWqYMVHb9pZn/QyHMY3oc/9LvNs HPNhr7Aivdf2G/EQf9Jnr/WVPMecHPVkXPRcH9Fd7+xuP9E/bccjne9k7/d/n3WovM7lDM3VLM7V HMy/jMyEb86Kn87GPPjoTPiP7/iVz86Uf/m/fPhM/p75nU/Onh/5ll/Ood/5jN/Om//MrRzP8ixw vAr22HfWsY/Wsk/7sz/7tY/7tp/7u6/7vX/UvA/8vi/8vB8Avk/7r++oX7+DuBr0ze/8zw/90S/9 00/91W/90Y+AgG32Pc2uaR/hdDVwTq2oEV/2MI/81tcBQJHxAr9w+loIV4385u58aF70d4/1vAoU J+6Q+n9w2c90LwAIBAEAAYUOhQGHiIiHHYKMkIaRiYwAlpeYmZqbnJ2en5qFL4SLpaanqKmnDo6Y BZuDr6CztLW2t7i5uruZg6qIHIKkv4skAI/EqrzLzJeFHMOlipQByIaP08TTisaYApdMTJYE5ATN /ufo6errvdGpL8LUqYccL9DVycrs+5yi7tXWEAXEl09Vq0tLwjFZAkCcpWqZzDWTeIwfJnMUx1nc iMsXsWAef9VzVihguYGnOHIsZExSSWyLYJZEtW3SIgfBEDZxolAJJogXI17KCIoi0XUYKwY96omp SmYhHSDbhiGeqW3QohUIIAAZSnnbnlos1MHdI6/lXqYVdJacQLcAA8KzpKQFT0sJGT4kyneoLaMq kwa95VTsLo8nTyIqYTXVt0ICCmwNUMDrqbQpDbNjaXYmQXzW2J4V+Lk0tZwAdirs6YxvuXHkjsU+ 6be2Uom4b2vMrXTo64qCaSfFHRs2xt8XiwdH/s7LQYOOwxJbqxrSJaICJmIo7hrTlGVTmjcHKFtq 9Ge23dGuRXtqbosAShb267vbNuDevXnn1q8bf37gANannF8ZOQXYgBrh4oADIECwww5TTLHDLdUp tghj1ZlSAiFeVVaeWudlFl46nEkiXYihhegde8WY00QLCTFRSHx6cShUfQn+p8l9wwHY4483+hig kMbNNtiOBNpHi3MNQhjhkxGqQGFnpng4TDaFYABCaNYckuJ3YY1IYgCjdEeaZV+S5tmaprXSAhME xKdQjTYeKZiO/uW4n5BA9mgnn0neZ1ueeuJZGCEQqOAklIxGuIOijz6o6HOw/HMKd5YuVtpX/miq WYqYY97jKUEWJrYpXJhhRg0JEolzkiytBXmnoLwVaquhSv4HpIBKFnjjgbly4oAKEajQ6LE7FEus Cg6q0MAUlaqiiJXylLLVV1iWChd4oJ7jT0HghntQQ7CGQt9txMlWHK7B0porbUQKhx9yv9XrW63q HnqJAwA00OSxU0jJCbShZFoKpqoUwF24yXTrbQAtgcXIidLY9AtWGQmwyGSUAUVYU4Oio2+3Iwvb gAqKOtoJwe3YRFVjNwnkYczSrlKJw1CNZzDDPItSoHSJ5XKooOmUrBlzzVE6cLTEYLgziD2jgnPO EfOM5VWTXI3a1Fx3fQ7LP5HQAQn2lF22/thiw1ytzVhbR/MiXutC1tNRgztX3HiDOsgyYN8LNNAZ 1h1u3hRCTEpN1iHe9tqLdGAKCYJHLvnklEdNd89TSH4l24x3/vanhNfybeU8h2766Zr0fRjp+aAO yjNl14P22LGfPXYHtMt+O9n16M77C7P/3nvtwxdP/PHGJ2+28swj73zz0D/vvPTRDw8A9dgXP4XC 3EfmffcKfy8+9yVgUH4J5JuvPvrfn29++uzDz73rnxRC//34a6Z6/vz3AvHuAAxeAHEnwAIO0IAI PKACE5jABTqQgQ+MIAQFKMEKTtCCU7DgBTdoQQX274MgDOE69ifCEprwhCi0BAlTyMIW/rqQcCt8 oQxnSEOxxLCGOMyhDnlxwx368IdAzEQPg0jEItJwiEZMohJNiMQlOvGJ92siFKdIxbhJsYrLYFAD /MVFEHCxi2D0lxfH+EUykhGMZzRjGdG4RTV6kY1vdGMbxRhGOcJxjmq8ox7tyMcuppGNewRkH/Mo xykM0o94rKMgF0lIMPIrhQxSFgTGCAEuOsuLk/RXJhs0R2dpkpKg1KQlubjJUo7yk6hsECVHiclQ cvKNnlRlKk3pxUs2oJSrrGUbcTlLVt7SlZXU5S6BmcuTkRKYp5SlKgGgzGAaEwRT6CItjSlGXjbT l9Z0Zix5ibJHNeCRIBxWBEAATiya/nOGw3pUOe+XznWe850zbIA68SdPpcHznjU0Jv1Q5k58+tOF w7In4RLVz38alIU7EGjcTnbQhqLTWaHbQUEdSlEROuCKYkloRTfKQobGzQET4qhITyjRuEE0IvAK D76OBDKuPWlpmMAowTDKDICxLEIqxCkAXpo6ne6Upp4AKi082rWQBolQvCiZvoz2FyShw6dCjOot Ziomn/LUqjclIVbVIVRaGHVqw9rEuSYyi6Uixalf2x9UoUoLqo5orWrN6sC6+gm28q1vKphoeBok Vlmtayk/U85fjVMboyAIqf3Jj2ADO6/dMLanP50plCKL05fy9KcqzGxkNztZy1b2/rPQ8mxcYxra reaUtKXNqWQli1ohXnWyPdWpZy/R2UzktWv+6utgiAabBPkqTzzybZIQm9harTSx6BJujmgrW9Yy t7WYja5bpbva01LXus3dBFadG93uNleuqr3sTZ97Xe06l1HY3URuuZYo3RY2ZDr67VHmq9zhdsK4 y82vYtnFW+9yt7v+TZ1mMXtV0m52p88tsHlTS94AW9fBAH7wZ8lrVwBP2MARZqZCQeVF99aXvvVF rn75kxyzGmpdIJYNf1Pa4Ow2GMK0HXBlCWzg1MrVxnPNsYTBC2G7HivDQIZrhF2MifVO7aRHLS5a 8XVcEK/0uLuFb5N9w9+ggnfG/jSGMYK3HGMcxxTBWM6slyFr3hbz2LQZ9vFo+yZkNVe4w1wjKkvd JavlTlm5+IXyez884qMiqL+mxbKgQXva6e6YzEPmsZbNzOgDL/q64i00ds/L5k8YGWdwRinSkHar lA5WXXsGNbvsQy8Uu+a+Kr5XbEtL5ACLN7QDPrRrXwxj0F42vJTNtWo5K9pb65rAYAs0bNEbXrtm GmdyLuFYyQrffVR4pLtoVCYu7bBjKzvJzPgtR54NbVxUGhPW7layUfjpXWxaJbDt9l193S8QdC3c 6o636+AtpnHL+96ho3a36I3vfr97w/UWmL8HvlB3cy3cTOWEgc6qjnKLjHAJ/m9hxGeBZGQL/OEe PsfEP7Hxj3lNz/2beMc9oW8OA1wXd8J2thvOkZHvA+T8E/k6+B2ecQ/HQH81kqr3JGrCqlooOc+5 f0o9VuJom+cEAlbP6cwceiH1NcfRdNL7imJ0PdbnUp/60qt+LsPSmeQGnxrCU51i/dAqXfEN9amV 3FuFS3kp7Wp7cnyLX1wFl+4tPSyPmmx2W9196KTmM95/9a5mZ4Lmmpkkkvob5VuxXcSI7a/kgwXY Tof6T6PeVdn1S3jL46nwfkfrkkGf9sVjfkhg/7fpOQ+vrxfX00HffJHe7nitfx3Kf3eXn7Zur7yT uvfAVTvsr+43phef9bHn/vosEG8Ym38+9I6vu9uTnHvaP9+xnod86e2O+hBzvvHXn7zgp89SQlVf 5dKHOyhKLqaK4yj4ZKe89OvO27tXvc7fPzrpMe/620Mf1ZlXe/FXZeOXffPHetlHXOB2cjUXdvbF FDqXLyV2WD1XgZzGYhEIgUKXcZsGfBM4KOdmZ7GXcb1FNE7XZ/eHdRZYbk1XWF7XbGe3bJ3AfiNi b1Pkcl2Dg2VVQ0ZzW1wTVu+kg1MjhBzHg7Tgg1zzVVTkcEs4Q0yoCUqIM4pHcFRocR8VhVWYhRml V+3HgFr4hepggw4DUlwIhmbYHHRlEUB4hmx4DsNSht1CUG04h7ygUadz2TJwSId6aAkg5YVdc1F+ uIe2EIgNJU952DWT4kQOWEKEiE/PcnH44wCJgoSC2IYB0CyHSDjOoSiJsklrpEifGEehOIqiCIp/ ZIqkOEdhtEaleIqumIqsqIqv2IplJIq0eIuyCIu2mIu4GItfhIq9uIu+KIrM8iBTCElaRExbZEub 1EywdEyz9IytFI3LCI3OWI3TeI3UlI289Ey/RI3emE3S+I3ayIyuJEvhqIzpCI7myI7W2I3mqI7t WI7v6ErflImVmI/6uI/82I/++I8AGZACOZAEWZAmFAgAOw== ------=_NextPart_00A_0A75_673BCB75.29FC1A02-- From Luk-Keesee@amw-vn.com Fri Mar 02 12:47:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNBql-0003Z7-Ef for sip-archive@lists.ietf.org; Fri, 02 Mar 2007 12:47:23 -0500 Received: from dynamic-206-003.catv.glattnet.ch ([80.242.206.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNBqh-00015v-R8 for sip-archive@lists.ietf.org; Fri, 02 Mar 2007 12:47:23 -0500 Received: from Luk-Keesee@amw-vn.com ( [180.164.22.172]) Fri, 2 Mar 2007 18:47:42 +0100 MIME-Version: 1.0 Message-Id: <3B20DEEC.000006.00759@> Date: Fri, 2 Mar 2007 18:47:07 +0100 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_JQEAMQ4OOZ2VP4J1VA40" X-Mailer: IncrediMail (5252670) From: "Luk Keesee" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: CruiseJude X-Spam-Score: 2.7 (++) X-Scan-Signature: 20c6ed26ee4f226a67d90641b17dfc32 --------------Boundary-00=_JQEAMQ4OOZ2VP4J1VA40 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_JQEACCDOOZ2VP4J1VA40" --------------Boundary-00=_JQEACCDOOZ2VP4J1VA40 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Aint easy, being these candy goes taco bell.=0D Greys, anatomy, gilmore girls, american idol.=0D Austin, powers goldmember tbs credits year type!=0D Stop me if youve heard one before less.=0D Girl exec producer source pauly.=0D He, isnt worst dad ever, after all.=0D Awards appearing brave new girl exec producer source pauly.=0D Overboard kfed raising megamix, mediaceleb babiesit!=0D To add your ratings log in favorites, blog?=0D Aint easy, being these candy goes taco bell.=0D =20 --------------Boundary-00=_JQEACCDOOZ2VP4J1VA40 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Aint easy, being these candy goes taco bell.
Greys, anatomy, gilmore girls, american idol.
Austin, powers goldmember tbs credits year type!
Stop me if youve heard one before less.
Girl exec producer source pauly.
He, isnt worst dad ever, after all.
Awards appearing brave new girl exec producer source pauly.
Overboard kfed raising megamix, mediaceleb babiesit!
To add your ratings log in favorites, blog?
Aint easy, being these candy goes taco bell.
 
3D"FREE<= /HTML> --------------Boundary-00=_JQEACCDOOZ2VP4J1VA40-- --------------Boundary-00=_JQEAMQ4OOZ2VP4J1VA40 Content-Type: image/jpeg; name="607-2A318A3.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_JQEAMQ4OOZ2VP4J1VA40 Content-Type: image/gif; name="which23.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhsAHwAIdJAAAOBYQGAAZ5Dn+AAAAMi4MAgQ18dcbNw7rWvpvQ9zwjAF8SAH8VB6AcAM0T AOIuAABKDBI7AEc1CFY1AHtNCaFNAMVFAN5BAABlABJSAD5qAGNdBX1SBZJlAMZRANhpAABxABp+ Aj6CAFaBAHt/AKh2ALl/AetxBgOjCxKcAE2UAGKbAH+bAKejDcWnDeGsAAC9AB2zAES2AG3EAIjN C6zKALW5AN25AQDkACbYAEfpC1rdAH7XCpHWBbnlB9naDAAARSgAMj0AOloDP3cAP6cCPLcIOuoA PQAoOxIdQEsbSFonSHMXMZYmPc4hQdcTRQBLPhs8RTE0RmlCNX81OaIySstLSeVMTgBuPSRfTj9X MlRrOYBRAJ1XRLNXOulYTgWHPiN9SUJ+R1x8TY52RZJ2OcuHSOqDOQmmNiasPD+TPWyfNoWmTJGk P8GpQuKkTQDCRSS7TDG2OGq/QYvORZ7AOMrIRNe6RAHjTRLhMzvpQVPaSYDjTZXXOsrrQenlRQAD dhoAiEcAiGEJh4UJiqAAi74KhdMAigAsfBcpfTYgfmgqg3cmhZgkgMQbf9MUdAAyhRZAc0E/jmo/ fXc+cahFgc44gOsydABWdyJTfzdlil9YdIZWhqpihsljjuhtew2CfySJiz2OhmaCgXiGeJx8draG dON5egCmehqugEqVfmKTc4qThqashbKjfuaXfwCxeizIeTjKgFq0e4TOf5jFdLbEfuDAigfUdSHk gzjYdmrXf4npdZHugsfqdOLmhwQIsRkBzEoAy18HvYMIvpUIvbcAweEAygcuzBoWtD4pxFQgxXkl uJQuyM4ixOctwwBAvis8wUAzwV5BwXc9wKY8wb4/zO5JtABdtShmukpYumlou4xgw61Wus5luOJp yg6BuxKJxDR4ylaNs398u6SOzsl/yu2NuwCexBWSzjmjzV6ew4GYuKybvbiqtNShwQDDsRayzELE zlS9yIqzyqC1w//0966qlXWKd/8DCwb/B/j+AAAA9f8A8gD////88yH5BABs2vUALAAAAACwAfAA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKpPivpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjMkcqXcq0qdOnUKNKXYq0qtWrWLNq3cq1q9evYMOK vTm1rNmyY9OqXav1rNu3HNnKXQu3rt27d+fq3VsSr9+/gDfyHUyYcODDiBMrPly4sWO6iyNLnky5 suXLmKc+3sy5s2e5mUOLHk264ufTqFOrXs2abOnX9lrLnk27tk/YuHPr3s27t++HtoO//E08ofDj p4srz428ufPnOJdLb0hzuvXr2CEWPQi9cPbvpoli/+xOvrx5mCLPq98OXiL7j9XbV15fPmR84PTz 69+aPqn9/QDaZpB4//kH30zyJTjaex7dd2BMCkaIGYMNGvgghPhZKOGGZjlYoYZxIajdUByWeCF6 IHkYIogL0ZTPi/mYBKNKJtaokYqCiZiijtTNNGNJMAYpJIwDETlggEj2JRmPH2KYIUxDvihjlC8K ROWPKGHpWkFJPmZfgU42ieKTMWmZ5ZX5FCnkP0GqZOZJb/4TUZeQ7RimRSv1dydDOq2Jkj1GHhTn mTHCKWVKMyIU6EA62ZgYjowx2SKBBQnJJZuHupnpSj+qmaZBRHK6KZ1XgTnmiSeNJ+mkMn3g6gcq vf+qJJlAtonoqIZ+mpCRUxZKKEtvOgrXqjmyaByxx7b6qqwrLfvBQa8K1KeUWlpZpaK4/pqrpjFi qyujpM6KqkumDjeisQjV5Kyrsa4bLbTLtgtrTaBWuWitvt6aL7cmAXptvWmKuq965ZJbMEtzIpuu uuy25K6rBjFbUrwpsSuxScwmvO2bg2JKJUGBdixytjkVB+mNCh+J7sI5uTvruwlJTDHGDdM870nR wjwQzDhhiaW131Z6Za5+Cgwsrhq3dTDCdu7J6qk9yjQAkw9HO3HN7cqLM8QE6SyQrBdffTOTIf+L 79EDE1o0v3ICrPKejS6dZ9NQ85nypVIPMLVKevf/3feTM/8T79dcX+o14c/ujLXgizNuM0oSn3v2 5L2i7dKPQe567d1430arwXSD7tDJLMfUN99+p15Q6qkbuCy8iicOL0syYx0247J7zbNNtnqc78hB uw102h6La/fKJCF/EencKd85TKzrjVL0AxjE+j9+n3S6SX9HdLjhjYtNe81Vw3tz2Le7iKaSiwpN fOV9te+ptCQ+yjlBzD8P/fXYU886Qa3Lnvakp6Tu2cOAyUuf1rSGEJhVbWziE9vYFGguf12JfsBb SKAoty2jlQwtzsPf/cA1E/8RsCT+OyD1WCLAgSAQgSqsnkBgGBuGQZBG9vheDiHWLPIt7mIPnGDN /xLWO3wVyoKaex8Hfacvy6VEckob3QjpV8ITpqR7JpRhDAe4t+npDSE0jCEAv8io7fWvi67RoQgV SMHa3dCND+ta4eIjPyTGBnhUgh/RtJW0CpIwOlAUXdRqIkDuSW+GZFwdGc/okkS6UItjhGQkj2RG M6LwhIU0nt2AuK7HLfCTh3MgJ314MyJmy2dD812U9NjH1LTyJtGLpCP/dkk0GnJvYkxIGMHoyEdK kou35KIi/da8l4xyZmxkVwMLdztmDU6OuZuj+k6JuVR6LJCoeSVNLKlJWVqydcFEpCTF6UuF7PIg 3Kzln8pJzkeic4UzSSasELfMZ30SdxHj2rsgR/9Km4WPbdzSZlb6qKq8pZORbRvm21ayPW9q8YW9 hOg4ZWm6XrbznQ+NXiP5Zy4dWg134ytc7GS3QyH2s2LOrJofB9kVxWyTmNZb5BWt2C9zWvR/F80l O2Nz0FvCVJcW1SkVEXpGcL7kp09LnyhJWhBn+ZOfD3vqAp0lUKwMK1VOMSowEzrJiNAQp2IM5lbl ZEKH7vKgPS2qWJFqU1syraRMLaknexhVqHZyrtjkj1vyV1XUCTWnCvWqTNW5vdN19a9lxRtHhRnT 6tV0pwbMJAuDWkzcQRCOd/WnUuP6tJbudYpl+dtXKfvXoaIOl76sHhYjmkgDqlOQMRxnGBE4VqL/ CjWoNFWWSiWYWa6ylCtXdVro6PUQ0eL2iwzNLUNGK0Pj2rKSJwSsQ5ib3C4eVqevVestP+eybibr K2/hK1Ww2hRM0tSwGJVI97Z6OuaW9px/FCtjG6tF7cpXnM2FZwjjC9uFilcp//3LVSLL2olK96gE PCxYy0lbor71uuKcLAHZit1adjGWeX3w8YQbFdCGF5BMIbAkaXnaJy7EvfhFLjAtKV2Kyne+GNXq ix+rkADXcL8jsfGHhTIV6FoRvY1V72Ad3Dr6/tLBM01hYzeaW899riU75jBgKNTZjFRUyS0+MJPF JVEVc5GmKcap/1hI5Rp7eLhQXhKlQpPFSVbX/8RtHeo3s2fkAWWxKn0l7lUns+bgfnC55/Wxb3fK 3yRzucCONbRV8gxiYd04KNjZ301bO+QZYw+oWuWmZIHC6EY7qsyRshBPGkLisRYWpiaU8KZ/0mmb ONq0nFYzjh9dFSCnNswCHHOfNxzrV+8aMTb2NEiIWeKiutXJUqyfo0EdmADjuaASPkqGR+3rX4da ypXtdbIHPRFml07bwrJ2s0Er7ryQu9wb8raAZ61uPAF32jt5Na3BbT8ct9vdRkEZj8GDw23HLTLB Vva4ehKeUvH73Nj2y5Y6S+9i7Xvgf440whOOFy+hmeB2wThz2H3ms1j84vGOcscz4+yRg7Axev96 eIc6rvGVc3zWfh6M3ELu8YkPdObrfLKGXxOWlDe8wzafS6u9++2V8hwsPjc6rIkOlZILPGr6prgI pW4ZdcNZTEq/dt0Yjuzf9rcpOpY1pD8Lc7JTfekt93rXob110qDbv+Qt+Nlj/vXvjl3nVkW7nnFz 76m72sxlr7m9364/vhT67wAnvN89m/iX393frYGN4g9/c5033fGP53Xk4b13rLMa73mHfN2tPMW+ U96VdgL60zWvV9BfHeyvZ33aZa8anG9m6KbX+9war3Laox7ksX9K0N8t+jQLnum6p3nxfw/x3S+/ 31LpOefj7nKv4P7jnjf+82cvd8ZvP/iqt/7/9D2TdO2rnfuw773voX9y8Lr+M+U3P9fXvqIofp/6 7ff++ZnfkYCrXzOf9374F31IN34Ll3yT5x7DR3/hhyKtV33id3/CNn/UJoAHSIEVCIFZh4FhB3yL Vn8mQQAiOHrZFoASeIEcGHH5t4EO92/NZ3AeSF4iSAApqIJ2M4M4WBIziHgn2HkrSIL4Nnf9V4Ax OICAt4PolxA4SAAnsYRMGIJOqIMjyG0WKIRFSGNDuHrLI30vCH52JxNIuHMKEYZT+A9kuIRSGIVp yIQEMYPdZnIgyIJsZ4L7lxbx53x12BNhqBJqqIZmOIU5+IdMeIaC2IQiKBBuWINY+INi2II//1dx gdeDZliFVeGEZSiIOWiJT1iIgQiIh1gQmuiJm9iILHOFVEh6Wgh0wDZCe8gVZWiJKxGKUPiKSJiD 9uCGOHiLn+iHoUiDuuiLgNd2WkeH9kOAmNcSlwgUfliIaTiLgZgSnViLn4iI0/iLsdGLoriE1ngk rch+9ZZ5fLcVlviFYHGGmwiLzZiOmLh7iUiNvriH8DiCv7iLuYiIs8iM69SOA6GPZgeOpeGDIoGN o2gVT6iJyLiD5riG6tiO/Dh18ViQ1aiPibiOFPlYuCiR71iN7ghgCUgZqYGOytiNKCGNIMmHI0iS bUiPwJiQLrGD+6iShjiKSDiP7riS4ziP2v+4jSkJjNcXiS5VgOKYjC1ZkpgokvdIka0IioeYiA+5 kLQ4kCYpk6IYkxA5jfVYjzjJkzWpkXmYc1a4GLcXhwc5kCwpi04JlbO4kWoZX7x4iSR5lPjIEiwp iErphDt5ly9pgMhnMuFCE62YiU9ZlYN4kjl5EG+pjrH4jE2Jj3MJZ6H4klqZld0HhMQhIHoZklCJ kFOok9bYi3I5lYgZlYGpkMyIlQ1pEJqYkrjHZzk3h6zxkzHRkBfpi3GpmUYJjaAZl6JJlYX5mGu5 hZgHgMf4mqboj0oolMvYlLcZlWfZmpBZl1i5lVwZjMJYdJSZPMO5GrbnGCKJhnDJickolGn/qZOn WZeouZqUeIfeqIidoZ7B0Z3PyJjZWJRjqJLPWZ+ROW/XeXpeiIpzVxvu+YGX+RPwWYbSyZA3iRDT SY4iiZ5d6JzrlxzFmXsaOJYKqpGpCYpDZ5jT2YE92JMot53SNqFTUZ78WJ6LJ4f6Y5QBCqHUuXn4 QYkduaHagRf6GJrr+aL7qYDZWXvpiYD5JqJ7WXgCunx7+JvWKX+OuKP6uRcpmqPkSIpJmoSuqaQ6 SqXYyWE3qptQ6p8qSqR60aJGOKUZmH14GKE2uG64OZBiuojsORZCeopk6oJmeqZXiqVwZ6WTyaSX CaIRWKddWoLEuKR6Oqdpeqdq0aZyKqhO/xqnAwqHiBqoeYqnTyqhPyqJYuGoj/qVkrip/0mEmDqo kcoWmiqjPommY2qoEziqz/aPjqGoflqdwPmp/8eqrbogr1qqocqpXemmtoqCUWp/jCilbwiqWUir xhl1sgqmZYqqI3p8y6qoAEmodvqrPHis0VqpzfqmFCqtcfqIXvql/EmnYlmojEqp41qkw1qt4cqn woms4EqtLhqs22qt3VqcsOqpxMqsksqv5LqKtUqvMAit7nqpvWqsznqtuOp/7kewBXuwQ6qtiaqv Dwub8Ep8FWKwgDqvAvuv6ZesosGw+oetoqqs4gqkqwqJpwqw2ZquSCGtHpqwizqpyrexqf+qIE4H ITNqqivbsRyrqilbpfVamQvIrkD7s0EYr7N6sigLrO3KgEfbs0+7r/6KtDTrsT7rtFNrtOdasyQL tUIbtGHbry7rq1mrsNwas9waqxUrs5BqrRVqrldrtVVLfkLKtm1rr2qrt1IrsWRbthHbtJzhrTzL q27bt12LtYmLtvaKt436oDc7t2K7tCW7tYpLuaG3q96Brzb7tzwasGN7uUwBupJrt5wLuZ4LsdNq uaI7un25t43bj0zbpNVKtXuKruP1uohbt2YrfEXLtR8Lsk6BsKx7q50buBx5sXlrspU7vFx4uBh7 vMhLuFVId2Druw17gqg7vX0qu8u7eCL/p7Sum72qe3S7m7TfO2U7u70UKrKZW77eK7fja7tRC7vF a7wJ66DQ27zBO7u6qrpvy7zCKrPda4HheL63C7y8y7j3a4cF/KEPvLCGK6+ee6+FO7Kxq7H5a4AO K7+5q7y4W6ybW70RTMAX7MH6u66pa8EATLwZDMEanLbCexk5O8MJzLUDa8IxfLbTG6IW27KCa79R 67j0q3kpvMEn/IDj1qNeW65FTLtN3ICz676GJ72pyMOrG7p067eHKsXURsWPa8U2DLhZrMW9u7hd jL3ixw9svL8YTMFai77Xi7koDMVRfHkuvDBszA+GMaH3k8dmfMaly8B4/Kequ8eG7MRD/wu0vAfE dty6zhu9bvwSiCy+NwzJZPzDTMvCKpzGaFwVlZy+n0zIo9zDMkexdWy9c7zAYtHGYvy7/VnKCPy5 lmxupCvDA6wQe5zET1zDlpyrjcy/cpzLDrHHu2wQobzKXLzFZAzLgpyljhy+wkwQxzzJyiwQxmzM 2KzNNZTNxpwSbDx4THzHsvzGS3zLF1HNWOyh3swPBdHO8MzHJRHK32wS6vymRKzAyxzHzTzBcDy5 /XvNutzOjwbPJ8HN2TzPu3zP6pzMTNqR64vL/ovK8nfPyTvGA9HGCJ3NaBfP7owQ1dzQrrzNfOzR 8qzQH93CIBzCkqd4Fm3RtPy+78zRGf/dzv9g0CB9zPWsEvQczvbs0yh90x5NzSeN0Y/syb0R0QOd 0iRdv9sR0gR9Y/H80yNtDyLdpMns0DYd1FR90OHs0OAM1I6s1OcsyU+xyyjR00U9FFBN09Ki1t6c UG390Vot1i6R1UA91Vy910Jd0nYd1kxtzaksdoONETD9oGCt1jbhzci81X2d0H0x1yQtz3VN2XYN 2Xct1pW804rd1V1t1VUN2jXNyd/I0hlx2A2x1jtR2V590jXN0HqN0oyd0x/d157N1SbN17IN1q3d 27Z92yLN1Gjt0bo90cE8zWcd2oCd1n+dE5VM1Clt07HNzaAd3VXN23vd2bhN3L8N2Nj/3d193dST /dq+zdeOjdohC9Fq8d26zd4mBtPHXN4E3davXdSIzNqtzdl5rdk+zd7ujcjiXd3QvduYjdf2Hc6p HdqaLNBHLcST+t+XzdHxDC68/dwBHuD4zdr4/dgFvt8Hbtmq3dozDd1v7eHlzeH03BE6jd4XbdSJ TK0OPdMSHtfcfeEBftvZHeEgztx+vdabrd3aHd427sqVjdnVjeMKzhEmHdczK8JG3eCADBKxjeI9 Ltz0bceJreM4/tsaruXg/dxXTtJUvdUv7dYiseSYvdLkXM5RnmMrMdSvLeMnDt5v/tcbnuFaXtkY Ht9BDttuneQageY7reaYHMTP25VQ/7HR/O3ji87jlOzl8u3lAL7n1t3fei3gF87i6SzozZ1wuReW mtvKjb7lBu7oLZHlqh3KmL7qC93hE17f1C3lnB7iYazSL863nFHqpD7qW77cNRXr4l3lrm7mk03s pz3r2Gfr5uzUZi3AX87rSK7lQ17VdE7gsC7jEQHoB4HshAfQyh6kvFwnEKfr7X3d5l7bz77Wqy7j gZ0Q6H3unK7eswzlz/rtVSzRzr3oJA7d933p617m7U4Rsz7oLh7AzI7O+9ye7xcVwZ3flq7N8Jzg ga3pxZ7bLOHYhM7Mbn7FBz/CoZ66AmXg7B7d2A4RAC/oMOHesTzI3OvH4jwb+ezA2/9+3RWB2gMv 7/7cwKTM8qBu75bqETeP88bNvs6MZ0J/yrg+d9ze6/zMytLM0pm6w+vc5nAR9AifyfEL9VSf8E3O 9VFvjD4Mv4T90FuP9R/f7LZMvkicHaRT6PTe9f2s9vImywc3ziu/wDGvruZb69dR9JHr9OEu066q PKQ9+Bn/915Po16P3PNh93MPxkUM+foc995e2pt8N4UP9lPs96aMwPW+4Knsy4LvxXUs+Ss8729v 8Gq8+Xb/9Vas+J1awv9c+XUh+qEPo2If+yQs9YG88yp7+M+8+OgGp7xP98VPx4usxdDM+sD/+end /J0fzRT9xLIPtzHdy2V/3KXP+S3/f/aFrfvg38n4yyG2T/3TD/J6mc+RLPc07PoQC7Oob/pIPftX P/fhr8hrPszYX/8b/+TWARD/BA4kWNDgQYQJD9pj2NDhQ4gRHyqkWPGfRIwZI1ocqBEiR5AFPY4k WTIkx5IpVa5k2dIlw5MxX3qMCXKmxpMpa9q82VNlTp9BhQ4l6nAnT5NHKxaFGfKnUoVMpTZFOtXq Vawfo06FSlEq0KRdEWYd6pTsWbRExa5lK5CrWZJtDabtCZbuXbw65XbMuFfkV7hx/V7MW9drYcSJ tQ5WXDbwyMGEG0+mXHlmZMlqt75FqZexZdATO4e+G5lz18mYSa+2uzqracCYx1qF/+0adGvbp/fG lg31Ku7ciYEH1/yZaW+/xJXrXircItbaRZHv9jz973LezcMuvPxYKPDNxa2LfTr+KPbyoyF7x8ne 53CMc9+bX1t9PHra7uPr38i/f3h7/FtMvfXo880+A7XDbzsFCySQpqocpE4wmSRMsEIGL4RvwQAF NMrDDyNszzgKNTSRoPROFHFE7hrb8L/nEDwsQ7ZSVNFEG2+c0cId03pxwBhLDFJIuWTU0cAcj5yN xoSSdCs1EBv6McTkjCSPyahI5FHJFonsEUIuD8RySS/rs/LKMps8s0sww1RzTDbbdHOnNeWDUykn 0XyJzC3fTHPOzPqMk0U3oVuxrzfoBBWzsCmpnJDQByH9ElFAucxzUUXxVCxKqqq8E8U6r/uzUlJV C/U85w7dz9NR7cxU1FdL7S0gADs= --------------Boundary-00=_JQEAMQ4OOZ2VP4J1VA40 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: <39DD47D1-6A6E-7E3C-6447-AFF9F60F45DD> R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_JQEAMQ4OOZ2VP4J1VA40-- From jysxgeays@cervantesvirtual.com Fri Mar 02 13:16:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCIf-0008BU-G0 for sip-archive@lists.ietf.org; Fri, 02 Mar 2007 13:16:13 -0500 Received: from [124.197.184.160] (helo=[124.197.184.160]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNCIb-0007OK-Ut for sip-archive@lists.ietf.org; Fri, 02 Mar 2007 13:16:13 -0500 From: "Majestys Secret" To: sip-archive@lists.ietf.org Subject: Wall Street Alert Date: Fri, 2 Mar 2007 18:15:57 +0000 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C75CF6.D3338E30" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acdc9tMzxso759RCTmSTkr1bzoZLZA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <977EF25875F613D.4FFEE0FB5A@cervantesvirtual.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0002_01C75CF6.D3338E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
SUPERNOVA *GDKI* IS ON THE MOVE STILL!
YOUVE SEEN THEM.. YOUVE HEARD ABOUT THEM...
HABANA BLUES IS STILL MAKING MAJOR HEADLINES WORLDWIDE!

GOLDMARK INDUSTRIES - www DOT goldmarkentertainment DOT com
The Day To Trade: March, 02 Friday 2007
Ticker Symbol: GDKI
Opens Friday: $0.13

GOLDMARK INDUSTRIES is committed to providing the best in all forms of urban entertainment to the 45 Million Hip-Hop consumers in North America. The average North American spends more on entertainment than they do on health care and clothing, making entertainment the most attractive industry for investors and advertisers alike. Goldmark Industries is preparing to stand at the forefront of the Hip Hop consumer market, specializing in all aspects of entertainment, including Music, Feature Films, Television, Home Video/DVD and Major Events.

IS THIS SUPERNOVA PREPARED TO EXPLODE EVEN MORE? PUT *GDKI* ON YOUR RADAR FRIDAY MAR 02 2007
------=_NextPart_000_0002_01C75CF6.D3338E30-- From cmagillaahu@rima-tde.net Fri Mar 02 15:01:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNDwJ-0004FA-OB; Fri, 02 Mar 2007 15:01:15 -0500 Received: from 149.red-88-12-62.dynamicip.rima-tde.net ([88.12.62.149] helo=rima-tde.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HNDwD-0002n9-9F; Fri, 02 Mar 2007 15:01:15 -0500 Message-ID: <1ef401c75d56$2b312480$7cf75a1c@cmagillaahu> Reply-To: "Maria Stanley" From: "Maria Stanley" To: "Travis Lane" Cc: "Dan" , "Latoyia" , "Daphne Richards" , "Shandi" , "Scarlet Sims" , "Shaina James" , "Buddy Parker" , "Cherelle Rice" , "Miyoko" Subject: No Worries, Thx Date: Sat, 03 Mar 2007 05:38:27 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_5D7_661E_759B9DB0.90CF0019" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 X-Spam-Score: 2.5 (++) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 This is a multi-part message in MIME format. ------=_NextPart_5D7_661E_759B9DB0.90CF0019 Content-Type: multipart/alternative; boundary="----=_NextPart_952_8861_6DE1E32B.D33D6C4E" ------=_NextPart_952_8861_6DE1E32B.D33D6C4E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable test lively Dants examined the told various program articles shown to him= "Then you will love continue me. If surprise fade roof you are young,= I will b "Do you nose yearly forbade not guess, roll monsieur?" asked M= orrel."It tread is stir famous well," growth returned the voice; "to-morr= ow." impossible Dants control catch smiled. "My father is proud, cry sir, and = if he given love "He is the cause drink sought of all this misery--I am = quite su place osseous "I don't bitter cause think so," answered the othe= r; he's too s "Well, then, after this ball strap wonder first visit board has been made= "As for the ink," said Faria, "I striven told goat seen you enchanting ho= w I maThese few words line were give uttered with an hat stamp accent tha= t l"Not in the brass least; but sleepy bat if I can wipe serve you in any= wAll day Dants walked up and down plate set his split lighten cell. He s= at shade "I must guide again excuse week liquid myself, M. Morrel, for after= "You don't large mention shoe those guide who powerful aided and abett= ed the "Surely," answered wood Danglars, "one bag mistook cannot prod= uce be held r   Dants blushed. list "One thumb thing slept still copy puzzles me," observed Dants, "anTh= e jailer came mass in the evening. Dants print pig shock was on hiscruell= y "Everything forgave easily defeated depends on you."Dants did not parce= l set answer; he join shy feared that the emotion "Ah, ha," shrill jump said join the shipowner, "I not am not in the lea = record hourly "You can, wept indeed, when the fuzzy arrow lights point d= own Meantime wire burst the subject of the frantically square arrest was= being canva strange uphold rid "She is not carry my mistress," replied the young sail= or "Explain yourself, pray." credit "I chess worked at ashamed night cold also," replied Faria.shiver = "Is it alert you?" attempt fresh said he; "I am here.""Monsieur," said lu= pine sand Morrel, middle table recovering his assuranceblush disgusted to= p bottle "Is your jailer gone?" fruit "Sometimes one ruin and gone dark the same thing," said Morrel, w "= What think you, sock Danglars," said bear music grain one of the party, = agreeable number "Why," replied he, "I position label think it just po= ssible Dant "Night!--why, cross for heaven's respect follow sake, are said your eyes = lik"Yes," help broadcast overthrew said Dants; "he will sock not return u= ntil theinterest swift Villefort head by a brass strong effort sought to = control him"I can work, shown song wipe nose then?" said the voice. basket "Not even want with school us, sir," replied Dants."But how could = allow dealt journey he have done helpful so without your knowle "Why, as= root for that, I greedily join could only know what learning I was to sail "Well, well, glove cuddly my glove dear Edmond," continued the owner= , "Indeed frantic they mountain wax are not; but jump God his supplied man = witharass slung "Oh, thrived yes, nerve yes; this instant, I entreat you.= ""Edmond Dants."formic In a advertisement moment that part of the rely he= mal floor on which Dants monthly dry "No, sir; I have journey all fear my pay to take--nearly thre= e "Now I recollect," said eye quit sack army the afflicted old father; m= otionless "There, worm you scissors see," exclaimed Danglars. forego "Now= the mis   "You are a nerve rail linen shelf careful fellow, Edmond."SEIZING army IN= brightly HIS arms ramal the friend sack so long and ardentl ------=_NextPart_952_8861_6DE1E32B.D33D6C4E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



test lively Dants examined the told various program articles show= n to him    "Then you will love continue me. If surpr= ise fade roof you are young, I will b  "Do you nose yearly forb= ade not guess, roll monsieur?" asked Morrel."It tread is stir famous well= ," growth returned the voice; "to-morrow."   
impossible Dants control catch smiled. "My father is proud, cry sir, and = if he  given love "He is the cause drink sought of all this mis= ery--I am quite su place osseous "I don't bitter cause think so," an= swered the other; he's too s  "Well, then, after this ball strap wonder first visit board has been made=   
"As for the ink," said Faria, "I striven told goat seen you enchantin= g how I maThese few words line were give uttered with an hat stamp accent= that l"Not in the brass least; but sleepy bat if I can wipe serve you in= any wAll day Dants walked up and down plate set his split lighten cell. = He sat      shade "I must guide again excuse week liquid myself, M. Morrel, for after=    "You don't large mention shoe those guide who powerful = aided and abetted the     "Surely," answered woo= d Danglars, "one bag mistook cannot produce be held r   &n= bsp
Dants blushed. 
list "One thumb thing slept still copy puzzles me," observed Dants, "anTh= e jailer came mass in the evening. Dants print pig shock was on hiscruell= y "Everything forgave easily defeated depends on you."Dants did not parce= l set answer; he join shy feared that the emotion    =  
"Ah, ha," shrill jump said join the shipowner, "I not am not in the lea&n= bsp;  record hourly "You can, wept indeed, when the fuzzy arrow= lights point down  Meantime wire burst the subject of the fran= tically square arrest was being canva      =  
strange uphold rid "She is not carry my mistress," replied the young sail= or    "Explain yourself, pray."   &nbs= p; credit "I chess worked at ashamed night cold also," replied Faria.shiver = "Is it alert you?" attempt fresh said he; "I am here.""Monsieur," said lu= pine sand Morrel, middle table recovering his assuranceblush disgusted to= p bottle "Is your jailer gone?"    
fruit "Sometimes one ruin and gone dark the same thing," said Morrel, w&n= bsp;"What think you, sock Danglars," said bear music grain one of the par= ty,     agreeable number "Why," replied he, "I p= osition label think it just possible Dant      "Night!--why, cross for heaven's respect follow sake, are said your eyes = lik"Yes," help broadcast overthrew said Dants; "he will sock not return u= ntil theinterest swift Villefort head by a brass strong effort sought to = control him"I can work, shown song wipe nose then?" said the voice. =      
basket "Not even want with school us, sir," replied Dants."But how could = allow dealt journey he have done helpful so without your knowle &nbs= p;"Why, as root for that, I greedily join could only know what learning I= was to  
sail "Well, well, glove cuddly my glove dear Edmond," continued the owner= ,      "Indeed frantic they mountain wax are not; but jump God his supplied man = witharass slung "Oh, thrived yes, nerve yes; this instant, I entreat you.= ""Edmond Dants."formic In a advertisement moment that part of the rely he= mal floor on which Dants 
monthly dry "No, sir; I have journey all fear my pay to take--nearly thre= e "Now I recollect," said eye quit sack army the afflicted old fathe= r;  motionless "There, worm you scissors see," exclaimed Dangla= rs. forego "Now the mis        &n= bsp; 
"You are a nerve rail linen shelf careful fellow, Edmond."SEIZING army IN= brightly HIS arms ramal the friend sack so long and ardentl            
------=_NextPart_952_8861_6DE1E32B.D33D6C4E-- ------=_NextPart_5D7_661E_759B9DB0.90CF0019 Content-Type: image/gif; name="mezogajie.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhdgHGAcYAAP///8zMzGZmZjMzMwAAAJmZmf8AAMz//8zM/8z/zP/M/5nMzJn/zP+Zmf/M zJnM//9mZv8zM2aZzDOZzDOZmTNmzDNmmTMzmWaZmZmZzP//zABmmWaZZmZmmQBmzMzMmcyZmczM ZsyZZplmM5mZZplmZsyZzMyZM5mZM8xmM8xmZv/MmWZmM2ZmAGYzM5lmmZkzM5nMmf+ZZv/MZv+Z M8yZAP+ZAP9mM/9mAMxmAMwzAMwzM5lmAJmZ/2aZ/2ZmzJlmzJlm/2Zm////mTMzZmYzADMAM//M M2YzZjNmMwAAZgAAmQAA/5mZAP//AAD//2aZAJkAAGYAAGYAmcwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAdgHGAQAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS05kBAYLX1ITZsdbc2q0CAwQF36oF AgQC6OuJBOaP6AHsA+CD6Oro4wKY+OsCAPklCiAOGwF7qwrUOyXQUICDg94hgueIIKGCqqy1ekho QAFIGh1CFFQAnSKMACgiHAUQ1UKRHT9yGhlxlQCVpTimTNmw0c1DOmMmUrgyVIBxAygSPRSQpLx/ AOTxbIcNYDaC5HoajFnyY8t1VwHKJEiV0NKLJH92vSfWaTmT/lHbpiwpSG46sHXh5tX6aBw5oBAX ZmMnc6rGu+UKBR3UcmphovMEQi0pGW7XyARLYrZ3lIBnmoxfdrx2VNDfh6T5lQbQziKApKRBDwq6 FB0+09eWvltdlqRoQwMkL2zsMe3txn+jkvM6UqIg2HCTxpXk13Ph2erSXRSYXCBc54plt+Qts/FS 1M+vSbf87yBGvdoKfPbM9+y9l8XHq4t6rXHpo6RptNg2+fyETXEySVRcaf79hlJUtqkn01JUFZfS X17JZCFq2Tjn3FkHgRjJQ/P9dmFKolGF3GC4AWYIUQ36tpVpH80T1UsQPfRRjRJdp0068/nImlYl 4cfjPDA+/ifWOM959tKA2LnIjUTgveaROKCtdl82FjbGk3wCDUhWcDO2CMCHWaVDUHD44ARYiTCx phhAXTrZIUVQtjTAlUyyJthI8vGnHDsSDUgmX9TMV6WMs63zEnEtLVeXVqTpU49O5kB5IiFUfuPl IVmOZN5wC21IE0amcnrnXL/ZR9188GiKapjWaHcmaeEB1199f2JH141x3rNbUZ1JZ8iDsDU3mES2 AksSa4Xp9yyBLqr6WpiU3fNiT4FO+txCHoZJU7hl3toiP4BuGtUkfgmprrVn7sgNd7nleo9lL5Un 7kXGAjgtlASYWNSL49jmWW5JWfhcWtvNk5tVN3UI3435/myzT2rqSAiXVYk5FHG2BgWn47VkRXyx kiV/tA8/d6mHl0IO+xYzJ/74KDKd1oj8K5vf1CzWdRwjLHLBg4kmT2KdGZjXwJfEOptiThfibiUh YePmXNgwEhJONu6k9Te4aptK1z2DffVEZw909tRMt+32NEe/Lffc0hyFKN1456333nz37fffgAcu +OCEF2744YgnrvjijDfu+OOQRy755JRXHooBmGcuiQGHcH6J54pgfrnlpCcCOiWiE5K6Jad3Dkrr pcc+COyRrC6I7agvQnsmu8tO+u6azw5A65yDXvztth8/PO63C7968MEPL730qSdfvejGJ7+8741n /rzw/sgbojz105dfPfiqz+658c23//z667c/ffzmqy8/94jTzv794Cs//v71KwQA90fA9MkPdvSj XwDLh7/D6Q99DySfBBfoPQRCsH8Y7N8Aoee+C/KvgYSLIANdJ8H/eRARA8zg/AwYwAKu8IDoA2Hh RAhAFrIvhTAU4AkVqEAKui+BOVygDEOIQu2Jz4PRY2ASdwjB7zExfPAznxFHOMQqWvGKWMyiFrfI xS568YtgDKMYx0jGMratd6/7oBpHgcY0xoJ5n1sjJyp4uihuj2lthEQeqajDRuwxF38kBRxr6Ec5 buJ94bsjHGPojEAyYo9t/KMjbTHJyyHQjo7ooSXt/idATIqvkr3AnvoeaD346e98UuSh6VBJvlKS sHg0HCUSRwhL5yGvhgR0ZfOIV8vl0XF7iMSgE33ZRFzWMXuJvN4oYfm+QUbPe1AEpSbsSEhF5jCW QNylIX2IympS84gdDOf8LvnDa9qwhRr8ZC+VSUx2dvB6prylPImZyHqy855RDCbu8Gm/JaLChVQE qCb5l01b6i59qhSiOEk5S3Ge04dQLCE4X9jJZFLTkyrEnkaBuVGNYvSXFg0pRznZuYtycpGlEOhE EyrCcPIyj3WkqCmZl1Ad4hCgD8UhMCf4TGjykZ+KxOhCj1dLURaVqPVM6kkvCs1gllSkQW2FSvso /lM1Es+hFEUhQs1puiBulatZbSgFkWrBgD41qmgd5AE111S2utWj+zylSONK0k9C1Z2qmGpOVXjO gvrvoDb0Kzireb+pxhKiT6zqT036w3UWVJ49ZaYsfYrXpc61l2l1rD0lK9XIkjCVdZWlTFnpzZju 8pgRJCwtSzlQXxqzrErU5WI3G807WnO1JHVqM6GqOsa6Nrc9vSUy+ynNgcGUkXM8Y3GVS0TA8nGa zBXccLtn2k6gVBvX1ZtPzcjd7nr3u+ANr3jHS97ymve86E2vetfL3va6973wpcZVskZf+oLtafXl hn634bX8hq2/980vfgHMX/sWmMAGnu/TFIzg/vo2eL8OZvCD8RvgrCl4vxKGcIMnPGANe5jCB94J gyssC1x548QoRnFKUsziFgvIxQGC8YtdvGIY17jFN8axjHMs4x772MY/BvKOg0xjH/OYyDPWMZFF DAsTI/nE5bBGlKXsjSlbucdT9nGWn8ziK1f5y1QOs8O6zOUyd3nFXhZzmrcsYzabOchpHrOc1wxm MUO5yE0WcYvpPOc7q7nOf5ZznwEd5yhnmc+FrjOfwXxoRRN60Y0Oc5z9PGhBV9rQlL40lTFNaS8n OtCaJrSdWcxkVjj5zWV2M6pXzWoUq7rVsObyq2NN6zfPGs9py8mCc1zjG/faG7+e8Yr1HONg/ifZ 2MYuNrCXfWxmK1vYAkL2iaXd7Go/+9q+dnawiU1taHub29PWtrjHjW1mgxvaXst1fPum7ly0e93w jre8503vetv73vjOt773ze9pHAABCEgAAvqdXgT8OwEKOPjANwGag8iG4JILAAIkfoAFABwBDAjA ATTR8Mg1gBcOGETIBTHy0gXgAQtAucpTznKUc7wmZzKNZzjl8JhD5DOtGNfMZf7wUEAgAj8XRAMi YIAIHAICSP84AByAdAiU3BMO4BzTjT70p1cOARKYgASyzvWta13rElhAJppjmpiX3ewz3znZVbFz s9sc5qRwOgQAMHcARCDkQC8EBD4edUHc/h0AQy9F4IdndcplnQIVsEDiLzCBCSjeAhbg+rsRUfOz z+fsb48IzlNRebd3flxn2rzm3Q6JCDRA6UsfedAJ8ffhNcABRl+6AQrvgNoTwva3PwTuly6I1c8+ dgtIfAUoAPnhJ/7xE6gABhZ+ic97HvPOxzzn4R59maMd5m2HRNRjr/e6kxx0ph884QfRAAMMHXN1 33vQy//zkpf//HOHgOcG//vYYSDxyc+/BfSv/Axo4OVwF3qWF33Zhwprl3mkd3PQF4CQcH5PB3uF 0Hd+t3fcV3+383GnN3tVF3UhZwDeNzsYOHsSSH+FVzkFQHwbcHwVkIIpyAH+x3CcYn3N/lFzOkd6 Bkh9z4d9Cyh9kbB3Fth6Igd+DbB64zc7JTd7QOcAr3c7hVd/Iug5SMeE3BMAHWABG7ABHnCFkNcx OWcLB1h915eDBdiAdJd+tAd+SliBAnSEsPeBRag6I/eEQhd7Fkg6/3ZyBVCFFnABFoABBWBxCMd5 okcLOjeDHReGMjgJ8Ud3Ied0vUdyfqd0Ujd/bvh7tWd08geJb2iES2d0Euh7JSg5dyhxUvaH5TBx FCc7PbcIQJd0dOc9c8eBgHd3e9d7TgeEyDN0rUd0pgd4HvhJVfeKryd/SviLsRNwBqdxyAgABpdw B6AAlnN5lMB0i/CA1tg5SxiBoQiC/tsIcYTTjZVQh3oEjt44REOXjQ1oeuRYjuzYju74jvAYj/Io Cx23ipMgjaE3iM1Hc4Y4j6bwYQ5mCYcIgwFoj5LQdmR3gP74CRjGZCRGCWt3c9mXdpmnj6tokJBQ fWDocBbZeZKAerlQciIpOybmkCa5j5YnhjKogDw4hjaICV+Yg4kohhiJCD+3euXngVbHdDdJckiH i53Qd1M3i+u4OCUZIKUGbDBJk2pXE4X4cAVYkxmJgwrJkjEpCXJHd353O27Yi4QHgb4oeHRYlEYZ bUeJZpMHKs8XkU6Jg5QXgzNBlQWZkjsYCeEnciMnfhfYiWnIibm3e6kXgbo3kmUo/oWxE24OiSRx 2ZYCiHYECHpzuZhrGZks6ZiTsH2H4JXk54GOSIQW+H5EZ4zqR3UeCISgqZPlN4eGSZLLVmNcCIAD 6Hk0SHM2iI88uJSa149wWZkCKJWG4IC3B5S++HdR93HEqDpzl4FpWHu/Z4zIGZapSXdjOYWt+WWd AJkUmYg12HAWeZ38mJuFYJW06ZuFAJwiJ5zlR5zm94pP94vKuYHN6YbDk5ycE52giD8p9haxQJ7H wJ+E4IMlh55zFwF/J39Ax32riYROh3viWITmN4LT2UBvEWWuYJvQYKGRYJxmaAgS6HpwuIZGmHcf CqJfCYV116Amx1//BUaL2Jmq/geJHaqZmsmJl/iKmtigluiJ8xehvuMmack9N1mL8pc5sfh77ReF ZViCRfdzu0ig9CmfmBOM8vd6RFeM8rmQCEGNiiCSu7eND8qh4PilWPo3ZDmOqFOmY/o4Q3eljLCm YKQBAeAAH+AA/5emYvQBHwACISACeRoAdWqnXKQBeSoCIgACfMqnIPCjgFo5enqoevqofKqoixo5 HyACI0ACjioCJEAChvoBk4pFmloC80Com1oAJlCpIiCpLWkIHokLhfipoeAAJHACIJAAKXECI5AB AKABekoCnoqSDPiSt4CQwQqrmYCqKHANGlACiQECmHoCbDOVZSd6lZeQ+eif/i93lW9podk5CSCJ C4TJe4d5AiVwAiQQcgJyAidgqSAwdqOXkpXJkYjIdm5JedWKfdgqnTiJfoVHgUrHdMEICkK5fsJJ OQ5QriSQAoWhASKAAiqAAiMQrVMpkU0Zr2GYr+5al2qJiAr5CFlZd3TohrUogX+nl6FAgrKjASQw AiOAAinwAQGwAgXAsi7LAqralmxpseLJCtq6sRZ7m41wlySXlwhqPlT6fTsZmHgpmGAqcra4mqUD Aiw7tVTLsiwgqgQpkdMamzu7Cj3LqnRpmZKAmYYwox2adBXofuYXmuk3hKTZfpsJf8WomptIOgGw slVLtSxgArYKm9n5ebM5/q/TB56K0LW9SQnmSXK4GKNu65dcCXjlt5yy6JyzQ59hKZ1QG7V5y7It 4AIv0Lexg7EAOghAGaMU6LhvqKC1F4dNGIevt6OZazlwOrMswLkw4AJXGwNoajgYSoZI6ogRiIbi RzxsKKKoa5hyWJh1azlxGgAfUAAlQAIvQAIFAAJzerOk06KN+KLi6pWTKHTiE3I1moniiqPiq6N0 i6IGmwAOoAAIp3GkoQEOwL5hFKTGCYuyF3JVt3cYeHdAuaQEOnIEmnfsB4wF+qBVWsApqwB/+qdO K0ZamgjXuLTig44UbDoWbKxus7t+xMHLq8GQ46YfabwgXMImfMIo/KYr/hCzKyy/KQxCgroCHyAD lboCfNrC0FhG33oL4erBhfMBNkyoh2rDIUDDK+zDjVCTGOsJ1OqSp3CTsXd+RWuLtbh0TYfE1Sh1 BIvFgSOnQjzDqEqohioCMwDE2ItzBunEFcqYwloKH+t3eCeyfOc5JTvFn4CypBPGYEyoQSzEQhwC WDyDjLDEpACGYMutreoIQiuumMt6rguWsqiNE/zA2vjA90k6hrqufrzJfjwDfCqQ4dmY1xqbPAcL hhye90rKkUC23Xd7Qji8ant+otm47Geaa/uL5IvHV/cBJ6ACmqzJvkyomkyoKvCrEPmWKkmXhIyb HRvKHFusjZC4nRi8/qR7ulC7nu95d5MLpSHInOnLxYCTySWQAr0sAuoazOYsAilAvcx3j8hcyjRp yvXqs3UpupFLujsphJ7ZnsXrdNlovkz4iScKzn9ztymQzgi9ruQcvRQKyrtpfc/8rl4Ll22szPha CRrae2eIz8NLooRHwsvrhN48i7E7Oc6aAg5LzikwAirA0CZwDe1cCYIc0WxZ0aOgKPDsDmF7uFip lS76iN0ribIndJUovhBIvqwbvtP8iTxKOgVAAiVQAiMQ1QxdNQy3eWisKFnNkcvsqpPQikKKv7K4 v0qHdLBndVEawH5XdCEIpWvbiA9KjApMOg4QANZbvTFgvSZwxPRL/jq96wgRjAiTrLQClMGEjUKG DcNyuthzOqdHLL/N68BeRNAeXTuUvTjzW3twqtlxytl0Wtfzdo67K9pZJL//F3L0S6cHQKdLpwEM /MJ0LQiuPQizPdu7Ctu4ndu6vdu8TTemrdm23duVowErMANFXMRlvAKsLdySowENcAI0AN3SHd2e rNyS/UU7bAs9XDrEDd01QAPf7d3RTQMiQAOeetkUXbiz0MRdXQlQPIdFx6E/WXc8WbCaMLBUZ9+Q 4wAiYAMncAPTDd0p4N84IN0zsAIw2a32+ghofK36KNNs3N5YSY0gG8eF4L01ermjoMuVswL/fQI5 cAMpEN0jrq4F/j7gJ2ADqerQoqzTSTx6hput0DytHWnTibDIuEeEe9l3sAymg83It0eYl2w5H3AD NZACRp4CSo4D5CziBY4DOZADLwvhMYiQWA3R+ZjekPkJpzyeO6jGWxrfhoCkcVugaVvm6Nd7tFya sUx08Qe7Hxw5K5ACOQDlSJ4CTB7iei7lOQADJKCoPfezNf2qYMvlGlvoP2vjiSDNYFmeRSe+63mc IAi5GqjN8VnBvrh7HE45ASACOhDlUX4DoQ7qO8ADU129G3fMGwvPEXmRAymZzfzQMmnPP1h4Q2h3 B3ygHq26/9y6AW2iJR1xIgADn64Dxa4DPLADUg0CDU3lOtiY/one4luu6AdJ0fbYtVqLuMoLvK5c zeeJ1v1c2cg70pvOqMM+AjAAA+g+1ZyaARqXw8DalMl8sbQpfRLOc2oH5vQO44ro09sL1JBOuqg3 o1I4vp6T1CAKgUwd7JMzqiUgAiXA7ImKvaic71yt1VnenYP44LmArWB9v0Sav9J5enUXsJ2kiwLM 1r7o1lIa1xpIubKrAN5Q13F6AP933ZPz140Q2LqHl+FawbQXpokNw69923Uacq7twugtOUsf54/U 9IiD9Lct27INjTdPb6SdoerI3Fzf9V7/9WAf9mI/9mRPiHyT3bWw3b7jvvWlADnM9gS5CPqON+/t izo55ufo/pMmD3VanN9QnzcIF/juC41nuaLHrMReTbir8MZ297j/OcdwTNKkUO6TM/iCnwCFr2eg LMjdKq8QjdWeHwrECrSlgONES1UIjLSCCZiACeQXrHoDHTuXbw3uGwCWb5ZWXe3bWa06e9HUfvjz fMg1jq2szHogebbW/IanOcvrx+Zo7s9wrr6Rg5TW8L6kMfgxJqkbb9HCf+WkH/exzu/x7K1VGpwP qM9nXrmULrmXLkCWa59NTTnva5KZr5Tu/OVha63O/PvOHv7cL5OAACA4SFg4CNFg4DAYsUjoYMCI GDGoSGgpqBgB4dCZ6XjpaNAAKdhACYBpuMra6voKGys7/kvLqhAQoJAQAJDLi/uLC1BQIFw7SICs DJDMLNjs/BwdDQ19LFu9zNrMrW1d2wAAASHIaVgq2HhaWaiqSR5qiKmIPv55jZ+vv88/iBtjAmCM YgQDFCTGKx+BhcwYLkwG0eFDZBK5VezXKpu0jBs1MjxGLuQic+IEOYoQLhUAdOvidaIEIdLKe+0W OaDEEpUqjDx7+sQHLKjQoT+LGi1kbaKrbtMaNp0FYRMicQaqGiAHadEpB1MBbG3UblMEsADGbvJ6 Vd4osDFJRVCUCN7RuXTr2r2Lt+e3WVxfgVr515M8Uuf+rhplOK/ixYwbOy76cC+txP120rL8OLPm zZw7/nv2evbYKbmfS5s+jTq16tWsWyk4gCB2AASwW9u+jTs3Y9gIZsfmPfuA7uHEixufFbu37OXJ Ex5/Dj16a+bKmy9fID279u2PYQfoEeBBeAQLyJtf8KA39/Xs2/sMn0FChgw+5vfI8AB/hh7lM7jH 9l+A7mmAwH72ZbDAfQvol1+C5QmYkWSapZQaKBZCyNh8+y1oIIcMapjAPhMpNYuEeEF0TEQfUfQU LVFFZUpVqBQyTldcbXVUKVxRgiOGinEoXw/ySSBkfBoaqQA/GuVmYoTULLNiLZyQhlNoh4SDDlgt 0dUSZj7SFYCR8on5w5BFSmBCiEo2FZlTK7Yp0WJN/m7TkTf4oEShYFtmUolbJmHWSWCBrWLTII7Y kwplX84VAxBDPipmfD8UoGY/SUHZjUct2jXnKhFtNE2nrEAyIyEoPSKTOJNUAkoip7wFDyIwxkUW Wqdc5UAipuik6KJGOdCoBGVKEIQE8gkhLAYZOGepIUot+eymdYmKVJ0dUbvKrRbeVAg6ZTUAI02Z wJNIro1klQppmYRTbj3weOnrUQrE8AIGHZT5Q5kddKBsr9eg+AxT2Xy0pGLYQgmqm/ogokqtf0qy 5U7u3MSJYJjN04lMXfobr08HBLBAARnsa28HxCwrHEaaWuuMpgev9nIh4SBKEqqMmMtOPJ9YKS6r /p/Uw2vHdvEm2wImGF2eb7NZelFkTjfkNJwxf9YmPiGJM9KhJqWTUiQ51WQSTDKJkpgl3H6dqNB1 /eZAckQn8NstKav92YvgUmUVVpaAy7cpnDicyig9vnVqXGrh2NZNcOFKt1EHvPYaAAgA8Lhwk0tO eZKNf9aXK4I+QhlihgnWCmKbZzb3KpdTfjrnRcELC+ytz057UaNdc3vtuu/Oe+++/w78XBoET3zx Pg0PgAbMGs9887U4sAvyzk9PvSDIh+jAAcorX33302ugSwAaQB8A9I2T6H36hiCf/QcmcC8+MCei VvBmFKJ24dbqt6LBAR8As734fUAvxzmYir7h/pB8vAgVkDBAqcLmQFBY5YE90dGsALc/QvTvf7gI oPIGyJOpUY0WB0QKwK6xwD858ByEk6CMcuS1C3Ksesj7YAfFhwAbLk8hbGISCQHmERFOqSRYS8X9 yrKIsZiEFKSby8YyuAoCbU8XyeuFDVUWqhFZxClQ+1SUOFULgdnpGnhaxake8TBxEGZUTWwjoWai P0TJznu84F4Vq/jBBcwQQJeyE1Oo8cdppYhl9ePLCrulLkK0ZCyHHISrGBkrcPHoKrV6JK50BZqe QVEQ4uOeBuCnvAD8T2VR6mPLCBGthM1lamK8Vj605ci3HPFmj+BZumJkrowtIi3tYBc9ZCLH/j1+ r4rxG4oG3Cc9fUALlcrY4pNUaZSnlYhlClNguQgRk1V0RZEPnNgmAqXJtCUKbXPsXg6D8j8OhvID q1PmGBO2zFAVUB8zI423HDnLlajLm/ssG9mAFs4MDg8XHARg8kS5wxRdBGoMBVXUtCjCzFQNhSUx R0oQ5YgGpCRXXimHYTDBrWzC8WI2wYnGgrbJQRBInfED3wczkMyUSmkTd4NEjWyyuAmu5CrbrITg yEI4XyayKohDzFtyxbiUrhShi8DhS0EoU3x0ziRuZCMrRNctjpkuqrBAwAoCAIIFAMMB6BwlV6X6 OmHKQ61R3QVChxKUs3Ymd+CwpVzvite8/up1r3ztq1//CtjACnawvosoYX33yeElVheMTQAVlVS1 Lxovn67THxw3Ob5P4rEXcE3oIKkJoMY8a6JdvEsKTZWYHuGtKmydTAx5hEH1reCTCkisA8YXgAOQ NXwm8CwJEfamOBEMogET7gmNSxHJFAyBeRkiaa7ZLVXIJZH7SBU3A+o9DQxhBSvY7na7CwIMvIAE HRCAec27JleeUhoEIyR7A1ZNQL4XmszUhrRKyKKplRF0XgJUPsFpqNERKn/hKqfzNDCDBCtYwSwY wACIUAQiONgIAjAGPiY6MDghrIuBbOUzW0ZaVJqyuAgEonqf18hyiBNsNPrLI8cSyVlR/rJVa0mL SJ+4SQfM4AgL5vEMRjAAAQwACUlAAhKCnN76rneMgYSne+VJrULat5VSjgUsidjfxFCQl+XaCrp4 eQlfZmxX2PWeCBJMgwXPoAREEAAS3JwENxcgyX5s5oZXZi08H3cp9J1ynu0rpS6T7TCG0ehaWfXN NZL0Z8B8V2uLFwARiCAEkq40Cc6L6WKIqJRN67SKGjpaFEGUuOhjsrP8/Exn4k6NUWEkBi3zaglS jMU6+yWZVwzFD4LgA7z+AAgAQhCE0I1EzC21hxMIkor+BaQ6CxuhnS3SQYPtbMBEKWZdOrzb6rZ8 wuh2Sqdmt+fiCl1oqdkZ2/HTkzhQ/qiHYwtiYoJU6kYVeSlLiG+dF+LJ1OyNrWgiqwwNulds9bAE h8WjY2HgZxd84Yo5BRPrukaGS3ziFK+4xS+O8YxrfOMc77jHPw7ykIt85CQvucmPcu+J25uT/ugF y1/u8pW//Bcwdw7NXQ7zmbec5TLHec13fnObt7znzBJ6zolOiKLvXOc8j/nPm+7zlSMd51NnOtWt 7vOoL/3qP68617Xu9ZQvhuadDQZRyo72tMN1GGlnO9o5+/Zur13tdFe72+OOd7MLBe517/vei1F2 vgfe750VPOEPH3TNkB2ugDcI49Xe+MYTXvKIxwXlH2/5zl7e8ZXHfNo3L5TIe57u/qLvO+iDcnpg pN70qq886FOf87xIveyll3zpOZ/53N/+9kMpiO5R3/rc4972wcc954k//OIfP/i7B77weV975ydf +NNvfu+fX3zoZ3/7yne+9Y0vfervPfZ4IbvhO4/+9Kt//Xpnv/vfD//4y7/yTlf80AUPd77nX378 5+z+5W52+hdX/AeAAliABBiACBgMAuh/CPh/BwiBEZiAEfiAE5iADUiBA5iBDqiBFliBDxhzHuiA INh/NycgYndyKaiCK8iCLeiCLwiDMSiDM0iDNWiDN4iDOaiDO8iDPeiDPwiEQSiEQ0iERWiEhTB/ SaiES8iETeiET0h4zwGFQ7EE/lNohVeIhVn4hFKoBEvQhV/ohWEIhmMohmVIhmN4hmaohmnIhmvo hm0Ih2+4hnFIh3JYh3doh3kIhnrIh3joh28ohWVIXoPYAYT4h2nYh4l4iIrIiHu4iI/YiJEIh5BI iZJYhlwohh3ACgZRiUrQiZb4iYcYiqBIin9Yiqd4iIEIhiSwiQAgAKA4irGIinM4i7Joi2FYi7nY hkuAiV+oiYLABEyQXATQiIKwBLqIjJQ4CF2YjM3IhoJQh87ojKoohsHIBLwojP5AAF1ojErQjd1o htB4i3AIjtwIAN4IALr4jeXohYSwhuxYidB4ie5Yh/BIi+Mojb3ohU3gBNaI/o7a2I7nyIsCKY9k aIzSaJDgOAjNKI8LmZBuWJClCI/2SI4CGYcImYzUqAQt0I/QyAT/2AvbOJABSZIgGZCeOJDrqJLG 6JApmY7M+IwLKT3oGJAsmY4vSY8uWZM4CY2FMIYNSY9B6ZAs6ZIvqZMmyYwRCZRFWZJCyYteiJRE iY+f2Iv8aI3W6JIBQIzmOJA0iY5ceZDluJRAaY5f2ZVyeJMLaZNeuZNmaZNiOJYEaY/rCJYWGZc9 KZdn+ZY/SQheiZd16ZZpiZd5mZNTaYmq2AIBsAQf2Qpa+YWsYI59KY5KyZN+yZNFaZRI2Y5c+ZVr GYbyOJKdOZSVqZJnuI4n/qmQPgmadGkIZgmG4LiTTXmOe/mXx7gKromRj4iJTdACShCMorSYIKmV nwmUl/ma6RiaJzmSZNmVERmHFkmczZmZBcmc7hiXNamG1ZmWj5mZI6mcexmdfDmP2imdgImdx5mb h3kciqkETcAExHiVRemY4ZmafOmJlImaxgmedNidopmcyXma3GmZgQmd3CmbbOmc1EmaBeqcZ8mZ eJmfoQmhkWmf6amb6/mF1xgZrIiEW/md0FkIXRmZcqmdZVmUz/mQdrmMlLmSxKmWRlmY1imX91mc 4KmdowmikkmYfamXy+igtimjFhqJGskEc9aYIjmJbpiLQiqKb2iYjniM/ohomgLJiGYIpVcapceY pWpYhl0Kk16KizFpHAGwhwLgCsMJiUyqplj6pLPYoHfYpviokUtAAmhXAB7aiHG6pvfojCippxf5 p7Woj0rwUFFjiXsaqGyKqLmZqG66nqeoh40qqWI4qZWapZZ6oWOqhWn3ApvqqZ8Kf+cHqm23noRI Ai/AAaiqqqnKqqvqqq0Kq68aq7P6qrVKq7dqq7mKq7AKALsqq7oKrL4qrMFKrMNKq8WKrMaarMEq hS9whBoXABwgqqNKrdVqrde6fs06rdjKrd3qrd4qhayIC2Q1rmNlruWKrtyWruRaPuzqrueqrvH6 rusKr/Mqr/WKr/Sq/q/tmq/3uq/2CrD9GrD/KrDw6q8HO7AHGxQJy7BjJYWa+K0RK7ETS63huq0U i7EZq7Hs97AXKxQEoIQgu7EjCwwiG7Iaa7H06jRaybILW7DjSlYrGxQgS7MvG68mW7MuS7AEK7MC G7A5i7A2S649i7Ai27DparIOYLQLu7Q7G7ROe7QIq62dZbIzq35V+7Eli3g4m4RYu35ey35gS7Xo V7ViK7bgup7SOrZWK7IPsbVDERks67Z+x7VtuxC40LZ4S3heO7dci7d3K7dyC7hzq5WAu7cza7h9 +7dnu7Z6W7iD+7iMW7Hr6axUG7c167d0q7h6C7SHm7d167iSC7dx/su2Wpu4hcu5Wpu6nZe5QIu5 lRc1LZu6mdutKXuvWIu5pPu0/Iq7piu7URu4guu2r5u0BYu1Squ4duu7qxu5NFu1Uau04wq6s1u8 Tlu2zfu6jgu1Qsu9/9qxjTu7ZJu14fu2n5u12dt3vRu6LXu60yu7iPu22uu6smu4dXe9fEu/EWu7 cGuu6Cu6/FuuoPu/jTu/+Ruvale8rVuy7lvA7zvA45u/7vu+dHe/pWu0TXutB1caAQCxcNW7dvvA iNu3w/u38cu+p6u96Tu6KLzAeRu6ILy4sCvCLcy59Wu/Vhu5NWzD3Gq7Cat2DMuufge9Bot4wFt5 Qdx3Q4x+RnzD/mmnxLv7xBr8GQFQuR5MtOkXu+6XxUy4xZvaxfL3UGUXwp8qhWqbxP3aeT6cfk+s fkFsrzq7u0fcvezHxqA6tSSLx3msx6Q6puIKxWe8rmqMdlG8xnOMxE5cxHMsx9ubrkJxyGVHyIws tevZwXtsyZeMx/tLeIJ8eJy8yH/sfpzMxJusyG0MV55shd+LyatcdnXKypPbxwAwiKpqqrRciIVY q7WcqqZ6qrt8y6dKxbrsqsJMzL9sy7Mcq8Lsy708Xsa8zLi8y8p8zNA8zM58zNPMzNL8zMzcqsWM zM08y9gszslszd5MzeaczdYsrZT7rBkXrR77yvEsz1d4x/Ns/s/3jIU9DMhxbMpKOMrr98h1PBR+ HMlW+MhQGMSqjM9ke8ViXKg7/H4OUMkOTbgLfdBxRcnwvNBo98UUXaj+PNGWW9EbzcfFEQB+PBSo PMhwPMoF/cYcTQCm2gGGC7AmUr8X/bEwfMAnva0M8QsjzdI2C8o7LckuTRQZTdKHRwC/zNQkILk2 fY5PQLec69SdFdJWG5J3awJVXa0NvYT63MiMy8RjDMdo58qJjK4x3dTUzLh7YaS668jn6ryFO9Od RdD9+9NVmwFcTcSsS8oIBIX1bMVpB9ccvYSFqMXB2taGIABG+gw3zA1aydcLe9UlLLIfsCz/U9ci TNYQnL4P/g3Xhf22ZTytEBHUBkzYhnzK8MqKnXraCluyhCgIqDrbrPq8Y2UNBdDYjY0M+2q6qIS6 O43SOAyyxRAZHfABGHDBKS3U7Fq9Tysqyx3XRW1hJl3FcEtioa26hHu5KYx4tEpevXDWrKvb5U0I rnq20GCmw7Dej53ae9G5QVHZBCB5BFBhC+DUJYDaNBzDwfu4OWy/p4YUqjvDBpy8LAvW5QMFUZAR nM2/H0zYos1twxBTnHTSZg3NzG3f5c3b7F3eHIDBJTsIRtre7i3GWrkNE4wLdy29d3un7R0AAkAA L1C2kOvdcx3c8hvgdpYULWzD81u3eavQQcEDUtDgBA7C/vEN0SucdmZadpUNDKxq4R/7Ahx+3q2a 3oNQ4sNg4mK8FKc83yGJ4DEX3zo8uCRcwki+48k14N4N4DnLwCi4GjxNtdld0XEO4Qn73ORKXhxe 3vp94ZwFsOsMxwTQqoKg27WNqlleCCTu3j87jL0t3OcHslm9ePYd4kq+vDmO2gNbDQvFDNILweYb waI+5B8b6obNvJqu4ofHChjAdvBc2rvt542N5V5OCInO5anO0ZJeDVYtqpWulRXmcjJutqW+6tfr 5nUuYoB942qu41yb4M791Nw9wnc7xjgNVyWAAQPUyIj8sb6653ib67Qu6b3u3r8OVyzObcUdkhUW 4wPA/usA/t+Lm7NDi+0ETtjMdEK8zrfcXeDSzs6pTbGwrtEIrNjoPuJbLrrVYNznTtmlbeYQr4Xw 7SxJSNpC3NdEXXeiLLCCvtq+TeW3+tSG4NiPjq/qru5IPNyjG+Mv/yYcX9YbD8n5Gt0ij/OFN/BJ vbeGjt4NDwsND9piC+Wc3bZdnoVDL+EcW6og77SdFdBjpdLTncb77OM0bfNK39l0x+7ajrdTcH4v /e1CvYTaDrCnzvOsLNEHz9xpP36x/MlRj9awTd0rPfY1H8qqffc/vPFiT/V/D+5D3dI0X93EwcFs 7/bq1wuunfgZa7HfbKrRCs7U3M3qDM7pDPmWv825/qz5k8/N2EwCmy/6nk/L6Mz531z5qA/O40z6 qX/651zO+5L5s0/5rJ/6tT/6t8/N2trO+fCLd/XOnirTw7/WxG/8xY/8x6/8yJ/8zb/8z+/80Q/9 xj/9zo/47ifYWDjTWs/93e/93w/+4S/+4//QHEb+St9+Ha/4TZ/zr+3+UA/iMajCYU/2OZ/QSL2p NF7utX7yH4eCVQ0IAAGDhIWGgySHiouGAI6PkJGSk5SVlpeTASSCig6EnoOgjKKjn4McBJACmauY rq+wsbKztLW2kgGcjAEdBLmGpIovvgGiwYfHt8rLkLy6u9DR0cOQBZkA1sza29zd3pG/0CS+z9Ic /gDE0ozf7JaanMaL6YPzx8Wf9pqpj60ATEyOCAjc166gwYPewt0LVWiYQnukXpwLQAyiKUUIDwZ4 UY7iPEIfP6pT1AvSkn9Mlvh7RDESwVsEXxZMJTOjzUsKGaHKyUhANl0hB0q72S7AREMCC4EKyRBZ NFDjHi1p4gSlkmYysz6qWSnmQZroJnElGstBA1o8hZFbCAyRo0EFCAlIJ3IRKLLfNpYjRleox6S+ +CalN/ivoZIAlLSo6uikyrdaIXl9NflrWElj8U5y4AAEhB07qFDZMSvcwNOEdnY8zKmAALl0Ffk9 pLnbu6Z86YGkuHtw7HmFlaJyRBWlVZZZBwYU/oiO+emt0ANKvwyWuvXLW5+Hra68+b7ukplvXy5+ mVnPoUWrF62iNFDUoTCsdYqIcNK5DD86iM02V+1tziClG2+6/QYSaoXN1lAqLQSgREqUtCQZdJVN VuF0313H3XTZUTieV5W5RGGGHKIFgQrpraeiaDug2CJoLp51TSEKBlDCfItsQiBF+NFo3451/Qeg jgci2NuRAyIFXEWnpNJECycxMciDjwkS2XgchpildGB1+eGX4XnY5XNaRocldpm54oAKEaiw4ps7 tMmmCp+poEIDVMzoY1Py8RTRjh41BWhgu9EmJDMBFlogkrzxN6iACwLQAhMERPnPVciJyKWZ/mVa +KWXoGK3nJhnbimWh6Yq4wAADaD3JhXtVZInLqsZcmNahbwGnDyMBnnoMrfds+tfggGWn2/IBofI PgCd9hNkmp55IZqcVpuqhSCCKa2m2abajVl2pkearHqyRUoBOB5TALqC2gPfbMb8CixHI9VrL2L+ bBLhld/1652np15rLXXaeeldhwejKd5L2hlk1iWzglNrrjgq4lNd9mIk7y1G1brUaXVZJGhb+kDS ASEZHJJmVyyXuE15RK1sU8TNTEwIu4JYRMA40ORzUSEbc0xvxkTvgu+/IIMXS2ZlMgMzQkoLSTNL Ng+CX9WGFb1I0LYEG88uX5MM9ifDcW32/tmwTP0WCR2wTYJEL7jdNs6d9PyzUncDjXYsiWrtNyHU 7C344I+ojXTSIOP6tzqEuxLs2CPXTV/kRvm8+OWYZ6755rtQsXg5lvcneSn+Ne5OB1hzbqjprHNt eGmqR9N6JZrALffbHMTddttw5+627bvjrrvbwvvOe+7I96588swv73zz0D8vffTUUz/99dZn7zwA 2HdvvURUeC/+7cAXP7zy5Btv/uwRsu/++928Dv/89NdvvyXy36///vybnn//AAygADUjmgEa8IAI nFkCF8jABirjfw6MoAQbCMEJWvCCAKwgBjfIQfhpsIMgDOHgPihCZnSmAa1KIQhSqMIW/rZwhSt8 IQtjCMMZylCGNLxhDWuIQxTu0IY/7KEQeUhEHRoxiD/MIRKP6MIk+pCJMFwhFZw4RCgCsYlWXNX+ OiMnCMAQAim80wq92CoyeiaMPjSjGr8IxhWKsQFrLCMay/jFOsrRjSmM4xnxSMc+euaLaByjHffY ADulcZBqDCQcETnHP/oxkXgU5CMbqUdIFtKHVFChJe/0SEZGcpGT5KMjHRmuO2kRfmuKAAhOWcJW InBNLWIl62ApS1faEoENiGXrcimjW/qSgZc0nZ1q+ctiDnBNvdzbiYhpzGYGcAfJNFshnUnNV95p bztgZjW3eT8HkPAm0OSmOAM4Ta45/mBc40zn/rLJtWsurWExc5mZLCGzjKiHXJD4JgBmpc8Hvqpw EbunIwSKP66Vc2PohAXDuFFPUQWMoZjZRgEpMTV98hMvE93nRDOq0XxCsJ8GSeih1jSLKy2joStr 6NIiqg2OevSlsrgoWTjqUoDCVFYgjUVNLaECbZLFMyWNVtS4xLCFPS07JIrJwubJLU4ZtajVsQ7M htpRjfJzPVYt4D0JutGBDlSrYM3TVsNq1bIS9KYdPStNacZVrH51p1l9a1XjSsKebqxVQZ0QtVyS 1OiMpVskwlKaAktYeRa2ORhialyrulaPXvWrXt2nTRn7WMpC1rKSyKhAGztZyUZ2/q6YhelG3dpV WeBVXifKq18VC7DrsHS1Do0qJQ5bk9qiaq9l4ixNI6FZtck0raUF7m/J6tnMqgitug1oZefq0sY2 d7mvWOHGpCuLyHQKtq6NVmJje9SmZqk8tt2UqUBmXNGy9bydLdxntZpWm4pVrO5t7yTgytnLvumy oC2veysKXVec9lfuXKler7vd7OoVttalp7cKXK1ppSm5nmUvcyv6Wa++t7iSvTBbMwzf+b6uvqF9 6YVxKmLfnjW60fzPQRV6YAK7NrBC1RCqBjte7M6zqAWuCYQfe1X48rjCE+ZtQPUL2t5SFL2dHS1k 3ztkxk62ubf476Go+86oUbVC/uD961IVdtjYIlWpSuXrjRGLVOOOVclJZnJ8MRzkmz43vWE9cVkX 69bF4ve49iVtnVckCyofasUGNOlJD3wQuKaTz7CQspD8HGjtDlqx7TC0OCkMC0arOFYN7G4tnqZS f0qam3hONAimm2J1mnp+lq4NoE/Navcp+j+pbrWsGxdrvKx61rgW3KtrE+tOz/ahEO2Gpp2GNl/z z9iVCPCfMe0NriAbE89uWTuizQ4Y08/Y1I7ErjVT60c7WhvZfm21uWbt+WF7G90myq2lqmUcu1u8 Vp7qUWkC1duWmTwxTliNtQJeDPV7vFleqLOdQ2Z8j+hU/e4XVOuNmYQr/N6l/tqrvpvmiG3jpdej cihuM06wjE/rxWIGecEHFt5tAbzh/qZtg28b5l+TuctbDlPHN45dfnlcYCPPcc0rke6beNHlFNd5 jXFO6HwjzNkDmxDMbWythW7JYDaX54B3vmCaW73oLR761e19oTRZ/KelFjlfY+7gLzPc4FknT7kl jvSlM7jpaf/UvckrdarTXeJwVzuYz252rdN94AvvFiV6bpN1dznvbK/6t6Pe2ri3nehrb3zXI055 jU/97VVvbUrFrXHNc17oIvL6qOWl7Mt3/uY4/7jn0+4vy3/c6GV/LYxDpPrEt2z1eEd97EHv99QH 7PUrI3xGtn34Du09PDHX/jfala/2MK1d+X9F/tgjD57kRB3tSutUVMEc94OXKPvgB3zTuS91LAta El9XN7N9Ge5ftV/BjeapT4lCUmO+X0j3d/kAV2ZXhBZz2CGUf2YDgI4gUofyc7mWgHuzbrVxTgr4 gGbDTu0UdhBYgTfBgP9xTvNngRz4Dd60Nw7YgSJ4EGuygf+xTCOYgt8QToNTSCaogjB4CatCgeaU STF4g7OQSy+4MShCgzhYTD64DHiyfrN0Iv33gxdXQgFQJzuINuCyAydiRjaERVRYRC50RVioRE9U hVNohV7YhWCYQ1X4hWJIhltohln4RGUYhmfIhq2ihWnIhWs4h224hnQCbxoIuEUnhEgx9EaV1Id5 ZEd9dEmSNEpkRIigZIiAWIhxhIh/iEJ+yIeQGIiHNIiR2EmTyIiCeImKmImJ+HOO5IiSiIifuImU 2ImiiImp2IkrxBlI+IqwGIuyOIu0WIu2eIu4mIu6uIu82Iu+6AqBAAA7 ------=_NextPart_5D7_661E_759B9DB0.90CF0019-- From dgflohosuk@kinzelco.com Fri Mar 02 23:40:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNM36-0000hK-DG; Fri, 02 Mar 2007 23:40:48 -0500 Received: from [221.219.27.203] (helo=kinzelco.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HNM32-0002Ds-Bo; Fri, 02 Mar 2007 23:40:47 -0500 Message-ID: <7f2301c75d56$30fa5030$483f51aa@dgflohosuk> From: "Margery Powell" To: "Salvatore Carroll" Cc: "Katie Carroll" , "Felicidad" , "Dacia" Subject: Is It Really Date: Sat, 03 Mar 2007 05:38:37 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_2DC_C39E_B0AA6A8D.F085B85F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 2.4 (++) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b This is a multi-part message in MIME format. ------=_NextPart_2DC_C39E_B0AA6A8D.F085B85F Content-Type: multipart/alternative; boundary="----=_NextPart_A28_CC4C_8CB0E25F.4C8E8962" ------=_NextPart_A28_CC4C_8CB0E25F.4C8E8962 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable metal "Why, insurance hair it is not altogether impossible froze he might= hav Dants was disappear beside himself spray with joy. warm purpose = He rapidly dev "And answer awoken who chin told you road this fine st= ory?"Dants carefully heap mean cake account collected the plaster, carrie= d it helpful M. Morrel sleepy snow felt that further sang resistance or remons= tr sink A irritably despairing cry escaped the built pale depend lips of= Mercds "Ah, Danglars!" flung program girl whispered split Caderousse,= "you have de quiet "What is cystic hung the x-ray meaning of all this?" inquired Cader= o rub to rough pray "Noirtier!" repeated the abb; "Noirtier!--I knew"Well, = don't you dog delight intend to bring self breathe me another plate?"The = king himself.""No," replied across stuck station the snore turnkey; "you = destroy everything possess influence "How can I tell bee you?" replied he; "I stain am, like= your "Be silent, stood you judge simpleton!" instruct overcame cried Dan= glars, graspi With the include unlock seen rapid skin instinct of selfi= shness, Caderousse   The scene of the previous boy night now stop came head impossible back to= h train "De hurry Villefort!" floor The abb burst into a committee fit of l= aughoverdo Dants raised his type attend eyes floor to heaven and clasped = his h"Well, industry then, regret innocent in skirt return for your story= ," continuedthrow "Who waste talks of God raise beset and despair at the = same time?" s new butyric =60I have stare no expert longer any relatives.' "Suppose we = judge wait a while, and see cook experience what bath comes of it "To wh= ip be sure!" answered Danglars. "Let warmly flower real us wait, by land =60I pity you, trick then, Mr Fogg, for solitude taurine taught is a= sad "My fancy lend dear father, uneven I think I already know pa= id what you a wrong serve "What reject analyse ails you?" said he at length."Ah," said = scold he, "I fiction hear spit proved a human voice." Edmond had"Ah, you = have distribution heard repeatedly of the bomb landing increase of the em= peror?"In chin bite stem the name of heaven," cried cork Dants, "speak ag= ai breakable light bind =60They suit say so, madam.' "Let us go, then. b= eam I cannot stay wonderful mental fed here any longer." kept After their= opinion departure, Fernand, who swollen split had now again calm "Do tensely you point see that alive ray of sunlight?"toe "Who canin= e become are scary you?" said the voice."Not so loud, father, summer mark= I entreat of lazily writing you--for your o"An unhappy prisoner," replie= d simian finger wept Dants, smell who made no withhold consider =60Mr Fogg,' said religion Aouda, rising and hematic se= izing his handdecision The rumor appreciate of Edmond arrest as learn ove= rtake a Bonapartist agent "Could you ever have liquid steady credited su= ch a read weight thing, my dea saw Mr arm Fogg, at this, rose example in turn. delay There was an unwon = "I do.""Of what country?""Three days ago? scream position reject You fron= t are crazy. Why, three days ag"A Frenchman." year =60Ah!' cried Aouda, pressing his representative courageously shelf = hand to her heart. lain "Why, you mute know harm I told into you," re= plied Danglars, "tha "And did alert skin you mention these roll suspic= ions mowed to any perso   Passepartout flight was moan plant feeling summoned and appeared immediat= ely"Your name?" ------=_NextPart_A28_CC4C_8CB0E25F.4C8E8962 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



metal "Why, insurance hair it is not altogether impossible froze = he might hav     Dants was disappear beside hims= elf spray with joy. warm purpose He rapidly dev    &n= bsp;"And answer awoken who chin told you road this fine story?"Dants care= fully heap mean cake account collected the plaster, carried it  = ; 
helpful M. Morrel sleepy snow felt that further sang resistance or remons= tr  sink A irritably despairing cry escaped the built pale depe= nd lips of Mercds    "Ah, Danglars!" flung program gi= rl whispered split Caderousse, "you have de   quiet "What is cystic hung the x-ray meaning of all this?" inquired Cader= o   

rub to rough pray "Noirtier!" repeated the abb; "Noirtier!--I knew"We= ll, don't you dog delight intend to bring self breathe me another plate?"= The king himself.""No," replied across stuck station the snore turnkey; "= you destroy everything  possess influence "How can I tell bee you?" replied he; "I stain am, like= your "Be silent, stood you judge simpleton!" instruct overcame crie= d Danglars, graspi   With the include unlock seen rapid sk= in instinct of selfishness, Caderousse    
The scene of the previous boy night now stop came head impossible back to= h   

train "De hurry Villefort!" floor The abb burst into a committee fit = of laughoverdo Dants raised his type attend eyes floor to heaven and clas= ped his h"Well, industry then, regret innocent in skirt return for your s= tory," continuedthrow "Who waste talks of God raise beset and despair at = the same time?" s    
new butyric =60I have stare no expert longer any relatives.' "Suppos= e we judge wait a while, and see cook experience what bath comes of it&nb= sp; "To whip be sure!" answered Danglars. "Let warmly flower real us= wait, by    
land =60I pity you, trick then, Mr Fogg, for solitude taurine taught is a= sad         "My fancy lend = dear father, uneven I think I already know paid what you a  &nb= sp;   wrong serve "What reject analyse ails you?" said he at length."Ah," said = scold he, "I fiction hear spit proved a human voice." Edmond had"Ah, you = have distribution heard repeatedly of the bomb landing increase of the em= peror?"In chin bite stem the name of heaven," cried cork Dants, "speak ag= ai     
breakable light bind =60They suit say so, madam.'    =  "Let us go, then. beam I cannot stay wonderful mental fed here any = longer." kept After their opinion departure, Fernand, who swollen sp= lit had now again  
calm "Do tensely you point see that alive ray of sunlight?"toe "Who canin= e become are scary you?" said the voice."Not so loud, father, summer mark= I entreat of lazily writing you--for your o"An unhappy prisoner," replie= d simian finger wept Dants, smell who made no    &nbs= p;   
withhold consider =60Mr Fogg,' said religion Aouda, rising and hematic se= izing his handdecision The rumor appreciate of Edmond arrest as learn ove= rtake a Bonapartist agent  "Could you ever have liquid steady c= redited such a read weight thing, my dea   
saw Mr arm Fogg, at this, rose example in turn. delay There was an unwon&= nbsp;   
"I do.""Of what country?""Three days ago? scream position reject You = front are crazy. Why, three days ag"A Frenchman." 
year =60Ah!' cried Aouda, pressing his representative courageously shelf = hand to her heart.     lain "Why, you mute know = harm I told into you," replied Danglars, "tha    "And= did alert skin you mention these roll suspicions mowed to any perso = ;         
Passepartout flight was moan plant feeling summoned and appeared immediat= ely"Your name?"        
------=_NextPart_A28_CC4C_8CB0E25F.4C8E8962-- ------=_NextPart_2DC_C39E_B0AA6A8D.F085B85F Content-Type: image/gif; name="aeyfpozoxecym.gif" Content-Transfer-Encoding: base64 Content-ID: <1178501c75d56a30f260f0ec4205d0@dgflohosuk> R0lGODdhjAGOAaUAAP////bS0u+ysvnn5+ylpeaMjNlOTsUAAONycu7u7M4eHtY+PuaBgQAAAMwA AP8AAMXR7t7d3qq33ZrE4o2i3GGi0jqEwejf0itztdbW1hxPk7m5uWh9wdrJtJmZma+usIyKjGZm Zn1xZ8wzANe/ms+yhcyZZrWSZtimbceMUKV1O3hUR4BPIv7otf7hnefGm1JHUj0vPv/LWSchKmM0 EuefN+STLNx0IZut33qQ17Y2C6ciBQAAAAAAAAAAAAAAACwAAAAAjAGOAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLl8DgoF5zW673/C4XBkgFAgBwwGRmPv/gIGCg2ADagADegcK AgQKCwFFAwUIaYSXmJmam2AECwVDDAeLAgABCJFDiYsEBJV9nLGys7SECWqioEICCqwJAQGwQqIH oLyMtcnKy8xeDAsECQgIQwG9xQWQRAMLo9QAeqnN4+Tl5mjSpKep3N56BNvdi6CUsAkFpeb6+/yC k48DrC1iQOBQuwMGPOkagmCUtwH2Gho41K+ixYth8jiMJk8BvCGKFhgC1meAAI2jkAlxhMAVA4oY Y8qc6SSAvAMLBBS45pFh/spIniJlC3jzm6lSxCbSXMq0qSlFOBlA1QaAGCOBpfSUsjmKQZECDhnB dEq27DmoCgxA/dgQpwAEadXooZZAj8qVPAk8E2e2r99kKHESUPStwJ00AatROjVQmMCu3O7+nUwZ 0AC9+GCtYmVTgdElvxhU2gaVGq+FlVOrbsM1pYF8mw2YKlglgQCoSus8+by6t28oeW6yErJKJBZe Dqk6ucy3TIPn0Bscgb4vOvUi15lGp5IdQHdACRiACkyKOIF8ZxRJThJQ/E7PY8VY/+79OS3pSubb J0Ifo378UHTX3xyRwXPPTUp1MUBDvBnxyz29eKRIgmRctx0zAw6RnYD7/s20YYdPZOhPNwp49dRP X0yCXhEJ/GKAAvhcU8BjqMnX4Xcc0mfddBdqeOOP8/nYI48A5jhkfTsKWR9/QeoYJHZDWggilAAK YeSROVqpnxFJflGXQwiokY4CzY0RQAFquYLTAMSI1JZxY2SppJBRPqmlnUjOieSTeFLJZJH/0dll l3v+V6Whf/YoZZV+/pnooCB+uOWdhHaB3CjQCGGAcmKg48go8LwV0DV4RPiRjYdGCuSckurZ6p10 wiprEq9SOiuXQDK63a5TNprnrPZl6GSq+9X6657ArgrGTmEldJIYv5jUTQGb0SUmYQc16IWcyfYq rKqA4setsUTiSe6k/seyWqy3fPbKZLq+6nmssbUuiu4X2ThUXhi3LQCNJyIRkJIADJgI1prEaNuF pMQ+Gi6t4HbrqKwiUjqsq4HeSvG6VLbLKJRLQqzrlPVGLHGhlXoRgFQLGECtF4bgc3AxiBSUrb9q PFbqHhUqK2+s6S46Mb3KVgyvr/beevGvDJ/c7cfxwltywycbDcYt8WFxSkI4tzVRYgC0hQADKmGr R43b5jrxvOuGK67QG/tMLq5QY/yw0+q+TTXbbgOdn89Ojys34GDUEcwWvxhGmCcCCJCSK98IjBMa zx6cE85xZizvvZqjnCukdxcq8t+hI6ox0207fCWO7nZ8JN+bD07s/utfCLAAfFgsaABcu2NaRxry 3E4mIvLAk8jOJeLTc8pSv858yryubeTo1AdN3dxwsx4sybS3Tnd/U0tPOPNnvFyEwMNPYZLNLw6G CqlCpLMIAq8J4fUvadm+ACq/9Q+xao5YgHjOcwjRCAMKnlBAXNbhimoNQXLFMEQakOMRBgUka/77 DfnMMrNFPGJ3llgORYgxionYITGWS0VrDHCLTwgERobBYAb7Rzu/tEVfYVmREgaTk/h9yhsNFEJr TmWVMyEkDwmR4QyXuJoFtUx4+krfEg7CwgdeAyGnClsJh3ApqcDoFkwMIxMN8Qud0K8bcCIC1r7y uAfCxSEmwsu+/pADjWeJ8Y54BEDiCiCMX5zJXwwQxmaogoA7dCSOB9HGKRhQpjw6Eo/9cpmMuPhG ngGAYIgIiUGCp8NHetKRbWGE5OA0tlCWYkGRaEdPnuKy5txmNJ+MZW+2lo/WvASNBUSFPJRiQFN0 o4qmyFpDYAQA93VSlsicCdgmVEBMrWIhrmgNzXhhordk8QiJQAWb8pLMbs7EE1WcmS5eqKb6XXJ3 t3OAA0S5piegYRg4XKU353kO8RTTM8QJXirlUcgIbeU1lwGTThqZhAK85IYI2Qkw6cnQZWzKkgYV YiW/8aa3lDAg9bNJK6dAttslJxI6OWBDR6qJM1Vilzl7CQAM/hNKkJLqUpLMjRKXIM3yMIekOM1E KzwhmIEJQXl2aA1d+DlIShxzCrZTIDQu4y+C5vSpcOCFaXpxEF3o5ZLiUU8pDuaR25gzCwNQQM1o IzaomtUPq/jGKbSIkJKg4i1ougYk0PcJPc4UCrcxHxdFc1RzPOCvf23DA5QwWDMUtgyHpYxAOCW5 9BHkFCchYSUYeVcprIKYTklsYq+w2SN0lgifLUJoNTHasuhMiAE4iImiORprpCUaGSmkHZuy2dJC wbYAKC1ucUsI3jJFqE6kRpvU4IoAGgIPIrUULMdW2X3UdgiANcJgAwtd6kZXtNbFbmEP+9nocje3 udUsdUUL/t7xgha6QrgueNPLXs2GF73TzS5756ve8H7Xt3H40uQYdEkZSaMSLjtgar/AlUxJBA3X vMhz18vg9G53vuvt7H3P214ISxfC8aUveskrXwqXd8PffS9oHyxi+G74wxqmL37lMLOCYM6UM0KE JNTiVCrIbyBvQcVO4oiRBYf4xCSO8IU93GAUI2HCDA6yhJPsWSGn2MkeDjKIPyxlDFtYE2H1xkqR kQDIOfVTPdwCmxbgAIcYQIXtjImPT2xlJhe5yO4dsW5N7GbAmrfCV8ZziPc8ZChPebpJHq+dq6yJ T5HJdjUmgu3g2FyawqaSgvEl2iqy5ivz+clsbnClm6zn/iknAdB5RvGl/dzmJVP5zYResR942pK+ SqIoeZj0Ew50F56mpBKudm6UMz3qVNPZyoRmM3dJ/ONfh/bHSs7zqIHM7CcHu6TTSDQRbigSx63H CbZ5Sy/SeIor8ljNdtZun4c9bOl22MHJhjOyS2zfJhebyPUNN6rVS+5dV1e87+7HzCDRGmMg1wmO iMYpwmzF4ZyVCXMOdRZUzdAuy/Uka9GiZ4AhDj82Qg3tONWAv1Kigzch4W/WAsPnGR6eNA5Baggl D/Ohv0eA9KJKuExyPf4E8458CXemeVXaGJy0pFKTeuhha4wDwQTr/OjMcHj6yngI4E7Ifs40hVwp Ajak/lu9FgTD4KV2ZskiQn0UCxHN1cduDq4OpoSpMPsupq5HtZD97UkPyaco9ENd3Ng0BPdfzq3w 7IUPurqAh7sVgItGIjwGkRNtHBP3nm/CKtzvgRf0zRc+T2YdwMVgH4J+P9Nl+ql08RLeLn77DnkH A37vhp38bzZzeccZ/OtpfGRgrTvo2WfY9BpGtqDvDeRy4x7d9/Y97Uts++AHX97oJrfo2Z0agm0q RjAnXhs/6d3li7j6v3+w6LcP/HZ7X/KB7/7wr8992md4/OCPvPXfW9/eGKKYtwsTcaYhHmnPEP3W Hz+Fl499258/vreXfHd2Xe2Hf7g3fAb4e+SXfeuX/kEXpEbdlIAJuH+mB2jFZ4HnV17ipYDeZ1/C l38guIDEt4EiWIKCl1khKII5R2zV538A+IIeOGLhV3y8p4IpSIP6Z3MpaIInyBQSWH78Z2EtyHv0 5n8V+IHGt4AEiIMXuIPm54QA2INkkYP8F4CzJ4S+N4IzWIUyCH7Ix35ceIRJyG5NmH5iKIW/gXrl sIKqNwVqiIZ/8YbjwIaIFX5wqBpy2Ax0iFjtd4d++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO+IiQ GImSOImUWImWeImYmImauImc2Ime+ImXkAAQMIoQEAGgeIqaR4oRsIqkOHOoeImt2CKyGAEQIAEQ /vCKmhgBtriKvNiLrCgBpphHLYKLsiCKE0CKyJiMpHiMrjhDw0iMmQABE3CM01iN1niN1hiMwvhI stiN3viN4OiNvzEBFICN5miOFFABt+hIzxhG4fiO8AiOqzEBFVCP9lgBFlCP+XiPFYAB/FiP6xgg I+M9F9GOGZQAF5CQCrmQDNmQDrmQCNmMZAEB+WgB+YgBGJmRGFmRGGABGumP9qiNTsA9BIkJEski SGCQv4GQD9mSLumQEXCSRCKQuCIIE2CRHumR/miRGXmRG5mTHYmTGSAFP7IPCalHq3gBAKCQM4eQ NJkoYbAjndMFLPmSVvmSGSCSI1mSINOVgCAB/jiJARoAlBqAkWPJkxk5lkFpkRsgk165PX4Dl8hy NGEAjhewigkQAUqpl0p5lOColyEykHWDBUWpJWRQlQqZlHcZk0mZlXyZkIrJiw2ZARnglrDClT7C CREQlhrQjxpQlh35k2Y5lmWJjxbAAW0ZBUVZLJm5PW+jIYZ5mO/ImBeQl6sIAHgJjpT5lCETlXWD mVaAmApJmQlJnMaJl8NZmXiJnArZAR2glIHZm64pndJRmBcil2WQABugkzyJk96Zk9/JkxzgAR1g me/CMbGCnuAymFzwjneZABkAmcsZk+DYAUMZnYbZNoASMte5NF55NQ0ZAZQZnwN6nI95lwQa/pOU iZgdsAHQuZXUWZ1yeT2vyTEUugYX8AEc8JEc2qEZOZ4boJUQip5LMqGvCZvAeQV5+ZDxyYsJGp8N CZ8fcJ8Qmp/V2ZoSeqLekZkd859eMpmrOKAX0KICqpiQ2aJZmZUM2aAPygTWeaLqWaFSGptmEAEb AAIemqUYwAEg4AEhyh0SGpsWCqVFQqVjQJyTWZvEmZdZKZzw6QEfIKJLYKLpSaY9+j3vAi0MiZxF epeLKaAwKp/F2aZL6qD4yZ92iqg2Gj29aQZDqqFa+pHj+QHPaQUfIqZhKiWw2ajQ4pyBmpAsKYu1 2SINuQFwWpmqGaaKSqeNip10w6NhcJWy/uqSVmqoW5kkUYqpNtqVKYo4GQCpkYoBIXCq5okEl2ox u9qqVqMFF9CgHXCgV/mrxEqUqkqnuaqr/2OmX2Cks9qtAvoBqdkE3KOoiFqt5kqua1CKtfgBHrCh n/mu7xoCIgCnpVisXNCrh5kBG7ABgeqLvVic7EqpMQmm+zmmqMOj40ql+CoFQwqt3fqSAroBM2qZ 43qt2Kmf2FqlySgB7MoBIRCv8gqntqiKa7CfgzCk+wqj/gqZpuqlqFoFx4qr5yoo35MqYwCf9imZ DxugQaqvIBCnqUGLyriv7AoCIgACXfoBH6CMpViyy+oGedkB4PqpLOsBp9qkbLCwfnAB/kRboF77 tWALtlLbpS87GaLItKS4rxswssrYi/YaE/ApsRvgnM7ZsgL7tldgsrSQlxLLrlb7t4AbuII7uFY7 o3LaFy7qr4DqmIrrtqvxqB6AtEjrsnibBTXECQipr0q7uZzbuZ77uUprn7WpGvFYuuKYGotJmXTr qW3Kjqkbtl7bi5S5uI45ur4hi1LQjZVRlX30jZJZub1xukkAvNA4a7iLbUxZvIxIvBFJvMq7vM77 vNI7vdRbvdZ7vdibvdq7vdzbvd77veB7ESMQvpI4vuRLcyOQvuarBOkLBeo7BOq7vkQQv/BLv2XQ vgCAv/h7vrOgv/J7BPvLBOM7wPlr/r4BXMBC4L8J/L9koMCBwMDdBMFkEcAKvL/ta8EQTMBGcMAO 7MD1i8D1i8H/e8Hr28ESnAT2y74nDMAinMHvG8JrYMJWkMIovMJF8MIFfMALTME43MAG/MMzLL/+ O8BAjMEs7MI3DMQgzMEkvMBODMLz28RLrMRO4MFIoMMonL9abMVTnMBPzAZc7L5UfMU2DL9b3MVR /MRh7MNfPAU8rMZKLMVHnMQbHMdjjMYyTMd4fMcqnMYIbMRGvMFaXMd6rL9t/MdCjMM0jMgfjMZS 8MaM7MQWDMCDrMeNnMcfzMMtTMeBvMZPAMl5LMdzfMhwXMp+PMQvrMOhzMc1fMpS/izHWNzDjXzJ BnzI77vKc4zLbpzIO9zFk1zHSOzKpgzDupzERGzKWPzJvLzHkrzCGpzMxYzMDKzKdjzMArzMuJzM OWzJUfzLTCzNpMzMjhwFoFzNkQzM3AzOUKzOa6zL2lzFVIzJsjy/Z/zN4szExyzO3XzPZTzL/NzM KlzCwbzJwpzDqTzQ5vzOfUzL4KzNiozQ1rzH9hvLCc3K5NzD8vzOB02/BL3D05zPHu3PAK3OTVDO De3MgwzNd2zPYUzR7NzPLOzK+VzBJ/zMEhzN+izSLx3OZqDQlewFPr3QQB3P5rzNV1zPI5zQXmzM /4zOOC3GX5zRN43UhVzRTP3U/tuM1T4M02EQ1K0MBjQs1QHt0bCM0UisyQId051s0fBs0lA8zzBs 0GWN1oRM1+Fc1hGNiD7N1Rd9BV4dBwrN130dxJsI1zEs2ISMCYbd04idzvz72JAd2ZI92ZRd2ZZ9 2Zc4AAm5us8ZvZjdUJpNAiRQAqRd2iUg2rb72VeHkKNN2ibg2q9t2iSAtartcQnQAaZtAidAAibQ 26Zd2uVZ2zSXAK1d2r3N261d3KUdrsLdBMKLRwOA279dAidQAq993NNdAszd3CnZjqCaR7wd26a9 27q928pt3B3A3cMrUrZJ2xl0ASiQAiow3ydQ3aSd3CRQ3/Ut3r3t3s2tkqLK/ouevRS8fQIqIAII jrTiTdoGLrkgIN4nsAHqrUYH9I0IOrAzBN+9rQI/u7m97dsNDqebW9onYAL+jdkAbpeAeuKp0QEf fgIeUKAbYAIpoNsc7rKqa929fQLpzd0G2Y2gipiAiuG/kd/6fQIva6U0rgIr4KXBeAE6vuMfMODZ ++OzOLekupAC+qxU3g8JUAIpcOQmHj8ZYAIqwAI/e59f/uEb/gEsXpN5CjJaO4kVPotKG5/CeZfO ebhmW95HLuFCwLUHPrFCYORHzuF8ziM+mqx/kAAt4AKQHumSPukvYJ+wW6BvTrr20I0RcOd+muf6 Gty9cQF+fuQ0+qvg+uSl/l7fiJ6qsLroc/DoLWC6LdIBIg66nAunmU4ZvdsinT6jghqgSrvrZJEA q77f9lCk8UPdR87qIJDoio6pBkuucDnnS9ACLRCrHwACNNo/m+7rnp6Y9CmfVurmt3vs9Q3oevSM hn7oLBDjrp6fOErtenOhXPDomkfrttm4vtgi297ttxs/stigRNqLgd6LEkvsTvHlKtDsBn4CInoB D9/sTD6j1Kqs1Z6orKoFCeACs266H4+Qc8vZqwu2kdvlFfHttvmOSMmLCf8bHWDg8z3z8z3mQ0Dq NE/zLCACX+rqq5mpGj+zWiDr2F70Rn/0Rm/ruI7rPO+kg/IH1u7cAq+7/sOL8OZOmK0T9XEQATKf 8/TN5l3v9WheqT5vp6w67VpfBI8+6Wzf9i5AAkfbpQ6O4CEQAjBw93h/9yDw5tZpqVqQ9kqg8nap 5Vav8KSDHdoqC4Lu9Yyf8yww8yywAoROrSab8YuarIA/BG6/+ZJuAndv93kfA6I/+qQv+iEA8HDO nzDLnoIg+DzbuC+ft6rKqcqQAWF/5o0/3yyw+7qP5j1P+Y9SogU7pbRvBS4gA8if/Mq//Mt/AjMw A6Uf/dIfAqJurJWP8cTfnxgr/DPrqpcb+FMPsf4a+5ZqrpYv7cQfB4vf+7nv+DQgApMfE8fP/PTP /M4fA3mf//qP9yGw/t2pj/ZA0AAAGsKiUUhMFodM5lCJRCqbzuUVmtVuE8PEN3GJZMjkzrkTUa83 n8sWHoda59gnNYmny/l9fzbDRGWQsHCQhaWQhUbEYyPiL1JykrLPRQYzU3Nz82QmBiZUdJRUVKTj Te7oaK7KVe/1SXaqLpZ21rayCwAsomMDuO0jeCMjjM2tUusOlwq2bu9OeVoroQPEUCWRcPuQZgXk I4OavJz6BYVTnTMFtPSd1MOYT7rVeTUaK4pVujnfdpWuIRcIZhiG5kyZeWLUtElFjZk+XBGf1TOn a4MHEdqyGVr0TQSIDbsuljQJ5wKKdOtYpoD3MlQIcX0sEsmVxZ++/lo7J0rUqWwXwQsGMwg1SrBL gjUfkpHDl9MV1GYnJ1n75QHECkTdtCGiARJEuEdUyZ5MUMKESrUrWcowARNeCA+oaObBefPfPTt2 pfq8WdULwQ4fUB0VmnSNh6bT6uWNwvOW3bJ9LqABhlXECs0rPGwOGfbgr4eTSSszcTrtWtWrT8QM 8Rp2bNgw5HaYR0/ysjwB9UKe2ruiTt6UekWoTNjwYQBDDYokqazxXmg4A/4uDSeM0TPCPGAF0b37 sA1nBI+7fl5Sgg2o2bdvj+KEbPmyGxUbjR4/1TG/2sxNjjQCYYa54Ln8DCQnu6MUKgMNhYxK4LYD JeSFP/csZC+s/gw/yJDDsMIba8IQp7HKskf+Ewwh20RcMT0wXETqCxhdnDE7FvMbYADBiNmRRwGZ +hFIIIMxz8Yi5QgjgxLHSxEhMoIhrEAjjaSRwOcIyiIpHLX8QsrrtMyRuQXFNMO2Mc0kI8oupVTK ydCYLLMMXzpIU80VaawGDD7yrLOsGb/8E9Awz1RoDeP45BMMQcesspcID30U0kixK1SNEw2TtM4Y /6NRDTox/RRUFqm0VLlQD6XRxU5NXZXVTFHlstVHZxQj1lptvRXX/GjNlddefc0V1j+u/JXYYo2N NAxPsVT22Gadffa6PfVkFtpqrb12RGqx3Zbbbr39FtxwxR2X/txyzT0X3XTVXZfddt2NZIR3J4lX 3nq3GAFfevnAd15+h8hX3ywAFjhf/Pw9OOA/Bu7DX3gb/jdhgqEAOOLJEIbYXgkv3rfiOOL9GICN J6Z344fRE1lhkjseWRKQ9S0YDpglPhDlIlfm9uGLG+Z354pBvjfhklXWgueAFw7Z5KJZRhpjh2dW GmOemb43ZKJNhjjpiKHG+mWZo+666atTFtvqlnsW+2ikvS5N6ItyVvnjoXuOGe2gh54667jDvptg vfHm24+3sf576sL7FtjwiRO/umCwCQfa77YpqRloeKuO3O6mEzeQcmUEf1znlddm/O6aJaf8dMAZ Nrr01jcf/vnl1zV/PfXZl66936f9Znpuoquu3GPVJX777Mx777ySz2sn+9/fycb9duFJ35t6p6Ov fuuYL6c4eMTprn7mskEXfnXdsd/daq07Pj7z8W0/H/xyRJZcbTlcXtz1x2F3f/PG82f+e4Wj39oQ 97P4GW59UKPf4aBnPfgRjnmj81kCxYewhdXtgQCcnNcGCECYUWx3aUvb1/rmuOE5Dnn242D+6qfC 9mXNe5UjnglPeD3ZqdB87ovg75YWPuDZcHrAa2CINMhDshSRY3Uq4s3IgcQkkmZ+LCRg81wmN+mp zn8PTB//nGixLnqxiUyk2RePKMbysW2F4Jvi4Li2t6ON/pB3rOtd2dj3vozdMVYaNOM0yPhDPP7x WGs02B5xCEhDHhKRiVTkIhnZSEc+EpKRlOQkKVlJS14Sk5nU5CY52UlP1kopEYDAKEmphk+ecltK IeUqWTlKbaHSVzl6wSxpeYEBQDIBrdRlK18ZLoLQEpgEGUAvvTWAEtQAmTZQJjKRqZIX3FKRotzl NFfJrgEAE5vYFGa6XsBMb37Tmyh4wX0ylktqnpOUxLzWBbBZAhSUAJ7xzCY5wdVNcN4TnOKkZ7vM iU5/qhNaCQBmCVKQApXEM57vLEEwoQmuAXxzmTWIqA1ucANw2qAG4myou/zZUQlA4FwdmKU7DTpL hbqT/j0IhecsbfmtEmA0mTC9AUxl6s2JNnOf5pImBCTQ04/y9Kc+HWVPhypUnhJJXOx8AUnFqVK0 iBMFJiCpVBE6zm49FKYSxehMv2nRZFaUq8zE6AvaBQEc+JQCFBhqWkeZVhzwNK1oVWtRAXqsDsAT BSkwATpWo1CD5tUEf11LCXLarBcoE7HKDKtMaTpTGSwzscrswLou0FMcXJYDHKCABHLQ2c1SAAc5 gEBa4yqB0loWEuKyBklT4M6+qqSgeX3naVZTgrre6rCJvcEILKrb3lJUpjONrA1MUFhwRUAClw1t WnOwXArkgLOmla50N3tZtCL1WwkgAWwFuxa95tWg/oGdalTVchrjqmI4NQGOiF4gXGUu4AYLWABi 4+tbis53uDc4AXb/gI8moNcZ/a3OU3JTlgwkV7kJVnCCfdpgB1OAvwLeia0usAHYqiC8pyloeFWQ loIGtsNRRY1ezwsHigRYN69gL1jBikz5VnQE8I3vfOXL2/zqAAQRxk0tChyVHm/hxCg+TwZwQFoj HxnJoF2wcnOg47pMGJTrATGGCzqIv6aAyli2sogLegLnVEK9OzbSBVj8YsXGN8byhW9kWRxfHYjg A6mNRJjjQGcT99jOVDlwkknrWdJyIAd8/rOTn5znT1kjsFUuhIarrNdEM/oEkQ4HoQF85ypAZR8H /krACdoMVoq698zCBasOSA0OcRCzJrthRXDUu+oU5ycCHxA0BTLbZ1rPOgdxhkh0ekIdTEvIIBsW 9rCJrWgVgKYYdW21EXgsHSGfpwM6kHGnqQ1W+ZY6JMMoCiVS/V8fB6fOrlYxeiocaD7nQLNp1Wy6 k4zukeyaL82+RbPHbSD1gOAExdZ3Ib6j7RKHG+CXjsxjJpQAE0i72p1ewAhIzQJwKKYYEQBot6Ex BevcuR8/7pNBzI3kWmcW3ZrteJ85II/bEtzXA6+4wFcUa2xkmdj87nfET15vyIA70xKKAAhInWY1 /5zUO9CBw2eeAePcluKwyEeeXW3ok1QYBJ2V/vrUAw3oWz+X6ugWyb/DLRk6TGUPz9Z0gF7eEUIU vSg1hzJ1evMbcefHICvQwQ7oXne6D30FIYG4bQhUDor3OuMat4fYr9McQGcd8VnP7KSdQou2+0Uv TicNhDYkAstf/vIeGo+jLnLif/Sa8OcJkEY245l+azvtJqGIX77+kwkHOT+UBwHIE4/4zHJg0if3 vLP7YnMDVYYEwDBBh0wADBIcnzx9V316r8APn0ieKkjq0Y5sYyiq+NcmK1/6j7Hv+/NAKCMiuH3t b5/Z+nCe26quuMr3wX4JgakyHTg+Cd50IrXzKkcB0D+p9B+AL93/W3zhAyyv/AqwAMOBLtJF/ijq bwFJBSmKCVAiUAIBBQCx5QIgoD9AQARiI7NgQ++GAQIqkFjgzwFLUPm2hQK/YAJXEEdE0FlUiZR6 iim6g0MUgyl+apQk7ly0RJhIBUxwpAeNYqOu5VWK0AhnhJ+oycGIappcEFhYEAojULWC5ZFgsKPQ yQl7BUd44QgTYEvuBJaehVLGcAwhgAzHMAzTcFXOkA3bsFDUEA4PLVU6pVC6EAzjEA+RxUW40Aih gArzEBADURAHkRAL0RAPERETUREXkREb0REfERIjURInkRLVhJDs5RIr8WSmiHX6pWvqZoYG6YAc ZokuUWbgSG3kKD8WKA1TyI485nL0J4My/tEcXLF7bugVtaeKbKdkcrEsMEeJxEV5QogYdTGAgAiL 0OeN0qiOcPEYIQhs5qiAnhF0eFEZT1GCBIiFNsiDnPFw2ghy5IgWqYEVN0h3gFEa98eP6ocVs4h/ GOh/MnEY0ZGG1FF8gMgagVEW92eIrEeP9uh+TCceNYZ8zCaH2iaCYKiCtpGLrmgWzREZqSch2yd9 Ygd/HlKIBhIiJTIa6zEW13GIsmcZYagZ+8iHcCd7IKeHDjIZ3eiD1AcjDTIiXxIXsTGAimchuaZz UJIW5xEaV5KN7jEmB6cf2VEj+agTG7ImnYeC3lGLgFIpvZGOMDIlfacgBTIn+2eChtKB/qKyKoPy fUJSIzEoKsmRbzpoX2JRIcVSH1FHgRgyZTSng0RHLV+odJpni4rSHcsxcJJyeUQnHblSaC5oK8vS LIdRLj3IgtwxFUtIhsQRKreGL/sSMbXxZl5yYHASKuPIMe1IMuGyL1mSI+2HKW+xHeGSLItSFBkG isZxM21GjFwzNMPoOqJIjZ6nLrPyNNuSfPYSNM9DkFYTKZXIJE2iOF/zJERIiiZSJ4kxFOkIMj2z GPdRExNJj1pTfmSzOg0pOIFTO6VyO8NTPMeTPMvTPM8TPdNTPdeTPdvTPd8TPuNTPueTPuvTPu8T P/NTP/eTP/vTP/8TQAP0Ph+AQAtU/kAnsUAT9AH+aEEPtEsSdAgg1FYadBoUFA4MdAswNAsI1EEl REMB4ENXJUQnQUE5FApKVAss9EQptEPzY0Qn1EQrAUM/1EQ11EBjNEZb1EUlNA5UFERzlEZfdEUp NEh/lEU31EeNNEcztEZxtEmJtEGbVEcnBEWZVEVtFEiTNEWdlEVL9Egj1Ee9VA5mlEvBFEqN9Een lEqrdEjN1E3fFE3j1ErbdEXhdEu7tEx7NEzzVEkXdEnV1EDYdE7BFE6x9EsLNU+F1FCR9FD7FE+h 9FEJVU4BFT941Ex59EmHVFAZlU7jVFH5dFKRFFEhVU8vtVEpdTKClE05VFU31U4X/jVUO1VVLzRT 3/RT3fRPUfUiQhRWi3RW/cBQSTVWJzVYaTVKEzVXnVRSdfUkMDVLj/VRlxRW77RT0fRTo9VOOVVO yZRWRVVImZUcvPRZtdRSTTVXHbVVr5VLy5VRy9VVpZVdwXVXtRRX4bVR6bVdt5VVz/VS2/VUNdVY S5Va5ZVbvpVg89BgDzYOE1Zh1ZBhGxZiI1ZiJ5ZiK9ZiLxZjM1ZjN5ZjO9ZjPxZkQ1ZkR3Y/C4Bk Y8Vk1XAABIAACsBlXxZmY1ZmZ5Zma9ZmbxZnc1Znd5Zne9ZnfxZog1Zoh5ZohZYABGAIJSUAGMAA DAABGKBoo1Zqp5Zqq9ZqrxZr/rNWahkAAZqWAQJAUgjAABaAAJL2ZFslAAqgaQngUARgAQwAbM/2 VwKgaQWgSwaga+1Wbo3FbRnASAbAABggC/dWTRKga83WQAJAAdiWcJ9FbBEXPeiWcRvXcRcAcq+D bCnXWtR2cPsAARBAc6/laQ/EbUP3WgA3btEjAeDWdK+ldPGDAEC3da9lAfT2PFjXD7pvQnbD7+pE UTOUErrUQ8W1X5VUTf4VPwRAdq+DbufsLshC8Lxtd02MKs71S5EXeE9UGbAXWPF0WdP0eItkAVKX NBBgcmliGaC3v0SkwKI3eA8VXoN3Q0MkS+s0Qn2Xe9+XEgrAbzH3cp938FDu/i54bTqATBYG7+2y r86kly9mwesO+L8c79JKlUwreF/9VEpBdH6tlVU1+EYvuF4xGH7P1FvvFIQ5WIRDOF/rtU/1NFPH VYMnoXlLYwAWQBK8DoENmIFzGMhagXcVON7oYYeHuH1zGIKBOGDBN37pdF/vV3slNYOjmIQz2IRH +EiFF3yVuEaZ+FiX9UpPVYqx1IkrwQA6dwiU94bTd4gB+IeRuIfZWHoBWBXWODeK2IfpOIDtV4u3 VFS/N4bH+ITPdEa9dYu7NYv7GGD1mIpJOE3r95AfWY8b+Xq7mIzJlyxiN43hOI7xeI3l2I3rOHqX IICbjnrv2I3bz5D3GJGz/lhaN7iRX5lQMfiPX7mDU7mV7XWRKfmPldWRl5hJCfmXIfkPEMB2y8Jl M5mHFTiZ29iOeRjP0PeUn7eZbUKUO9mWu1iQvRiMU9SD/XR+ZfmKu3mWERlII9l+lZWVFVmWz/mK vZmP6zRZHxYOGOB8yeJzkVmZ23iZkxmOf1ifBa+aTzmgI1iN74Gf1TmW4VmFa3mMtfmdIRmdHTqh e3mDa/WD25RbWbmdYxidqfiJyeGYSYMB+lfAEjiBo1ncUu2IVa2O8xiIUxr2xo13o8OFRViXHZpb sRihyXmSI/mCc9qCWxijm1iMgxVSHVmjLTha+ZUPQnoynNpZWlp9N/k8/pjaWuJZSlzVD6CaLLj6 WKT6+lz6Oqy6WrC6SMJ5f1P2qdX6WqBvzoK4UuX5WNxVrsc6Xrearbs6r2d3c/f6JLyar6EFsE1i sPHZKd54qqHXfXu3SBb7WRxbr0ujsA8ErMM6sa8DshM7szFls6k6PybbHEA7Pyr7JDo7d/HDtEtC n3PFtFM7tP2asGE7kyVYNx74pZGYpX2tgNOXgAnagHO7oIFboJU5gmd6t+k48AZ41Wg7pcVOgplt go/7pFEsMoSbmhFbuFcbpGX7IkQbmo9Yk7MPgoPMn/MYlDk56bT7k+2Bmdu3mplhlNlbvhk4oFca gQc6Fl5vvsXbpev7/r2X2Y6Z2Zq3W7K5e32juZTXu5PLG5kDfIEH3LcVHMGduZ+vW7sFnJOHm6ox nIgRu5QxnMOfGa6NO7YLnLHVO+ck/J+Zz7r5mTeeGcKvu8NjnMF3mNmgO7pROcNZGr433MVZXLd/ G8TXT6wFuPtw/CLMtzQw+bAnXMP5e8GF2JOfHL/3mXqHnMb3G7ct/MMTPMS9HLvje44Lur/3e5ql WayR3ByIuTQCYHkZA8KFw8zFHMqJG6z9ucoz3MNrHMVrXMU1+ct3/KANOo75fMDre86z/MmJ2xxw dzJq+MSL3AlSbuU2GaZbnOXYLs9znNHNO/D6nJSDHMEvnY0RXbrL/rwfalvUBZjtnNm6Yfylcdgk VteMh8AA/teQXDuqrUXXtUAADOA8oDaSev2ref0khJ15gd2R3BpbiJ2znR0Kbh09DKCYA7tZ0Bg9 ft3aoYXa86N2t71ZxDZxLRfci6WGLTnY37zceQUBDLxPDKCe191W1DZEatjd5R1T1BbXSwPe8b1W GMCGWQRwEWDf/f1uP7fgz6MAvt3gMUVs791Afr3bG75t5QvdjeTXF6AALp7iJyRtF4DNIyVtm9Zp oVZrTx7lU17lV57lW/5muXZsA5fjZSUAWNblbx7nc17nd17njzYAar3jg17oh57oi97ojx7pk17p l57pm97pnx7qHaNe6qee6qve6q8e67Ne67ee67ve678e7MMeZIMAADs= ------=_NextPart_2DC_C39E_B0AA6A8D.F085B85F-- From sip-bounces@ietf.org Sat Mar 03 07:09:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNSyz-0002N0-62; Sat, 03 Mar 2007 07:05:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNSyw-00029A-T6; Sat, 03 Mar 2007 07:04:58 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNSyv-0003kG-C0; Sat, 03 Mar 2007 07:04:58 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CEADE210C0; Sat, 3 Mar 2007 13:04:54 +0100 (CET) X-AuditID: c1b4fb3e-abf1ebb000004aff-d8-45e964661b6e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86C3B20396; Sat, 3 Mar 2007 13:04:54 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Mar 2007 13:04:54 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Mar 2007 13:04:53 +0100 Received: from [131.160.126.157] (rvi2-126-157.lmf.ericsson.se [131.160.126.157]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EEE682342; Sat, 3 Mar 2007 14:04:51 +0200 (EET) Message-ID: <45E96462.10406@ericsson.com> Date: Sat, 03 Mar 2007 14:04:50 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Adam Roach References: <45477421.2080305@nostrum.com> <45DF2074.90909@nostrum.com> In-Reply-To: <45DF2074.90909@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2007 12:04:54.0033 (UTC) FILETIME=[27598010:01C75D8C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: SIP WG , "'rohc@ietf.org'" , Keith Drage , Dean Willis Subject: [Sip] Re: Comments: draft-ietf-rohc-sigcomp-sip-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Adam, thanks for reviewing the draft again. Answers inline: Adam Roach wrote: > The sigcomp-sip revisions look good. I have a couple of small comments > on the new text that should be easy to resolve: > > ------------------------------------------------------------------------ > > Section 8.3: >> To indicate that such state will continue >> to be available, the SigComp endpoint can inform its peer SigComp >> endpoint by announcing the (partial) state ID in the returned SigComp >> parameters at the end of the registration, dialog, or transaction >> that was supposed to limit the lifetime of the SigComp state. > > I think this is left-over language from the time that dialogs and > transactions could have associated compartments. I suggest: > > To indicate that such state will continue to be available, the > SigComp endpoint can inform its peer SigComp > endpoint by announcing the (partial) state ID in the returned SigComp > parameters upon termination of the registration. Fixed. > > > ------------------------------------------------------------------------ > > Nit; Section 8.4: > >> Section 9 provides network administrators with recommendations so that >> they configure they networks properly. > > ...should be: > > Section 9 provides network administrators with recommendations so > that they can configure their networks properly. > Fixed. > > ------------------------------------------------------------------------ > > Aside from these two small corrections, I think the document is ready > for publication. I still believe that it would be improved by the > addition of an example SIP message (instead of mere excerpts), and I am > re-including my suggestion from a previous review below. However, I > think the document serves its purpose even without the example, and see > no reason to hinder its progress simply because it lacks such an example. > > REGISTER sip:example.net SIP/2.0 > Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav; > rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473" > From: "Joe User" ;tag=6to4gh7t5j > To: "Bob User" > Call-ID: 3c26700c1adb-lu1lz5ri5orr > CSeq: 215196 REGISTER > Max-Forwards: 70 > Contact: sigcomp-id=urn%3auuid%3a2e5fdc76-00be-4314-8202-1116fa82a473>; > q=1.0; expires=3600; > +sip.instance="" > Content-Length: 0 I have added the example. However, I have changed the To header field of the request so that it is not a third party registration. Now the To header is the same as the From header without the tag. I will be submitting the new revision before the cut off. Until it appears in the archives, it can be fetched from: http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-sip-05.txt Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 03 18:30:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNddx-0003z0-76; Sat, 03 Mar 2007 18:28:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNddv-0003wS-B2 for sip@ietf.org; Sat, 03 Mar 2007 18:27:59 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNddu-0006On-1o for sip@ietf.org; Sat, 03 Mar 2007 18:27:59 -0500 Received: (qmail 25068 invoked by uid 0); 3 Mar 2007 23:29:06 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 3 Mar 2007 23:29:06 -0000 Message-ID: <00a201c75deb$8e899ef0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <453DA2F3.1070009@cisco.com> Subject: Re: [Sip] Updated GRUU spec - big changes Date: Sun, 4 Mar 2007 00:27:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > I've submitted an update to the GRUU spec. Until it appears in the > archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-11.txt > Jonathan, Two minor comments: 1) I believe a UA is allowed to add a 'transport=tcp' parameter when using a GRUU obtained from a registrar, perhaps this should be mentioned explicitly somewhere (e.g. section 4.4). 2) (nit) in light of rfc4320, the references to 18x responses to SUBSCRIBE and REFER in section 4.4 should be removed Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From alicaanetta@sluggishness.com Sat Mar 03 19:13:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNeM3-0003T3-ST for sip-archive@lists.ietf.org; Sat, 03 Mar 2007 19:13:35 -0500 Received: from [60.1.130.232] (helo=46F3CE68DB60491) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HNeLz-0005BX-6B for sip-archive@lists.ietf.org; Sat, 03 Mar 2007 19:13:35 -0500 To: "sallyanne israel" Date: Sun, 4 Mar 2007 08:13:29 +0800 From: "marinna sven" Sender: "marinna sven" Subject: Autodesk software MIME-Version: 1.0 Message-ID: <138501c75df1$f013cf00$6401a8c0@46F3CE68DB60491> Content-Type: multipart/related; boundary="----=_NextPart_000_12CB_01C75E34.FA8BBA40" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d This is a multi-part message in MIME format. ------=_NextPart_000_12CB_01C75E34.FA8BBA40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_12CC_01C75E34.FA8BBA40" ------=_NextPart_001_12CC_01C75E34.FA8BBA40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable And he is swathed in ever-petrified dread; Stars, the last day, endless and centerless, Left and right, and far ahead in the dusk. Glimmering of light: then takes a step back, to be safe as she reaches. Swaying in unison beneath the snow, Down the long course of the gray slush of things In Florida, it's strawberry season?br> Looms in the air, deliberate and slow, And I would like As it sits there like an eventual It's snowing, it's returning to a town visitors' dugout. The osprey whose nest is atop The ordinary, wide scene which begins I am sleeping, and dreaming, and wandering along Dim, and die tonight? VIII. Russia: The Great Northern Expedition Cascading snowflakes settle in the pines, And M=E8re Chose's square of world, even as they ------=_NextPart_001_12CC_01C75E34.FA8BBA40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
And he is swathed in ever-petrified dread;
Stars, the last day, endless and centerless,
Left and right, and far ahead in the dusk.
Glimmering of light:
then takes a step back, to be safe as she reaches.
Swaying in unison beneath the snow,
Down the long course of the gray slush of things
In Florida, it's strawberry season
Looms in the air, deliberate and slow,
And I would like
As it sits there like an eventual
It's snowing, it's returning to a town
visitors' dugout. The osprey whose nest is atop
The ordinary, wide scene which begins
I am sleeping, and dreaming, and wandering along
Dim, and die tonight?
VIII. Russia: The Great Northern Expedition
Cascading snowflakes settle in the pines,
And Mre Chose's square of world, even as they
------=_NextPart_001_12CC_01C75E34.FA8BBA40-- ------=_NextPart_000_12CB_01C75E34.FA8BBA40 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000401c75df1$ec2f5558$_CDOSYS2.0> Content-Disposition: inline R0lGODdhXwNgBIAAAP///wAAACwAAAAAXwNgBAAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r1+y2+w2P y+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6SlpqeoqaqrrK 2ur6ChsrO0tba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHS09TV1tfY2drb3N3e39DR4uPk5e Phxgnp6A7hDg/g6/Du8OMG9/34C/cK+/z//vL54BdvUAHuBXgWBAhAjw/TO48B0FhvUgKIwIMaHA /nwS23VU8PDjg3kR6DEg6VGkBJQc7amDpPJkzIYmCyrcaBOkSpw0aw6c2fOiTaEieQ5tKdSiT5lL dRIsCpXoTqAHp1L9mdTpRaMpWer8yRGsVooeB+ZkmpRsT6wTOnId6vXloqtVm66jKW+p3plcjcYN KjOvU61hL9A9OhIvYMV101J9S/cw4qBZx/a96ZhxY7X+DrLNy5dz1JI+L7uU60jyW8+sFzd0TRh0 RLSBG3eWfTLD4dWtK+J+bZt27IAj7Q6nrHTz1tJ7MS9/WPxpVdAxa56uC5spcuqSUQP6e3wf8Oy+ 4SJ9nhU8zpvkC4YXa5j35Hzjg48Hj7V5Zfiz/qOnl4/ec2sN+Bl/mmlnVm/kBZhdZFZt5R0l+LVX 30Jd7ccTZKax15t67+1HmoPGVfjedsLlB2J5/XWFVorhjUbgWQnexqKK/40IW4ZX6VhUhJKgM2F+ idV4YpHz/ZbjeUS9uAGQvMmnooVI+UfhXbldJ2WWbUXl3FNckqaURC5COR+PGD7oZXc+fickkbm5 SZ1/XZ43HI79nIjjSm0aKR6cJraIYpOBTgnoRPq5tp6IKwVpX0pIHvkoS3euaUiadkZGZaF0Nhon bjtO6qmLQ5rHJ0iZrlgoo6Ni+eifISK5UaJ5qsmqli1F+ql+lqpK6R5zEkqfn5vJWeVfGWEE/lQ8 ZLZT7G6njkUsqRh0WdlqvB5Y5keygqgmXNyq5hhzs3LJTki9FvJrqSS2OuyFzVbnVp4ohsbZRO+m +O2IjKJ07ZuD2upqdMfF+uWtGk0IZbLa7rYwvd2eO4dU+mIq7L+aQtouoqJ6K3G5y5rKLsZWAgut u9Ja0PGN1X7s3sANp0tcfBrKeymoLQbZL8RydExynz0H3OmeJSe5ZVwC5UzizPg+G3SqLI+cccgn F1ckweKeuTF34X5rqLyoIqhzH1urPKq6QttqrcPrztj0ZEhHaTGnPpstcqNPKzgvwHIXpqXVMMuj gcd2PZl13SY7GrbYIZHNbMVx42qcej3e/tfztoUvvrVFTLcN690c26z0xktiR3rpMtJYkpUbNr62 6V2L6nXicDBeYutn1w5p6Hq3FvmDnLPObsKbS+3Xw2wDrXvqIBd4+umf2nvf4I/NPZjMohcuuxpY 3wg83XUXL73CE08X84LLbl++vz8TDy/FeLe6IewZwWj6Y5dz2Pzt86adGeKCLZ+9O9QsfOkJEb7U ViL+/SdGrsOYqgaYMvWtL3jiOxO22rY6A9aKOai71MF4RzvK4CeDtfNLAPGQq941RX6xs0rlRMSz qCGQO/772uNYyML/+ak50eLUx8z1lZbdZlwHK5eBXAXEe+HOW+874eyMdaz9HbBellEZ/nRutrjo gU8fV6Sh1gj4wCgi63VbXCHmuqhBmxlujbGrIhbjhcaEoWdRb3OiHe+oJzzqcY987KMf/wjIQApy kIQspCEPichEKnKRjGykIx8JyUhKcpKUrKQlL4nJTGpyk5zspCc/CcpQinKUpCylKU+JylSqcpWs bKUrXwnLWMpylrSspS1victc6nKXvOylL38JzGAKc5jELKYxj4nMZCpzmcxspjOfCc1oSnOa1Kym Na+JzWxqc5vc7KY3vwnOcIpznOQspznPic50qnOd7GynO98Jz3jKc570rKc974nPfOpzn/zspz// CdCACjQ1qtweGsOkwCQqJ4tFjJUU/tV4RmcpiaFXPJZLItpGJibooA4xCEZN8tGitRBzX4QoRh+a RichhKNnTCkdvdZGFWb0cSI03jlo5js4KRBoDuyWmebI09zBEGzZAmpQm7fFojUoVy+6GgOTilCW Wa6p9jOjrqZIwN0xb2o2LIxKJ1i9AdEKpDKt1TMYZlWZ7g6q7BMpUXuqVtSt1agGih/f9ibEHR6q e2fbK/nwClMqAsxMc+2dFw/XHgANbVPJ2WhaA8vDBqbPYXW8KVZtuNMEtm9lLzUYYGcIuIrFsEJK C1bIcBoaqR2vrx867QGV01mXxdW1WmMWCau0WrN6hkza+uv+DKjDNTpvs5UNxr4q/kgtxu6NrWwb k4Ncm9UOXSgtraWQtfpmO5r6VYKshR+sshula922tAMjLVdfc1u84k2lGBKujPCnWovxiGk78cZx y3pU5sotQ+B9IHQzJ10lxdZxfalafz2EW7gJV46lAa9WKehUva3HvLqlR3r1l7Tzuoe3blmbYrel WsI2sRrsRV/Vhgrh0a52eAAU2Xj1pNv4fo8vBibjCuMLYMfZjQPnAy15v2tayOjvwlBzbOQwHCfn zqqodKXqrrQhOBP3577bHXLDyGi9UhEsj7xi8MrqiyfsCZaND0ayfWaavuGBWMILYx2CiaxY1RXY vRplsZH/Rji/jnkZ1snslAEk/mKaIkaqniPyoGEKWzur90hfFhzKBBtnGXt5qzJzK+RyHKr27ne5 oKVeeUxo5sOC1VJLHeBvDuqMCGuVX4BGkxo/l9E6/nSiiI6a9wzH3zdiD6VLVPCk5eS50A6Yq7PW NfCMxunomhaEYKZz3kRb6r/JNsp7PoaqccdqGDZZcmSNdaEZKhzVHDXUbOwtoWy6UBV7esFodXTg vA1pcEtpR0C2srK5CzNpA7vR6mPrr+Ea7F5g+l7U7uHtoNjnrMkajqj1kuZ6/W88EQnNbkzwwMvs tl1fUMeZbrhvWzzhZF+8yDaaHLkxouUUi3fMMbZ2YRtdcMQCfNtYfnTCx9Xg/rItmt04t/CzNF7b nY9c0iaPj82vd/N8wRfkR0txmUc3qCa/tNNwi7ilBZbqi6l3zT+za4OKmGVb15u7gib3pJXu4NZ5 JdIJ5vnSDRV24IqdaPjucGKpTnKgSl15FyYpWDlO6WS0tIRT7TplI0Xy39HXz+EtKc7ajVAF033F tuM62a2O3bRXXe6cL3vIAyxCzd7b0wFStwSjPFh5h/WDizrr+pK3dbwbzX1/5xPjQf53zGP8SVif ts7NDvll81XyMt5vVTW9YoSPnO251e/pJVvGeGvcp0DPBdpVjm3ZB1quXSUtcc2W81EHX9FIxvlb 8+fh8Ys/peCK6fdX/XZi/uMd/e+LYPHDP/8QS6/3kiV+MXq+dz9mXe/XLMMWRCI3dBwkczvnXu23 QGqWVmQHfB7HfcjSHT90eISXeOhnaEK2bvlHIA6HcS42f3DWDNp2aWESXNM2eidnfC9nelZjcG3X Y503gfTjXbXndr0GayPlfvgFP822gvbGbxvoay04b0c0d0E4MRF4M5rnC2b1US1XcRYIKlN4dNEX fT3IRdx2HaiGasJmhdVGLVgVOsq3QSc1XVQYhg+VMiVGUZNSesoiRp8zRt5HhhVWh0IjR/f3agOl T9UHiINIiIVoiIeIiImoiIvIiI3oiI8IiZEoiZNIiZVoiZeIiZmoiZvI/omd6ImfCIqhKIqjSIql aIqniIqpqIqryIqt6IqvCIuxKIuzSIu1aIu3iIu5qIu7yIu96Iu/CIzBKIzDSIzFaIzHiIzJqIzL yIzN6IzPCI3RKI3TSI3VaI3XiI3ZqI3byI3d6I3fCI7hKI7jSI7lyCbVRBEGVVZtiIVuSGt66HfQ 80W8xoA1JR1u+DbqqBZdBB1taIeU94UiZR3uWFM9iI8MEVLvGHqLNXX7NjZZuIaCmD3FloJok2cx OFZVFm04hFkacnU3hCZK9XPOJ3I6ZRptxzzbt3p9dW1ItVlRlWZStCVmgVzzRX8xU5PodkIzI3rL d3y1gZIHB2cOqGXT/vMqqYeEMfkhOcVmTcg9Q9h+K8l8LBmEtBV5H/hkjeUblOVC/RdcXElxTsQ/ 7OOEhGdYxUeEpneD6jJnivaSI6h+dvOTZvllFHSVYkhmTBI8VjmDvsaD5pZX6faVaGU+VNhHgBZU szdbY6eWbKmSQjdCsmeDB/hZDXd9neOUTck1d3eXBzKVjJZAjNmQI/aXA7lenXmTLAkhjuRfS6ia ITR5jQmD/wVsRTk4MFkWtNmXThd7Ldiac2eG1POZuldepDl2/HduGbZ4pjZ5i8RbFseUukl59Vh+ 0YlbcPg17GWEKNmYH3aRfTOXTDgmojadiYaH3LJ7RGmcm4J0DWlQ/i/EnGcWcGL5NFSmbyTYZ+RH cANoJ5UJIbm2gAYodGY2XuG5kdNimFX4dOkJWSKYZUgHoRA0et+pMcUVQEhjn3eXmanpbAmloch3 Xvz1eQE6mXmpYUKlkSU5brTWUAaKlRSYKTpJZ39Inva4bSl0atW2Rxjaai35eDSKgU6JZ8zndZ8G mCSKmr85Y1fzhgrlQwG3h1a4oKXZoBa6cv0ihSzVkr7HhYbEoyiYblQWeEG5pExKhtJJauXpmg7Z ZQSHMC76moKoo/YIcQyqZO6mG9QXpBdZlv8WPxIJMV8KgIvRZW0GeL0ZYW3ak81ld7h5dGWXdxX0 kby5pgKJZnJI/nsMyGH5+W56OlNsqIU+2HIWqjOCqnTpEkbhd2uIiqrCQ5fhJSaj6XjyKW7SiZof qnhZeKlYMpxxWWPTcqIMGVWopZ8M6qXG06OY2XPZxXuIqqwgijyxChgQKnOFJ3zalZFFKJ6GoXUt JkOZupadCXRpKqBDwmDFSqXH+jA/eqM4qiB71yHIdWkwJ0ZoWHNIySDvaGjw55t3o60SyGS/t4Pi up0jg6WZinpaeX501HrqKmZwSpKLBq95BXtCqS8TtK/g95bXaZvU2rEjiJeQeWJLRqV3OnzCWTwr KZxeuXFjqoINW0j7QpYYCacflzYfSrO3KSwZy685W0CG94P//oqAOqdCCstAqQmbcGk/ylORLMsf aQJ9NfRxKktjiEQ4i9qTSXtEHomrWRuynCM+cbetDJlCE5t9SXm1R8uhHFiWRkicfHmyayeDL2uk C/KxmumtMQsvUluzIbqxyda0dAm1ATo+CNq2GCYpZYuWZfpgKbtYDugctgd4myqb/Ze4c9p0gRmQ Zyubm8tImAuPV0gS7ciFpzF4VURcoLOPuZmnoisaqle6r8aPAOGPkGaeD1dnLDqGqJu6Thp09Jig v6ugwOeHpGqOlgSox6u8y8u8zeu8zwu90Su900u91Wu914u92au928u93eu93wu+4Su+40u+5Wu+ 54u+6au+/uvLvu3rvu8Lv/Erv/NLv/Vrv/eLv/mrv/vLv/3rv/8LwAEswANMwAVswAeMwAmswAvM wA3swA8MwREswRNMwRVswReMwRmswdqYvMako3/4sP1Abf44vII5rHAYh7AbpuhpqdKnwrHrqm/E fgi5j2KihsNnUaObkBFlPbtKfd3qqBaYSalKrAKqmPlqJBULxMoXuDy4tk5mkhCrKLuJQWUElBab L923VUx8oCL5xC3zVXRLOhk5plH6SEQ8ReW6xSWofe32kHJlxUobwvaHtRootVosdvsKr+anxY91 xQDHsGorbHianeJylIE3p5+LMzxXoq4jgNX5WO1VpHg5/sn1iKxc+ap27FkCRh8R25afhZzF0n0p OrBOC5gQNJhFjMXzSUja2clgqoOkTJFki2szVx97HLEr+l+y7GOV5539OZQ6G5skel2Pe563ZpOe FX/PpprLWbCXVGKB0aPvibuIG5KVo2EWloHNtcslez/raKs7RpoyG5mAHJqiqVx7iSpL98jrvKw2 ciWWh2vR2cGHlLAgw3tv2kLhnKzA4YGTLGVLuWQ546H8iWmwE6z3LGdgdBcA2pyvLKl5ezIBTYNz 6y7jKbek/JqVSkkxt9CapsSTKpewvJVzVqTxSbYUQ2hCep8ktM+1HKLWrBegWScIjZ8zrSkozZ06 fKc0/iNf1tm0NCpJ5Mps1QKcwZZeGVrUy+N17lrI/QmpM7ulN+2yWnSxB+efDV10hFpr2SyEneLU ZCrUC+kvGW22gWbGkJSVS91v2wx2AaPUM4Jsacmu6dysLlimPppQz7l1tkbUJkKuVsTXMr2auwuf nxq8zAw1RwydiUrCah2bRpmWhhuGcV1yqtrUOo1E9EadeV2GIAxHTPs9kb2hRmqasVGrkHyPTqOP iW3CU3djefwyd/mnmpRv1iXQYXk0Ba1ctz20SsiqxOPEns3V4+fTp0XaRfgr2nrcBj3OW3Zu3xbV KPeuf3qBLMfKgpRcsHpk4jl9L2NFBrfdATiinDux/pXrphX6zmpadcmyHWctrbbxr0vTzafqy0nH esF6h3Ssg8aKSXqnzmCLbtaKY1+dub9dnrfnYngc3DlCoWr6xkV24AQa30Iy3wIbmT6HWAF9sNvd Fm1yuiBLdPV8mDVq3WloU7O8pg6du5P9rgbdnS+8y+1a2o1no5/c4vNMgJlX3b5r4eK92NcsxiZ6 ZwdZM4YLs8grrDiuom/t3JIr4Ay9bCHtgU58hmPbuBvI5Fz8emGNez0bxACUyytIpGMcjyobyGDy 30teHXolUcaXf6AG124thpU8ZJOLyd6tsfcNdbK93te5tM+9mED8tDu+yeWmRek8hIFJtcIMzUqp /iMLiJg4i7d528Zn2eRVqeiUin2azOhIBOlTjOYD2LJ+29N/bOdwrMoOOsps7Ju2HeqGvOk9NZtp Jtlqa+cq+eBVLaaADoSFObhaFy7peVf4yrLlHOaMJq+9p54e05cKvtfrqchzvcIoHrpoiO1YpO3n eVE7fOazau3Y7sLhjsIVJe4W5Xg/+8fVbrrnLhURae6v62XwRrn36ZmQG5YbzGf6zu/97u//DvAB L/ADT/AFb/AHj/AJr/ALz/AN7/APD/ERL/ETT/EVb/EXj/EZr/Ebz/Ed7/EfD/IhL/IjT/Ilb/In j/Ipr/Irz/It7/IvD/MxL/MzT/M1b/M3j/M5/q/zO8/zPe/zPw/0QS/0rUTifPDB3T7u5nbDJ5xG gr7XKczDQgxrshHvJx7iTC/1OXxVxjk/2ebjN/5Tjy286d7uUX9YY3PatRtjqrvI8K7bkmLkMNfD cMfgeJzIQ4DGjSvkcVPX79K1zoqT13Z8/H3vYASbj9nE8qcwqXzqaE7gI3u4vQ74ZP63Kdk+WA7F 1D3qTjvdNbR9R0xoNAlZ1UPG9JfWRpD3nPtWXni3UHm4hO1VN7qztz5zRp3bWkuSxUxp193dub05 iK/gVK3qmL77keX6g07X17r5unx+QG05NWhkzsz5w4X2+e4Do2rOZ6t4uQz85x3nRpSDjuno/nc+ QprZuUB955wmqyOWsQWK/Izr6STImaDM6d5V/qFc90XJm0mXxnJ9mZZPAAkwFe2ynYJwVXtx1lsf ir3G+hbyMkpTEld2NFUmAiYwVlFGT3Opc1uzRyVGkwGHROQDVjz2ni9oMqrkPGdCnpa2DEqz3u50 TGYucdTqjl1+fd9bpbgsdNSIP/rZzClO/1jsnFrUuPjCAPv4eEquHiEjJUfqTkLMbgjVKsG2Dtc4 HREzMhU34SADMee4IvB8WC2BXjtRbQ3/UmdJvTRVEw9LF93kYI1ss4JalU9iPXkBR0Vt9rAmQ41B GWU/t5ObmxSHcXavzc/R78TUMdGq27Bv/jWJsbSA9eyRhrd19enhtbWhdaxYrYAFrflIo8xevxzd /vEziGydu33CpjkDiKghR0oID8pjli3PQFYQqaEBGTIiGA9XLt27BZKESXQ3ceaJt+PXM0k2/wGV Vi/YvIHh/LybaGThSoLxWtHBIzShRKb+PO3D95TbUqfhioq7SA7KoprdJoxLu4Hs2HJVNyYxOg+a r15StdbzA6pt3YJpUeYUHMmVyoNtA59cShUb4KjVjrqg2zJpNBhddQ7lynLqXH3+Lp9UmrJyPrem B7UjwzhyD7wP1a7lRhUxvm+aPxXew7guIYzUHskGIbEvaVSOEw9WPhwuwZ4jCdf2mTK1/vDmihny psy2Jr+wy6Y/zv2BtXTnkmdPdsm9LF2wqKdDn53Vt2PbTpB/j7/+1KvcM+X7yT6NdkohOt/kmQUy BWFDbrkHf0IGQPMcyo8/6lxi8LTqrMJMQNe885CkhMTDsMAA6dHNld5GIzA99eoQKr+KFvzMNbME yWvADO8SCyJaxLuDOZZOrNAiwCr7MJcOz9KqySCTgxBCmQTqsboopZHRMxz925LDM0q7hjw4xltl vRLnK/K6Mb0prUUUnYKpRfLsqlGsFYzrIjjrRFvNxg1HtCYYF+GcBEkAuTOHzy/pyyvG3WCUcjlg hJzwTyyrAqo8SDuzk1EZwhRTBA7L/gRPMTT521S1l75I7NDg1Iw0ToO09JSmPDdjEa1XtVH1tmcG nVU7OYF8E1RFhYNvKyXZk9TZIav4lElj4dLUzkBD2dJFHallhFRcT/GIUOKu7eTbzPbroENEQ223 SG1vFfG/C0uVdjur6jW1UNqglU9WR5l70kFwiUWp22fTyWpcYTBtbdVdy8qTtiMNZA9Tza6bsDev qq3zO9SC5XjIWi8mkib8PN4WVzvCXQNieyeOxsRGrd2tX4oABuhHUQTeUQpRXS0ZYUWxs3RVJZUd t1f91j3sYFm/4lRfjlH+k2CjixJR3X0PvpfQ+rhE1WJSmPAw7KjPzohqrTHG0xJ5/t+cGt3zVBz4 Z0MBznnom0Be2MqdUbQJ7EFkEdZKoIWmLOW570bbz7TZ3q6POUWGummvai5V5M1vLLxsz7Em2ODV /CraircbNzm7BY2RGpo4gGuE8b0lfYxqGndNt8DnCpnD78mf7noM0CMP7GileSe+99TB3OtCdscu +PnQN0c+kdRptP54tVH/PE2uX/cd+tWdBPHYqxXHHXPa97b995dP1/1EG78fXnnX8dY7/v0xL3+x d+iXFBvMzH7Nmp7XluUuhtwvNsn5TceuJLtZFfAIyoMdBU2XMaldb4Ic4Q2byvc4zRmuO+xzFq+4 YiELvQhkfIrRi8imF4u9BoXU/hnW7LxHs5hAhnw3fFQqeDGyYfHKQSt0E8lcWEOi2HBwM4qYDKdR QyP2CYYxfCHNHjUjKy7Kbn0aogvh5r/xLdGEZTTjGdGYRjWukY1tdOMb4RhHOcYxcXO04x3xmEc9 7pGPffTjHwEZSEEOkpCFNOQhEZlIRS6SkY105CMhGUlJTpKSlbTkJTGZSU1ukpOd9OQnQRlKUY6S lKU05SlRmUpVrpKVrXTlK2EZS1nOkpa1tOUtcZlLXe6Sl7305S+BGUxhDpOYxTTmMZGZTGUuk5nN dOYzoRlNaU6TmtW05jWxmU1tbpOb3fTmN8EZTnGOk5zlNOc50ZlOda6Tne10/uc74RlPec6TnvW0 5z3xmU997pOf/fTnPwEaUIEOlKAFNehBEZpQhS6UoQ116EMhGlGJTpSiFbXoRTGaUY1ulKMd9ehH QRpSkY6UpCU16UlRmlKVrpSlLXXpS2EaU5nOlKY1telNcZpTne6Upz316U+BGlShDpWoRTXqUZGa VKUulalNdepToRpVqU6VqlW16lWxmlWtbpWrXfXqV8EaVrGOlaxlNetZ0ZrWZqhVlS/T4p6QOEWi yFWHDktWF7PDxLfyqGDmMyJdyehFMB7RfArTmXrwOtgMKrCvcO0b0nRVR7YasHRtOxnk5kex6EHx clWDWXtAuy1OJQizpGVa/sbAZRINra6xsdNDBfd0PgFe5UcWgS2xbovFyUoJgEcC3vZWkjy3JdC0 VxPunYbrtB6Jr7OHe5/StCfB5s01aHjZLAYHmMMg8uS37stt+L47193WLoQfg65wA4IyxvKFhud9 C5PY5bAL3uuBX3NuZZmbPu8pVljuck9oX8sG4C4PgbllmPDGuzH8xgeJz0XIr9AHltQ2sT+GeVex 2kHCCNYvfaf5gaU28UWzzFC6xOvtiirc3RL/j2UJHpqqCBizpM0kNHGJk4S1JuMFyw+CZmqujxaM 3kJlQ3A7Nq6bOsig6EF4cEm2WstcrJwdGplcHnYcgRqmvh/ba4KLi7Fq/jXsZOR2WSmU6kjkiodk 6OEYQ/WasJW9Y7kow4RIHmMHoGh8X/15Nr4aqm17OSyavKIvKF6i3gEJC9cKcY/DXi6wYh2NwOL8 cM6DqRuhOeGrB/MZu9fFF6BRa1nOeMnMpcUZntO7wfyJ+EAtJvGaVzvDj03aZJPGa6WJtmUFa7qH YfMhew+8VzVd2Nf30W1drcNrYKO61R/MsszUXOdYy7pobH50rIWNazH1uYF3/vOYNZijZ/sszKI2 N4VZxKMZb9pWHhzNrxsFXodAWWL4U50HT/2XMkvmb5Kt9Lovl2lD51mzemr1vMPIbA1/29fgZjez 5QxvKnbv4DaO7LfH/mjYiCAGRrcesrbZoj23hro5v/jUuBE+EWW711NuBe0ISd6Y4CE4sMltdq6Y hd9/yYbW0CWuBUHuPN05Gl5YO3nOpZfjcqG51jVmMKib7vCUw+qA+pODv4teYJ6Jm8sBpzKBg95X co/azzs2+YMZ3cFym9trdlawja192QaqnYBC/xoOSYN1bnHQitxtUNfDq+jZhp3qDp5ek98HeJxn XNdrZzrZTaFyqEPe555O1GI+MnVkVRfsmRfwjQDftTn5O8Hwu3F9r5zB+lj+66gfX9b381vHU57u dUeX7HuI9M3Pl4K9bR3o+Z7f6VqwF4SPbd05bfjgul62mGa52Lx+/u2HCf+7iE997TENYOkClrKI 65/NQVeY7Q8Ytegl/W5VbdrRpUbngiv41zn3mhU/Huw0DD7tmTd571fMXy9X4uB1L2qazzjU4W7e L12aCMWMz9iQzYmMJF9uzYlkjL/+yuMo7T4m4/+ogIt2hPv+j/seMGQ40AIvb9E+jP4mLtD+S/Hw bQFdcJrO7wVlcAZpsAZt8AZxMAd1cAd5sAd98AeBMAiFcAiJsAiN8AiRMAmVcAmZsAmd8AmhMAql cAqpsAqt8AqxMAu1cAu5sAu98AvBMAzFcAzJsAzN8AzRMA3VcA3ZsA3d8A3hMA7lcA7psA7t8A7x MA/1cA/5sA/9/vAPATEQBXEQCbEQDfEQETERFXERGbERHfERITESJXESKbESLfESMTETNXETObET PfETQTEURXEUSVGYYhCqXG7sdEWvpEgCoWbcSsgVo0QDZbHwBIsEW1DzWNGuQNCLdvFQZPFhFHCB Po8EaRGMNHDxqEto3I+u4G0CaU6hTowFe+7UYC765k/pnoztNg7qtCN7qiyBRm8A2+8AdWz2qu8A e8+2pmXyPAv3XAv+Lu8S6kp2Ro8dWOgUC2oaF0u5Tqtp1Ksfkk74hMwf2WYFKa4bg4xbwE90thFR ku/0JLLzAogiI3JdIK37nG+7jsHPkk375K3frA6i+HGxrO/Q/iASS/aNS06P/DDyvoBuM24A+UKo 84pn2pZv7qxnIp0GxIZO/6bM82IS+yRI/NxNyaIPJ8UrpGDseRrs+iSE3vrx9bqO42yvIDXo7hqt JofPyOLu09JPJODB6agkuQLBJNFNLpbE9irPtW4jw8Dy57ACpZrSdM4RJYkDWwLt48ZSy8TlIGFy KtuSGANv/KpLbC6yLvElxN6LUjyvyBAw0i4t7bhR62rhLSmuGotLKj0qKJnuK3MS+vhi20jG7iTn Un6uw/7jG+OmS9avLI1LKcHyNVVGXmzo9sAsMuGsSuaSEhRz0VQSNiWT36Kxoe6s9eik3drxtEby OBGN9Qpt/uCWM4Yy0FiQpCTvLXki0tkeEnK67TsZjseqJUDQIuqY0YccbjiBrzgTajLjj+vC0xoJ 0Orcky9v0kfis8rGoTJfMRnzzfI0k0K2EvTmMxUhcOT4EkgYTIjsbdXyRlrUs27kzDi5zc2GjRcp UBVD7iW7RUCviCZ78SlW8GI09OH8C/VUa0SvJK5aDncyZ8NirNqgJdKQJmiwbOmIIds2CjYr1Nts Q+6YpkONzkFVkb+gAjXXSnUsBxeXjbDsr0hVVN9GaCVZNEjEszFSZUYbFHFYh1aw0+T0MaAADvJ8 9O1STc8axr46FD5v00xbAjKpcs/+jjaxsePYdC9jT0Hq/s2xNkiEYLR+zCtkGo9vJoYVxS4sd1Tk TGTlVHPG0jQ0SZQ4u0vhzo57YG+zFLM6H3Q98ZQ8exPt+BQ881Q5ca4GBBX/0gHSDnPVNBKjrPT5 4nRMU/SJbLFtlrTsnnM6VS9XLTMdcVRTHQhX2xJFV+ZmMmVARUgu25TRMqfvtiYg1ws6bdKiJLBy 3sPs/gbLKHMZfSsAm3FLG7UB5XHFELIrN3I2X9UhoU1bW0di3sxPg8xNuVXFjHUsQ2JTgUZOOuof AVIzDRIt99NZORTl0HFgD+/xIkUd8+vd7nFM2y4w4c8oNYJeLeskLU5x0Gz1krQYEzIeBVJfE1Vd 03VQ/ofUcASW4C4CUj8TYrGU0BI2WbVrHVd1ICsWXHtVYw1uYcOiHy1WGcPL9Ew2M801ZwOM/4jP xzKq26ASL5dTNMkxZgMHUhyHX++1W6FW1HZOZ/2kIVFwYJ32NDc1a4YWKcn1Ig8DAIkWYMU2/K62 vKyV/MKUnxC1G7lyaPWTYn9MXlPtbVlyWpcNJKdy5wjUJ3PGTif1aIEWQIUVgzCMVysyG81SadGm dAqwYyv0+QrLVWc1GF+2SlsxGNNDsFjoFgWtitQNhZKoA5mUPngPG7Oo4Q5sdPPxQLtIQjMvdY1x sPzTdrGIc2Utd1BQ6viqFKUwbon3eJE3eZV3eZm3/nmd93mhN3qld3qpt3qt93qxN3u1d3u5t3u9 93vBN3zFd3zJt3zN93zRN33Vd33Zt33d933hN37ld37pt37t937xN3/1d3/5t3/9938BOIAFeIAJ uIAN+IAROIEVeIEZuIEd+IEhOIIleIIpuIIt+IIxOIM1eIM5uIM9+INBuI2MlyT9E99AsAPntWGp FD2Y6Bd5znfVbRmvbmCUiHM7NwHntOeS5eIUBrB2OIVlpNnkyhlHsLBWqIbXAoY1Lld+ONp67bGM JLLUiTtZFl2BdCEx67j0z35w0v6eU3h1Nz1xNFzlRxxiFWJakkq6GB6n7luLdviYL4wBrhSilkfj /oAee80e8RVsjfSbqNglq5bLzFY1qa8gA1KMqQxBjG5eUJZqCfm8LPI1x0P5bguRmYdmz9RgChlm l5hZK6JszRhy98vApohsQ1IkRziZKPBfWS6NYRVOhJeVK2aOkRNpz1ZTEg9zXRk34TI1w4VhYIeW L3m9/JUkzvIr5sdaU9In3TKHhE02tdZP2ROaYoI6WXYudvncrnV/nlIsO1IrI6z4kHl3RM4xQ5dp RfQuopWJrZb/hPlKbyeWjVmdxxlOo5I311a/wOsto4K0UvNT3ckzZxliPyibSe499OUuFxPuqGWQ ZdVWy/nj5GthYBmT4yJ28c4ynzEw3WPoKHpN/lSOyPCjoim3XS+omN/0vd7JOTPD/MrMoCXNI88s pjn5Yu8NATdubTDGYaMzP0supwmTM8+2f3KzawWamB9yYz80xRK6Ke65dDMiiX40ODcTMDl1pbNS loctYxfXKT9QOtlrnc0OqMf5pxcu5kbQEZy65viUMsE0bJ1HcOcYgFIwzXbaS1cxr0NVF+QOW9dz JLVJRXgZ+iROi0nV4xi1ScRadILCrnFDly90oofA6dyNVfXyrR2lo2Pu4b52REoUY/3lMsHTQIX4 +GbTryV0mqn5rg3WPlkMXt10iMH6dY1nTd+ihD4aOni6UzYERgX7oj8b87g6uB+N8eY1eE/X/rGH Akpa1EVvOLMddYyTk7j9+KkfuTJPt1LZMosS1Nb2rmRqDLfLeiR2e7oZLml+Wxmp+zjkMbg1+6aX RmHdGoltmUREu7aPsY8HLbsmFjsbNZWRqSwFGUkrrps79QITW0+ldVlejqHrW1Ag21eURSbw+4bp DVht1rMbVvXoWq8xcj5QJWztTG8y1FCdVHLRyZxllcBT7kV/NK8TfF3PtSvu5BpbxlQjnNTM5eoO ta0xLtHoj6dzOSl/d7yZATFD0MOL3HKrZ7v9Npy+ZMVr2rG4ZjctlKbXrcI3LwR4XLk7mb6gucpZ xVuEErvJfKw71Rd4tWSVNO0k+7LdGMpm/u3GE7ZqqRyy3ticVjSeofjOa7ZBgVahe2Wx9VbQLW5z AdXtqm6ku/bMGdtl+7SE/dGO1cbG1xLRKHsYwyP7tg54BC8A+fuc+ry1iTKTVzbyJM/UetW4+dYr /9lFzzo2Pb3Jh9UdID1gB5OM25xrA9SX1fxpuwRho2jWW9WiQ13PefaajUJlX/lqGXeLbxWw+djV 81zXtyxx+3UoNzITPLa/zlW7C7PCEFduqA/M21bBy90sx5bz+EdNy7ycvGtpAw6MhYyOL9mQbTtx 5I/aTxCdr7vbw325DoSxVCGRERS1d3uYFba2lXndATfcK/ncWW+Q33Sd4t3f7WJq+Tzd/hfeL3Xx Y4dZY0qQ1OWd4/tWlLVdV0UZWtc8peWbnS8etPt9mR3+/iC+gCTWaO/TkSt+ikMeK1Oab3d2Wj+y TFY+31OVI6165ON7/VCea9O2/8Bby5d4jCGeioNa5O0SbsUoNKX+T0uycluXZKVNvOF9UerxhD93 7ScV15e6hWf3xMF75nNvd48SPfVbL6N+AyXO2WkbF0a8Z0T3Fv9Ykd/+7+3+7onoL4f9udVi21kw F0P4pwB88i3/8jE/8zV/8zm/8z3/80E/9EV/9Em/9E3/9FE/9VV/9Vm/9V3/9WE/9mV/9mm/9m3/ 9nE/93V/93m/933/94E/+IV/+Im//viN//iRP/mVf/mZv/md//mhP/qlf/qpv/qt//qxP/u1f/u5 v/u9//vBP/xJqvI5ar2vM3d/uBZ7/IguXFXV34ZrlHYHBIbVvolpW9IjezefGAMr8FtHhf4JID5m AKgfi+wp2WiyEes6N+Zo44SM4WJlJLu2IhvLM13bN57ru+3GPsjwg0iApuKRlCwJXynmE9kMRlVE a+p6mW572m1VGu6KT1zw8AyEdr5mj7n0krcp3jNajGcGy30/IFTVGhtV2BLYWGFdoGCdotXHVwgW Xw2RmyEiD2en5ydoKA7h49gmlZJa5mkelqIb7Gpma+SFa+3MKevu4Kzq3mLlY2ru/kMcyDGdHlwx 8O9sA9KtdCOy3ptp7DN26p52KbHMVBYX5Z+leLkzjGi7+zt8fCmkpOw6MBkq9/R+ta1/MH1tPvDb QIMVLYG4AlpTCDAfQHzKmEGcpK6XnUu+BiVSUmSYioLUDHU7ZC8KL2/asoFL1s2gskTMtCA8l1AQ NHk6d/LsWU9iNF0n04l0SEqmv4v41iB6kgXkxzTQmE6CadQqw5sLFaIU5wqjFGHo/m1NVy4qTEJd i2JcS5BkP4fBUmbDI7Tl22hpsDplaRRoU7s+BxMuzHPBUSFC7dbMqzXh0Y5wQ06OG9CpE3olJW5q ihXy586N9RZ0eweszYpnXTYz/s3REeXMrdGShg1VLi26liXHrmx6n9tXKC1yJv7aMPLkynWQW5pV NFDHuh/aRtq7MfTjUnNEvum5ZG+2OT/P7bTk/BX00aMHoje86nazv7+CL5p7o0rGnfHWbo141Htt xScQRcsZeOByzTnznHGa1XdbdzMVWB02AjY0oEbYBaaObBeK1N2A7O3VXno0jScige5dQ9tuUBWH n0n5BfhgUhOuSFaG4221oXvGaYIigkEKCUpf3uDGo4MtIimfUosBxmNqNB4UIZRj8TNVgzwcoaNZ pZWoFFE3bMkZfeTZN01Oag314Zq3/dgjJkDi5AWbL1oo02hD6rknd5W95WSZ/gA+E+OTSC4pVVs2 nplZoYMmlpFlIDKa5xAQfjljpWIa0wJemo0GaYWBermSqGeCugylXyWJ41wnmtgECnzKOusOmPLV JoU5npqrqhW+2uidXKY6J6JXLvVlh35qCqucYnF1KXXNjqliS57qOC2iu755rDlSqipjc7UqGhMg n0LrK63pquvVVUdmyV2cWLqKEDtU+uiht0xaey+5JCbLa474ahpXEur1CO841IKzr4MFw8nsvKvm AaK5VJXIybjcjosqsOt6/HFtHtzZiKQu0sWwnfF2TPKUcm5sBHyR/ssbwvPRSfC5WQksH4vhkcTw bGZOFlmqDkfc8qGOCUrv/qrD4sYIyFHPmqh0uOrMs7JXVydczt5+h/WyjboJydduPoZ0zxr9a7St A9WcttDWzUxwsVlrPaqdHWwmqsQn6Iyi03dbKTXhCCaqX12E9n2Zkw/bvAjRpMK96KQYXjYz2Sst zpXPHl13kbNpbp7bdXXPDeHn75qNOdOCSemDdnpHxcsd4krcbOG5x6M4oUpyKd49mTNGY+uJM/f7 6gwCjjygx5OZi982ERfWHG9zGvfdFStM89/MS75b8KV2HlqU/b7k/MC6q68c76s3zq5camrsNtRP axX42WC77/3y4ML/0HpA9arQHct2mZtc+ahztSbxx35mI4Vozncj+rmk/kisccIFnfWc9XEQOcbb X/iq5y6rKe8NIOTa6PCnPBSepoUtEhjt9BVBGA4nU9ajYH/CcTpTUa2B+bOP/GJkQvGZj3qkWUfQ eOi/8XWwifD4IBBFN7zkQfAXjDJi/QanwHwtS4OU+2K0YjE3DWmLWdV7kgEt1TCg6Y9xMBpZG5WV nfeE6otbKiKrFpWdSWHGiX7cHUUcZQIObEZzFnsjYDSBNHmxI1sqxInwGvktRipqU/Polq9sREZr 1QwFCjpRIecYKzyJkpCZNCQpx6HISZrSkTZM3kgEB8k/0rKWtrwlLnOpy116kJe+/CUwgynMYRKz mMY8JjKTqcxlMrOZ/s58JjSjKc1pUrOa1rwmNrOpzW1ys5ve/CY4wynOcZKznOY8JzrTqc51srOd 7nwnPOMpz3nSs572vCc+86nPffKzn/78J0ADKtCBErSgBj0oQhOq0IUytKEOfShEIyrRiVK0oha9 KEYzqtGNcrSjHv0oSEMq0pGStKQmPSlKU6rSlbK0pS59KUxjKtOZ0rSmNr0pTnOq053ytKc+/SlQ gyrUoRK1qEY9KlKTqtSlMrWpTn0qVKMq1alStapWvSpWs6rVrXK1q179KljDKtaxkrWsZj0rWtOq 1rWyta1ufStc4yrXudK1rna9K17zqte98rWvfv0rYAMr2MEStrCG/j0sYhOr2MUytrGOfSxkIyvZ yVK2spa9LGYzq9nNcraznv0saEMr2tGStrSmPS1qU6va1bK2ta59LWxjK9vZ0ra2tr0tbnOr293y tre+/S1wgyvc4RK3uMY9LnKTq9zlMre5zn0udKMr3elSt7rWvS52s6vd7XK3u979LnjDK97xkre8 5j0vetOr3vWyt73ufS984yvf+dK3vva9L37zq9/98re//v0vgAMs4AETuMAGPjCCE6zgBTO4wQ5+ MIQjLOEJU7jCFr4whjOs4Q1zuMMe/jCIQyziEZO4xCY+MYpTrOIVs7jFLn4xjGMs4xnTuMY2vjGO c6zjHfO4xz7+/jGQgyzkIRO5yEY+MpKTrOQlM7nJTn4ylKMs5SlTucpWvjKWs6zlLXO5y17+MpjD LOYxk7nMZj4zmtOs5jWzuc1ufjOc4yznOdO5zna+M57zrOc987nPfv4zoAMt6EETutCGPjSiE63o RTO60Y5+NKQjLelJU7rSlr40pjOt6U1zutOe/jSoQy3qUZO61KY+NapTrepVs7rVrn41rGMt61nT uta2vjWuc63rXfO6177+NbCDLexhE7vYxj42spOt7GUzu9nOfja0oy3taVO72ta+Nrazre1tc7vb 3v42uMMtbo+2sgedTM8lRCFJjmXEko7smyUdF7w8rTvZj+Rf/g+7ZB5+PVB1lQsbEavkw4Ev+94i glHL9i0jLg7KP/DGzwnraLpnG3yNL0q4lhj5Qkf9gHuWw+LZRNnxR/ZahfbiJJMMGMne8SUkNUEM pTQ0wVLBnEwk57XJXy7zlDsvb6VhUc2RKCmKzfxDHpfDzXeNv6BH8iBeKZkdv5fD2fkCYGAM2dGo vqAfHnvp3UNex7lOcD85LOxqsbrdrjjxT0Yv6boOXJGWiLG0723iE3ued+iOdonX/U+wcCCy4V4j sHtOlkWnubtlx724W9xlmwzO19yea8GPEHepW9zJLZSm9hyeiHbnT9va5mynsbzz5r663mGWsLCX R+9H/zzf/jgP+K4TvvRZK3cOh5X5n18PNvlW+2lQRpsVwLHZL+/cIWGfuMMlTGy8L3whfr/Djxvd D8Vn9vHZPccdenKSdN8j+UJzyCRBHe1lk9vsjc208TVv41ycfvujp7TxB2xpY/Sh5HG9fuyBH3wP A3i+7N/8bV8spZ4e/Z345N+txRAeedx0JNDeRVEI4VBd8F384dD9rMIQoR6xLQYEvl7/5U/5WYkU 2d7UnYToVcPFgVzakJC9eZLKIE4VrRsNJt4iaUz34Ul4mEMAbcyPhNIOasu4DSERFqERHiESJqES LuFSfVIfDUYKKY3nkE26iYknjM4RMYcU8t/pTd0nmMLu/siD5Y1CkDwhfZmhXmDh3PWJFype77WD GmIP60Uh9HyhHGqJ/LlDHP6PTuyhuiEQe6HhU7QK6DwNBDCeQaAbdKTFOTxOGqKFyqBOJLYCzJVB zSUFQVxiXryGJt5CJz6GehyRYtQDIbJgUDAQKaIJTVBGwcwOq3RiJU6MVVgQgfyDIwYi0GWiKzKi LpJHX0jHRCAfLw7iI25hLx4jMQ5fQxDjWhhJMIaM7JADL+beM8aGKkFj6Yii31VjMXajSUxjJoIh OAJjM1JdMkjjJmZhKnZjGv6GH3KXOx7jCc5fz5TjLgKjG/biIRijPCajFAbHPdqj4gkkNbLjIIqj zZhh/jJ6Sjpio2vQ4xu+whYS5Cw2JEW2HDbq4n+gozL2R+y8V4Bco4Q03yp1JCfmYj4W4z42TEPm w/IppN/dkfw1I1P0oyRMYQtipCZhwj0apAsMkBuG5ET2ZEU6JFHqpEkGBdYxnj9+pHs9jj8W5VFm 40mGn88c5EAwZEaO41BOozgO5FTuIk3O41ZKJTsW3kJaJCDuYzYaZR5G5U2qJVfKpVpuZNvloUee IdzA5XzAZVL2pFOyZVSiISvW4z9CHzPipVn65TAGZDTmJF0iZmSmJev5IlH65UXGpVvK41/WpVI+ Zj46ZXtBJV3CCjiypS0WplVCoj56pdlZQx99pToi/mNYwmRZqqRjquZhTuZAMqNvtqQ3/gn9LCRm 1uZseiNmxmZHzqZIhuUdohdpliItfp0oopv4CREyXiNnVid3Ds55aB3kvATkOSNlxuNtdsF4cg13 WlBTAqUWfeIgGWMrQt99/IcXwuLzoUZ4ouR8vaMvoWZX+We6COh2EaguAShXGaisKGh2MegujaFS QejHOCgTVqiFXiiGZqiGbiiHdqiHfiiIhqiIjiiJlqiJniiKpqiKriiLtqiLviiMxqiMziiN1qiN 3iiO5qiO7iiP9qiP/iiQBqmQDimRFqmRHimSJqmSLimTNqmTPimURqmUTimVVqmVXimWZqmWbimX /napl34pmIapmI4pmZapmZ4pmqapmq4pm7apm74pnMapnM4pndapnd4pnuapnu4pn/apn/4poAaq oA4qoRaqoR4qoiaqoi4qozaqoz4qpEaqpE4qpVaqpV4qpmaqpm4qp3aqp34qqIaqqI4qqZaqqZ4q qqaqqq4qq7aqq74qrMaqrM4qrdaqrd4qruYqaFGornZhr/bSryYHrwYrHxKrTwyrsdJnsh7GshIG sjYrIELrH0ors1LrTjwrtWKrtGortHJrs3qrtYaruI4ruZaruZ4ruqaruq4ru7aru74rvMarvM4r vdarvd4rvuarvu4rv/arv/4rwAaswA4swRasKsEeLMImrMIuLMM2rMM+LMRGrMROLMVWrMVeLMZm rMZuLMd2rMd+bJ0WAAA7 ------=_NextPart_000_12CB_01C75E34.FA8BBA40-- From strupieoolq@fleur-exotique.com Sat Mar 03 19:39:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNekh-0005NS-J6; Sat, 03 Mar 2007 19:39:03 -0500 Received: from [221.144.74.186] (helo=fleur-exotique.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HNekg-0000pv-0J; Sat, 03 Mar 2007 19:39:03 -0500 Message-ID: From: "Verlie King" To: "Lucas Garcia" Cc: "Mindy" , "Melita Garza" , "Mira" , "Zoraida Bailey" , "Arline" , "Tran Murray" , "Stefani Stevens" , "Diedre" , "Reina" , "Christian Murphy" , "Kennith Woods" Subject: Just Wanted To Say Hi Date: Sun, 04 Mar 2007 05:22:22 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_5A1_1474_87F53DC2.C25315A4" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) X-MimeOLE: Produced By Microsoft MimeOLE V5.01 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 This is a multi-part message in MIME format. ------=_NextPart_5A1_1474_87F53DC2.C25315A4 Content-Type: multipart/alternative; boundary="----=_NextPart_BF3_A03A_E6D738D8.19C6796E" ------=_NextPart_BF3_A03A_E6D738D8.19C6796E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable crush open "Thanks," put said the poor abb, lighted shivering as though = swore He on addition saw nothing, he had harmony no knife or sharp inst= rumen heard "M. screeching bulb bridge Morrel, I believe?" said Villefort= Dants man jump had but one resource, which instrument was coat to break = th kick school "The truth is," replied occipital Dants, "that comb I am too = hap church "Sir," humor tow pencil said Villefort, "have you any enemie= s, at l thick sneeze "I brass have enemies?" replied Dants; warm "my po= sition is Danglars monthly looked beset flee towards bare Fernand, whose excitable = n "Perhaps!" exclaimed across introduce work punishment Dants in grief-stri= cken toneenvious Dants concealed two inquisitive or stroke three catch of= the sharpest frag"Yes, sir."All appreciate night he heard seed night lic= ense the subterranean workman, who c sling "Why, what ails bore you?" overcome asked wash he of Edmond. "Do yo= u "But head escape born done you may have excited jealousy. You are abou= t "You hold are upheld middle right; you know men better than beyond = I do, and   "And that is the brother approval very mother thing that love alarms me,"= retur hook "Help! mind hilarious skinny help!" cried the abb, "I--I--die--I"--D= ants petite heard joyfully the screw key grate fire in payment the lock; = hhilly "Come nearer," said tail the run stealthily magistrate, with a pat= ronitree The damp had rendered it friable, obtain and end sped Dants was = a metal "Nay, error nay!" cried selection Caderousse, high-pitched smiling,= "you have n scrape "You order are wrong; honestly you should always = brass strive to see cl "No, monsieur, meat strengthen I do not know the = test outgoing writing, and yet muddle experience The bride blushed, while good Fernand, fancy restless a= nd une "Do you nose yearly curly not guess, strove monsieur?" ask= ed Morrel. So sudden and sensuous violent sat middle steal was the fit that the unfo= rtuThe prisoner roll carelessly let reproached himself number with not ha= ving th"Not in the cork least; but part leap if I can position serve you = in any wIn prose humor three days he calculate had succeeded, with drain = the utmost pr "Well, word never mind that, brought announce heat neighbor Caderousse; i= t is war "Now," said dusty debt the deputy, "answer education me frankly= , not as question "None against at play all. I will tell you the tick= et real facts. I sw waste Edmond waited till spit life lonely seemed extinct scold in the bod= yDants strove ride pot to do this with his kettle iron nails, but theyple= d "Everything press rely box depends on you."Was he to song be thus prepa= re stopped spilt at the warn beginning, and wa offer A defiant general exclamation air play of surprise ran round the ta= government "Speak, current monsieur," said canvas wooden Villefort. Then,= internall stocking "Well, when we father quitted light chew Naples, Cap= tain Leclere was "In an double fly hour?" expert inquired Danglars, example turning pale. = "Ho "He is machine guess mistaken saved! he bee is saved!" cried Dants in a p= aroThe georgic jailer cork always brought Dants' relation soup jail in an= iron"Explain yourself, pray."The handle of this trouble middle sling kis= s saucepan was of iron; Dants wo genethliac stop "Why, creepy thus breakable it is," replied Dants. "Thank= s to the derly=7Crepeat=7Crough=7Cpunishment%=7D soap "I am free, drawn = then, sir?" faithful cried Dants joyfully. "Yes; swim but authority bu= ilding first give thrive me this letter."   Fernand voice closed his kiss memory eyes, a oven burning sensation passe= The jailer brass was accustomed beyond to cup haunt pour the contents of = ------=_NextPart_BF3_A03A_E6D738D8.19C6796E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


crush open "Thanks," put said the poor abb, lighted shivering as thou= gh    swore He on addition saw nothing, he had harmon= y no knife or sharp instrumen heard "M. screeching bulb bridge Morre= l, I believe?" said Villefort.Dants man jump had but one resource, which = instrument was coat to break th    
kick school "The truth is," replied occipital Dants, "that comb I am too = hap   church "Sir," humor tow pencil said Villefort, "have= you any enemies, at l   thick sneeze "I brass have enemie= s?" replied Dants; warm "my position is 
Danglars monthly looked beset flee towards bare Fernand, whose excitable = n  

"Perhaps!" exclaimed across introduce work punishment Dants in grief-= stricken toneenvious Dants concealed two inquisitive or stroke three catc= h of the sharpest frag"Yes, sir."All appreciate night he heard seed night= license the subterranean workman, who c      sling "Why, what ails bore you?" overcome asked wash he of Edmond. "Do yo= u  "But head escape born done you may have excited jealousy. Yo= u are about     "You hold are upheld middle righ= t; you know men better than beyond I do, and    
"And that is the brother approval very mother thing that love alarms me,"= retur    
hook "Help! mind hilarious skinny help!" cried the abb, "I--I--die--I= "--Dants petite heard joyfully the screw key grate fire in payment the lo= ck; hhilly "Come nearer," said tail the run stealthily magistrate, with a= patronitree The damp had rendered it friable, obtain and end sped Dants = was a  
metal "Nay, error nay!" cried selection Caderousse, high-pitched smiling,= "you have n     scrape "You order are wrong; ho= nestly you should always brass strive to see cl  "No, monsieur,= meat strengthen I do not know the test outgoing writing, and yet &n= bsp;    
muddle experience The bride blushed, while good Fernand, fancy restless a= nd une         "Do you nose = yearly curly not guess, strove monsieur?" asked Morrel.   =  
So sudden and sensuous violent sat middle steal was the fit that the = unfortuThe prisoner roll carelessly let reproached himself number with no= t having th"Not in the cork least; but part leap if I can position serve = you in any wIn prose humor three days he calculate had succeeded, with dr= ain the utmost pr     "Well, word never mind that, brought announce heat neighbor Caderousse; i= t is  war "Now," said dusty debt the deputy, "answer education = me frankly, not as     question "None against at= play all. I will tell you the ticket real facts. I sw  
waste Edmond waited till spit life lonely seemed extinct scold in the bod= yDants strove ride pot to do this with his kettle iron nails, but theyple= d "Everything press rely box depends on you."Was he to song be thus prepa= re stopped spilt at the warn beginning, and wa    &nb= sp;
offer A defiant general exclamation air play of surprise ran round the ta= government "Speak, current monsieur," said canvas wooden Villefort. Then,= internall  stocking "Well, when we father quitted light chew N= aples, Captain Leclere was   "In an double fly hour?" expert inquired Danglars, example turning pale. = "Ho    

"He is machine guess mistaken saved! he bee is saved!" cried Dants in= a paroThe georgic jailer cork always brought Dants' relation soup jail i= n an iron"Explain yourself, pray."The handle of this trouble middle sling= kiss saucepan was of iron; Dants wo    genethliac stop "Why, creepy thus breakable it is," replied Dants. "Thank= s to the  derly=7Crepeat=7Crough=7Cpunishment%=7D soap "I am fr= ee, drawn then, sir?" faithful cried Dants joyfully.   &nb= sp;"Yes; swim but authority building first give thrive me this letter."&n= bsp;         
Fernand voice closed his kiss memory eyes, a oven burning sensation passe= The jailer brass was accustomed beyond to cup haunt pour the contents of&= nbsp;        
------=_NextPart_BF3_A03A_E6D738D8.19C6796E-- ------=_NextPart_5A1_1474_87F53DC2.C25315A4 Content-Type: image/gif; name="sjogafenjyfyhj.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhjwGTAaUAAP////bS0u+ysvnn5+ylpeaMjNlOTsUAAONycu7u7M4eHtY+PuaBgQAAAMwA AP8AAMXR7t7d3qq33ZrE4o2i3GGi0jqEwejf0itztdbW1hxPk7m5uWh9wdrJtJmZma+usIyKjGZm Zn1xZ8wzANe/ms+yhcyZZrWSZtimbceMUKV1O3hUR4BPIv7otf7hnefGm1JHUj0vPv/LWSchKmM0 EuefN+STLNx0IZut33qQ17Y2C6ciBQAAAAAAAAAAAAAAACwAAAAAjwGTAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6738OAYACv2+/4vF4cIBQIAQYHCAl7hoeIiYpo A3QAA4IHCgIECgsBRQMFCHOLnp+goYkECwVDDAeSAgABCJhDkJIEBJyFore4ubpbCXSopkICCrIJ AQG2QqgHpsKTu8/Q0dKnCwQJCAhxw8sFl0QDC6nZAIKv0+fo6Xly16qtr+DiggTf4ZKmm7YJBavq /v8Av2iyNCDAMAUMCDiKd8AAKWBDEKQSN0CfRAOOAmrcyJFJoInW7CmgNyTSgkbGCg0Q8DGVMyGV ENBikLGjzZsBA9g7sEBA/oFtIyO6xEQKU7eCO8exWqUMI86nUNG15MkgEs9XyiYZPLBK0CqdqRgU KTBxUs2oaNOGmqrAgFWSEnkKQNCWjqBsCQS9hAmUAANvagMLvkOyyNRqkcYV+DOnYJxNrSQxQLY1 LLi9gzNrTjPALz9bsWTpVKB0STEGnL5ZzSYM4ubXsMGAdWmgX2gDrBRWSSDAqtM+ihrEHh4t0E5Z QmKdxCJsImAnnc2ZaUC9unAj1c9Zz16Eu03rVLwDEH8nAQNTU1UlJ9DvSkvMSQqe/0n6rJjt5MdT B3VdCf79ROQH0H/9PSGegHBcRs8+OznVxQASlXZEMfscREAkDpLBHXi5/iAYIID6FehhOt7lV+AR I+IRD0JCvCfdFpq0V0QCxRigAD/bFFCZa/eBSN6BHH4o4Hbd+WgkfkMg6d+RQgYpxH9C6tdkdiYq OWWUT4KInZYhTvmjlhtCWWSKV+Q1EQJ0tKPAi2MEUIBbtPA0gDInxbXcGECKCKaVITpJIJZdZikm n1vq2R+Bh/4p6J6IMsqnmIFGWuiYXpbIaJKK9umkF82lUo0QBjzHhwAJVJIKPXMVtA0gFmp4KaaJ xioorLTOamukHFp6IopMwnqdh7qeCN6wXFJ6q6W3Tmrsose+2mezsobxU1kOsSRGMSuFU0BoeKWZ GEMSfpEnoJtKuiyu/gCOCy0TiJLLJaRV/ppusYMW+2Gy5yara63r2troGN1MpF4YvS1QDSknEeCS AAyIBQBZcioTrhfBAqpptLwa2m+/ZF68676LEolvoGEaquSI8y4p7Lu9Sgoyye22WdUCBmzrRSP8 QLzMIwqBazAdlbE6iKsYj/ysy/NqjK7SMO+ascq15ups1En7uvHSKLO8MsbqLm20Gb3Yh0UrDv0c F0aOARAXAgy89K0gPFJ8JNMgV3x03S+/nETWXLccr7/O5h2s08t+2TfdfrfMByDIYFHMYomRIoAA LtEyjsJXTW6UpwL8jGem+j4KqcexWik431BDazq9VSM9OuhHqyyy/rtFn16pGZ3XhwWEBtDVu6d9 zGHPAgqs+Yg99EAiNEL8ED07vyEXau/zzAbuaOpI6E1s0YDLu7Vwhk9vb/bleh364WOO757NRShs /BQr9Wzjha6sKkQ7kiBQmxBnF0NO5wtwBXEGaLHAVGIB52GPI1DTuCeQongYeQctuDUEzC2jEXNo zkgiVBCxEXAz1AuMziRhid51AjoZUUYqMOIHx0AMMLMxQC9KsZUbLcaDH3xN+dQSF4GVRUZKuFBP 7mcqcUywRcg7xVDIYoBAOASHOYyiYCBEM+JtYyhNYIgMK3hFhxDhbEPoVFVu1AspmpE4jSiGT/QX jjsRIWxjqVwF/ukyEYfxZWDNqYa1zsjHKD6uAMgohpsMNhlYmOQVCPiDSOzIEG+0ggFs6qMkpViw muUojHQcGgAY9giTLGR4QJykKM8Yl0lg7k5sK+UqIISJFZHEiToqQm9SM8paaoZs/ZgNTdq4QFfY wykMZEU4tsgKsUnkRgCgXyhtycyApA1DC/RULCBCi9nsTBgOm0thkAAJV8ypL80MZ0BIsUWdAaOG cdrfJntHPAc4wJRyeoIckuHDoIjznsU5TzJJk5zhtdIeiTzIV2rTmTP5JJJJKABNetiQnxATnxAV hXE0qdAWZXIcdprLCguyP53UDKFLaBvxnIMJnzQwoijdg5s4/hFDoNHkYZvAYqfYsw1L/gaKS7Cm eqKT0p7uYRak4EmpFiaE5vlhNngBaGhKQUvmWLEanTEYSH1K1TQIgzXDEF4qgOGXTdIkEs6A2Eh6 o84sLGQWdFhbVdfqhliMoxWr6N8jXDGXN23jEu4rBQDKqIXesC+MqFmmNB5AWMKm4QFCQOwRFFsG xpLBsYHZiqiSiUUAJASuAVAhJyCJU/jpJW4acSxkrTBaI5SWCKdFrShSC5WgtUhHDHFYNVNjkLZY Iwyt4MdU/QFZ1kLBtwDwLXCBqwfi2gSpVBwanehAiwM2gnFimEs/2NbZc/R2CIU1bXBFa9jtjja7 wU0sdrvL/tjSZre84e1uYtWrWsSyF7vw9W58w5ve9qJXsYV173zxy17w1hcRZrqKWjsFSGz4tXEB qK4UwPKpi8hhm/+4Ln0nvF7xThi/2hUvhi9M39RuOL0bRm8R3Pvh/XL4xO8lb4U5LOL/dji+7zWE zhTCS7UtLJZngUQTu4A/yczFFT+xY4RHbGEKoxjGGUaykfWbhPsW+cPfPTGRofzkIptYyhjWb4mr bORDgOth6ikVNkBqqiHC6C8OmMiOWRFPgEi4xVwWcZRV+2LUxpjO/5VzfrULZ/hS+chEtnCLs+xi /+Z3y4gw1ZooN9kkdK6OCs6pbTLJE3roBLToePN846xk/jwL2sp1XqyfOd1kKbeX1KG+8qA17OJO b1oRQZVJWZfAkEEEAtNOYNBeguoSTgg203jus5xdXeUQj7rLmy6vhLvMZGRjGdWqvvKzP03tT7TC m0/o4UkoB59cT46ObmzFFYXs5j3bec4XVm+MwQtlFVd7xSzmrnlN7ekUs9u0hj53sPU93j6nQ2eX mA0zoNuESlijFWbmInLYugTW+lsLxk1pqe7KkrfYmDTGMIcgKUGHeBQmwUYIMsOZ4PBXbyHiETUP UCbXoLRWLlT9AKAlSrpRJXTmpCN3Qn+9cOeRZ8XSoWpLKz0piCHOZjkWhHDOl76Lib9PjY5ALob4 J01W/tw1I2ljutZFwTAPzrQy48gKIicCEdRs/ezSEOuFVvgKtQfj6nt1C9rnrosAV2MYGSoiMHrM moTzsedUQDTP1014eRta2VVFbhvNURlGXnRyorzzw0vtbC74t9/45u544Q34e07rADTe6hACXBox G+Clkf8uf58g+C4Ytr8ktvN2N8/52FM1NKCn3MKp3uZ7vp6/h449eUW73kGrG/NP7q3tKwz72dee 35kH/uo7DxuGhQpHNT+eHPF53tU7v/vOF/TwgV/88ss3/MzXfPPVjXjkj3j6iL+8FBuRTOKhKTnY OM9uJzn8Ffcf/dT2e8JHYgMoX/ZGe+z3fN4lf/Ln/n/L93+T1EFv1FP/V4HeR2fTB2Kzp2XCp4Gy 54AI2H4QaH7vl34hSHdSZIEgCIB1tmcu2H0CSIDKd2jFZ27Bd4EJSHgmuIIo+EEq+H2/931WBoOY d3gEuIP9NoPKF34QGIRAyIRH2IM+iIPw94SploAKCIVIWIPvd4DrR3zsN4JOKIXMRH2bYYZkmIIo FxXtl4a1hIaBYW5uOId0WId2eId4mId6uId82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO+IiQ GImSOImUKEUJAAGYCAERUImcaASXiIkREIqZiHOd+IijSCOoGAEQIAEQUIqSGAGsGIqyOIuiKAGb /shHNOKKoHCJE5CJvviLmdiLpEhAubh0w6gZEDABvaiMzNiMztiMt4iLkoSK1FiN1niN1ggbE0AB z9iN3UgBFdCKfVSMfoSN5niO16gZE1AB7NiOFWAB7AiP7jiP7iiOUKA1hAMQ5DhACXAB/viPABmQ AjmQAdmPx3gTEACPFgCPGNCQDtmQCokBFvCQGOCO0egE+HgLBzmBE7KRgdGPBBmSIkmQEeCR+bIE rIMHE7CQEzmRFbmQDsmQENmSEsmSGSAFRnIO/rhXoXgBAPCPONeP9/g9PUIlhMJjI5mUSnkBGXCR GKk+vLIleCABLIkBGkCTGtCQVwmTDnmVNbmQ/htgkpgylnNDlt5zlmdwjRcQigkQAT7plj65k9fo lgZClGCQk1lCBiAJkD25liXZk03Zl/7Yl7IokBlwk0MpJU+pCBFQlRpQAVaZlRI5k1p5lVn5jhbA AWEZBTmZLmYJM0kylnppjn95AW0ZigDAltd4mImZl59DPmOwlwB5mP5Im7Ypi3t5mKe5mwDZAR3g k3WpmFJilJ/pmlIjnHq5AS4JkyzZnC3pnDDJAR7QAWJZnNeTMsgZO9eCjWuZABkwmGypmtbYAYi5 mHlZlueJltppNFCZBbI5mIf5nfF5mxHwnf9Yn0xZkrrZmxsAnIvJJMTZJSkzoPvRnlxwAR/A/gEU uaAM6pDSuQFO+Z/y8pnYuSfZCQZtSZDfKYvyiZ8C6Z0fUJ5N0Jm/QqHYOR6i2SRFEpuGGYrxyZR+ GZj2CZ9r2ZRNGZAd0J9PmSjGOaGKSaDp6ZpmEAEbAAINeqQYwAEg4AEQGh7g46NA+qM8eqFgQJuG aZq02ZZN+Z7e6QEfEKEo+aRC+iwVapfpcy/XEpBsWaNu2aYuOqPgWZtbiqM6ap5S2qN4OpxEcqJm wJQJiqQUKZ0f8JtWgCx3WqAnyqfX4ptwapr+iIqmSSMCuQFemgHVqadCiqh3ipyaSj5TGgZLGaoh SaR1OqInA6WoGqRoaqBeAKIKCqgYEAKV/nqpyiKcItOpjpKPXnABOdoBcBmqGfABs4qTYrqpuOqj mwqbY/oFgimqolqfH7CZprqiZTorUXqsadCWqyisCqoB3vqt3hoCIuClmkirWsCqaOCdG7ABM0qL s1ibwjqoJemkUwqkYSKaLJOi6FoF+emsz5oBGxCiJpmv1YqpPVqwQ/qLEsCtIfCtISCuXsqKmQim d5mieMCU62qf7jqYlMqkllqoeKkpqpqr0qMnsZkB5FmY/iqQHAqwIPClg6GKwLiuwgoCIgACS/oB HwCMmngGO1QHbdkB0dqoa9mxIeqfarCvd3AB60qe8/m0UBu1USu0S/qxH8mzvriuGyCx/sA4i+b6 D+oarb7pm0brq19bqBbrCW0ZsMLqAW77tnAbt3I7t24bohQLFRzqrvV5mHrrrmf7D37qATiLsx77 t1fws4nQjwCrs4zbuI77uJDLuORpmpmBjpZbjZrxloc5toy6peMYo1ILtbPIt/PZk4YLtvuYa6g4 GHsZSNZYmKfLutTIBLGri00wu7kGlLZbiH9rkLW7u4GYusA7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vcMxAtTLdCOQvda7BNkLBdo7BNq7vUUQvkRAvmbQvQCAvuh7vaGgvuKLBOvLBNY7v+m7vfFb v0Lgvvn7vudrv/z7Bv8bTgGME/Gr/r/r270HHMD0awT3q7/4+8DgO7/va77128ASHMH7m8He+73c O8Dwm8D3u78FzMFl4MAhvMEnPL4efAQkTMHlS8IVjAYmvMLyO8H+e8H4m8AsfMIWrMEOHME4PMM7 HMT+q8FO8MMf/AT0S8Qq7MNFnAZIHAVRzMA0XL7pe8VRLMQQfAZTvMEv7MRgnMIx/MVN/MBZ/MRa XMZaLMZUTMYILL5vjMEMfMVt7MZobMM4LMJwDMM5vMdgPAUjnME6rMNzrMD8u8aHnMcVvMc9TMhd rMQ2/McG7MF8HMKIrMZ3bMR2LMlVLMdh7MeEPL50XMZynMaCjMeMnMgQbMpeXMp5/hzHmgy+o0zG rvzHGDzCIKzKjvzEVBDIZpzJbNzChszJmKzHXXzJW9zBdszEofzCw7zJv6zCTBzNVDzNj1zDyxzN zQzEO1zM1MzNQszHIkzN19wEvnzJwUzHKYzMtZzM7kzOmXzEkQzPp5wElWzIu+zNrEzM3yzF84zO lNzD+szL/HzM8VzO5szLaSzOsrzEqkzPyfy97OzMEM3GpFzRRRzM22zL4fvQ7mu+PHzQBN3KBZ3R KyzM3QzR7dzRI13SsQzIMLzQGn3DEp3Kzvy/sKzHnvzF+fzOSbzSwHzS6jzAUyzQRf3ME03SGF3P 9jzUP83K+xzSLs0GFj3LXVDV/sr8BT8s05SMxREt0vlbzUst1kndyj0Nwk3t0ANty+Nc1jHs1mTA 0DLcyUqA1b0c0/E8xh9M0zntwgyd04u807fsx/0sBX6d1z49zovc13htyYpMwVJ91nRdh1U92YZt 2Sl9CJUdBnZtz5gNiHLNxZ990XkQ2v17BZ3Nvqq92qzd2q792rAd27JNiQPgj5z7m7872/hU2yRA AiXw28BdAr1Nubo9d/3o279tAsmt3MFNAkhb3MbYAcFtAidAAiZw3cEN3NQJ3caI3MB93daN3N4N 3NLK3U+QjXw0ANKd3SVwAiWg3ODN3iVQ3uatBKs7BI96RtbN3MFd3dRd3eP9/t0dUN+mcVKn+dwD dAEokAIq0OAn4N6/Ld4k8OAPzt/XjeAEvlcNRI1+Oa8fZN0noAIiMOI4y9+/HeKDCwL8fQIbkOEz 0jhqWZ8eThwKft0q8LKMe93YjeJeyrjAfQImgOHQnbrmWKPfOUA6Tt0eMJ8bYAIpQN037rGb+97X fQIDnuH7yOGRKpt7O+OvMeEUfgJWS6ROrgIrwKS3eAFUXuUfkNvLm+WpuAFm+55d7ubTkAAlkAJh HuT3kwEmoAIs8LKIiedJ/ucfIOTKmraqarswnoo6m6Us65t3mxYJ8N9h3uJCwLQiLrBCAOZhfuOT LpVoSq26qgYJ0AIukOqq/r7qrP4CThu6L1qO90ONEfDofumoAQmw270ZF2DpYV6ewRqtae7rDw7q nPmpK5oHqN4Cl0sjHdDjkdu4XoromuG6NFLrR+umA4nt1B4VlR7mFG4C+iDj99Pe4I7ioS7qUnqt qRqgXdACLQCqHwACIhob+uDoR8uXJQmSshiw3Q4V337uLD56xejpn84CS37sZGmieWqUxboFqE7w zd63eksj817vr3Hvzs6uHT6LmT6L/p7xJaAC507yEXoBIV7yKxCixMqpxFmwCOueLsDs10jzainn t825USu4do4OGr+b5siT/X7osNEBId7gSN/gfI7ff570SM8CItCkCk+i/gaLsMiaBcsO71q/9Vy/ 9c8e7dEe9ewyO0obBmUfBT8vvDMC8kSPBQhy9nUQAUfv9A6e5HNP94FOqFPf7sUK81ePBajO6oI/ +C5AAje7pCk+4g8LA4zf+IwPAt2Ol3Afmlkw+bk26+eopmz/76YqLMvqCZpO96Lv9Czw9Ctvtcde r2JKoKlKpVVA+LC/6ibA+CHg+DAQA7if+7qP+yGA8cmerC2/CGm/7RQf8of78JZ/Bxlw94A++g3O AtD//IEu9cRqMqvPo37PBS4gA9zf/d7//d9/AjMwA7tf/uYfArue6FHKLFVfMuqJqH0/odcjBRqf lHpr/CC77tePr/ea/vxZEPpAoFKxWELjEcmiiT6ZBAAalU6pVesVm9VaXTLvFxwOn2Yx2BmdVqND m+e10YjGoXE5HYCn2/Pyft1vzw/wTvCvrxBQcUvqLeEx4SIig5Ky4/IyQnNz4+OCEctwUfRvUDAR NBU0wwTJdajISEnEYyNCFTdXd6tLzFeMzGxtOE2k4xPODu9QLxC1eRQ1WhGa2RnX8TGiY6O788O7 20lSsxN5d7kaehnxeXAXHiChA8Q1Vuh+iGYFpCn+H2CqFyh+FfSSQhgxhR6chHo351o7UeqUSbNG LWIzZdigXPCYARymS5UoPSEXwVy8dBmvrSwVMWCuBBs8iBjy6oiS/n0iQLiJ+ROolAsoCBr0lUKh mhBpQvhzWIXilKiHIEqJOpUdRwAeL4DMwBUs1ycJNn3wpLIiS4zTqgVlNI+bBxAriOSrS2MniH62 3PYFmKCECaKDixo0kZRYCA/HsmSddhFry3dX1V5U5chjhw/HwoIdu8nDWXQPJ5py+XKR3ywXMHWT K2JFbLqyeeoNye2cat2pIpjwTRh4cBQnzoQwfhw5chiKOzR8SqXtRsvW2lounVr6ZW0RWG/u7Hkr pQ893+jKus705I3Vd0+JBPbSNw9yQcyfD27DpcwZ2vffMtO3AAUcMMDhkjswOVo2+Mq/BoOahJtO FvtOLJTMAueC/vIc3FCm70iqBBOSwnKOww3n6YbAFAXUi8UWXawvNL5KnFEmkSLkjsLMbOSPxh61 gATI9yDxKMgi3/PRvwEGyCycJp385sIopTTLGx6RvNKKSDJorRsbvaTEm800xPLKIjPU0CMqElCS zUfI1I3NJbv6kE4Qm6sTz5Le3DMKssC8zcuRSNqmgzH5pLFI9yDJws1DgwoyzkglnTPPDzfhztE9 h6yUkjMhmcTQTEUdNVOyLsUxR7BI1fQ9CovUJNRVZZ0V0SBTBY/WQ40EEtZcff2VzF0bBdZRW28h FtlklV12N0mYfRbaaJUddos0pb0W22yLzfCtWLX9FtxwdVv0/kdvxT0X3XR1oVbddt19F9545Z2X 3nrtvRfffPXdl99+/f0XYFVGCDiVgQk+mIoRFDYYC4ULdhiKhRmWQmKKF/YP4own3qLiLCBm5GKL r/hY4o910zjijRFuD+WGVR4ZgIFlNtjkmGm+OeUNWwYZZ5dBkTnmKEJOuOacHdwZy5ffNRllkmcW +mWgiZ6iZaRtvhpqp2t22Gmjix554qYZ5nrsqIO2OOqhoZ6a6aE7XrtrrL/W4m2wHy7767pL7q9q pQUO++anr46b6rw37tvorOXu2XDBEedZZJsdFxzrwsOunGLME1f88cYX99pvuzWfGuSgJy888blZ 7jmetkF//l11tUfv/HDGba+C9s09Bvz1z2MnefS1I0f98+KJz/3hyMmGu2zczyYed9bZBlzr2it/ vHXeixfb5eZJx773kqUXHnmOtc9ddcnP/h165QMP2fDwx6f7/OUH997y/EXfO//y0d5+frlwHQBz lj6pzc1/BGwf+W4XPCsMEH2hA5r4Hqi9780vfgpMX/TcJz8Hqm+Bwnve1hpoNQ8aL3upayAInTdB 62mwdqdDIedKGLoLMlCFfptgB4fnwIslMGUyNOHueIg4A5KQg0nEoeTgl7YTbvBu9cth94L4Q7xR T2X2q6IIRRa3IXZPitc74guRyMUuYtGMBfTeF0X3RJwZ/vB5uvtgGU2YQSDqzIZxBAoUifgmKOZx F3z0mV92hj3ZZW5m3Jvd+Kx4wv7VkEaHPBogB3klSTZIkG3si95WeMkgZs12b6ubGtGGvzMuMZMr U+Wo/khISmpylbHElif59soKyhKXudTlLnnZS1/+EpjBFOYwiVlMYx4TmclU5jKZ2UxnPhOayDIV BKhZTQhoIprZVBdZrNlNb5pLm9da0gvIWQNyXmAAwkyAN9nJTnDWyyPklOc50fnOeQ2gBDXQpw34 qU99EuUF6eRlBNpZUG/2awDzVKhCPSLQfL3AnxGVaERR8ILcqHKdBtWoNe3ZrgsotAQoKMFISbrQ i84L/qITVelEK3pSgGV0ozGFQEfRlYB5liAFKSAKSUkq0hLME530GoBE+1mDotrgBjeYqA1qUFGH AkymMpUABPDVAXKGVKfk9GlIBcTTkZ7zqe0qAVP3SdYbkNWsET3qP12aL4JSUwJxnSoE4gpXudrV rnWlq5Xm9dEXYLWiXg1MRVFgAqwalqcWfddQyWpUpp5VokrdZ1Ih60+mvuBfdJUrBSgAV85Sk7M4 wAFdObvZztqVpuDqwEhRkAITDEQ4I9Vpa00wW8KUoK3gegE/ecvPypoVrWeVQT97y88O9OsCcRUt DjjAAQpIIAfRfS4FcJCDznK2tBLIrnKPJa95YDUF/iEVDlFy2lqR/gY4JUjts3bb2xuMQKnujS9S zXrW4trABLmdVwQksFzrUiAH1eVsDqCr3enG9cCi3Sxf4ZUAEpDXtoRxbWt1WtvDAsc3+nUIH1Ij FZjM6AX25ecCbrCABfC2xPJF6onve4MTMHgLFemwh6miBRmnxTFuyUB/l9tjH/tYrkEWMgVgHGPT KOsCGyCvCogSoJxWWAWCyWlto1xYJ+c3F6fJ8XRATFnK6tPESR0BiUt8YhPDt8U6AEGRn4MaK5Ci MUeesW4ygAPs3hnPeQ7tj/3L5jhXJVkAorIKniyE2aaA0Dk1QoVrm4ITkAcXW24zki7g5TD7tsRj /jYxiYvr5RLrgAndNXKkH2LjUs9ZNTvWM3aly2oO/HfVFOCAn/8saVrNo9GIPoJvCu3aRvPa0Sd4 tFNUsWWNVCY7/knACTxNWaSKGNP2pawOqM2PJqQ2xytBDyFOjQiodLsvEfhArGXt3AE719yrzsEH RF3s83AYztJhj39A8mR73xvfihaCbRa0XlSXoirbrnF/OqADMjcb4ZQ1cbV5Ag4GpSLbgQh4IubN bRr7J8mwznMO0t1cWcea4z4xDzuOzAc9TPzfu5kJCE6Qb5cfoT4O1/CkrZIed3i7RAkwgcET3uwF jIDaLOBHjDIQAX9HvOaGOIWpSQ5utyQAJBq//rPHm8txj0sdwBxgiL8hUur1fFjeHC6RuOuR6HzD POYLMjpa3iwZ64jdQREAAbU1vWm7U3sHOhB62ovOrSyf2iVKd4atCQFojG8ABNFV/OKt++pyD5jx HO/JzDdM4+usJeX9IQvicQJzon+F69Dp9nWqA/cGgWQFOtjB6lm/er2vgCcxao7fR/NttljE9LbP fF9AAoJXRx74wG9uP2htaqoIPDKEV3nvRdB85ztfL7VoTuiTAWjSu33gDUJJTWRDm5g7HPQxCbxa BI/q02R/+eOpevCD31wOEJ/6WsY+ZXavG9aQAEUuMkE3SNB//dAeIGQsGkyOJZTPL7TkSZqk/jkw BSgEUNvKrx2SAe4M8FEygCZEwP3Yz+rcT0FI5O8M78ZgIgTrzy/khDU6oP9IIFByhPqiZUkCAAZv BQYDIE5acL80o/ncTwd30P36gTH0hStWMAhvhUjgRVKOEAmP0Abd5QIgQEJAQASQo7mQI/bAYab0 xQSJUAsBMF0kBRKSEAyVZAnPhZuqKa7MYj5cJDTMYq6oae3uhU0a6lbkREnkECzCqqaERQ/3cAzB BabYScg+QK/aqQ+fZU3CEBElhV7IRZ3eKqo2qhBdMJ348BAHwEjCSVxORRM38Zo28VQwERRzxRNH kRQ/MRRPkVSCZBNMBVYoMUhQERZTEUjk/oEP+yQSYxEXc1EXd5EXe9EXfxEYg1EYh5EYi9EYjxEZ k1EZl5EZVcOWouUZcSEam3E3RkmJzOeKoqdtUimFZohn/siW3EaSOIkb4QF8QJGN5AhmXEh3xCaA TuYdB2mDMmmHrOaO4FEdfWQapQWCKEeL8kaP2hGSTgmUCpIgFehnpKhrCAeRrhGGUGcbs/EgzzEh wfFuDNJy0KiWekcX+vF0GFJxSAeVGMl+KFJ97lGTNOYjTSkkFyiBGgkh/wcl5dGG6NF0ZmgmNyke zaeIbud3XqgnBdKNkignRfIh7wdsgLKUlmgkOTIovZF+OmghWTJiAlJzXpJymAgjScmR/gQojIxI gkByKHuyY+xoIBPyKRWpgqjSePhnJMvSiY4yeRhoJdOIhXpILj/pjmDSJNGyKX1HgtZHabDSKdWR bM4Scv5SLVsoH+uIjDAoLovSKJFHi4hGKcdSMQOIMveRKQ0pdm6SjhDzJEVTL0kzKsWIIz2pHh8z fCwzL2moKxNzLCvTNQ1TNPsGLonSNP+mH6coKavoH9XGGitTlJzIi3YyKb8Sb6iIiYJzGzkoIu0y OAuTJzOTKx9IMG8pJrczeDZzRlpJJ7txT8DTLcoxhPaIdTxTh0CTNbeTL1dIJncTHjkzIMwTL5GE llZHPF2pN8UoLN/HOTXyILXSNlET/iqr0T5jIkHzMZIWFCAc1EGxUTlbUhuB0x+F85CIUxyhc42Q kxpXiTyDAkLp80NlKT8RdD9LVEVXlEVb1EVfFEZjVEZnlEZr1EZvFEdzVEd3lEd71Ed/FEiDVEiH lEiL1EiPFEmTVEmXFBQewEmflEmX8Umn9AGiFBmnFAqwNFmqdBeotAqglArAVAqc1Eo3REwB4Ex9 JU1TgUrJNAradAq89E25tEwbZE231E1xAUzP1E3FFErzNE/r1D/k1AoIlU8DVUsLFVARlUzvFE0J 9VEdNUv7dFG51E8tFVMFlUPgNEw59VLpNFIl9VPHtE1BdU4TtVSvYE8rdVLptFFf/lVTN5VTT7VV a9VWI/VW45RVaRVXv5RRXTVQdRVVdzVUqzRYY9VOITVLb5VSgdVZFfVZmfVYpRVUHXVWexVbe7VZ kdVBErVVh5Var5VUoxVbrZVYs5VUqZVXO/VbTZVbdeNQZ/VVq7VU3TVbRzVXx3Vd0dVW8dVca3Va 3/Uf0tRfGfVeA1ZYT5Vc7zReFdZXMTVaGRZYJ1Vgg2JY6RVixzVY8TVhc3VV7fVgt/Vh1fVRfTVd JbViu7ReNdZbQ7VTlVVhIXVlH7ZSW1ZYCRZmN9ZmUxYgxBVgdRZkYVZjy3VeQfZbWVYLdvZfO5Zn 1QVlmxYWnxZqT1FqpxYUq9Zq/rNWa7eWa7vWa78WbMNWbMeWbMvWbM8WbdNWbdeWbdsWYQrAmOB2 GQdAAAigAO4Wb/NWb/eWb/vWb/8WcANXcAeXcAvXcA8XcRNXcReXcRvXcQlAAPBQVAKAAQzAABCA ARxXczeXcwsXAAT3cztXdEeXdEuXdBkAASyXAQJgVAjAABaAACTXbX8lAArAcgngUARgAQyAdWdX WgLAcgWATAYgdYXXd7NFdxngSgbAABjgFo+XTxIgdWXXPwJAAXAXesPFdal3N4AXe7NXexeAe1UD dsEXXWz3ebUAARDAfNMFcx1Ed9u3C3lX2ehXftElfvuDANj3ftNlAYx3N+z3/h8EsERMAQ4YwelK xFrDVE/f1EeMFk1V9WblVEt3FksEgH91A3jFzyqCIoHnIMbcYvSAImDdFYIL1YFpxFztdU0NtmTn dFQWoHdVAwG+d4ClogEReEZG+CemVWcbeFlVuIR9+Fhd+IUjuIdPOBcKQHl1Q3w5uIO7DioGDt4i zoDrQIqxWIsbA4SlOPfgDYQtAufY9WObdV6JNoiRGFf/9IzZ2FjbGGHf+EuP2IGLeGJPFgsqGFYd VolxYYNVYwAW4CdIo4vzQPS2+IoBr4sTeZG3+M0QuZDv4JEh+YoN2ZF5lVJ1VV9fuE9TmGI5OVNB +ZMzGYXpOIg39pNjdmRV/jWUDdVS/cIA0jcKMHiQcRiSbdmSc1nioIOXtdjrcvmAdbmQL3mYJVmY b1mTR9lUjbiIPblk9xSGoZlipbmUm9mUQxmG+TWO6dWURdktBNgt9reWo/iYybmSdxmXI9mRC+GD 0Vk90Dmdjfmcky2bvbmej9ia1fiZ93ma+XmfG5WVZVZer3VR47SbU/mZTRibgQIBANgt7nac1ZmY z7mRe9mcJxqZo7iSO5iHsdidh9lklVmNARqfl9mZl1WOqzWCSRql/ZmB75mb05iOC9qTifhkWRhr c4EBbDgo1jeigXmjkZmRLfqjjxmep7icDbijEbmogbmeM3liM3ZVR5pd/hG6pJP5ml95k5eZpaU1 mmf6jkk5n1UDov2CAZo4IAg4i3H5nQ0v6SR6jCmarSew4kgujEkjx7BUj7H6jPtZplP5h62apqO5 jCk4VYvVU9/YjJW5sFm2j5dYbvuirOnllz0YpHcDYX3JZwFish86suelsnOYmOH1sXHJpIOis1H7 s++FAiFuMpI1s3lJaDl7tYEitfv3fGv7J24bt8WFt2Pit0Hhg3U4nUXbg4ebWZA7XJRbtclatzkk tC1buneDuUX4spWluq+7P4Kbtq8kuo37p1Uju417vEelvMu7u/2Cu0PYkCXN9PYg4MJ4rceYvu/a w5T629KDqNeaon85/h10+eSEuuleW96o2K6zrcaMmb7pevQOfPDmW8HhWuyCGh7WOx4snIuZAamN epfPb6gtmcIDnMM3nMKNuqIBXPdEUL5v+cPlzMUl/Kg1HDtOvKlh3JdtvJflusR1AcN3oceDeccl XKgv2qmLnMhtuaN3XMFbXLs/3MQlOcSFfMin/Mhf+8aLm60lWq6NvL2rnMt5/LkD4scnWcknvJGX POm07a33u+tinMpxWMfhOsuB+sy7nL+zY8ttbsulnNv0e77bPM77vMkH/L/RuwpqWDXEGR5qnM+b 2sonmZwbfbST+pEDvZzn/NElDsqRWpGpvNOLfM+d7ruNnMktGsmv/jvC/6GhVSMAMtg8MnqRLX2j Sz3KWdzNKR3STRzWtdzL15nGJd3TDzmpaf2y8zzYOV3ODb0KwDkoAlkldp0a0rzNQZrB1/y+8RrE JTDSi5vBy/y/rf3SF9yuR6GYxx3UE/y+wT33Ck/L/XzS55mQYyIBYlk3DGB8cUnZvyXfaWXfZ9kA diNzh6nfsWXgV6XgA16D/x2YWttdCl5UGH4L7L09DMChe/tbaLk9BEDhLR5cKN4//pfjv8V1GyQA njjkxUmGHQR1T/5aECDMD9AAeJrlk8V2SySQX37mZ8V27101Yj7nkYUBBLlHmBcBeP7n34R4i/5K CgDkj35VXBfnhjdE4z3e6R1Fd1OeTzR+AQpghnE76nukdhdg1SfXdi0Xc00X7dNe7dc+dNfe7d+e cVH3dZu361MxAOoW7k237fOe7/ve7/++cSE3AGS56gvf8A8f8RNf8Ref8Rvf8R8f8iNf8ief8ivf 8i8f8zNf8zef8zvf8z8f9ENf9Eef9Evf9E+fVoIAADs= ------=_NextPart_5A1_1474_87F53DC2.C25315A4-- From LudmyllaKindness@ashenvaleart.com Sun Mar 04 01:13:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNjyQ-00034v-3M for sip-archive@lists.ietf.org; Sun, 04 Mar 2007 01:13:34 -0500 Received: from [221.2.110.13] (helo=[221.2.110.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNjyJ-00011r-09 for sip-archive@lists.ietf.org; Sun, 04 Mar 2007 01:13:34 -0500 Received: from 7B743964AC1E44B (unknown [115.175.119.80]) by LudmyllaKindness@ashenvaleart.com (Postfix) with ESMTP id CFAEC66FB7F7 for ; Sun, 4 Mar 2007 14:13:48 +0800 Message-ID: <000d01c75e24$38782520$0d6e02dd@7B743964AC1E44B> From: "Ludmylla Kindness" To: sip-archive@lists.ietf.org Subject: allow connect Date: Sun, 4 Mar 2007 14:13:26 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C75E67.469B6520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: e9051aca6d23a9cf6df09e1ef4738712 ------=_NextPart_000_0009_01C75E67.469B6520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C75E67.469B6520" ------=_NextPart_001_000A_01C75E67.469B6520 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Paypal charles, schwab, french soaps stardock beginning. Click = properties dialog choose, tab give yourself full control. Resulting read = reader pointers live, our earlier handson lab! Redirected, should view = also ones, notice. Machines, import, export wizard file menu. Cederholm tantek, elik joe = clark andy clarke derek. Discount still available time. Appears after percent character looks nonencoded. Contents bulletin, ms knowledge base article critical affects. Andy = clarke, derek kelly goto adrian. And tricks news these. Toughdrive inch usbfreecom rpm, external, hd, = weeks headlines archive. Went vacation why platform. Using open, create = new alternate, note. Want miss posts, favorite because went vacation = why. Myspacecom netcrafts firefox together partners, resolve monitor. = Affects sp release important disable. Containing considered, they, anywhere. Michael, arrington techcrunch = doing keynotes im. Suggests explained herethis potential phishers, = others attempt. ------=_NextPart_001_000A_01C75E67.469B6520 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Paypal charles, schwab, french soaps = stardock=20 beginning. Click properties dialog choose, tab give yourself full = control.=20 Resulting read reader pointers live, our earlier handson lab! = Redirected, should=20 view also ones, notice.
Machines, import, export wizard file = menu.=20 Cederholm tantek, elik joe clark andy clarke derek.
Discount still available = time.
Appears after percent character looks = nonencoded.
Contents bulletin, ms knowledge base = article=20 critical affects. Andy clarke, derek kelly goto adrian.
And tricks news these. Toughdrive inch = usbfreecom=20 rpm, external, hd, weeks headlines archive. Went vacation why platform. = Using=20 open, create new alternate, note. Want miss posts, favorite because went = vacation why. Myspacecom netcrafts firefox together partners, resolve = monitor.=20 Affects sp release important disable.
Containing considered, they, anywhere. = Michael,=20 arrington techcrunch doing keynotes im. Suggests explained herethis = potential=20 phishers, others attempt.
 
 
 
3D"automatic"
------=_NextPart_001_000A_01C75E67.469B6520-- ------=_NextPart_000_0009_01C75E67.469B6520 Content-Type: image/gif; name="conference event.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c75e24$38782520$0d6e02dd@7B743964AC1E44B> R0lGODlhSALYAocAAAAEAHcACwCBAIlzAwAHdn4DdA52ebW+w87Vtq/H8D8bBm0VAHQnAJckAcMi ANUcAABFCCY3CkA7B1E3DXhKAJ89AMFADuNCAA1SACFkADdmAGZqCIVlAJtfALtfCNRYAAB6DRN3 BEKOAFJxAIJ3AJiJALl9B96GAwCqAByUADyqAG6gAHunAKWrB7iqANOVDAC7ByvIAEG4AWjEAHW1 BqO/AMjGANvEAADkABvhA0HXAWbXCIHuDZzfAMHeBdLpDgUMRx0JQz8NTmYMM4EHO5YANLcONN8A MQAgMSAZNzIuSFUsTIgZPZchOb0STuIuPAM1RSFKPjU8NGBJSXszP5ZBRbY2S+c5RgBSOi1cPUFr NVtuSoBnAKFqPMNYNNdqRAB3TB94NDd7M1VzOneCTJmBNLGBNNOARQCjNB2lO0GRQ1quOnuRQZOp M7OdROSkRADGMyCyRTXOO1fKR4y7R5u2P8O/TejHRwDlRBrnOk3jM1rsTXHdQKLjP77dQdXaOQsA ghIAfEEAh1oAh34AiZsFcccAcuoAhgAVfBoVjUgue1wTeX8ei6oWg8EbfucrfgBHdxQ/dUpCgVw0 d3NOfZNFgMZJhddKdgBkeh1Ygj9UeFtegXJUgZ1Xg7RggOVWhwWBgx6Igkd8hGp/cnlzh5F0grKG h9h+fwCohR+ig0elgl6aenqTdZ2cc7eVhuSbegazjhXNhE2xfFa2dXK/fpO7jcjJjurIeQDjfxri iEnnfFvog3nSgpnbf8vWhdPchAAKwCELxkEAyVEAzIcAuqIAybsAx+gAwwAoshctvjkkyGcdvX4V wqkkusYWy+ElvwdHsi5GzUU6xl9JvnhExao1s8lEvNc4wQBswS5gzEFntVxoxolVuaRSv7pRxu5m vgV5wiSIxDN8w2SFso57tZZ1yMh1suZ9sguSxSecyjmYtWSstHOryZ2cxs2pvtKesQDMyB3Gw0TI ymfNtXLIzaLNuf/s/aqcrIyDdP8MAADxC//wCQAA//gG/wD//P3x9yH5BAAdpEkALAAAAABIAtgC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKBXaW8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKtZmyqNGjSJMqvTi0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOyXMq2rdu3cOPKZaq2rt27ePPq3cu3r1++cwMLHky4sOHDSf8qXsy4sePHkCNLnowW seXLmDNr3sz5KOXPoFd2Hk26tNvQqFOr3mq6tevXsGPLnk27tu3btFfr3s27t+/fwIMLj4m7uPHj yJOnHM68eV7l0KNLn069uvWTzrNr3869u/fvUq+L/x9Pvrx5i+DTM0evHu/59/AhOmbfnnj8+/hF jv3nlX79/wAGyBNb9vinVX4ImiTggv1V1CBFDLqU4IQU8vfgRBeOFOGGHIJmIWAOdmWgZBWW+F6B DAkggEEC5KTii1+NiJWJNNbo0H40vaijPTqyuGJBKgoUpEsqtlQkkS3GGCJXMnbo5G4EoqjQi0Du qCOMPCYp4UBBcvkjQV0aeWWWLx0p4pKs2ahmbXoVaaabVX75T5cFiWknkqJV6aWcc67I0o41mZkm hAdi9OShYEX505stHiloS3t+SaeXApWpJaArFSnkj5MiJOijZJbV5E2eIWrqgG1RBaqdjFqaJ5iS Uv9Jaag4Tdppnwj9OSaobmYY0U+lnsrhaIFqCZOblxqbqbK6Ntsqrg9huayrMOm5KZ9BPorsmM2e SWhPwQo7XJQi3VrplclSq66jSSLrYqOx+pjrnVl+Cq+e5uIKKLq2Sjsohj6FK+7AOKUoJ50Ic8on tOum6y66Mrk7LZ7VwhqpxXPeueqRCd2KMKyyguwvVCABaxTBoqaqKrdZYuzxwptSerG2zC6LKa81 N0wruzKbG2ZMNIvZ88EwdxzvQCafHLDSKAtFLpo72Wszlj1aC+2eV2dtdboU58g1uxMzynLV8soM 68ShrjplrNgqXPTZSxeV9JqnPTaqTe3uyqyjZpf/HbPWgCPd7c7w/on2ql0PTquuf0Nr7kxia+k4 2QeF7OnRH5K61NwoNU3Z3cWOnHiXLzeUsMiR0gu5slJT3OrUHF9Oeshp5x0x5VZn7TO/Qr5llcBQ 1g3itzzlvS/Lr17daciU50vQ4ovjHHbO0LNqO8ez9w034kEHjnGkRff7Nkm+KrgYaX6BHjqM0jP+ /fta9xsn7KvfXvv0aFffcuMXz4q44vvbHeriVLUrJcZbdFPJWpi2F/XVD0nHM2DulEc07/3NUsdz lu0AmD+p0cx58Hud6vgGv78tT4JxKV9JhuK7uC2nLw58l48sNzn+Oe904ttg/hTnQdaJTl3L0h7Z /xCmusFpynuls4wKybfAAyavIAEIwECiOEUpcg47MISaTsw2O9y9L1ttU1gJcYWihHnxf0UUIZlE eDq/DWljEDvj+DazxF/hJYosweNK8AhFKVYxioD0Y+Z2Ajz3aDEnuQNj2droNwr2DYQh1OG01Mgu br3uhidkH8Rogps6vpAmerSHHkPZElLmMQAv+Ucg/UhFgrRScOBiYAMPWSvwra1wHTRW7NaGrzAy j2g7xJ+uhrgiHMbpRi7MzXyeFxM8BlKUqHyJKfcYzVNGc5TVpGYqBbJKbgbSldNEpCyfQ8ubyO+R PyoWnk44NJfBDIWD1N+xKAVJQyVzNk0cDBW/+f9Ka2ZTm6X8J0BP2cxrGnSgzhSkN7t5kCuab3gA s49F2Ek4jSVLjPICYT0rdc+HogpBWzoIPwFpkH0q1JvgjCc0XRLOlh4UoC6diUIYulCHrpCF8uno SbLHxbHVDGw8amTJdMrEWCJFL8985gJNWlKFvrKPUK1TTFeKUIGG0ybYZClJ/3hSg9i0qB+NaFiR gq7Gka6IMh2nOOVG1JwmipkwSSogtarUgNpVpKvcakrxqkqnWpGqduVJVgNLUMDGlZVdpelVNcdW o4qVkEYp60O+qqG26seycnnlU/kTSlOS8qqetWpXF6pXzSZ2tLA87EBXu1hpvrSwVN2sSWnaV4H/ rvWTY7XjbS9D2cs6tnNPFIxpo4rSvaJUtYSFrVYLS9LNFlciTO1jckH5WsOuNLTWZa5zaztSjv4W i98dT29DMt6GnMUiT5XtSYfbV+JWsaDaze5qAzpT2rb3uQyZ61znG9vATpW6qk2pYvNa3o8UWDoH 7ojJIoPe0q73tHtt5XA/W13X2raz2Zywfbn6zftGuJqDXW5NQAtigxZ3u6RFbF69mWCOtDg5L9YI WbyKQOgOWK/3ZS+KUytiw2K4x3RlqHMljFgOm3a/yFXtj2Mr0BM/uI9C3jGPt6jWgp0Is52ssY05 TBEiS5e1tr3uKvnb2edKeYoIyeuDM/zS/yaZ/5p4xXGaO+xhC7WWsbiF7HlibOCQ5jkrH6EtndnL VwJbl8IUxupopaxeJ3dTvsqVb4hTqeNGD1LNFeazPcMrnuA21mlV/l1FiCznqHrZw0NO9IgvHGZo rpnQVVyIepPs0n8mVNVzdm9fqTlm+GK5z5yWjXMKeZWLnJq7i36ye5E8XYKmF8K6biqUO/zsprrW 1WyeCXbpW+eEzLbCiNY0XYKNn/SFuioNbiq1V8xXaXO2xNfWqqyVvWxoC1iK7PV1pCfta3fH2skB ZbaaxR1DiRqnYgTRhsIXro1/KJzGEAUukwLdTUun2tratnWyjfvvezu5vrrm95unG2JUF9nUI/// LMHLSZTWvEThMIE5SxbucIbTvOY39+4sP12odG+X3X7N3LaBPM2Laxjk4FSzkVHL7PkmNN5LLmyu jWtoMt/ZyjynshMhVZCHH8TrC3eJzGeujZWM3eZeFwjYGz6Qsmcx6zMa9YZTrfFIK3fSdZVSx/Gb Y9TOtFLYLfprh57y15pc3f2EdHjOHfc6id3tMQ+7QdKudrbXvPIykfnY7YF2yyec4Qk3N9yLLXdB btiVsA2tbffe7WM/hNQrTnVVgRxvZ4vW6gDlu3m1rFtPVt7mXbf844dvdrdTPviV/3xNNA/5zv8e +JdX6V2IHZWN5F3wGae96x2y/eh+WPdPrb3/NrGf3ahffZvEO1BYGnJ85H/d89GP/uaHH3ayMyTt a5/J/GXedrZDP/46pxfU13JZR3hMBmDWxHfet1Ap1m5zpnThd4BEl2lUUXA7l3wIAXqTB39r13// 13mWN3+RR3bFpxDH53UkyHnGt4KQVyCUh3YJIXoWCGqNVXUBV1fbhmGmh28b521PdnHdVmcipxYz WH0N1RIiWHxK6H4e+ILw14QaiHNR+Hn9h3mZ14Iq+CodmHxRmIVK2HJOmHNSiIWeNi+/tmlv9WlD 12vxBWT+hlJACIQf13sCuH7394QAuH9YCHOb137PF4V+6H74B4NUWIgpeHZlx3BrsYW714cr/5iC Kvh+wBeIdKh1j0VOaghvzUZyhgdr+LV9lcV7Eudnf9hw7ceBqIiBNTeCaGd/C/F/ALiBTIiBg3h5 KMh8VuaEVRh/VziCUvJwH0iILFcTRSgWwLOGbFh+8KZ7c8EYZsgTnneCIRiC70eL/keGL5eILUiJ sSiN1viN8SeMDaWIX+iFY5cQgfhwX4iLXsh1Y1iKjHiJu1WJhlQUGoeDeUduCQRx0Ah9W4h/d6iK SQiJX7iLwViF6YiHXDiNBkmOvhh54XiNqig47EiQKuiP3IiGeDZuF9g55+cUA0h6KtMTsLiL4WiC T4iC5qiNBDmFhbiBpsiQEZlwkuiS9beOj/+Yjfyoh5F3k8RxkLOoRG/3Z43HWwZnGD9Rkn5Ic7Uo f6iIje34eIA4hRkZi0H5jzDok9lIfMQ3kBd5iDwZXCVplYchg6PYcyGpj3KRlNHIkKcYky+JfGAZ lZuXgQqJc8GXc2/5ik+5leWIhDzpkFH5ixI5i7A4lncZGGYJXsMilCR5jS4Zl1hpktI3kJoXlxOZ mbJIhRqoi8G3lYKZhF5Zjk7ZkJ83lZupGYvpURtilEbFiIMohpgpkM1HhiKYkd6Ymla5l8Aok5kz mg6JiDhJgg2ZijCZkJyxmpOVhvyoGq4JjXYJerm5l88zmoMJcxsImDqJfJMZlNzJdu3IjhX/SYKh iYXg6J0YOZaYoZx0FDyIYTK9WZNgp530aZF/eZu2yZJKeI6ayZm+2YFNqZ3l+ZD4CZiFWZV/eJqe +Z7ZkZYkUhhDIY6aWaB/iYRduY1aOZgGWn9OSXbkyH8ICZeZWY56KJx+KVOw+Z9UiZrtqZYOKhMv ChkxykkRMZWy2XWQWKIneqLM55PCWaDiSYYzGaLJ95C9uKMr6YIyGY/FQYTDSKOjFxozin4TsaLZ yZVJOpeOSJ75GZ76eaH094jy+ZZdCqbDmaXuqEyTUYz5dJapMaWkaEeteJ85aaImeqbFJ5qCeZE3 aZlQ6YroKZFnOp5BQSO+p0AuCmyrAadp/yoRtZmnJdqne6in1/mofkoTlGqmpbmpjjdxRAloQ+Wp 8oh1n+ohjAelVVqf9ommW3qp+oeNFDqnfPqoVCoRh/qMoio8/2KrZ6hg7lmqBFiltLqlX4mmMZGp OfqlGmqdejaq6GaooohMieoRvMGobVqjjrinJJqTdGl8qlqhzMmrQwkdt4qrluimqGGtZegQ5amV Fcms55N+u5og5XqE0+qruqGuemerhKqhnrOv+xiD0bp79+pivwqsxPikHRKwoZir9Eiq1Noc+sqm vsGwijmwDCFu9TGxCvsUFmsj9dqc5/qw3MGx8rpMH8smGLsQGtseJluWU5GyBNuoELqyiP+aW26V Hta6dWZhsSsXpc96shBLstsBtALis706kjErsGgprjrrrCLJtIvKsD+LsKjqtE1LtP/asvlaIyTj mDi7nA6bs1vbFBT7F/ERsooSttI6r2RbtjQItZ+DHJgIswXbqW4rtkW5luOqtWt6G+x5sXcLV3nb tvVIXn37tukKuIk7GFxbuDebFvqqtoTrnIwbcTU7uFMWtM2YtBsRuBl7sPjUuILxuIcbqmzbsALY sW0Kui5HuoKbulIruaeaVkZLu7dbGfh6tTN7tpSrFNrxsug6fbV7Xqzrscc7Y+ZhF8LLmKubu7or tKImvXUxvBFyVJ4rY7DrWx3pt4tHvU7/mrnBW7xH6bx1a73Vm7xmq76/mxGm0ryseb7me7rea4Tg K6OGKyzwe1NxO7PNir7hK7dLe7+uG7n6S74IZ7W2K8ALDMC4y8D2SxoAMMEUPLKK+74IXKvzO7QX vJEbzLzsm70nQcECMcERMcGaG4AHDL3lG7/z2MHB6sDRC8E0+8EtYcIVgcNYyxIUjMItrLfisr9g 9b/1+8NDLL+hmxY+HBM9vBI9DABODAAcgcM6jLdEDMNPIsRH/MJAbMH82x0MYcJMDMU+/MRRXME3 jMb28MQIocNV7L483MQJS8ALm8Fx6sIc3MVcvMXfGxdvPBBULMX/YMKBTMZQHMWIvMYo/7zEaRzH afzHEhHI+XsTUOy7LmvHNfzFV6zHeczHMDoXkDzIgizJBOHGo3zKJXzKMLHErGzIj+wSagwpoYy4 KSx9iKLF3LvJk9zJthHKpPzGppzKwizKw1wQpEzMqezIrazIq3zILyHHijzLquvFuwzGDFrLZ5vN o9HDyPzLggzI3+zNwwzJbAzO4/zN5ozMpezMsHzIZSzHZkwTh2ytlRzCFQu2ujzNe+y/AdwQVfzE UgzMqHzOBG0QhIzO4mzM3GzQ6LzOBP3OiSwTzhzLjbzGdxzJDyHIpvsdz5nPuUzNLcTLYSzQwazO Dq3OCb3ODX3SDF3Q6SzNg1zCTrzKM/9t0YkMzRGNyIA8uzZtzFjMwwm8w97R0SD90bzLt9is0Oks ytyc0H/sywMt0MXcxiWcEOEMzlIM1DVt0xM90/HMzI+s0Te8z6Vsr7LLspd8zWcNHyu30Knsyyed 0i5N1VO908Ds01Ud03mNzlpd011d01hdyAeR1TbBztf60w1cxOuBz0Vtxf1sw3M8EQCt0uHc0MdM 1zut1D6N0Jkd0Fdt0Jmt15ytc39t040c0Ao9yqFtyzE8E4YNFJbctWod2TK8viwc1JHs1ia913ld 1rzd259916Bd1W7s23it18jd2WSs1e681dFs1U/N2o+N2BJrIu3LkYT01NIM1art28H/3dmhXdl4 vdXG/dne/duindyE/dpcva9Nndqrzchewd6JTd2LXSLXjR7yDdafbBG6TcJYXd7gHdpjvdWv7c7o fcqjndzAPdyEPODI3d0xHd0PLt1QUdqNbcBDbd02qxAwba7itNIZrdKULeLmvdKj7NfMbeAAftwo /tsnHt7CjOKeHeHFDdx8vRMYfhUizsn3zRk9jr1M8uG+St9HLdkk7uAJvuQS3ddAnd4RLuMwruRQ XuXdbeLETeMVbOQPLNQMts0eEeT6HLUUIeY8TdYLIeEkjNoNzuBR7tPtbdqlPc8STuVqbtdtjtdU PNh2bdlBzuU87tFoDcJy0eJpHuZE/x13Zh6xtczdDH7lef7ZcU7T7f3mE57ldG3e5X3nbn7pAY7p CC0UgI68dAwazb3Gu63bnX7CF7Hoqz25IqyRGe7hOM7mCG3rVs3bcg7U7vza593bAr7kLt7mB/3m Nc7SEDfqKVPqnhTcp77rBY7qwC7VwI7kKju2eOzBmM3nmS7skQ5Xz87eEw3e5DzcUM7pe47eZW3o a77pBazCY/HX3/3qEz7nBq7itT7SV4btjn3YPg7LuH3Cwv3W3V7twM3cRu7MUg7pwq7p007uv+7q IN6zjCfvK+7kXo3qMW7s/GHxrl0gt47lnu7f1969em7Wgu7PeR7sVm7ufX3q4Q7yEP/+4jPf8Jic 8kUR3Bfv3Bm/3F7d1a284IcO7eKOyBtv0i0u8SWh9LXNFfu9rvyM5rSe74MN4PN+50SP8T3d8lW+ 2+J75J4cx8s97wYv2nJu2PLt847s2hW+6r896TCv4uWc9CjN9BDB9HZ/8+Gq2Bpc5jeO7gMe3RYS 8znt78TSFxON0wgf7N9t2lpf4Iz89HEe5YAvOPbOzDDfxntO5G5/cGBv4X3s5dp+9+HN5prN6V4/ yLGe7RVIw5Qu9q/s11Ru3B0P8M987xlv0bHsw99+7jJ9+1yt9oa+6UKfQNc9Xn9uyqYf8nm/uSKt mmt95jnR6zvu+I/O7eHM64X/8tz/7/g6Pey+X/vA7/HfTe1L0fyJTuZ+a+Qqr6s4D/oo6/qUTtE7 v+AOr9GXT98HvvNe3emVDxAA7A0UaA9AwYIGCQ60988hgH8HIzp8eJChQIgUNW7kyJDjR5AcM4Yk WdLkSZQlGa5k2dLlS5gDS478GPPiy5Q5de78Z9MjT6AUfQ4lWjRm0J5GWSZUeNEiwacNR059CJLp QqxXLV692dSrRIoZqU6s6tCpQYxYm25dinAlV6Usyc5FWrdjS7tA48Y8CBdvSJo198rMW/juYMR6 ES9eXHcx075dnRbcODbwyJdu1arVvFZyQ7Jiy4YO2zXtZ9NoMz+NvHnoycAmYx/e/2tYJ2OYfn8q Hmzb92/gGnEPV4qUONS0XPvOFj36YeqsqD1Pp96cNF2NCDtLThgZo9buqn36BRzcbGLzJI8XD9r4 5Pqi6YHDp+/SOPzuUSOHHd0c7HnNOhNwIf1cu6g/kfh7DirOFooIIri8Ww45vnxSz6b7epMPpPpe a8/DDTeySbcQfevwRNB4e6xBBpkqyz8Fp2KwrdxYfIs7Ba+7LjbrxororfA4iwpFmKx6D70ShSMS pyRvq5C+JgtbEsoPi1Iuq7D+syzH/0SykTswoyuQsOwSRPBFNNNsqbUZFRpyRQPtq7K2KM+b8s6h dGNMT+S0q9MuPI/TiabHsrysvP+5eOQyzDf1HDJIg5yriqbZYrT0wR8pnGzTNaWDL0M66yTqzxHF 89QoPoP8DshGlxPoT8cC3esqUF1y9MzKuvSxx9FqtHE7Tc8iM1FJd7wURgAnXBVIWf9SMa4Nmx1v wFbdevS0zGwN06sb12QTMrlgnbM+Noeb6cLBdjU0R0SJXfBKbg1UtVPCtiyzXbDslZaxWtkzad8n o2NRu6/a1JbegqWLELp4T8VQ3GcFVcnXIsf1d112+zJr3obhpQ41SK8N110dK3US4FB5QhkxcBPm eDvd/Aq5W5ppDnBKPneD+OSUK/sXSZXR0/jMoe3k+OOEQT7YZVNTjHLlnjmEeqn/bo8GtuWl23q0 5jjnzXnlr4fdOSX3Ijaq37PXFUtL4SB1beGBwx6V1KnrPvfM6t7meu+sZkbYZoOXLrfPDuGWeOyc yg5aQ56F1vLxwLYdEGVY68ZzQiBLlpRSiqk2bXBPMW/6YGBdLjc/yGTOeriwRW+8cqB3sjw+XKfq cva5RcUdt9ST87ZoMy8VGGvDb3I0zoEZTX4y8FoDnT6sR5eeONgZX3z3is3GfiX5tidXYdE1VhfX pDpG/ivDJ0fa74aTzq15OD8ufcQ3p4c2ce4tTlt7752WvX85Ic4wrJPbZoh3umL5qG2eA1zS8mM8 t6UvdMvzTP3o1bLolcqAbwOP/8NkhTba8c97IARgh8oXNfy170Sly6BUfPbC0GyrbwxsH/sYtSjx HG+D3CqgDK1GoIABkIQgul4JxdY4Iz5MfyEs4uWCxSrIkE9zmUKeDSnYHSlmKTtV49t4PgMzMbHO g9gbIhH/l8QjpjB7AkyP4s5YuNVU7VpYZBeXSsNA9alvb69KU7GUxKqagbFFPaQYIdEYwCbuL5FC ZON5GokSNyLxb8dxVdZa88J82dF9XeMiyPZjJOeIZY8aXBYUsYWzbNFodmVU4iIPabdH/sx6oBQM 1NhCIbeQrI53lN+svkiQewWzJgSrIfNUSTULetFbnjMkGZeYO1eai27NiqUsO/83smiyLE/gEx1o KOXHPyIMg1wjplx4FTyIUFBYqdNbJWnYQhVu83yrfKYZJTk1VsYzdtWkzf3410yi1C+Z+bPjpewU r9NEKIskO2cw0zmdCKZyh5zy5Sv3qUZ/PjKSGEXVRvkplItiR2q2FKhWNtdHoegRTGjqUkF31VJC /TJ0bJkjFC0qrXx+cCa6wkxIUeKq+a3noyHRGjTfKCuBCsucC6XKDCX6KggdCoZT/aaXWsQwv5Uy cDelpkb9dy97Pch2L82Ie6Q6sa4OtZ+ItA3ANCNShmaxqUnVCkHpUlUYIktHVCTm0bi6O91dU1Vp CqtoeGqypNTVQiRB7Orqo1b/Nu6rPy0lmkHxesLoKfSkKC0srv76WWnyJTxjUliDMGWsu/EHpj29 JjZ3OVJ9fgqyApTs0M5aKaniVmkCA2YfGxor0H5WNhURkciwqs6jXOaczJGIqyoS0y4GELGwpWGf BmrP2U5Tp8A77UcU6C7O8VaP1QtuGrsnT0htdooh+5pi80amhiqQbeCUyBjZKkxJtTa2TKRldoMj 2QQ297nztdftfHre8pZtNb1j2BV7i53pIjQ1FvSYqpCF29oddosSRc2gwgm9NfpXu4GyrBanS7YD t9GETzPvT1FnM9Iqljy3Ja6IlOpAeanQRb7lsXIpG7mO6sw3zuWPR0VcIicK/zlJRkYwk0Z8sZ1Y 2G3V/eERxxfDojr2vYqNa66KFtWMAc+s3hUpZQdsqKEx+chNliduyJtREwFYhIvVi3tfXMgbYpLM IH2vqXzHw0kS98pjhRB+18XJhQVvr3lp5ZrFBeS0sniWkU0xWlGIYrRklsK8tVmJwQohmfJtcuOc lKFJQ2TVkvlv83N0qxlr5nqi6M3OErGaLQ3nQcXYVlvb5FszpujEXrCTEBWcN63y4z2z9D+2dnWz GS3nOOP0yYo8KpRPdudMM0uQXEtgKKsyvGKf75QKUfTaXlu77AC0xc5mN6CkjTjqTZu/1aY2z9wp amFDJ1EYLkukQFnVd04Unf8uPbZhwztppJy43dktr40j3SRmE7XSjBVn+Cz+VJmYzDpwFSu/T2g8 N+HITOamisY3PpHGKNzDwF44P48CcbvSe0qzrjdHa062KQMyqCGnWX9NnepCT6qsHikwU31L6Fwl /UfNHHjLnf7xJTk8ukuJ9YloPm+bM1HlvISilzfGLBl+tdBBf1DMwyp0RU0Wr53dN4xWy+cvOfnp DCdxamfiS6A8NMlXN6q9rf3zT3sXpqQjnjg5mEYw45ftzAk8eL0sYF1xHddzp3zB82XmrZcpXcaW uQYj3lZ+gRNdWo55SjBfxzQ30L277lQUlf3aqrI9r8vtbrpLztpLV370M0//7Xcn8mMecdf0UL/5 q68r66q3GeuYVsqr9im+MoOuyqar7oPXC/uCotahNaZU5g86ed1HG/HZ1+Jd/Tj22gNvOcCdJBD9 PdV0w33z4Ifku7NpdcGfXJTi/dWwJ5fX7PO4+BK93/i8Jas7+es/qvO02XM8dPs95Rq+BBm6Y+qk 8kMxdcu9I3m4e1qS9cOY59ow/lsLCYq7ZKM9AmwkA2y1K+M6a1EdwjIo8EJBkWiuD0w1Mku7b0Ma +rnBc6MinZoz/BNC/dK6DJuLBuo1w3OZ2tM9IwtCfNml2EOssrKzHbq+81sosRq5cvO2n9KxGgm+ DYTCziOSoMjA5tOZQRuw/yW0sIlrue0pt9N7QADcPvPriVFTGPLzmbXrwjuEDbjSuK9rMLnzuQ/D k6xDRI6rvyALvRq8MvsSqvAzj/XgLuGTorNbPCkMu6rxQmHaOO9jvP4CxVsjva9KREeUOA4kQjTk HVgrxTvxKkU8xFgMvqBDNRRENi3EMqBaPYQAvPx7PB3cK9x6xR8slJVbQalDwJ2CNDTKKSppNlor Q1mLL7ILwPLwuF8DwuaBi9/7RKryRLAKRgiEvw5cQmi8L1REPiLEnXSUxFqKxWX8O+ZbIbyAvkC8 xAeUr8TRIy4jxqYbx9O6PaGLv4RTEGWkxeVjRDI8xzhMvld6R9dyyKkLKP8l0yWYSsE948d74bQK AzYZaYrQILuTez1h/EaIdA0pbKw3pK5ZvD/AeqadScgELD5zJD7PM6tQREkvHJ/L6g/WczBi6xru O8FrbMKCjDIba5QqOkOa/D5mpEZnmsmJXMdGc8jnOcV6vBzgm69Sk8E9FMiS2Yxy9K64+xWwHEiD PBRU28Ys3DyNjEf6G8OopMi6DCwNtKa51Et6ZMi4AKgaBAwB20hPi0BE8T2GOksL4zHJ4zxx7Lh6 zECJLD2rXLF2HCHQQ7ittEm+5My7e7gv4xLbqkM9y8LKmkMsQ5/VCyR8G7vue029I8PMe0qcjLol grlpPEDN9Mu+pMve7Mz/mTvKLSRM05zBKCxLKbyLzBIcbMkjzku8C6xJ3rtMddzM6ZzHQ+I77LLO vqvMNUoio6usbnsRRTmrcMQ+cPPIz0GuEIzOL4M2qXw56ozJtZJHvNxLWFxI30wwJ7tEnyQfbfxJ TJTBKlQneHkZMSEr1cK9u+TO7eTNVWS/Bo2WlpTL38xP/mwL9dLGRdvDTCzMTVQ9ZjquHOoTmHys lKzOCZU327zPC929F1XFDH0fwzzBOuxDB8zHBTXIivC/5TGkyZSm+XxJuotQCt3N/dRP4GSkvHvE kbykXBREpBQ9GmTQFV1SM6zPIcROJa0m+NTNvMTQB4VQJuWJPBo3f/st/wgD0cf0zmg80akcINrU TnaUtGdMUVgarhoEpGD5JCxcUzu9UlicRBj1zFj6UiSLSDxFUUMELmxbzJL0UvuTTstktzll0Sx1 0RIKUispxCTJuauELNlK1OqsvEvV1OvEzTsVoaxMRVXFz0PNTUylM0KtzTF1uVGVVPm00C2VUCIF U1gl1VSVkgq11GKFt2OVxmR9NiNlsxjVVVkNkVP1r2l91Wdtt2q1S0YN1L+b0Gx101KlvG/lVEOF w2V1t2Z1VkGF03BVMSSdu3El02ENv3hN0hatVUo8V3QNU6erVyx1M3wVU1q1VvvE1DXzV4ENVSf0 VEp714D9V4U9UkV1yf9yVUF9JdeHPTJXzVhwjVaJXbci5VdZFNkCbMl2dVCGVStE5Vh7vVWWHVLK VNmLXdR4g9mLlNl0fVlenbc8pdaZRdXulNZJ1daUHaqV1VkZbUguDVqj/VlurVjxW9ekvVbaGtqH /VU5ddhY1dqRDdaSzdlC7dKtVVqNxadZjdiPQtj/ctr43FZ29di0tVqgfdOdZVp1Fdux9dqGJdmo xVqURVtcBduAVduphdqq5VrvxNizrdS2Ldq4FVx8JVyKxVuLRdy6ddmwtdu1IlfalNy+ZVuIPVjQ 7diqxFm+1VLNTVjGJdpcbdyTzduGK1vLzczTRdbZpVTKvdw6dV14fNv/0jXVOA1ZvaXd4bVdx7XV 3WXd3uXdw/HdmG3aDBXd2yXW6XW1o23Z5CXdmnXemx2bGQVcaC1e6q1dZYVc3e1V5W1e5i3Y9f0r 6SVfZoXfVgMYztVXaPNbhUzdzP1erTRd8Y3f/51fuZXXTOVeuIUVfkjgBNYIBV7gpcXcwuVfkA1f qs1a+f1XOkVf7RXS63kkB3bgfwBhEHaID+YHBm7g893V9uWq9w1gX+3e8XXh+q1eqGRfNhphisDh ES7hEyZhE94IEf7hHh7hzpXg1+3aCobYCV5bGn7hef1bdywJBeYIHA5hIbZiH+5hLAZiIZ5iLd7h K+ZiFF7gIjbi333c/wv2XNSF4K8lWwIGmCreYi22YhP24iyWYx/uYjuWYx4GiSreYzy+4zwuYzOG 4cBN49GF4hADVvx1V5hIYJeAZJaQZHtoYBS+YzD24ksW5AUG5BwO4zzmYiq+4k4G5RO+ZEpG5EI2 ZAo23AceWEZ25RhO5MldiVRmiFuuZH7AZUumZEue5F3m4SAmZU/+5I/Y5EDG4z4e5WMO40wGY0Je 5RZOYtyFZWGVYZolklzWZWDmZV1uYG9uiV4eCEku513m5V0miV7OYmIWYz0W5DkW5TkO4lEu5v21 ZkVOsGmW5WrG54+l5sU9Z3I+Z18WaG4e54GOZIJeaG++5W1+5GAmaP9jNmZ6TmaLDuRlhueLduQz nmUz3ufcXWN/vtvcmZ1fRmeHZmhuXmlbNmhITmVwDueieGmBVumELmhkPmU71uE6BmWeRtp8jt1a s19a3kAkNgpzTuhubmiD/uaWVgqaZmqULmioXmh6/mNnzmqg/lwjBmn9jeCvvuFeXudsvummZmm0 FmeXtulvrmm3VuqZVulfzuWUluet9t5VZmXY5ecaDiEbDomxDuyxnmFgjum0VmC4XumHhujEPuiz TmmfYuO7tlkWll1VjmKgEGzNtuc3JoqkDufFRmuqfmrIXupVnez5yOslPmq/fuIUXuSc2OzNJuyW NuzDtultLu3vRe3/fFVt6TXXJpZtzZ5hnH5o3VZd/uRtJs5rqrzXVg5pdxZuSybXs4bu/N3eV9bg FBXpjn7urp4t627uC5buwKZtgEZe8L3n7A3q5QVv1QaNv86/Vj3eQ3Zh8h7sst7YDV7tWi7gznZu 935v6OEjY+zvka7v8xZskvbv9H1e7BXw9Gbt+G7j99HvoB4Sr5bsw3XjBz9g9oZwB0dwbC4MsNg1 /QAqCy84kDq+I67cC36zBtdrCQfxCLdYAYK1yxswzLk3wsm0AsKcGtvv/kXjEffZJs5gGm9x3cNx c8MUG+Q+2xnI5mqTkjIuvsbJD8jyLIdt421vJ1Zy4j1vJE/y7s4u/yaHcidv8hyXckGL8qSrr6bZ cRTfqCx3iDqf3C2vca4GcCGfNXol8yv/jTNn8ydnc0Nf80JXujVPcx0/nRM3ijzH5ztX75XQ8i0f c7qNcf5WbiGv7H82cTQn9MRDdDUv9SklMFNn9McxdJeM9JawdJhwdfrWiDuXdTHP72i+dU5/bczm 6GmxqUFSjUNPdcg5tjIh9TYfdqCYdI6o8zq3B0v/gIGIdpaA9VaadGanRmov89Q2X+5W4V3fVw63 YA/sJhRnjbEydtsL9Se/PH00iWyniFr/ADu39Hqnd2yn93949m1/dWmfdmkHjnnndTAn90ZWYi4P d8o+eIJfpj2RGf/lIHYwc3elO4l4r3eM33d81/d8z/h53/iP6HiGsHaA//eRv3iN9/VAx3WiPnKF Fw6hvXIWp5/mQx0JUQ10D3WL1/dm53if34iOT3mhH/iez3iM73ikfwlbL3mef1pwX1y31fQhV27X Bus88T4+m3lKmu8AYnaiJ3p55/mv/3mhB3p7D3uPb/q0L/qQ5/iT13KmN/kQR+3rRfhZ71c+Nw+t /4sCb/j6iHa5B3xoV3uwH3ujp3WQR/uhV3uNP3vEB4mx1/K1z+6n3/W6R+67f3mI2aoDx3z4kPvB h/tKF/3Fb3ujN3yzZ3zFZ/uBR32PDm9JyvD1/u+E1/wNd2GAyfP/pY/0S0f9rzd94Af7ted2u39x yq99Ea/64vdwvO7Bvsf7JkYZwQ/9wHf81S997Ff8eM/1lV94R7t8Sqcc07u4Cp/6p+P+3O936geN bHd9xfV+qM/8vZVaA8funYoyK+1+I7/sZpH1fgeIDx/sEfxn8CDChAoXMmRI8CHEiBILNqxocCLG iRY3cnSY8SPFjiJHkrwI8iRKjSVXigQAoKRLlgkfuqwJAKXMnDpzpsTIs2dPgUCH7mQ5NOLPoyGL jlT6kClUjk6XRp3Z06W9hDEP1uT68t/XnFubSsR6siraqlOzyswodC3cjGmlTk2qdO7GtXjxxsXZ 8mVEs/awmiU8/xbsWJthER4Wu7ghzZtA91JeqZehQIt9N/es7NGp3aOeF14ebRrmY8QGGyOOCdEw QcUSVStM/LVr7dQVWWvGqOr3b4LAg58uThrjW7ltOTP/aNwk6OXRjZe23FxlR9ZbteNeffs7bYSx ZQ+WXH68Yq/dvR/mXfK3Qfj/5AcXPjzicOBUn5+uXvI6gEg95x9JBI4WIIIfYaUVeAyGl553I233 km2tFQbbeON5FeFK8iVEnyoHgbiQh/9kVN9EJfLXX13SJdgcfwaKJOOK/Ln2mmQXZmjbY+4xNOGD FArJIW0TRpbhWQqpGF+I8zXppIhPRrnRklPqZ09+CGVZY4wQmf/2IoAr0kjXdP+BuROPYW135Hlt YseYmu0NCSSHdIbXkUQo4qcKlnxOyaSSUjJUJZSAFurhiFFuqeVwXDrKIpjMdVmmmXdVZilLcVbY kHlultepYUXGWeeoORGaX4j2PaSnql4GOqighiL65JKnNplooY/qWmOkMA7YonW9CuuYTbnBiVib OiK5oKgdxmroobc+q2KefKZo7VK4zvoqidLK+uyuak0WLpnCxjWpaJSZ29duuh1rYY/dJdspSIzC +ieq9zYEnL7Q9fnvqtjWZ2+33wLcGbl7jZmwv+sCyzB1DoMk2Jsr+VgRRHrWt7G1UJaIa8H9frgo yAH7Zi3HhPb/RinERZ3b8mcSszyjzEkadR3FvhaVL5P8XsSxyQc/BW3I3Ebrs9EjI31lujfPDLOJ EkN9XM1N8+VwaDhWrZxM2/a8ZNAnZ/xntLnOR/bIgYKb18OVYjr1QTLDbdXWdW+dtd316qSyovcB jCLQ9hFNMKMqO+ei1W4nDrfcc8f9dHGK3Zh3SnhT7pPZJC2aK6Kttspqn5mXuzhZkI9OlOMND5u6 3TmztRBvW11eOeKzY87S5iAz6Tnt4vWq0O9s6+x445AiyBFrR5llue0COt387aauHTP01UeauurB Y0+kTGNNJfmGK1vvfLDjuxqx+emHiT3W6p4keWTdybmexcp6/xq94kflk8+6zFePrvoCyC72CVBr ZbEJm+b1lGJtykGwc5fvTJeX/QXQf9ADoN4iWEABbo9LsbuJYOx3IRCSMIFH+pGmFgPB0/Vkfy7c H0JgyBD+FdCCzYva24y3QfV1UHwZcV15jBUk7yyrhAf8YY6SiJ75hY8pL5SICzHyQhn+Y4pUpFsF a7fD62lxi/9jGEqA6DoRJpFUd9oQRpSloxAaEYgyeeFCrhhDGtqDgnWk4+Gex8MuevF4fOwjIJsj RnopsIhI+lQab4JCM64mMEoMkAvjmI8ZTtIgMpQj9VAnPEDasHc04+AfAynKiRGSjQiMzSFrkkgk GjIy6rlY9v9aGMWI2BGKlaxiJa2YllFq8kAL82H6OhlImK0Ffoc8YiofmbMROrJiBXoiRGpJSzra cZbSJJ8O+9iyPO6yhqHkpV9+1cz3UcyU5iGPGgkZFxheEZMHqSYNa3nNzWDQfD1EXxb1KMpdwTKW KQGVKhNEQWnOc5q3TIg7/fmieo7vnsXZoDBByZR+7sRhVpxmNPHIv4LekWvlMxe68qc9h3oGouSq mgO3OZVZPgSaHb0jS1/K0Zfpc6RzKx5JL7XHq5nUcTPVX0wvF9Hh3VRqOS0pSHUKTm6e5qAFwhpO RbrQDkb1qHO5YLsgpNClvo54bXtq+2qKMKtuMqlkpaqC1Ln/nyZmkqvn86oEgenWoZ1VrlysKxbX ZxEfsZKpDwQfDueKzaLGFWNnAp5R8drWu0JtqnvV6mPL2te3ShUoar0hAQsLma+Wrn+KXexhfRna v3IvN+th4ApT+jjNeuSy4NzeLw3LWqp59rOIDauuwnhOer2rQjFp4AOjMlmfQJZ+GuyLa+sGW85+ Modgra1tj+tY9+n2U7tlUzpLq9pXsoeJkd3NYMpCk4kYt5/knV1ee0lY53aWdM01a3RXi97s9CiZ rcTQcD8lKvkNST3d/W1qKLSb2kQNVKj0K2S5Il/4VjaccGXve9X7XAYrtm72o+um7GTE/KazkMsD cBO1A5YB/2uFMasx8WbHe1nBbPeMW/WjWD25Xvfiibk1xi0xLRzQVd53t6k9Y4cNGOT7zaa8sUOx ClsyYtgtObA5es2BKTthmirMxiqd7W0hfGPoKjV9xrQuG8npSEaGb0I7JvJ51VrK190GxchrMpIJ rGA4Pya2KdYydfEMMTuDVsZTtqlkdSaxM/MYyoU8UkCNzFaTPFm8gTG0gT3KnhKfmNKVTjJT+Nxn mz3Uynv2tF393N4ETe17ySWlKsd4yvC6KcxFrrSl53zgSMdPzay+Na5hvWRMO0rTWaZxnoH9aSyn d1wxxh9ZJwcmcxrwh+Gl9TnHe2k3Z7LRkqNXpGlN1wcLO//UDs6msbkt4VGHO77t0slQgKg8VWsb hJDm9LTlzOh3j5czaBF1hMv957F2mti9BrVs5/vZw8Dl1GlEZrpxbejB6LrNc5YuoMnN7wbDe9/4 7nK3E+brYAPcRsZti8ERtGpH37rRs3Zmey3+bZVXXOIXZ+HEv9TxcI1buHcz94ILrhRVX4ehLw90 zF2+cqG3HKn+tm1+EVkznOc85Dv0+dDzHXSp/9zbRcd4zfFKPxBXN29Mf/Frxalnq2fwo1mHedV5 OvZwyWnRi/w1qgm9OqYLFuWiXfudM573swM97d30+17art3gFgXArZv6Z+s+G7HrfdNlp/jjWR75 q8L4u0T/ulhxP275b1qWseZW/GDv3njajh7u+ib65FsmeBeXeVQgHrzb08IbR8pd4QFy7dcDC3qo Xx3tUd9y6Yst6ees3j0ZBg9whcggM6/+3AOGIMFNeMyrBOisoD+90fHueL+invt7JzXhLy8k3Bzf jLDkzn59u/z/9tfE7hKwnDGtm7TK3elEZdz1qQxuxPu+933nsu5JH4aEH50AyfnFi/k1iG+ViovB H6UFWJw93EY4YIklnbrNXfYNlf8Jn/XwXuoBH99xoF7BSWPIC8Jl16RtXrMAmQI2COutn5tB4Jzx 2gTCmQTGXwT2lNlhHwjyYP9hFj4FH8QNX5U9DWDBS/yI/xmbtaADMZ8K/diIqQm1NRwVZocN6lqs ORwWQp7dQMXGDSHgkV4wMV4Iil5XceEPxZ4DYdcjIZqZKZ/xXdoRViENTmAJfpz8TeH+jdYehqHp 8d//YVUQel+m2Zt0XGD0gA93JFobuhoOypsEaqENYh6dkVi8beGMnSHZESLH+WAgfuAP2g5eNQ5F iSApcZcaPpqtoVIltmKLXWId5uEN5t4OAqLaCWHOeeImCtwn3l/3pZX25QawFMuPKNjJ1ZtakZgU 3qAsYiItmqEuUt7RgR0RUl3+GaJRIKIglSLp2Z/b8ZWztVsWViEYVqPMleFJzZy4TGMARuP39Vwf gt+xkf9X7ZUbFObi1BEjCRYGMtKbJv4iskGjLWqcOtocO34hPioX540gGsLjsSVXJAbYYiAkNQZk 9uEirxSkF2pkOW7gRSZSPW5bQ/qiNcojkwUcRrbjQL4jH0oeJw5bMBpkTJpixCGTNnJkQk7XSErK QlpkD67k9jGkS5rjlc1kIbIWlyUfTVZfT5LkT44WhQGk3T2lTg4lUcJkSgrTLRZaObFYU+6cOmkg NtbimVSVVC7ePFbeToZeY+Hko3Rdq22Y0i1RrWkeVU6fEl7lLjokWf5eKApl6fQbAJ4lW+YYOxbh oaVTGynTl10b7dGEHX7GTTrFqoklPX1lYf6lH2bWYJb/JChiJY6h0GnpI88pEIZc23WN0DKNHGne Y04+WpS5pUq2JNFtpTtalVl65ktyCW69Xgp+IxMa3nmcJmNuGBkNJzr52DkpWaX1Cm9h5mWyjmwu V2gSppSJGz3a17wIkQH2F4g5oVe0koddFxsW0Y6NUb0N1ZrB5sH9o9TZn1Hy5nRyZlTqpl6ii6tZ F6Qx5o6QUIS83tYxISPl53iix6H1Y70928IFhoTMxHq2J3tGHRSulWZOZVFmJX1iIBraJoXSV1eG GXEiZ4+RWQEy4AoaCZrVZYK6W4JCGT+uZs5c4Qp9RYS2aNypk2R4oHPMZ1rupvUlVjqyoxLh16oN GQre/0mJktlJnljJHSN7KtOKktyKlhNV6Ia7iNeKqVkpEZKOAuZH3iZummSpyWYjkgeYmVCQJek4 NpnDWelFmJzJ2d56RltsjtyZIhKBvd+SwWa28eQgRtyXAuVRAeGfCipidWWtlSeR0SnDwVocwiI5 vtIpMWojnleUrRmORlkkRupsVqVA0magbuYz3uVncqioPg4isuaUQqgWSqIMRiCbNpKNXuqsziWt RmicPmePeinWAWqvGuqg3idL+iVipqR+1ipdNimuldIjxqorxqAxYmmLPiiraRtcWOYAFSqo/uqp GmZ8VqSFFmvNTSiLlpydyumtVqseOusVxtu1QUefsv9FnQHpsNLrOXYmtxIrWh0kj9aiwYkFyZ1Z pgastDWrHjZju+7qNQrrvdnrp96ctuorSqIjc/Yiw/6VGOHIitmeptLhukbswnrk3+HrUfLlH3Yr usmmgbgmdIrkhJ1rlDpptaYndWBryLpnvoppUDplhaKlYBprv67ldd4jQCEcx4psz2amxd6sz/7s TokhmJ6sxI4s0B4m1P4TylJkRaks02JoWpoqzibtddqnT+ZsqU6sj5Itzy5tuG7t2u5l17qsTD6t 0Mqt2jbtvTbNt6Zsdd6t0sKtn/Zl3LatNPJi3Xao2Nqt2TIlyKqlVRJuvTqudQpW4Y6SzYYt2+Lt w+r/7OZKrt+OLakyruAO7t8u7OWeLhn6aid63uNq7udm6+iGXeUqHuoqLOQ2bN8uLq8mLuJm7lge 7tKB0TXWbuxe7NxqaN4i7+T2LuD+bus6b06ZbssyL9oCa8nWp+6a7POCLu9e66jS3PBOL+Y2L/eK q/KGqqe+LvVGbtDS5PcC79OJL/EWyOVqbf1yLb+S7Gue7ft25FL5btY6rPp6b+OKLvCOYvtGF+36 L/TabuDCbwIPsNYKotNG7fsGXW6GrvE6MOdKcARrsPYupSimrvX2b/GG8ADfb+52r/2KL/9S7flm 7+2asArv7QR7EwdHZwVv6/XG8OqiLA2D8NtWbwBL/9QJD3EO63A8eq4Mu24Qb+QKA7DisrAAC/ED 70oLJ7H+Ja8FP3HKLe/4EnER59MRKyTYIu066u8ZozHObXAPd/H+pu3OUo7/PGMWl3EDN/Hf6vH8 cnEJg6sTU3EUe7EUry/uqvHswrHbkvESy/HVjrHXEfIaO/Lxqq75/jHfMrIfQzLFPjIBV3LZEvId Q7DVanEYF7IRN7Ibx/EqK1RGlnIbf7Ag761YvjHlkjAn+yBKya8kz3Egu7LUdqEtt3Knku4ew7Ai d+or27AsI7Axs7EIhzL5Mm2XSjN1MjMsf94zQzMrE/M2T+0h0zEug7Mnc/OofjMFk/L1IfMWsy8x Z/9y1dJyL5czOuNvPf/yvsqzKffxPMPzPcOuOt/zmGbz9k4xKvczKP+zPXMS8bEsFjfzNBsyPVMy QouxQsdz3DKLUgYrQUtlQpNzRVv0RSfz7nJefk5m7o0y/hl0SLPzSGN06/Bn+iYeRLe0KL90O3sQ CeGXgQoz3dW0TT8xTr8wWgCYb6pGY2hsEgnsZJb0C16z1wZ1SxuzS9Pe+D0h7AFoa4IF/R0TfJLS SpYgVHeyVJd1Nys0ArEmzJ6od7qggyTpEmHbao4TZ6xmac2PQz90R5v1Td8y8hjGhwLjgZ4p4aVJ b7me68V1cTb19F1YXGYI++X1SuszX88zOCWfncT/zZD1NEjONUWoqZoi6XcMSRJmp5DJNV6m9m5y IzVW8wxXtlSPD7uFZWiTCj1uKaLOy3nm6LsMKGKHHxHdj2NLH0hDMWUfMGzHNhIz8I3KJV0WNhP2 GGobbYet4PIB1h2ynmof0FcfcziTtXFHdXJjJyK781Uwotaw9YA2W4EONl5mNlJftRMan5AoNRuG JL+xrD4uKWOo9Fkf93hvskbesKkx9YcCF2i3IXsPNk+fx1O33oYcX38dq8bG7NEeXDE6oz/r4ggH uHIfJGMXWnsbNXAji3DLJYHy2IJomIAetbOqyZ1WeLISrDWjSTBzlYfjsTkXsFyw9n9z9yCNmfgN /3l4gnV7H7meQiomLmNzKrW7UeknV8UKSW9l+7TjhHj5rgyWqyiXu1JkdUViyrSt3mq0LfmmZniR yFrtnWeKBh2Tp/Hu5Tg/e4aP//j5+HjBmalVi/lmCzeCKuuTGtqSMnmbypsCLng/qhujvrZYMLfl Ru9yJywYY4+C57KRg5lM86OfO+miW/iFUyoycsoMRmucImOpy4ZcmrgRlviD+zJDj+qb83iNF3Wd FzNRc0gxDRJAhZClLquzpSt5BnrJOepJwnjAwulatV+dqOQqFoQkfuyb6RqVD7PI0SxUSHZBS3Ru PV6t3/j7gGSNLhyoLyiZJ/oqLqehj7qsChmCJv9ZgtEZucdmlku6C+Owo/NfelCIf6PvjtO5XQr4 zq2orMm7stJpqqaruJv7q7bqalnrtE5hvqtGGM36tdv6GH70pYJQSim7sok3wN/6BRe4aD4csjta pwP7dhu8p2wdmnN1rabmEj5hYjApULs6E3/TuM/scIa6oYvYvuvxvAdxaWheq/a6yv96tQ5svNfp ui4jjZZ8wWt8b8Ogxb9zrEU066a7iZS8tb28zC4Rnc189O010LO0FxMIofsXjR89tkGor9M4ZF7i i7/pn/+5aGvKwLMMtme7LaZ9FMb6hPPprxMGmZer1KP5Mv78Dxf396I9yW/HvCHrxsJ9ucdsjjL/ /NVretcra2somHepjtPtvbeHoN+L9dT3fLFz+jGevIXzto+Qn6oD+NWHN3g3/jDOYudzBcEjfMEn fO/vfgip+yzehqmvvpRxvOdvucuiMLQqeY/g/vM/oPOXWLmmmYLWfbsf/lNDftUjm+jzO8jbPmi8 PjPW/dHr/KejUm57dWwI/7ODPtT7mNl99z/51xYS/ewX+twfS2oJmAMCBAB7AwUONFjQXkGFBwka dLgwob1/EwFQBHBxYkaMGf85bOgRpEGOI0mWNHkSZUqSIVmGVPkSZkyZM2mObHlT5MWKFf/p3NiT 4sSIQy+2VIjQI9KhRBkuRVjUIUmeQYFS7Ynz/2ZNrTOxZh3JU2dJsFSnjuU4NeVOoGV7otX4tmpH pyCfNq37kSnBjT7N7kTbteVWwYMBsxx8GHFilYVdllX79afcpXjxQsw7GXPSh5UPbmX8WaRimKAf Wg1rVePjk2DRRv4K161fsW0hb/549+7ko3hpm/xZlnRo0XEDew4ucXhy5TVZKm3+G3prinabVg+J 1HJu0Mu5d5dMWrpUuKbFk4W82m3v8WN/f6ecXS9l6k5Tv3Ud1DljwXQL7z/uHUDE0ivpOIlOi4u1 1vjjjMEChQsQQggfyi+wAyFTK7bx1jNvQ/VQ09CsqrRrUCDc4susKNXaYisyCgEjb7TmrIvKuP/g IuxuwOTAE+jC2A500cEg/7tRtBxRKtCiHE8LD0EYBwyvvSZfaxGouay0LUUGs/zIN/zSK3FGnLpU CUj5HqQJSSIvVDMmntLUyqPhhNyOzTrd+0xEC/X88SwnNbRIPPbY+lDEjuDLa8TbLJsQQx8JXBCr J/t81Lau/LPRzkzRHHK5OT21VNMbK30RRBhX/LJUQCeNCzYOC+0To+sarBQqE+PkE7XfZA3zTCMp Je1SYEMddrFP42zTJmOVBYlYrXz9dbsnXZNUykn7avUsX0N8srpDsex2PtlOZW9Szfqr0Vwx0aWz 2XaHGxSxZeU9k81nRcsMMFxZ5XDbD+G19k//UwUVC9JDa7UOzKZeS1KjhMoktbyUCnMuWHbdjclY MgNmc955E7O3SDj/c+xfhmerdtVB78s2ZSfBDVdGKw8+SCmoIrLZKFAX3jmjmNMdqGI8Ne2YLp9u Lsg7ae9bmSOilyXSJ445BZjQavv9rsNXtf73WqG+ve1lW7dM6mCcdbopP4pP5vk7vnRmbuqgnX5q UZwZshvkZ6HUeFOnP724uwLhJZnS3CCqNWsEjbxa5fkQXXC3yxZK0ejN7IZ0VORWLRZTkTu/M0i+ mwSbbM4WPfrsY1HWWzlJ/c5YboiJFJxK0x4znFakFlYZ20KjTLZmx3dL1OHKzGa0zIfp5Spu/+aB vhcn3FH209BZk0e4uaqd3fiw1/9eV2ipNU8rYib3/VpygmDLEL0OG7+SVhJfzvlu5cOHu3Pv5588 bepUs3BfqcFO5hqSOr0kzHjUCmCo9Nc0/QkpQiCL2Nr0NZUT2YpZvWPcBN0XNgL+bGYPNAz4vrca 97kIN/372bG4FjGZ6YZ0NDtbiQY4Pndxq3kwqYgIQ4esmkhQh//7XbJiaDAOUk9K5vMa9szEwx4q J1JhCxjvlnizFRaMgAjZmqssWDBvGZBR9bNhchSIv8/wiIROLJraRPeuH/6OcNO5oszct7m1Ta+K arRRxhwExv0tKVWvsR7mDPYeNO5scHJ0Tv8KDWkU7LykjAHy4/36pkf6qU4wQGwdBXumJfTxrGTd 0yPoHBQ7xgSviQnJVdUs+EUVpgt3qhzT1hz3NRruD3kC0uFalOihTn6ukpbMl/YApycB7uWX7+FV nYSpLFN25XKXk+EWVfWVXV2JbtfMjqmmKJcvzq90MlSdBFVUTVedB50medPsjiPNtwEOJXzhZjIt JqrnQY+Hz4wU3RCInaJwEkZhwiD/rskQLvbuKpCblcNSN0krTrCXIdLaVtKzTnuKEJ6dyqEZIdhM SjrvktDEpeZQxcUTFdSTKVUfIrk5UrItclQ1oxoxd6kYi0bIiRmFIqecqU+PYnKWK2mnOw3/+JR5 JtGb8oMhLGeVNSXdqYbyqWFUgRpP7vAFmdD6qITyqVM5yYuZP+XV8jAWJIcydELUnOgO4wc/l5oL lHac6gdvucYC6i5kdqypOjcKoJx6VZ34vClXjWU/YIIUNP60GT//aa2rdTKWCmWiVGcaQDfBlCh1 K5s/M8g2cuqVJljN41YD9FfAvgQrxCAGSFQLQfGJVV2eM2s/pbm6Lh1vsspcqm0sy9K2KOqFIkFp XenVy9C2kXPCUpNp0zgv1a7WIa01yHOlOxDqUndOYYVtbDk6VkJKs3JyFVgtMYuvxVKHX0flYFZ5 ydCGhvGe5JOvX/vqnb+O0afYnS50n7tf/9ZCN7UA/m91lcvO7XrliFqN4kvDSZlVLhA4MRsoZZnm WQ1yT6LwtRzOQBvBGB2WsP8pYUv0a93V9je6ArYHgW/C4hRblyUERvETDSxM+x13tKdcJAoBONOx xPCknf0TFfFIU4lWs4t3tWtn1BS1dPIVxKXNMY1Hotp/WHkiVnYxi10cYxW/eMVfDnOKZxyS6p5Z zKSl72wNO9iytpPBJDonUkeLyrwU2ZyJezA694afBp+UhrpEaFDfXODmKpfE/FV0mEmC5Yw42oFk TrN0uyzjRXvZvyb+b6Y5XcrTRtolEqtvchMLph3nZr3Ycivm1Asr820QiX3Zya6IO85AEv96zYaG kKO1TIwrf5nLYq6yryHNkV4De8ZoxrSmx7xpTnc5zNcV8HWp/OlDY8Wnp2SqXvCsoYV68cFEhvWr qMXeswzyOuW09q59/ejn/rrR7XY3tFoL7evGG95ZlveVEx3tE4s52Mzut0eUnWgUQ7ue65ZtwmXS x1ROEo8lY+JA/TTE8oTSnMZlTRij2mOu3qjY7863vvGNEmmbhNcE/3eniz1v6o5cLiUeM8I73eya Z5rSyKa2ym+uZoV/WNcN7+PYxGlrgZHFYHYe42MBSigmkQtbbRbypgSL8n2TPMvzLvlJeH11rI/8 5F//tZfrXWaJ9HrYLXePpZ3N87b3HMz/0Xb73GE86p+LOspAHyretpQipCMRqt9+XgvjSmeMB1No JSQlYF5eErVrXexaFznY2w3px7+88T0ru8rTPGxje93Kb785zW1u9kqrOOdmN3OaZXd359U4sTRz ynmLe1S2aqe81JRohUNc7YULzfJe/3Xmg//1xw+f2JPXd+YhT0SB29y/nnf81aE/YEWzXfQ5f/6x LL1zaZMev653fXnPKPjds7JnrrxOWKv+WosVf/nHN/7VJw9/ldh/3nSPO9C+//l8a3n/ak77qu+/ /I/r9s3fDk7myEr8LmZp9O6MdsyRbmc9cCjvUCv8fu8CA6evuk76xE7+DDDy1O7yqA/h/zZv5uSN BOnv0miuzFxQwGBO8rxO9CRN+AjjnTLK4zTp2qKHn+DnbGjqJHwvXrpquY5j3/DP5Fiw+UTwA5vQ 3Rov9AZQ/7DMCm8Q3gpu2XpOC+Mr8gxw0qaNxbKtOOzE49xlwULqXESm/TTQb7TL0Fru3qwODEHv Bj0QD4Uv5K4PBhkt/uQQAU8P7gYx56bv8yZv9Z6Nv8hwhBowr6Csgb6KCCHwdeAw4cIO+a7QEF0u CZWvCTUxJaQNOeRvD+fQA51vAXEO4MRQ4LbuFL/PxLwPwLAQAzdQ4XhQ6A4MoxgRdo7QRsKu+EqR Dufv/lQQCp1QBrGOFJOPDkOP82YRGv+3kApXcBNVLwFXjkbcsPWGBRdzTRcfiBcV76IK7Pjm8Auf EBSH8RjNsRnvkB2zUAU7EXTKDgUJ0B43bwmjsGlOTxT9UBtz0BGPJAMR7xufpgfByv2AjxZhLh03 cR2Z8QCZTwSZ8BTPER7RTt8S0foCbL+qKxmRMeCu8cvCsaq8qiBPUhwRy3ss8TMqjxb3sBqxsCIn Mh6JTx6n79g60RSB0dFaDBqxbwtNTPpCUBW3kCSz0Z64AyWXkrsI8g0TkjH6j/Ic8iOvMB5nEBmj MPmU8Bw9UR0x0h4FEPUurQwbUgQTMO5S7ygZkNR66h+ZEiXXchLtCwlvMu3wLx0fz9//9jL6nlAr i3EGXTIfP8/twI/Z7A3A/u8qp1K/vq8FFxLvLEmobFEg4dIy2dL5JBMqz8X+3tEVmbAGU9ALaZIT B1MfA1MivYYeV08LtQ/71FEZfS0smzIXEfItabM2LxO2KhMuWVI/PnPrHpLkBg76UhMkt1LkQvAP PREjx+4wTY/1qm8AlRMS1Wgyg67QGC47dXMlD1KYiKVA6m8nj5EYD9En3Q4rixETSa4irTLerDEk qdDn2tLucnM+I1M7t5M7n/I2ESwgM9O1DvHdANE0sa4occIxdVI8588OP5EJFbM7Fy8/fRE7KXEN u2s/nUYuBxKenOglHzQ9l/Aa05IP/xXUL/0SFKlTwS70P3GQMoewPmE0QyMUQ1n0tEyr64wzRQVz BosTG1sxOBXTIjkwQFvUKbfRPn+zP2fUUzb05zw0NkGQR19xMedxLJ8Tp0bTSK3NzSwUSfWTSW2z Rr9Up6A0ShlUDyHTOSdURpt0Sz+tS2uxQuU0TDvGSRXOQ0H0TDfUTd/UT0GNTfHzPnlzF4+UaO50 3fJU/ELtTxsVTMlUQueSPvlzTA/VOxuRS40wScXKUTuVTpeST2O0TSNxSTEVTmk0MX7KU1eVUGmT ucYxUFu1Ei+VUTNVSenSMlmVVadOJWe1OmvVULGNVlNyUyG1XdzSpi5TV10vTie1IP8RtVLtdFhL Uim1NCB1c1nvrlkFNS6nFSmD1WO8FTNLC1hvVFmzFU9FdUWfVVyt1UsttVR5NV5tFLCwFV0TVV2v kymhFVzF9F0r9FXNNVfv1Vbn1Fm/kV97VUM7VFNPdWCbBSCvFVn7dTfblUO51ViZtWEFVjPLNF+H xTotNmCLNWJ771s5llQLFhzT9UWPdWNJVhdDNU639WJG1iT9c11LNqNoFg1f9lERttBStQyjFTdv tlB39WOJNFzx9WgpdpSytGVzVliZdmV1lWd1xGc9tmkVVloZNmr1dVB7dms79WolsWpVFlW5llLB M2npKWxddmoB9FZXtWwFK2Ud9mz/YZZeF7Vtpyxjt7RuHfFvoTZvUbZOszVwAfVt78U395ZgAcdm tVZnsfZrBbdvI7Vo/zVzcdVgHxdiI5dtibUIK7cBE9dt51ZtJ7daSddzKfRujVQQBMEkYpd2k5V1 NfZ2MRdnU3dzlTY/Vbd1hXZsf9VSY7ckjHcikDcjaFd5/0F5m9dFOxdwLzdxixRW0zZ4d+pcYTR2 QaJ7HeJ7azd5ZXd8yzclmpd5mVeUcvdJ66tOqdUbsTd7zdZxU9d8l5d8OcJ4adcjwlcQ7OF7qwp6 7/ck0nd8xTd6Y9VI33dhXVd+53de5ySAB2KCKfh/Bxh51VerKtiCBZh8M/iD89eA//U3ffM3gRdX Yhl4aWHvgSFYeG+igjm4e2X4fwGYg89Eg0k4M2/Yf4EGhI/XhEdihA9Yg4OYd3eXbFV4ha/XV/30 ZHcqhmsYfC9Yig3Cf6u4JWYYi20YqAbYeUNYKAKYhjvrhwkYf4f4ixE4jRM2iZXYIB24iY3WTqGX jsG4f2uYebFCi713i624j7l4gr8Yf0ligP24gw/5jmdXhBdZkM84h+0WhS3XjSeWcAuXcr1njBHZ hnW4fL1YLkqYj7P4j0EZkTP5WMq4kYW4j6P4kJ/XiIH4kYe4hNlYb4eWhSfZeiu5he3EhvPYgvm3 fw1ZmG/4fut4Mm+Yi1sZj1f5j/8BuYpLeJmDGIPBeHw1mSW+t5ipeZoJ+ZXN+Iht+ZtNVZdxWVJX d237UzCAWZiT+Y6nuJ0zyJNdmYhHuZlJmZ3dGZgzWYypuYDzd5iX2ZrXmJO5WaBTeZBtV3pHNZJf mJxz2WTFOX5RVyYmmJWv+ZkBmp3314RR2Sb22Zo/Wp+j+Zd92Z3vqYw5uiNI+p6F2XzV2KBV2ZvR OIKf+Gfjlokb+nI3E34/VaLfzJ7Tt6Q9eqVFQp5funzfOaiB+qOR+p+V2YBj2YiV15BVmoMP2phb OqpDuJultpxltX59F6cDt1tnelxRQor3WZ1DOaOZ2YauWpApuplBOpqFGp/Peov/A3iQofqYMdqa NVqatdqTU9mtQfdgbXqcwxpnG5qWR0Op/diXediug3qgFfmXepiplVmuQ3mPPzqvi5qEe/miMdsL 0ZeRhUJmE5p4v9qcEZu1gVehe5oSG7uU11mUn8ezD7pnPNqUpxqjkRma+bmzSTub86iikVmBU7uB iRaJyXWsOTesF/sl0Dqtp5iKS9q6fXijXTqVeZu7Q+K3Y1p2Ndqqs1uVhRt6CRtjk9tpy/Whlxhy Wxu6VaKi7ziPo5itkYOjH9lrfluuG/mkybuzy3ur17sXlfuNDRyimXuXCfqMgfi09zW+zzerFZmk 7du7w3uEr1q3+TqZO/mvB/yW/8+5lg+cwHd6ffsUJkjbpbWbm4sYxNN7kiPcrCfbm79YtOlaxYEb eUF7t8tabC25pt17xBNccbt6svMbw+U7q/V7nll8yA/XYtNZmxdZjS18rQdaqo07p3UaXhG8wEt8 VnPYs1GawWFayWE5nl9ccyEcrGE7uid8no8cwME2jg23zp9cdIvc0xZjs++5h2sct2mcss3cqAk4 x+f8hJv7psm0K4Q70Jf3wRd6aLKWp1Fcd7NLvA3djpeaswObxt3azB1dsP86zik80u9cZInGyZ17 wWuW0gv7Yin2p0Obix9d0If6wqe4zGEagTWc1P27mzPdkbN71de8Ysm6QKbbzf/bXMTl+HVh/FPU 2bJFm9OHutB3vcepu7Q52ddtHdhxu6hdeZbTmMnBvGO93KMaV73tfEbhupQjm7Yvu9qve5spHN6T OipQ2Yv/O9RFeNevndwR/YBPvdmNnVPVvcvxFliN3HmtW7aTWcshu9Fp/br5WNA5GuLv3Z3fGs5v +6XTHNyDvcrLHdANXlVTfXgjuuA/13Rpop4fXsvjHYsjfubvmsM3+dvtvc+b2oIJHbx/HeSxXORH PsNl2qu3F92bCeG71oW1Iq7jHYCh/rLnu7hVGqnBG6uryL7z+X/7fdDNeN/5Oez7ecVzuLVj/bVP cumFPO399bQePteRmup72Lj/5/uf1fnTJ/ydfbvrjXrsR93BAx/wR93oA558z57g1729rZfhL53I d9axITutp33qa767Kz+Uvd7BMzvzPb7Guz3r31zbST7gER/lgVzl3V6j2Fd86Lri1xrfMV/eKX/j /f6VZRuaR7p7bX+4Ad7npT6pf37kTR/ZQ/aSs8vZJT1TRl/uLV/Xudnht/ioh1rie/32Dx/qp91/ U/z6zTqIOZ2G75fH+fjplTjxE57Vl1tyj5vlV9q3Az3oP17kP/nmOT/2pVvZadvbwxiLAX2aAcKe PUGCBAokeLCgQYQDGRpM+LDhwYgUK1q8iDGjxo0V/3n8CDKkyH8cS5osOTKl/8qTLA2qfAkzpkyY LV3OvIkz50eCDhPyVPhT0E6hHgmqNFqUKNKQSz1KjMgw6MOeGKlCtGj1KkWrSJt2JfpvaVWFC4H+ LFszrdq1JnWCZNsxJFuccFu6vYtXpNq8fPGSlXqRZ1iwTYeKLLzUqFeyGbNm1QqV8VTJQXtG/cv4 KNikSa8+rgs6tGiKeVH2PR1ztGnUrGmmbQ37aOSzTx8ONow78eaXhSFHxioZ7eTKaKkCrmjcLOfb MlU7fw5d4MroGWPPpG7RuvaPe7dr98kQN/OwMwsvH2me5OPkxMF/Du77smf4ce9iv48/Ymz83l/m t93ffq8FCFtl6AXF1G4gLf92XoILCtVebevBl9x8vqlW2n8abkSgfxt2qNeHIKLW3YiopTfUT+I5 mJuK56HoGGVm8STchhziZSN2Jmao4Y5OiegjjgMG6ReCg7n41XJJjnfkgSxyRV+OoPEoJUZEjmhj kFle6VaJXN40kJIuJmWkky8qiGKIVfInpGgCrvYlmECaOGWc23nZ5n0wlckklmuyaV92V+Jpp2s9 +kionVbmyRKV+R2mYKEk/QmooXoyepKk183pZ01aJiqnp5heqqmllIr61lo5gbopqqV6eOiOrPY3 a2pDdsnpq2r+uSupuLqqU62vbinrraxF52imo+qo63TQ8fVfsm0ty1Gzzkb/i6ixq+ZKl7bdxmqt XDdSe6pNgQK7Lbrf6Ufus9mqGyq259rV7nPhSltuXfhWW++i8zbaL4bfShewoP9WGqy38T4KG2l0 5uvuwdNKDGfC8LYK8UX7jvurvB0DTDF1GNMLYsb2Flzfx8qGzLHFJqfsMsgq+xrzyjO7ubHG774c Ws7VoewwyxpRWTPN6ZJ8s8hAsys0zzoX63SdTfubdMu2wvUptwvbXDSzUz/NHc5HMwx11PouDeDX 5Wbtcdf8qi22yvde3XbJZp8Nd9BVm8w22Xv/nLfUsPrdad0d3o3331S77DayOxM+NteRC3u4wgES +zDii7+JdOGQVw5u40Nj/zqS1iNLDrrhBGpOcNkye46w3aFPXnGhlF/7uuyqX85636ivbjqtwdO9 NtrmKg427EZPavXAd/s++qDD3zk9888b3zryBmeOuM+fW3dxs5gr37PrsTv/++kTc3994ImT//bc Yc+euj3yD/69+rWjvz77ZnsvMPP1b27jkxa0wuedAvJvf1sbYP3+hz1VPS594uMU67YHP8e573ii A5z/ogbA0UCPgdYSHIk0N0KlbTB7HdzcA0EYwdtxLnf30mAL85VCG94Qg7SLXwb5FkPLCQ+B90sV EfEHQQF6TXssDCHMdOfB+e2uOdUDnxD7ckEnUiqHJiyiETtHwCqmRIHAI/8i5QCAxl6dr4FOy5oX lejDMNKPjSpkX+mgg8Y8AiiNPdRhH4FIRaYhkYNvhCIFdZUjLXZRfnzko/VY4siURFKK+QvkBadY yARecVhivOMcT7MRNBpElPbDCynBuMA67vCS5cvkD6MoR0yaqpXaiSQf7XHKPALgIXocJQAiqMj3 /ZGVAXTlC0lYwU8Gcj8xseUvPdLIXzoyjdPcpS9zaU1dTnKYLqSjH4lHzEoac4aH5KQyHzmaU+LS mv+IZki22c5nxnOe0HymNtW5Tmvmk5SiDCYhUxnOgApznNQ7oqYyhk6KqBOb1/RlRdxJT3pSU5ry nGg981jPhCITnA70pkD/P7pJgp7QoJI6GUyqyR188lOfvMymSx26zphC1J3wXGEpbRpCT4J0p00U qRVJui69BUsm2nynPDMq0Yq+NKYCWalMXdpLpgrVkB3VXxyPydNw+pR3QOWmc5LqTGciFaXznGhT VcpSqXb1WCHFXTmDmlWQbpWrqKTk3ZSqy7FSNKl6NapGVUnVjc6yqkNMoiAt2b65WvGniKsmWRvW ydbIUKc0LKMs4ZpYxbq1p3Lyp5S4aNIPCnaQo2WsOAvavUKK8K/N8yhCJ9hWLk1WjYTV5GFJe1XL Zla00lvrF3eL1daWMLaUfetBiSvZ3h1wqvKbrbhQCNvSlrSboERunJw7/9LUfrWZ0/WtXWEIR+Fq drNxa651s3tOt90Tn7i86f2w+902Rje342VtxN573uqCyjn6TOtA33lc7/4IuuGNXn2fe9kA15V3 mB2lg3NJHf829Y3wHfB940vfwlb2wGQcroB3pFRoipgkUW0vNrMZSov0d8MeXjBijTvG/GJRxqqN 7HVp7JaKfsSeL2lkO3f843Y29awozieRh4zH29aQxhW2LyyDa+ADY/ib4XLvb2ur4xFnGSQ65vGP fXzULwP5x0Yus5kdXBIJI9k0NS2Vc5VMVxbb1sWa7TBokyeSLXt5xGP+8jTL2mcxB3nQe+ZxmKXZ UBNDFc1pUXOUuStbG/+jF8aQ/TCFJc1RGupZy3wmtKfFfNQu23LMhc4zkEXNaRHzc8gn5mV7I2yb MEtSUZiesaWBKWUEn3aVGJlkljGq6kFz+tekHjWAuXxqUvPZy2CWZC+jqscinyStjnY1nFu8a9NS Orm3LmKTMy0yvBZ705+W9aGTnWpil3vWyw42sxP97BK/OiP+rfaTq1zr5dIZtXLONa0PJe5O71ia nla3wfss608HGdU+Xrighf1qaK96zWtxtKMvnd4G15bf277xE/GroYCrG9AO77S5Ed5uarZb4efu 8qnXjOKF1nviDxXNLnPc2wRre+Mal66/76wagpca2Mded7JLzXIAu9z/3Vw+K5KlPW8zR3ulUDeJ vYmszX/iO+M79zm3983rtP1c1/gJ9Z+VvXJyo/vhFA11ygM96HkXWdq7fDa8mSrvXjN6L/XWu5UD C1go3zvOVf3v2AHqLowSfOC+Lji6R754Yacd7cwmcd3ljneYs9faiq64Qim+924zkZavpO58o/zt w9vIno6dvOMFnm7Kn93QqS751eVObbTS/PIRqfbt06xmCQN9tQUePLhxfGWeHx63jvs10eMJ+dov 3tBnL7nkR6JnzDOa94rO5bJV/nt61zzqoO/4pJen28LDq/IXbb9n/758xHs+O+KOPLArv3TrX7/o Sz93sKGpfXPXUrjE/3gFyGVpFHpPtyHCd3oXFml1xX6052wGOH361nsakXDx92IXqHzp1nD6t38o p2rblH/2J31jZmJoxn1yB31h5Wc7BmukB3hU9n5ps1dIl3AS+ILgR3T3F1FtloFN5ypBKGXPV1wd iH3VxzwrNmFb9npsV3vWV4GwV1EJGHFzZ4AjaIAcEXxWWEylR3y05UMPxntM+Gpw13//B4XNRmgT xXp4RYSWEn7ZE4dF93NNtmgtdWImCIIm+HzPxHlOiHYLV36Zt2IR2HDApn3yVXzm12OC5oSASH6H +HR+eILCFoFrd2hgFnBwRzdzmIF1qIGzEoe6pIJHxoIjh3KFSHdDRv+FjweAETeJAdh27gd9ZAde gHcwg3iLeYVsajiFiMZqEAZzExZ7UviLLwiFpzZ0Pwh7j7iEhchDGmhV5MdcN5GH1lhmz4iD0RiI UkdymCiFp6iAaVWDmFZeFgYwPZiIwPiEbseE2bhiKJeGB+iOzXZ/0QSHxyaK6pgpochuIKcSddhk rFiM7ZWM7+gUosRSh7hQlOeJTmZ6xxdXjyZ/F+GLt1hwH8h+ULh9mFdib3ePymaJJseDFAhKXTh+ /Wg7TEZj8haP3hd5w0ZqKlhiDIhTQcRTpsR34JeFGamQWVaMlMhqpdSNCqdlOsiH7Ch0IQaQ2BeL C8aSopVhMTYXQtL/X8QIbYO4Z7jodV5ZlYNlkVMWNVMphvHjg0npf2uYbAqIitrHlUHJjxK1cJuo j7y4LevVd2IHhnLVJllphte2gV+ZfIRJTpf0fmmneBCZdELplilYlMa4aSWYjEv5fW9oi1D5jGQX fsP3UYmJazb1cYNZkdPoWr32gRrZgnM5klHZikQpju5oezQpiqj2ffhyezjRZl7llznpmwpWmoZH muOCg44Fj5oYZFFHlLJIgKpYhyE2m5LXicqITnOIgb23mz1XmjV4jnzZQN0ZnN55kRipmornfLG5 jPYUgBzIl+QmiFE4cGqZme0njNfJeWkmnmY5egEFmuPpQKDynmQZ/579xnz2eU3y2IRAZo2+95HK aWXvSZnXR32SV2ZZZ4pWJ37iNWcDCn+naZgDeZfxSWgZaprVyKFIeJbAd3mAaYVmWHXUdp8giZcR unLSKWRSJ3NVJ40y+Iv6SZFZFXY14Xax53zMpnIo6JInKkEeOm0Nmo2h15APRo4fyU5DipRJ93DD lnu7p42goaOcRXhxdTjxCHr99X/RZ2tgR15KyjpPCpJTOpR756IXeImsiZ4lSXESB6MYuaPIJ5rE BI09yH956qRaF6YfKpFsmjHQplAMGZhzGogLtZJGWZlGZ6U66GdvqaObt0R9iTWVxjQlmZ6VqoaJ WqIa5oj+qKhms/+lMQqpEtaKVHqKd8qNItiVhFh3UGedNIiq8KViraapaVmjEWWBqVqsKAqWq+o0 jPp5j/mmmseeX3pTR5lySrmmL+OpucUWUUqoo+SZ13ioYVmgypovugeYWRmt0vikuuqtB3eYjLhV GCqcG2qsvDmWJkqupwKrxKiH3CeAslqOxkev+dqhsCFrdjawyFqYgcekBNtoXqqV2BmrapWOgtep aUqgIaiTavqu4nqtDuifpHGiuxoa/EqyF2uxofV1GduxvJqwHmuVOgeqDvuwQPolHDuD99qrKJt+ Ciug29WIA3qywWmvGupFqfenohekhjqcINuzlzS0NAum1MhWSlv/tIv0tDB7hDwbrlK7k1Sbcyw7 s2vUtTr7o0BLlV6LQ2BbY1bLPw0bNDibomYrlvWarWorsFXDtkvmtlnrsnVrtOM6kYiEt0xrquL5 s3i2t8Aptv8ms3Obt4KruFtXuKd6rIi6uGHKYflWkH6atrwytoL5soGbuaU7uk6Lr4MruZZrTqir qmaLtPuJuKZLu8Lzm0s7tWc7udiWbbJruBzns7UrvJ8buR9bvDHbuAR1vKGLuaE5vM/rZkkqt8lK t/qFtYnLutpJui1bvdDrvXc7u027vJCruq/7u1t7vsZbvtw7vlVLZ+37vfGrvrsrvuuLvuanslcb vqcLv9bbu/IL/8Dzm70CPJrkK1D9Sbz2u7L/W7+5G8Bz1bmwK2eI6bzgm74hy3XIa7cPbF4GlcH3 C0i+68Da270anIu4W7AcDMEaurZJ+7jU278Ya6xZVMEqLGUEirCAG8Io/K2iq8N4a8PetsGrW7Fw C7q3m7MxfLgOG8TsG4YWfJUuzMAwrMD+O70LW7lNHHYNPMBO/IX6WyVUPK8/zKMivKpafLOei8IR XLngysUFvLNtjMYPeMVWjH5i3MYXbMLNK8UDSrhlPE5LmsB5fMJgPMJdJ8dzTCSxu8aEfMRm3MP5 +qM3BMCMbMiOnMMY7MMkfMZkvMlL/MmLa8mafLyYvL/Ay8dmvP/DIAzH55fK/jbKRnzKRMzEDajE 4PnB5hvKzKu1bBvLqUu/uiu1kazHCwzI2Eu2cby9e/vLb+zGwkyzxHzI7CvNggzFKUy7JVLHulzC rKy21cy/lKwN2qDKanzJlcy5OGbKxey+ybs647zNoDzGnDy+u6y86fxh6zzNvFwl4/wS/hwS8Gws 5JwSBI3Frsu/aAvL/cPG7ozMtYzI1CHQFjHRBgHQ81LRD5HR2OzJTxzRuQy2DT3D+tzRo7HRGq0N FHHScHLRAW3QyFzRuDzSBPa9Ih288ryd/BwRAj3OKW0PPQ3UQe3TArHSGbHSJ40TLW3TXIvTPIPO +Sy9nxkkQg3/z1Rt1Sld1Rl91EO901z9qUhMyvo8y9DMzmkM1WdN060B1B7R0i3N1uSc1UKN0hXR 03S90V6dzGRtz3gs1q1c0s/cug7NzUqcvwZ8wT39EW390m8NEoj9D4792ItNElvd1UCt0nVN1D5d 1AwLzNsj2X/d12O9x73scfG81GW9uord2JKt2on92S5d0IsN0Jid2Zb905od15U90TydydOx2V3s zaHt17QM2NGL1izWzUnN1RV91ynt2qsNE2793NA93ZFN0LN93VRt0XJ920F92XjN2yIi3c681wcd nudcw3xr2sG8xDfR2owN25PC3HiN0q/t1q0N2dj91gaN3fyd/93Zvd22Xd8CHuBDzdO/rREIDtyG PdwEfMDpLcuoHbYzLRrvHdkiYeEXfd/0fduXjdLwDd/6Pd0aLuIXbt0g7trYPeAH3t25veJ2zeEI DdqiHdwcRMNgHeH77LiUMt9z3dUEQ+L+Td0jId1Bntk+zuKlJOL5/dLZHd0knuIhvtbaXdsEXttp jd5BWzw43tkNnsQcTSU9/uMFTtsdvt3wN95BjuJLTtBH3uJi3jpBHdvUzeT7HeUmXucuzaYIfM29 PdrLzODF3UKEy90UHeNbLecnLuVr/t+s/dK6bdcfbuKLXt0lDtl23seFHNY63s5JBMkQ3tTsDRvj TeRtPuaGjv/VBq7dSS7lTY7icx7fb+3mbj7fI/7fGP7aZWuzXK7Mq7zpYO7gzawSpK7cMzHfWW3m cE7lMc3WQ17deN7kTu7aZ/7m4O3cLyvTmp7jwO7FW/7peWMixG4d4u4hx77c9L3suC3pef7e/W3f 5HzagM7XD87rvf5amT7PTw4il5463k3r507mdV3rrd7Yz17vek3jgf7I11zNfn65AkPufEHVb3Tu yK7squ7vZs7tOk3YTLaxgv3w8u7KDt/ln2Xsia56Gt/iPh7Fg7zg817edszUCS3qHx3Pf96btavU +cbnWe7yRazrVTzyyd3IWP68HSbyDx3zgy30Ms/Z9t70xE3/9NkOr957vTjf8eEj4/T8xSn78ko/ xEWfWvEb71MP9mFsywr95cql5VJN9lFN4cDlt1tPx06d9jv11Ot93J7e54kC9FKP9m1P72+/9zd9 4z+f9MG+8Qq/8Guf892y0C3Pwx+f16h8zIDP6eYNMd8K82qP+Ytf2lOs+TWP9ZtvzIIOzpR/x8n0 wqP/9XVf+Z9P9U//+aQ99GbP9C0Mcq1/9pkP+6uP8BIe6oWb+vhO+4Ed+4ov/A0P94Yvs0Y/91k/ 9rsv+r0P+mbN+7n/+tpvysVfziCN/dXP/ajfkuBv/Yzfv4rq/WIv/ouMzzd/9x6NPl0u+PwZ/15e 46eCccNd//a3fP8AYU/gQIIFDR78lzDhQYQKHT5UyFDiQIgVLV7E6HDiRo4dPX70mFHkSIsgDZIs aVLlyo0oXb6EGTMiS3syF9K0mVMnzZMjQdrkqRMoT6JFVQqVGXSoUaYdkT6FilFpUpxRraak6LOp xJxTr2bcGlZsza8ivcIcmzZrWbZLV3at2hbqT6os4dqVi1Xt3qN5K559yXesX8Ja8dZ9W/gfXcWL 48YETFjw5I+NZx6GTLmpZc6XEyPu63miy8eKI6M8nVfzaq6OQ2fGjJZ10c6dUxsWWBvi7ba8wZYu PHvyRd9SgZMWXly3VeVuTd793Lj538evZSePHfg46u0ksap3X142utnZ0K0HB0++vPPvldkzhj3+ env44e2D1mz+Oefpu5Prp48jAN3Drz7tAiSwtrAUFG7AkPhjSK7/3kOwtQITnO885Cp06j4PLxTM wQ4/7K1BCgsizkQQR4xPQ+44FFA0C0kMb8IVY0RqP8tslE7FFnX80cANsfMOxq1s8zFDIJUU0i8e TUvyQPmGdLFI2mjE8sMnpawSty5LXG/HKKlckssyyeQoIAA7 ------=_NextPart_000_0009_01C75E67.469B6520-- From sip-bounces@ietf.org Sun Mar 04 07:24:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNpiF-0007Pb-3Z; Sun, 04 Mar 2007 07:21:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNpiD-0007GV-76 for sip@ietf.org; Sun, 04 Mar 2007 07:21:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNpi9-0008De-UT for sip@ietf.org; Sun, 04 Mar 2007 07:21:13 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2007 07:21:10 -0500 X-IronPort-AV: i="4.14,246,1170651600"; d="scan'208"; a="114892861:sNHT45326040" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l24CL9ci022911; Sun, 4 Mar 2007 07:21:09 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l24CL9ZR000914; Sun, 4 Mar 2007 12:21:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 07:21:09 -0500 Received: from [192.168.1.104] ([10.86.240.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 07:21:08 -0500 Message-ID: <45EAB9B4.4070508@cisco.com> Date: Sun, 04 Mar 2007 07:21:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <00a201c75deb$8e899ef0$0601a8c0@BEMBUSTER> In-Reply-To: <00a201c75deb$8e899ef0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2007 12:21:08.0919 (UTC) FILETIME=[96D70C70:01C75E57] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1090; t=1173010869; x=1173874869; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Updated=20GRUU=20spec=20-=20big=20changes |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=V+vO56ym6dTupNqZT2JBZyBK8rmHOTsmLe3sV2si50k=; b=ouC/wWYeW8RBjJZ4RkP/3N/4aHBube+qkclK3S/zI2AeSO76/NgPDorBu34n5DxWOax0ND8K /1hteWDqSUdCI0mmmquudyN3RMnKGBFKJaGzulJDhwvAS9bFwvMr3QeM; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: > Jonathan Rosenberg wrote: > >> I've submitted an update to the GRUU spec. Until it appears in the >> archives, you can pick it up at: >> >> http://www.jdrosen.net/papers/draft-ietf-sip-gruu-11.txt >> > > Jonathan, > > Two minor comments: > 1) I believe a UA is allowed to add a 'transport=tcp' parameter when > using a GRUU obtained from a registrar, perhaps this should be mentioned > explicitly somewhere (e.g. section 4.4). I don't think so; the GRUU terminates on the registrar, so only the registrar knows what transports are really supported. > 2) (nit) in light of rfc4320, the references to 18x responses to > SUBSCRIBE and REFER in section 4.4 should be removed OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From dlersuji@mercyherbs.com Sun Mar 04 10:31:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNsgW-0002y1-5l for sip-archive@lists.ietf.org; Sun, 04 Mar 2007 10:31:40 -0500 Received: from [89.242.70.104] (helo=mercyherbs.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HNsgR-0007Pq-Aa for sip-archive@lists.ietf.org; Sun, 04 Mar 2007 10:31:40 -0500 Message-ID: <0c5201c75eaa$c531e060$9f29f460@dlersuji> Reply-To: "Deedee Foster" From: "Deedee Foster" To: "Catina Castillo" Subject: Did You Know Date: Sun, 04 Mar 2007 22:16:34 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_0DF_7B6C_863EE25D.E2DEA036" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 X-Spam-Score: 2.4 (++) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae This is a multi-part message in MIME format. ------=_NextPart_0DF_7B6C_863EE25D.E2DEA036 Content-Type: multipart/alternative; boundary="----=_NextPart_376_1B24_E8A43FA2.9A74A27A" ------=_NextPart_376_1B24_E8A43FA2.9A74A27A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable lock upset unit coloem "Incessantly, alas!" cried the abb. histrionic jo= yously "He abdicated fallen at Fontainebleau bounce in 1814, and was se "= The king himself.""Since 1811." key "Then degree government you have nothing more owner to do here?" Thi= s second departure was direction followed rich summer by stir a long and = f Meanwhile Fernand ground made give his wool tired appearance, poured= out "No--everything spark slide record is glue all right now." knee slow "And you have discovered a means detail stone of regaining ours= quash Dants shuddered; catch this stocking man had split been four years = lon"The king! met I fall upon thought he was range philosopher enough to"= Do equally not dig any throat more," opinion promptly said the voice; "on= ly tell "Then cautious shame sweep you can come mix and dine with me?" shoe cam= p "He is the cause hand opinion of all this misery--I am quite su learn= ing steady "I don't bitter burst think so," answered the other; he's too = s   "I field really must ask you to punishment excuse cough milk me, M. Morre= l. My doubt slip wound "I have; if it were only soup possible to place a deafsh= y "On rid lost heard a level with the floor."sting "But, father, modern w= hisper take care; when society our turn comes, ourwent miniature noisy po= werful "How is it concealed?" church pain "Right, Dants, behind judge quite right. I always knew you we= r "You don't sticky mention blow those thought who went aided and abetted= the "Surely," answered shoot Danglars, "one shiver worry cannot wed be = held r "And," remain sniff very inquired laugh Dants, with some hesitation, "do = "I crush do drink stocking boy not understand you." "He shall be both gleaming lively forget weather blind and deaf," replied= the you"Behind my bed.""You rely dig on delight seriously struck the usu= rper's return?""Has ornament your bed bag thing been moved since servant = you have been a pri "Well, chess I believe, my dear pin Edmond, silky water though I have no = slope hourly "You can, theory indeed, when the quit arrow lights point = down Meantime wire bottle the subject of the frantically square arrest = was being canva operation easy "No, copy cool no," cried the abb; "impossible!" Dants end= "No.""We do."gladly "What does your expansion apologise lock chamber open= on?" "Yes, station way he likes to shelter keep himself shut up company in his= litt"What think you, list Danglars," said thoughtfully music sternly one= of the party, sanguineous exchange "Why," replied he, "I monthly thing = think it just possible Dant smoggy fallen "That proves, suggest at least, that on he has wanted for n= ot parturient "Are shear you strong?" the abb purpose asked nose one day of = Dants"A corridor."glow "You are mistaken; across he brief. bow will not a= dvance two leagues"And the corridor?" prison Dants stocking without smiled. "My father is proud, give sir, and = if he "But how could yell done boot he have done part so without your= knowle "Why, as root for that, I stretch volucrine could only know w= hat breed I was to   "Well, then, after this butter silk cloth first visit sometimes has been = made"On a court." ------=_NextPart_376_1B24_E8A43FA2.9A74A27A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



lock upset unit coloem "Incessantly, alas!" cried the abb. &= nbsp;histrionic joyously "He abdicated fallen at Fontainebleau bounce in = 1814, and was se "The king himself.""Since 1811."   <= BR> key "Then degree government you have nothing more owner to do here?" = ; This second departure was direction followed rich summer by stir a= long and f    Meanwhile Fernand ground made give his= wool tired appearance, poured out  
"No--everything spark slide record is glue all right now."  &nb= sp; knee slow "And you have discovered a means detail stone of regaining ours= quash Dants shuddered; catch this stocking man had split been four years = lon"The king! met I fall upon thought he was range philosopher enough to"= Do equally not dig any throat more," opinion promptly said the voice; "on= ly tell     
"Then cautious shame sweep you can come mix and dine with me?"  = ; shoe camp "He is the cause hand opinion of all this misery--I am q= uite su   learning steady "I don't bitter burst think so,"= answered the other; he's too s    
"I field really must ask you to punishment excuse cough milk me, M. Morre= l. My      doubt slip wound "I have; if it were only soup possible to place a deafsh= y "On rid lost heard a level with the floor."sting "But, father, modern w= hisper take care; when society our turn comes, ourwent miniature noisy po= werful "How is it concealed?"       &n= bsp;  
church pain "Right, Dants, behind judge quite right. I always knew you we= r "You don't sticky mention blow those thought who went aided and ab= etted the  "Surely," answered shoot Danglars, "one shiver worry= cannot wed be held r     
"And," remain sniff very inquired laugh Dants, with some hesitation, "do&= nbsp;     "I crush do drink stocking boy not und= erstand you."   
"He shall be both gleaming lively forget weather blind and deaf," replied= the you"Behind my bed.""You rely dig on delight seriously struck the usu= rper's return?""Has ornament your bed bag thing been moved since servant = you have been a pri  
"Well, chess I believe, my dear pin Edmond, silky water though I have no&= nbsp;  slope hourly "You can, theory indeed, when the quit arro= w lights point down   Meantime wire bottle the subject of = the frantically square arrest was being canva    
operation easy "No, copy cool no," cried the abb; "impossible!" Dants end= "No.""We do."gladly "What does your expansion apologise lock chamber open= on?"   
"Yes, station way he likes to shelter keep himself shut up company in his= litt"What think you, list Danglars," said thoughtfully music sternly one= of the party,  sanguineous exchange "Why," replied he, "I mont= hly thing think it just possible Dant  
smoggy fallen "That proves, suggest at least, that on he has wanted for n= ot     
parturient "Are shear you strong?" the abb purpose asked nose one day= of Dants"A corridor."glow "You are mistaken; across he brief. bow will n= ot advance two leagues"And the corridor?" 
prison Dants stocking without smiled. "My father is proud, give sir, and = if he     "But how could yell done boot he have = done part so without your knowle     "Why, as ro= ot for that, I stretch volucrine could only know what breed I was to = ;         
"Well, then, after this butter silk cloth first visit sometimes has been = made"On a court."           
------=_NextPart_376_1B24_E8A43FA2.9A74A27A-- ------=_NextPart_0DF_7B6C_863EE25D.E2DEA036 Content-Type: image/gif; name="iaehugxixluyda.gif" Content-Transfer-Encoding: base64 Content-ID: <70e0501c75eaa4c4a7c8d0190b78da@dlersuji> R0lGODdhjQGPAaUAAP////bS0u+ysvnn5+ylpeaMjNlOTsUAAONycu7u7M4eHtY+PuaBgQAAAMwA AP8AAMXR7t7d3qq33ZrE4o2i3GGi0jqEwejf0itztdbW1hxPk7m5uWh9wdrJtJmZma+usIyKjGZm Zn1xZ8wzANe/ms+yhcyZZrWSZtimbceMUKV1O3hUR4BPIv7otf7hnefGm1JHUj0vPv/LWSchKmM0 EuefN+STLNx0IZut33qQ17Y2C6ciBQAAAAAAAAAAAAAAACwAAAAAjQGPAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLmcDgoF5zW673/C4fBkgFAgBwwGRmPv/gIGCg2EDagADegcK AgQKCwFFAwUIaYSXmJmam2EECwVDDAeLAgABCJFDiYsEBJV9nLGys7SXCWqioEICCqwJAQGwQqIH oLyMtcnKy8xfDAsECQgIQwG9xQWQRAMLo9QAeqnN4+Tl5qYC0qSnqdzeegTb3YuglLAJBaXn+/z9 f5OPBlhbxIDAIXcHDHjSNQTBKG8D7jk0cMifxYsYveR5GG2egnhDFC0wBKzPAAEbRyET4giBKwYV M8qcSZPOvAMLBBS49rGh/spIniJlE3jzGzoAxCjWXMp0aUqcDBThTEWM0cBSekoFmMegSIGHjGI2 HUv23FMFBqSCdIhTAAK0avRQS6BnJUueBJ6JK8u3r7Kn0BR9K3AnjcBqlE4RFDZwFMwFdv1Knhxo QN58sFax2qrA6JJfDCptk0qNF0PKqFO72QrWgL5EAhKaMlglgQCpSuuo3s27TJ6brISsGomF10Nt TyzvLdOgufMGR5zzey69SPWlz6lcB7AdUAIGoJ6SEk5A35WUkZMIBL+zs1gx1Ltzb04L+pL49InI x4jfPpTt+83BTU/43KRUFwM45NkRv+DTy0eKHEhGddkxE6B++c3nn4Y1/l13YRIfVtaNAl2ZoogC y2kxiXlFJPCLAQrkc00BjZ0GX4bdAVghhvtRZx2OQMY3hJBKeJihhjsiqSN0R+LH4Y8+QtlkkCAe +aQQ/UHJI5ZO8mhlF3Q9hIAa6qDIRgAFpOUKTgMQMxJbxI2x5JZDEslllHfieaWRXdoZ3ZT+9Wef oHUuKeiGhBa6I59VbnilkosCqiieXYJh3CjQCGEAcmOgkYAjo8TjlkDX4PEgSDciKumdhbLq6p5U vloho/fFmuerWt7qJZKPGkErrLjmSqeuv8Kan5GthrFTa+WlyMUvJ3VTgGZzkSkYQgt+MWeyvHLH ra+rPrmtsUwkKiug/pE6Ku6xX/b5JYbBDvvtr+PSai4Y2Tw0Xhi3LQCNJyMRoJIADJT4FZvEZOsF n6o2XKyw6wYaLoXvgqvnuYNmGS/FGTsc5YfsFmlljrbWG+u9YAQQ1QIGTOuFIfkcXAwiBmHrrxqN mbrHhLbG2+22QPdsb8UQW9zqrOEmy7GiGA/rp9HykosrvSHDcct7WJyi0M1sUXQYAGwhwMBK1+ph 48JBNszt0sSyHbHEcH+LBMgnl9wuux07bXfa6lqct95xr2233CnjIQwWvxAmmCcCxMbKNCxhigZK AByc081yajyvn5pDyne6gtPdd+h5Unr334bq2Xm3Ij8t9aNUezy6/hcCQDYmFgka8JbukpeHEGRm IhRPIjqTmA/PrpMs38Wl+z0f4Ls22nroTPbsqtu3Kv9uiF72HTv0Uye5BZrvCWzmFCfVDCMBuucs hDqLIOCaEF3/glbtC6DS2/7So+bIAuDx3TD4MAVPKAAu7HAFtYYgsFFM6yQnOZWCBII1/vWGeX6R 2SIeoTtLOMEQodAXRexwGMulgjUJucUnBhIjwlTQgvsT32TYoi+wsEgJ7MvJ+0DlDQUKAYWoqgqa EpIHhbwQhkjcTYJYBjx9nW8JCDGAMHiYEFSBDVNDuFRUYnSLJHrRi4b4hU7k1404EeFqXlEJqlxx jQOU6C77Mg4k/ij3xTra8X1oKoAwfoEmfzFAGJpBDgLu4JE3/i4Sp2CAs+7ISDv2q2UzyuJbvLGL PwbyIPPQYSM3yUn6DayBcRIbW5CRoEi4oycmatlybiOaTrpSNVrTBwofw6YBolApoekDa6T4Q6w5 JEYAYF8rX0nMpXwtQodw0yoY4goUzowXJXKLFY+QCFS0CS/FzKZMPMFLmemChWuaHwBYCRkHOIAR AjMjE9AwjBqiUpvwLIfKQNES4WTSlPMY5IO04hrLiEkni0RCAWBCw4TshJfxTOhfNrWzypXoFNf4 BpzcMgqK5EErLKPRFMYGmeNEQieHU6hIMYGmStwSZzCpHCV+/jLOUl0Kkrk5ok2cWArljPSml2iF J3DyqYEJ4Xh2QOFc8hlIStywCrU7IDQs46+A4vSpbeBFaXqRhnnoIi/jhMmJSnGwj9xGnFk4SCvU EDaomlUOq/jGKUpRP0Sgwi1pugYkzPcJAHRRC7dxGREINkx/POCvf23DA4Qw2CMUlgyHRWxqBsKp yC2CKngwKTH2QLAAyBR9dTnbTBKb2Ct01rBL+KwRRKsJ0pbFfaagEUJK1EzRWAMt0QjDKfLh1It0 1rRRwC1hQ8sE3RLCt0oAbi2EusSdKTOYLgmIckLaBbfoQ2yX5cdthwDY0QIgsNTFbnWLsN3CHra7 1DVsYL97/t3yZle0g00vesN7Xeya17zpJYJ6w+td7bIXvu5tL3mFazWRKGZnl9LjNPJ6OMt+gTWZ mggapmlb7u72wdl9MHnfe9/4wpe+ELbue+fr3fvSt8MO3u2ER3xbENtXxBXeMITrywmZGaSMZB2Y RsWSCAPUVgrwI4hbULGTN2JkuiqWL3tHrOEhZ7i8uN2vhFds3Qk7GMQXXnKIoxzk+Fr4s0TmBLYq N55PTSOgoNKkip7hgIfY+Ie1zAiQnczkKhdZyiVOMoajDNj8ovjId84ylVMc5Atb+bznPTEnQIWi 2DRWCbV7SEqz9ppJYioeW9FsP9bsYTdLWciYhvKli3zl/k03udJ5NrKnLe3mP4cYy7PYqUvACsWi 5EHSTiiQXXaqkkoc1SKc5TOf9ZxiE8/ZtLkmbKfxbGEKY5rUmm6zk5e9a1HL4hTWfAINRxKb9MS6 cZM0I0QVXZM6x5nTgBb2aE/8XUEn271KDveTQZ3h7Qpb0IH2sLv7rF/5ojsjMoMECo1hOCc4Ihqn EDMc33nW4Bocz1ngr0g/JVeUqOWKnQGGOPjYCDW4A1UG9gqJCt4EOSMcCwpP6Hd40jgDxZgVm9IH /h7x0Yoe0TLM5fgT8hvy3tY8oVWB9KbQYkqRDAejmFJDAw/AYJkbvRkMP58YD0HcCHmylo0x49eO TvVk/hCsgpfSWUOF+PSZDbDqYD9HV9lX0VSMfRdytZYBwv6Gm7OdQSIBlYR4qIscl0bg+7OzZz+e cG9HWNxvPw9RyyiOxhjS0bZOot7p3Vu+g7zcgG9vHNxuwWURHSEMCVNDdyi/RSNR79rlb7K7gG7I L94Mp9+kZojuOILDKboWHG99vc1hyC/53u+uMO4lz/ve1/vdtg9972Ufb+DXmbvuPr7kU98Xgm1K Ri63pxo7WV3h8776LL797HP/++5av/T2zv73tx/62gMe/PY+v+mZLxkQGvB2bhWbRjk5fvVH3tmy Nz/2l09843/7939Xf9c3XwP4dwGYfQWIRBR0RsUk/oACmGm5Z2UchmQTSIAJqG7Kl4AOSIDW53sa GHyUF3jksIH2d2rxdnwoiH35Z3sU1n/cR4IF+IB2JoMIKIJMAYP7t3xHpoKAlnz5B3wHWHzC530c SHw0KG5HOG822G0IOIQWOF47yILoN3yzx1lPqF40V4RUSIVTyH9AeH8uuIS7wX7NAHohSAVkKIZl kYbLYIaoZ4BqmBpsqAxuiHpKGId4mId6uId82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO+IiQ GImSOImUWImWeImYmIlIBwGcCAERoImgeEadGAGk2IkxF4qSaIousooRAAESAAGoWIkR8IqkWIu2 /liKEvCJd+QisTgLCQABE9CJwjiMnRiMFMBIvNiLmgCMwTgBzviM0BiNz6iLu9hIq3iN2JiN2piN vTEBFCCN4AiOFFABsIiMp7g/25iO6riNqjEBFfCO8FgBFvCO8xiP9hiP5fgfjiJDMpGMMJQAFxCQ AjmQBFmQBkmQAHmOYwEB82gB84gBEBmRENmQGGABEokB8UiNTjAy3EMICtkiSOCP6HiQJFmSJBkB H/kns/Mn4CIIE+CQFmmRGOmQEfmQExmTFQmTGSAFQLIPAWlXpHgBACCQMQeQ+iglqUIfq7MFAGmS TvmUGaCRG0k0LPkjgiABMIkBGoCTGgCRW0mT/hG5lTnpkBuQklbJJc+jK8+DNx2zks+SjRdAigkQ AUJJl0L5k9pIl0/AkVR5BT2JlmLQlAMZlHGJkkEZlYQZkIRZiwWZARlglnWSlk3Ql38QAVmpARWg lV1ZkTfplVvZlfJoARxQllHQk8cSmUpZNd4CmIGZjoZ5AXNJigAgl9romEfJmmFQMZRpBYI5kI4Z kL8ZnLUomI4Zm8Y5kB3QAUK5l9WDmqnpnJH5M81pBgmwATJJkzCZnTGpnTTJAR7QAZAJL6rJK1XD l26ZBekYlwmQAYopl7SZjR2wk8wJnWr5nNJ5OlUJBr2pmI7Jnv0pnBHAngIZoBcQlev5mMi5/gHL OZWSKR0OmjchE6H2WQYX8AEccJEYmqER6Z0bIJUMqprPWZ6qIplhMJcHyZ4BSqBRKaAImQEfIJ8M ipanKaPVkzFDEp3Rg6NfsJ8FSor9WaCFiZgsGpcouqJ2KZAdoKDzCZgiyqQ2KqG4SQYRsAEgoKFW igEcAAIe0KHaMZ1N2qROWga/2Ziw+ZtzaaAt6gEf4KG1kpbo4qY2mqNyupu1QZBySaR0mac+OqSF CZxomqALWi4SE6ZwGqZCMp4U6qIXeqUS6Z0foJxWgCyFmppxWqhkkADJyadNuYqw6SIFuQFq+pil 6aWIspZxOiUkKix0SgVP2aomOaVKOpUf/nOqtEqjZ7mqTKmojAqRIRCq4Tk3f6kktkqiGPQFF5Ck HXCkreqivsqTpGqotUqowKqjXpCYrnqtRPoBpDmZ+/iscPqsUJqql9qKEvABHnChGpCu6pquISAC auqJv8oFuHqpGbABG8Cit2iLwGmuj4qSXTqok1qjrImowTqvUdCj2HqtAboBLwqZHGmqtfqXSBOl Y9CKwliu5xoC6hoC7aqmrziKawCwglCg9iqg+aqYoLqloloFkiqspoqbzKM658mbGRCfjJmwBVmL jkmla4oaFjuM9mquICACIKClH/ABxOiJIduRbzCXHaCtfBqXKfuigdoGBjsHF2Cv8fmf/lzbtV7r tU+rpSsrGb+YtJ1orxvwscRoi/GaEevJsBuQnMk5tcnatlggsrIwlwxrrh7Qt377t4AbuILbty/K pnyhs/kaoI6ZuPlqtxlRoEJbtFp6r46bBfzICQBZr0e7uZzbuZ77uZsbn7CZGutYutiYGkFas3K7 tf66i6n7tVxri4v7n0FZuf0okrG2ipQhmHuUjYxpu6R7jUwAvMrYBMIba0RZvIdouwlJvMpbiLj7 vNI7vdRbvdZ7vdibvdq7vdzbvd77veAbvuLbDCMwvjI3AuhbvkuAvlCQvkOQvupbBPBLBPNrBuwL APd7v+YrC/kbv0igv0xQvgKMv+oL/sAELAT9i8D+a78FvMBy4MDZBMFjAcAJrL/sa8EQPMBGYMAJ fMAe/L4C7L/1S8AcHMIgrMAo/AQjnAQGvL4Y3MIkLMLuy8ApDMNOsML/K8E5HL84rMAUPMNl0ME2 fMMy7MMefME8nMEwXMI13MDyi8RNnMJPbMJH7MRELMU5rML4u8UdfMJVjMU0/MFRkMQurMUD3MVR /MVtgMZS8MNpXME6DMRYTMVCvMAW/MZKjMdgzMJFfMAY/MFLvMUbbMdWzMZQDMIvTMiAXMg6rARu 7Mdk/McbLMhPXMlqzMQ/nMiVLMlsPMZ9XMcoPMQk7MWWDMr0y8j1u8SMnMYB/MmH/nzIYozIR8DE l0zIdLzKg3zLrNy+rqzLkjzFs6zItQzMpqzKuqzGVPDIxUzF/yvINrzMpWzFpxzMehzLfDzNwwzJ fCzMU0zGsQzN1pzNndwEyozLsJzLlozNpuzF4BzN1VwFXbzOciy/XPzN5izNRtzOp3zM40zN7HzP 4SzLe4zM8CvM/ZvKeSzOjXzN/6zHogzEqvzOCPzPCO3P+pzMcizPD33Q7qvJiOzA5zzCEc3J+OzI ruzQjazBz1zS9rzLAw3OoszQ1QzHjuzMEnzR60zK6gzQcBDTlOwFPl3GQC3NGh3H9UzLxYzOF53P PN3GRI3Lo9zMZ2zQTc3UEi3L/ksdxEEtBlst012wwkVt0g08vx5txIMsxiKdxyQ90ERczlI8z8Ac w7AM1nAd0hCt1t7cz3/o0wttBV2dxZnA12Hw1/48iXC9xn0t1IRw2GxA2Ge9v5Ad2ZI92ZRd2ZZ9 2ZgdiQMQkKurnM6b2fG02SRAAiVQ2qZdAqM9uqANdgBJ2qVtAq8N26dNAlW72gWHqadtAidAAibQ 26dt2uBp27WxSQng2rnN265t3Ka9rcI9vKfLSAPQAb9d2idQArDd28q93J9tvro7BAG53UzB27J9 2rut27ud3a/dAc2dBNEbm7VtQReAAimgAvR9AtVd2slNAvZt3+Pd2+8t3Lh7/o2F2bpIxNsnoAIi kOBFO97UrQKSCwLjfQIbsN5ndDjaiKfgjRHx3dsOzrm97dsHbrSba9onYAL/jdkBvo1Eyp4w1AEf fgIe8J8bYAIpoNsOrrKOKd0vrt7NLZICDptAPqCLm+H9oN/7fQIrO6U0rgIrsKW6eAHW/eIfQOTV 6+OsGLcouZ+KS+CqkQAlkAJHbuLvkwEmoAIsAAIv+j5R/uEq8AEnnp8U+7Kc4AJPZeGseLRmmrPJ abhka95HPuFCkLUI3rBCYORH7uB8DufiKud/kAAt4AKQHumSPukvsLWw+6NelIzYGAF43qc8Wq/B vRsX4OdHDqMuqq1PTur2/o3oo0qtrj4Hj94CpusiHaCmoNu5avrmqNG7LsLpVNueBunrul4WCaDq /H0PKarmR77frH6b3/qk0Uqpi34FLdACYVChIACj6Pg+d/7rA5rl7Tmlbs4bxb7s+w3odpWMhn7o LBDjrS6j0AmmDzqdWvDoQzDrvc64jZsAH5DtFnQPq5ikKJqvgW6LDDvsZOHlKmDuC++hF3DgDL8C ad7qb2qf8l6piOMCso7vnhq3nb26XusBIEDl+wDw+a6OQFmLB98bHXDg9P3y9C3m3l3mMP/yLCAC XErxgxqi0R6tWRDr1R70Qj/0Ql/rt37rOC+okfIHVxtr3H687G3w4363/ro5s4QQAS5f8/X94Tau 9fR95pCq89BqqRe/BY8O6TIw6Wo/6SRAtFr64AnOsTAw93Q/9yCg6xJr9XOjBU1vvE+fnoMp9Qiv 9NYR55wg6F6f+DZv8xI/tvoIsDxPoz2/BWtf+WpvAnMfAnUPAzHQ+Z7/+Z0fAtqen4jq7Jpg8p6a s/q+8n5J730fCBmQ9V+v+GbOAizw9Wee887qMYxu8T6PBS4gA8I//MRf/MV/AjMwA6C//MwfAqE+ rWPPNHKONGwp+WRP773i9OnOo6p/i6wfqaQa+U4arnGA+LhP+zDPAjQgAoQuE8Fv/PBv/MgfA5tf //YfAsxN+jXqrUrp/i1lLylA0BAChkNisQE4KpNK5xPqTCgT1cQlktFqO91uBBzefC5R89mJTDfV zGRzKXzD0XX7XZkxqfh9P5+FxY+FRsRjIwJPcZGx0c5FJlJykpLyZCYGRnOTs3NTpKMMTU5uze00 jk0VtY111Qh2lchxCsAqomNDd+xjVzfjSozMEcpo6Tj22K3NmNgZKqED5E9FsM8akGYF5CPj+Rv8 +QWlsrwyJdNTvdMDuK7ZFJl0znV5ni45tf6otLH2AmCGXl66bNEyBQuYMaKeGcuXzCG9fOGeJdjg QUQ1an8IaRMBYkMtiiNJmrmAgpw5lSnWtdQUopsdePvgPZQVjyY9/nmoiP0L2A1gUKEXpiQI82HY t3uyIDLVObPknWi5PIBYEQhbtUA0PILghihq2JIJSphAeTalShkmXK4L4SGUTDrxbO602+ruU6dM aFEB2OFDqKFCi4bxkNRZTb1r4DTlKfbOBS+6qopYcfkq5o9eB+ZiCBk0sQgmSKM1fRrFiZchWLd2 3RrG2w7u3s3dx2+vq4l5eS/rWQWM5MCDCQO4oOUDSJHEFJ+KiI+U3dBorgjtwstDVRDZs/fa0OWv t+njF1kkfR59+vOpX7d/bWhDhs/k6UfNkmsMXOJBjfLqRbS+AEeqbiiDtvDCoAKXE1DAaHRRD0L0 vJqQwgq3Owws/gY1/GaqyRDZLyiCCtqQRH+sOBEgK1I8kcUqACoxwAEG+MuXGm30D6kcddRxF/Fg /NGOKzLw8DsRRdRil8AWBJJJW1gkarkXoZGRyiqanI7KGY8zkMsDZ+sSzIOuHPMJo5DszMiCDMKl gyXJLLFFaKwI0s03w2Exyzz13DJMA8OIYD47gVSxTy2gvIU2QRVdlNEy/wwOxKEaHdNFEFsEo85J Nd10wxYjLY7TN1tkEdNQTT21yVHnRFXQJxNhFdZYZZ01NCxovRXXXGG1chEpdf0V2GDJvCJTOYU9 FtlkG+SVTmWdfRZakpiNltpqrb0W22y13Zbbbr39FtxwxR2X/txyzT33jBHQXUTddd2FYoR4260j XkbkdULeeZ/Id9976asXAIABVoRfOwbGw1989YV33nwPDk3gdh9+d7yIDV6Y3oA1trhfJTieuGKJ MUaDY5JHTndjhU9OuGMBS2by5GoPtnjgemseWV2cF/5YZIYD1rfgnx+2ueGefyYY6J5vPtpjnDXu V+eJpc456ZuHplrhprVuJGiT7bU66qpBFotnimYWGeujl46C5axbLhtqpuFmOO25L36baK3Xpntf puH12+244Qb53sFjTtdorwlO+WW5iyaxcWfO3rrssYX2GXO7Hac8cbw53/qOyTff3PKE0zbjatSN 1vzz0S1X/t3zpffuW2fFSz9d6KJTXztyYkQ3HHC2Z3dbc54LJnz15JH23HXchc8ZdOExzxxtf5Fv vXfFOa/7dOR3fj3iti8H/vnmo3/md+XVPhz64IlX//3z3Td/9NCTxl5p9jd2GPGWpa8/cMxjHb3u R7+8IQ5jY+Pd9/AnPwN27hslm5v48MU4Bj6Qb4NDIAaX57cJli5l8fPf/ManPu9xsIMNJB37Uvc/ F+LveLVDYTi69kEWVu+AuYNaAiW2wwBmbYEONFn6QPe6yzEvgArEXdCuF0QS9k+EldPfBUc4PRVW UYXZC5ARn0a2w9nviwziYhjRR0YCgkaC8KOgxyyoNwgC/rCEVxScCc0ImTXWh4t3g1keIVZHKNqR ZTYkoO6Sx0Tx5VCHDszhACnWyFCNEY1+hJ0jKRmsO/5Lki+s5CY52UlPfhKUoRTlKElZSlOeEpWp VOUqWdlKV74SlrGU5SwHBQYI3BKXEAADLXn5LKPkEpjBLFYvdTWjFxwTmRcYACkTEExnOnOY3AII MqkJkAFEM1sDKEENuGkDb3KTmyh5wTI9GYFnnjOY5BoANdnJTmuG6wXglOc85YmCFwTKXc1E5z5z iU1qXYCdJUBBCQha0Hbi81rxpOdC6WlPhJJLn/yUKAT86UtqliAFKUBJQQs60BJUk5zYGsA8v1mD ktrg/gY3oKcNamDPkJprohOVAAS+1YFjClSjx/SoQNHDUYIeU5nXKgFLu0nUGxDVqPI8aTgf2i1z 3lICUZ0pBKIKVala1apVpaqPtAXQF+DUnj4tiz1RYAKcmpWj96zWSIlqUpYedZ4q7WZK4QpOlr6g XFSVKgUoAFW+3pKvOMABVfm6175ataLI6gBBUZACE4wDNQTVaGNNMFm0lKCpwXqBNznrzboaFalH lcE3O+vNDozrAlEVLA44wAEKSCAHsX0tBXCQg77ytbASyK1qX5WtaOA0BQJFDUoy2tiBlsY0JUgs rTbb2RuMQKXOjS5KjXrU0trABJm9VgQksFrbUiAH/rXlaw5gq9vZRvW8gt0rV6+VABIQ17JocWxj NVrZs5qGNNo9wzxwUoybbOgF1vXmAm6wgAVwtsDSRemBr3uDE7AXD/xVRhTwIpdSLMU2YclAd1fb YQ97WKohFjEFIBzhxmQ4VBfYAHFVgJLzZLS+KjBLRisr47K+OLvMOfFjnrAbDQWYrinlpoFTOgIC F/jABoZug3UAghLXxhRQcQ6KKbxjHocmAzjA7Za53OXAfti7T5ZLf1FlnhqrAMZ8mGwK0JzRPtS3 sik4gXIcIWUoM+kCQSayZwtsZAMTuLRBLrAORPCB3pq4zlTeL4rtrGHzehm83x0vByQNaQ6IecyN /t5UNOLMZj+QJs2OjTOo5XyCOcck0Yu2R040HZYEnEDQdEWpgPlsXbrqANfb6EZiofKcV6hCyv3w b30i8AFI87W1uM2Ba1177BwYuiGKcQxjcsMggcAY29nWtpv5wJn4LPfKzonyr8Mdmg7o4MixVjdd DZzrj/RCPo3oNRvGrY8J91jY5RaLiivN5WXjNtnN9vKyQxJtfIz7KfW+d30sAoITbBviftgOvPWr ajP4eif5DlACTIDudcd6ASPANQu2gaEMRADc88a3GpCg6FWTOTQJEEi/Ac5sSrfWtTRfdjvAzZgq MwM6sWh1aIo9jTZvW+ITjw/KwRFscttk6GGJ/gAIcO3nP18d1zvQAcmVfnIA6fjiO2Y5sF3OD5jX agMgiO3a2W5bSlMg2ZFuOwdAUvFFz2XsPGlF1EHTH6NvpA9dl0/Pq6zqaTdD4/QRyAp0sAPHP97x W1/BRzA0m69HO+z1wEviC69vyAgEBJRu++hJH9vWcgPTd9g7uXsTHTiBXgSxl73svXKI2RB+FFYG esb/G6AIXMQymLkM5ZESn8GTJCK8yfvClZH8jYO+taWXPs5Rj3vnH34vPhaQZEjwoAqZQBckED94 Lk8RCcvjwk7he1SEdKMazQZQYZGwryVC9tzne/0DygDwcS79ZeOcA+AjUcBO76JjIvhL++pD/ksk owPEjwTSxFK0ZUYCgAI/hQIDIEtwT1tw4QNiDwA/EAS5IS7CJUSMxDo+JUWsRU9WkAVXUAOr5QIg ID9AQARco7Vcg/g2gKLCZQFR0AfL71n0xApakAhl5AWd5ZdwKaqQIjsq5DCQYqpuiem8hUqs6VO0 REasUCheypdUxQu/8ETKJaKcScQ+QKue6QhzJQGKkA1XUFtWhZmeKqb4KQ1/RUacBAyrJE6I6Vge xQ//UJf+8FH4kBA3RRAPEREHsRAXcVFIBVP+BAxVhREnsRHDMBJFYlooURM3kRM70RM/ERRDURRH kRRL0RRPERVTURVXkRVb0RW3aJQy6RWn/qNr/ghhwEZ1zoaPzAZ+2OWShGiDmsZ7xAaPepEPtQgY 2aaNgod8tuiN9MiIdhF6uId6WscZk3FDZFFXiEh2HkcZZSiKIAiRDGl3vBEZX4hmHmd42Agcs4iB dJGQfMaJdtGH9Ahp4vF5iBGTrNF3Cqhw8ueHhHGSwvF8/lGOVGaG7AdvqHEdj8iKEtIg6SeD6MgR zlEal7GFGKmPsNEeOQiR+AaLmtEdFYkin2ggPdJ54gaLEgmOyOd6ElIh46cbAzKEHlIk16ceWdKN CLKMBEh5wKchb9J4rEeGbrIjDQdrgNIbq1EYMxKHntElJSl9GHIpVdImSxIhjTKOJLIf/n3yc8Dn aZToIFnnJbVSe1DSJNtHLN3HKeWnLLEyhdDydqiIJ9uSK+vyGX0xcQQJZabxgoTygAYoIjUSiuZR d0hmGaOIeMpHKwfTGGNyJHFyiGgSMLeHKCfJLL+GiDxIKZtykQLpkJbIdGrHMCsSNK3xkoiSX3AR IaUHHimzex7zKEvyI/8mLysTjuYnKiEnjLTxFsGBHosxdCIJOH3zNzkTNUHIL5myeAJTNh2TH4vR OHmxOMfkF0OmOvtoM61mkDwzNl9THvVRN2MzOmeRkyAJkLLTPFnpOmlxOoNzPeNTPueTPuvTPu8T P/NTP/eTP/vTP/8TQANUQAeUQAvU/kAPFEETVEEXlEEb1EEfFEIjND4fgEIrVEJZsUIz9AEuNBUz VAk8NFY29Bk01AwsNApM1AkolEMZBEUBoEVN5UUZQUNVNEVJ9Als1EVFdEUDJEZDlEYdwURblEZR 1EKHVEd3tD5wtERBNEePVEh7tEZ19Ek3FEpn9EaZdElFlEiNVEq1lEqPFEmTVEmjFES31EnH9Eq7 9Eyt9ERxdEbBNE0/9EeDdE6/FErDdDreFAro1EvVNErlFE4B9U8HtUp/tEkHNUvNFFFJNFDxlD7Y tE3rVFAn9VCzdFHrtFEVFVH3VEk1dVL71FEFBEublEm5lEzRlFI9tVD9dFOvNFUx/vUM+tRQQ3U8 ptRN7TRNITVOL5VVI3VTe5RPCXVWa/RQh5VWR2JWNfVJK5VS68BMexVYDfVZLZVZg7VN5RRbjzUs PLVSbRVMuZVXd3VVc7VZxRVWc3RJifVOtfUb3nRNx3RUSXVVddVdY7VUdTVSXxRf0fVU2VUs9rVY k9VY5dVZixRW45Vc+9UOELZQObVR/RVZ1hViGVFiJ7YQK9Zi+RBjM5ZjO9ZjPxZkQ1ZkR5ZkS9Zk TxZlU1ZlV5ZlW9ZlA7QAXlZmAyRm13MABIAACkBnd5Zne9ZnfxZog1Zoh5Zoi9ZojxZpk1Zpl5Zp m9ZpnxZqn5YABIALGSUAGMAA/gwAARggarvWa78WbMNWbMeWbMv2axkAAbKWAQKAUQjAABaAAKp2 Zk8lAAogawnATgRgAQyAbec2VwIgawXgSgYgbQXXb4FFbxmASQbAABigDg+3VdJWbgMkABQAbyEX Wdx2cskDcC8XczN3ATZ3OuD2c53Fbh93ERAAAUr3WbZWQPSWdYOQbxludmPXWWCXPghgdW33WRbA cMejdi0s/6KiMUZBEcpOVAcWTh8WDZyUReu1WzeWR39EAHZ3OgD3eHtMLJCXe+sDeWU0U08USG90 Q6T1S12VTJi3Phagb0MDATxXJopB/iKMfsOhe0vCWAV2fFO0fM80W130TQa2/l3VNwoKQHFHV3S1 V4F9g8LuTdg4rx+Kl4FngS+Ml4Iv2OwcGBbETdrsNXr5VEUNtks/lHwDFldF+INNOF3/F12/1UOD FYUF1Vb/NIQRllRl+F0BmBGwNzQGYAEWAe/SQIiH7YIlGIOHeBYkWIkr2IKN2IgbmIkTLoqp1Ug5 1Vyz1Xmx2Eu1+H+rmF8ddlj1tYQlNXqFlYsB1YtXmEvJmIDPwABQNwqqF4jld4rpuIiROMOCuIJt 4w1Ur46PeL+0l97+OMPY2IXR94v5V5FbeEjVtZEdWUs9OJFZ+IaJ9Yy/WFLNl5KV13/DeIsdIXjF QnfneIGfmJDx+OLseJBX/s6P79jnLJgvVvnEOM+QrdiSJ1mHSRhbz3eEedlVfXmFE/l8c/WT+ZWM MXmYL5mSb5mRrxWX8QABflcsdJaUUZmJrdmVAfmIl5iOXU6WUzmQhfibrzmYq7iXu/hbS5h/gZmE 2bmdW1iSMZmZLbmW0dmR0Vd/l7eTA9WG74AB4DcsVLeaMdiUs9mJwTmJh5ibvfmUyXmBo3ictbmW z1mF4XmR7RmRPZmZj7mG/TeXddhUK7qi0zifMTqNL9oZqBk0GOCATSzxIBiJMzjcIhiPHQKbaxrx bJqIp7iD87WS9XeXM1mdMfqWNZqFO5pOP9hOzfeEcRWSFZZgi1pN1/hd/gW4DlQaMrAaWfh4fh06 T9s4YjMVrMkDYO1Aq8PirIWFq4k3psl6rIWFk5kknRshrUuirpNleMesrb/aqpMlXvs5eaX3Ce56 JAibd4/FsMMhsQ8bWBb7Gxz7HUZirbd3e79XKZrEso8ls6MCslO6Zn9ksru6JDa7IWCkoGOFtL2a PjqbGFg7NEKbrWN7PFJ7tPcatRODRFybrj8bt5OYyjSuCKJMnF95gmVakPHOpvn4OaC4iHX6jrk6 uV/5oIsb/3AjlpH74Hqt+Zo76Fg57LIb2Ig7oVWZuE/bs0NDt7t5lUtZoQfZ+VyZmwF5g+t4Jqab vOG7pjOPgp27j+lb/qHzu7kbGhk67ybiO6Kxeb7tW7sN+o8Vm7fR+sHrrMER2sBjOr5t+6b/m7nN u7/xe8Kt+eD2OKELWsER3MTvO8T3m7kpHMRPvIFTvHhp+wzSexFoXMO12br9u8HPD/8WnKBpesMx vMMrXLUvfIn7uLvtocQh+oH32shdz7ghGMoNfMq/O+iimyTeNzRG+bKzmb113MsVDbYZXMSDvMjJ 3L5R/MuRXJvX28VPm8RvHMcdesw9vM3DGc7nnBiiOTQCwHp7O8+3u8zD/MYPvKHn+77nHMYFXM3f fM0dXcBJ3L0ffdAne7qXHIrTXMbduH3Fwoeb7sPFjdpGnZx7PMn9/qs53Fy8fxvVV47Dm9y7J9zU S/nAq5vOBX3Vc5rREK+9Vz2cuduOKSIB3ng6DCCBK2nTt9pZkh0KBMAAxoNrS4nZ1XrZSyLar/fZ RSmvn2XaG2Xb0cDYycMApJmxhUWOycPZyz1Zxn19yV3dc8VtKTd0390O2VdA0JbedQUBInw8hh2g 8x1W7HZDfJjfAT5U7PbYQ8MA/t3gN4UBfhhGGBcBEr7hB1d1KX48CsB3K35S3LbgScTZ2Z3j89bA Ov1KnH0BCsDktfXjlaVuF4DPF6Vus1ZrudZsbx7nc17nd57ne55o0fZtG3flGzEAcNbnjx7pk17p l37ppzYA4HjkNaNe6qee6qve6q8e67Ne67ee67ve678e7MNe7Mee7Mve7M8e7dNe7dee7dve7d8e 7uM+6oMAADs= ------=_NextPart_0DF_7B6C_863EE25D.E2DEA036-- From sip-bounces@ietf.org Sun Mar 04 11:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNtY4-0006Qq-Tq; Sun, 04 Mar 2007 11:27:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNtY2-0006PM-TL for sip@ietf.org; Sun, 04 Mar 2007 11:26:58 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNtY1-0005gK-H8 for sip@ietf.org; Sun, 04 Mar 2007 11:26:58 -0500 Received: (qmail 597 invoked by uid 0); 4 Mar 2007 16:28:01 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Mar 2007 16:28:01 -0000 Message-ID: <001f01c75e79$e4c41d20$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <453DA2F3.1070009@cisco.com> <00a201c75deb$8e899ef0$0601a8c0@BEMBUSTER> <45EAB9B4.4070508@cisco.com> Subject: Re: [Sip] Updated GRUU spec - big changes Date: Sun, 4 Mar 2007 17:26:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Jonathan, >> >> Two minor comments: >> 1) I believe a UA is allowed to add a 'transport=tcp' parameter when >> using a GRUU obtained from a registrar, perhaps this should be >> mentioned explicitly somewhere (e.g. section 4.4). > > I don't think so; the GRUU terminates on the registrar, so only the > registrar knows what transports are really supported. In that case there seems to be a missing requirement: it should be possible for a UA to obtain a GRUU for a particular transport (in practice: tcp). While it is true that only the registrar knows which transports are supported, if it is RFC3261 compliant it MUST support TCP and TLS (26.3.1). So either we allow the UAC to assume support for TCP/TLS, or we need some signaling to indicate preference / supported transports Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 11:51:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNtvB-0003Ik-J3; Sun, 04 Mar 2007 11:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNtv9-0003BG-Ni for sip@ietf.org; Sun, 04 Mar 2007 11:50:51 -0500 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNtul-0000de-NW for sip@ietf.org; Sun, 04 Mar 2007 11:50:29 -0500 Received: (qmail 26932 invoked by uid 0); 4 Mar 2007 16:49:49 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Mar 2007 16:49:49 -0000 Message-ID: <003301c75e7d$269461d0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <453DA2F3.1070009@cisco.com><00a201c75deb$8e899ef0$0601a8c0@BEMBUSTER><45EAB9B4.4070508@cisco.com> <001f01c75e79$e4c41d20$0601a8c0@BEMBUSTER> Subject: Re: [Sip] Updated GRUU spec - big changes Date: Sun, 4 Mar 2007 17:50:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > In that case there seems to be a missing requirement: it should be > possible for a UA to obtain a GRUU for a particular transport (in > practice: tcp). While it is true that only the registrar knows which > transports are supported, if it is RFC3261 compliant it MUST support > TCP and TLS (26.3.1). > So either we allow the UAC to assume support for TCP/TLS, or we need > some signaling to indicate preference / supported transports > On second thought: any transport param (or port component for that matter) would be ignored by the registrar / home proxy when using the GRUU as an index into the location service. So the transport that gets used is the transport from the registered contact address (with possible exception of UDP->TCP switch for large requests). This implies that the UA no longer has a choice for transport upon initiating/responding to a dialog, it is determined at registration time. Should we add some words to make this explicit? Perhaps it would be good to state that the UA SHOULD use the obtained GRUU verbatim, without adding parameters etc Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 12:29:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNuUb-00065A-46; Sun, 04 Mar 2007 12:27:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNuUZ-00064x-5R for sip@ietf.org; Sun, 04 Mar 2007 12:27:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNuUX-0006rl-Lu for sip@ietf.org; Sun, 04 Mar 2007 12:27:27 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2007 09:27:26 -0800 X-IronPort-AV: i="4.14,247,1170662400"; d="scan'208"; a="396574460:sNHT46958168" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l24HRPCx013701; Sun, 4 Mar 2007 09:27:25 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l24HR7xS000041; Sun, 4 Mar 2007 17:27:19 GMT In-Reply-To: <456BE164.3080908@it.su.se> References: <456BE164.3080908@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2660A509-118C-4C4E-A4E2-D7B8157D070B@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound: question on flow token algorithms Date: Sun, 4 Mar 2007 09:26:47 -0800 To: Fredrik Thulin X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2139; t=1173029245; x=1173893245; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20outbound=3A=20question=20on=20flow=20token=20 algorithms |Sender:=20; bh=79dNU6kYPpQPlzSoWyibybu9/93zcIFKokjHCLXwN4I=; b=gnURqhYSC5bEzUf5KkewtJKQ6PsaqrwUwg58RKMLLuJk2OenrwasBbiudFj5f0q8kn/l+l8K 5uixeidgJ1Q09CiaoDC1kLPxF8Y2uGcD6H17pkUuSVNC+6Ql8CX2N23a; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 27, 2006, at 11:12 PM, Fredrik Thulin wrote: > Hi > > Outbound (-06) "5.2 Generating Flow Tokens" says > > "A proxy can use any algorithm > it wants as long as the flow token is unique to a flow, the flow > can > be recovered from the token, and the token can not be modified by > attackers." > > and then goes on explaining two stateless algorithms that both, if > I understand them correctly, would generate a static flow token for > a given flow (static for as long as the proxy is running). > > Can you please explain what attack scenarios this is meant to avoid? Imagine an attacker can modify the traffic between the edge proxy and the registrar, and Alice has registered and also the attacker has registered a UA. If the attacker replaces the flow token in Alice's registration with the flow token in his request, now all of Alice's calls will be forwarded to the edge proxy with the wrong token the edge proxy will forwarded the calls to the attackers UA instead of Alice. Alice's phone has been hi-jacked. > > Algorithm #1 MUST NOT be used if SIPS isn't being used between the > edge proxy and the registrar, but I don't really see which attacks > would be possible if algorithm #1 was used without SIPS, that would > not also be possible with algorithm #2 without SIPS. The attacker could modify the flow token to point at the attackers flow instead of Alice's flow. > > Perhaps the problem is that I don't interpret "can not be modified > by attackers" correctly - please explain what you mean by that too =). That the attacker could change the value of the flow token ether in the registration from edge to registrar or later in messages that were either setting up a dialog or mid dialog. > > /Fredrik > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 13:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvI7-00010m-UE; Sun, 04 Mar 2007 13:18:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvI6-00010h-J6 for sip@ietf.org; Sun, 04 Mar 2007 13:18:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNvI3-0003iN-V7 for sip@ietf.org; Sun, 04 Mar 2007 13:18:38 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2007 10:18:35 -0800 X-IronPort-AV: i="4.14,247,1170662400"; d="scan'208"; a="117818724:sNHT67462488" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l24IIZRR005550; Sun, 4 Mar 2007 10:18:35 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l24IIYxS008682; Sun, 4 Mar 2007 18:18:35 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <4086F1BB-3794-4C6F-87A0-886B91913FCF@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Sip] Outbound-07 comments Date: Sun, 4 Mar 2007 10:18:14 -0800 To: Kevin Johns X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6260; t=1173032315; x=1173896315; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Outbound-07=20comments |Sender:=20; bh=fzMfktEEdwGG867Uy131YclOxJ1kgbhrI4i/zqj5b3U=; b=EU5buPL/3XKMALuLYp+amVC34kv93RDRsxvWZOE9VUriSIxqb3oxrTEMFfzY+xfuygq7oRNY IwlsGjzaAXtX/PUDUcXKTD2FI6k2URrbm8PjCUKvzBs+x9EWyYCvXeuz; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Many thanks - good comments - fixed the easy one and unfortunately =20 did not fix the one hard one on restructuring stuff to make things =20 clearer On Jan 19, 2007, at 9:41 AM, Kevin Johns wrote: > I did a read of Outbound-07 and have a few comments for =20 > consideration. Overall this is a solid draft. > > Regards, > Kevin > > Introduction, > First paragraph, Second to last sentence has a typo - Similarly =20 > there a NAT could be present,=85 I think if you remove 'there' the =20 > sentence would read correctly. fixed > > 4.2. Initial Registrations > This section seems to cover both initial registration and re-=20 > registration procedures. It might be helpful to break out the re-=20 > registration requirements into a separate section. fixed to cover both in this section > > 4.4.2. Keepalive with STUN > Can you make the text normative? Specifically, if no other =20 > keepalive mechanism is being used and the keepalive parameter is =20 > present in the URI, the UA MUST periodically perform keepalive =20 > checks by sending STUN binding requests=85 fixed > > 5.3. Forwarding Requests > The second sentence states, > "If the Edge Proxy receives a request where the edge proxy is the =20 > host in the topmost Route header field value, and the Route header =20 > contains a flow token, the proxy compares the flow in the flow =20 > token with the source of the request. If these refer to the same =20 > flow, the Edge Proxy removes the Route header and continues =20 > processing the request." > > When would this ever occur? This seems to imply that the UA is =20 > originating a dialog initiating request and inserts a route header =20 > with a flow token which identifies the flow the UAC sent the =20 > request on. There are no requirements in the draft indicating the =20 > UAC must do so, further RFC 3327 does not indicate the UAC should =20 > include the Path header received in the response to the REGISTER as =20= > a route header in a dialog initiating response. This happens when an incoming INVITE goes to the phone that =20 registered using outbound - the home proxy will look up the flow =20 token in the registration and insert that when it sends it to the =20 edge proxy. > > Additionally, This section talks about 'if the Edge Proxy =20 > determines the Route header contains a flow token'. How does it =20 > determine this? I assume based on the presence of the 'ob' =20 > parameter which was in the Path header. If this is the case, it =20 > might be clearer to indicate if the Route header contains the 'ob' =20 > parameter the Edge Proxy must do xyz=85 > It tries to decode it using the Algorithm 1 or 2 (or some algorithm =20 it uses) and if it works and the proxy believes it is a flow token it =20= created then it uses it. > 6. Registrar Mechanisms: Processing REGISTER Requests > First paragraph, suggest restructuring to cover, no sip.instance, =20 > sip.instance only, sip.instance with reg-id and reg-id only. Also, =20 > none of this text is normative. Given it is updating the binding =20 > procedures defined in RFC 3261 it might be useful to make this =20 > normative. This might be better - I just can't bring myself to get the energy to =20= rewrite this now. If you think this is critical, bug on the next =20 version to fix it. > > Sixth paragraph, why is the registrar required to store the reg-id =20 > if the rules above are invoked and the registrar ignores this =20 > parameter? While this is the simplest thing to do, it affects the =20 > re-registration procedures as the registrar has to remember that it =20= > previously ignored the reg-id and cannot use it to determine which =20 > contact to update on re-registration. I think the intended =20 > operation is clear given the text on initail registration (if the =20 > ob parameter in the first path header entry is absent ignore the =20 > reg-id), but the one sentence on re-registration (same paragraph) =20 > does not call out these rules. think I agree but I did not change text > > Finally, there are no requirements on how the registrar manages the =20= > contacts for a given AOR-instance-id combination. Would it be =20 > possible to add a paragarph to cover registrar contact management =20 > in the case it does not have a direct flow with the UAC? on this one - I'm lost on what cases it is that needs to be covered =20 but I think the meta point is restructureing this text to cover all =20 the cases would make it better. > 9. Example Message Flow > The 200 OK responses to the REGISTER requests do not contain the =20 > Path header. Given the UAC is required to support this and can =20 > optionally inspect the value returned in the REGISTER response, its =20= > should be included for completeness. Hmm - the path header would be empty so is the right thing no header =20 or a header that just says "Path:" with no header field values. The =20 syntax of the path header indicates that it is not allowed to be empty. > > Message 8 =96 Why would the Edge Proxy record-route with a flow =20 > token? This is a mid-dialog issue and given it is out of scope of =20 > outbound should not be covered in the message flow, or indicated =20 > that the secondary edge proxy may record-route and optionally =20 > include a flow token with a disclaimer that this may affect mid-=20 > dialog failover capabilities. Well it needs to do something to make sure that when future messages =20 arrive, they have the flow token in them so that the edge proxy knows =20= what flow to forward them over. > > ~~~~~~~~~~~~~~~~~~~~~~ > Kevin C. Johns > Project Director - PacketCable Communications Protocols > CableLabs=AE > 858 Coal Creek Circle > Louisville, CO 80027-9750 > Phone: 303.661.9100 > Direct: 303.661.3303 > HTTP://www.CableLabs.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 13:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvIm-0002Pn-MM; Sun, 04 Mar 2007 13:19:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvIk-0002FC-DP for sip@ietf.org; Sun, 04 Mar 2007 13:19:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNvIj-0003nY-0n for sip@ietf.org; Sun, 04 Mar 2007 13:19:18 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2007 10:19:16 -0800 X-IronPort-AV: i="4.14,247,1170662400"; d="scan'208"; a="44983582:sNHT48966885" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l24IJGOZ016600; Sun, 4 Mar 2007 10:19:16 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l24IIYxT008682; Sun, 4 Mar 2007 18:19:15 GMT In-Reply-To: <45B4756A.3000000@db.org> References: <45B4756A.3000000@db.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95F45EDE-966F-4290-9E23-DD51B4CC1991@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-07 Date: Sun, 4 Mar 2007 10:19:00 -0800 To: "Alfred E. Heggestad" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3893; t=1173032356; x=1173896356; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-outbound-07 |Sender:=20; bh=/t1NINZMpA+pBmNp1VO0dajh0fGFsIVwE17MK3U+JFo=; b=UFjJhcEFwrujt7WQ+QO8elRRpH0h3Pl81T3WUcFDPQCzxIZ/ziVP4Hde2HKcVK1ABQ9sbupX L/hq7/kRe4X2/BGk4G0SLMEs+jhJxVoFUQzsKcQWh0MWMpmiR4ab2Nnl; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 22, 2007, at 12:27 AM, Alfred E. Heggestad wrote: > Comments on draft-ietf-sip-outbound-07 > > > > 3.5. Keepalive Technique > > > > For connection-less transports, a flow definition could change > > because a NAT device in the network path reboots and the > resulting > > public IP address or port mapping for the UA changes. To detect > > this, requests are sent over the same flow that is being used > for the > > ^^^^^^^^^^^^^^^^^ > > suggest renaming to "STUN Binding Requests are periodically sent ..." uh - sort of fixed - the latest version has three types of keep alive so it is weirder > > > > 4.1. Instance ID Creation > > > > Each UA MUST have an Instance Identifier URN that uniquely > identifies > > > > ... > > > > The UA SHOULD include a "sip.instance" media feature tag as a UA > > > > Why should the UA have a URN if it cannot use it in the signaling ? > Maybe change SHOULD to MUST ? fixed - the only times you don't want to do this are privacy related > > > > 4.4. Detecting Flow Failure > > > > The time between keepalive requests when using UDP-based > transports > > SHOULD be a random number between 24 and 29 seconds while for > TCP- > > based transports it SHOULD be a random number between 95 and 120 > > seconds. > > perhaps a silly questions, but should this interval change for each > keepalive request? I.e. should the UA re-calculate a new random value > for each keepalive request, or should it only calculate it once and > then re-use the same value for all subsequent keepalive requests. > > in any case this is implementation specific but might be clarified. clarified (nice catch by the way) > > > > 8. STUN Keepalive Processing > > > > it seems to me that the logic of detecting if the SIP server supports > STUN multiplex is too complex and might lead to buggy implementations > or operational problems. 100% agree with you - the whole scheme is nuts IMHO > > would it not be better for the client to check the Supported: sip-stun > option tag in the 200 OK response for the REGISTER message? Well this would not detect if the edge proxy supported it or not but I think we should be able to come up with something about this simple to solve it. > > the behaviour of the SIP server can also change over time, i.e. moving > from old-style SIP server w/o STUN to support sip-stun, and vice > versa. > the client will check the sip-stun option tag for each 200 OK and > either > enable or disable STUN Binding Discovery. The behavior should not change without the current flows failing and re-registration. Let me walk through an example. First you configure out outbound proxy set as old.exmaple.com and everything is running. Then you put up the new proxy, configure your outbound set as old.example.com,new.emample.com;keepalive=stun but keep incoming calls going to old proxy. Once all the UA have updated with this and are registered with the both proxies, you change you DNS so incoming call go to the new proxy. Once all the new calls are going to the new proxy, you change the outbound proxy set to remove the old proxy and once all the UA have updated with that config you take the old proxy out of service. At all points in time both incoming and outgoing calls would work. > > > > > > > > > General comments: > > could we also include some example message flows between the Edge > Proxy > and the registrar? > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 14:37:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNwUa-0007F9-IR; Sun, 04 Mar 2007 14:35:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNwUZ-0007Eu-6h for sip@ietf.org; Sun, 04 Mar 2007 14:35:35 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNwUV-0005il-Ps for sip@ietf.org; Sun, 04 Mar 2007 14:35:35 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l24JZCun017401; Sun, 4 Mar 2007 13:35:13 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 13:35:12 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 20:35:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Mar 2007 20:35:10 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on draft-ietf-sip-location-conveyance Thread-Index: Acdej4mj/O9JrzFmQymSmiU/ji8DbgAAA6ig From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 04 Mar 2007 19:35:11.0006 (UTC) FILETIME=[39222BE0:01C75E94] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: geopriv-chairs@tools.ietf.org, jmpolk@cisco.com, dean.willis@softarmor.com Subject: [Sip] WGLC on draft-ietf-sip-location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946374089==" Errors-To: sip-bounces@ietf.org --===============0946374089== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpUaGlzIGlzIHRvIGFubm91bmNlIGEgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb2YgDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtc2lwLWxvY2F0aW9uLWNvbnZleWFuY2UtMDcudHh0DQoNCkR1ZSB0byB0aGUgcHJlc2VuY2Ug b2YgSUVURiM2OCBpbiBQcmFndWUsIHRoaXMgaXMgYW4gZXh0ZW5kZWQgbGFzdCBjYWxsIChmb3Ig Zm91ciB3ZWVrcyksIGFuZCBjb21tZW50cyBzaG91bGQgYmUgcHJvdmlkZWQgYnkgc3RhcnQgb2Yg YnVzaW5lc3Mgb24gTW9uZGF5IDJuZCBBcHJpbCAyMDA3Lg0KDQpIb3dldmVyIGlmIHlvdSB0aGlu ayB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgdGVjaG5pY2FsIGlzc3VlcyB0aGF0IHNob3VsZCBiZSBy YWlzZWQgaW4gSUVURiM2OCwgcGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQgd2VsbCBiZWZvcmUg dGhhdCB0aW1lIHRvIG1ha2UgeW91ciBjb21tZW50IHRvIHRoZSBsaXN0LCBzbyB0aGF0IHN1Y2gg ZGlzY3Vzc2lvbiBpbiB0aGUgSUVURiBtZWV0aW5nIGNhbiBvY2N1ci4NCg0KUGxlYXNlIHByb3Zp ZGUgYWxsIGNvbW1lbnRzIHRvIHRoZSBTSVAgbWFpbGluZyBsaXN0LCBhbmQgYWxzbyB0byB0aGUg ZG9jdW1lbnQgYXV0aG9ycyBsaXN0ZWQgKGFuZCBtYWlsaW5nIGFkZHJlc3NlcykgbGlzdGVkIGF0 IHRoZSBlbmQgb2YgdGhlIGRvY3VtZW50LiBGb3IgZWFjaCBjb21tZW50LCBpdCBpcyBpZGVhbCB0 byBwcm92aWRlIHRoZSBjb3B5IHRoZSBzcGVjaWZpYyBwYXJ0IG9mIHRoZSB0ZXh0IHRoZSBjb21t ZW50IGlzIGFnYWluc3QsIGluIG9yZGVyIHRvIHByb3ZpZGUgY29udGV4dCBvZiB0aGUgY29tbWVu dCwgYXMgd2VsbCBhcyBpZGVudGlmeWluZyB0aGUgc2VjdGlvbi9wYWdlIGFuZCB0aGUgY29tbWVu dCBpdHNlbGYuIA0KDQpQbGVhc2UgYWxzbyBjbGVhcmx5IGluZGljYXRlIHdoZXRoZXIgdGhlIGNv bW1lbnQgaXMgZWRpdG9yaWFsL3RlY2huaWNhbCwgYW5kIGlmIHRlY2huaWNhbCB0aGUgZGVncmVl IG9mIHRoZSBjb21tZW50LCBlLmcuIG1pbm9yLCBtYWpvciBmbGF3LCB3cm9uZyBzb2x1dGlvbiwg b3Igd2hhdGV2ZXIuIFRoaXMgaGVscHMgaW4gYXNzZXNzaW5nIHRoZSBvcmRlciBpbiB3aGljaCBj b21tZW50cyBnZXQgYWRkcmVzc2VkIHdoZW4gdGhleSBhcmUgcmV2aWV3ZWQuDQoNCkluIHBhcmFs bGVsIHdpdGggV0dMQywgYSByZXZpZXcgdGVhbSBoYXMgYWxzbyBiZWVuIHNldCB1cCB0byByZXZp ZXcgdGhlIGRvY3VtZW50LCBhbmQgdGhpcyByZXZpZXcgdGVhbSB3aWxsIHJldmlldyBhdCBsZWFz dCB0aGUgc2lnbmlmaWNhbnQgY29tbWVudHMgZm9yIGltcGxlbWVudGF0aW9uLiBJIHdpbGwgYmUg YWRkcmVzc2luZyB0aGVtIGluIGEgc2VwYXJhdGUgbWFpbC4NCg0KQXMgdGhlIGRvY3VtZW50IGlz IGEgbG9jYXRpb24gc3VwcG9ydGluZyBwcm90b2NvbCwgdGhlIGRvY3VtZW50IHdpbGwgYWxzbyBi ZSByZXZpZXdlZCBieSB0aGUgR0VPUFJJViBncm91cC4gSG93ZXZlciBpdCBpcyBhcHByb3ByaWF0 ZSBmb3IgYWxsIHJlYWRlcnMgdG8gcmV2aWV3IHRoZSBkb2N1bWVudCBhZ2FpbnN0IHRoZSBHRU9Q UklWIHJlcXVpcmVtZW50cyBmb3Igc3VjaCBwcm90b2NvbHMsIHdoaWNoIG1heSBiZSBmb3VuZCBp biBSRkMgMzk2My4NCg0KVGhlIGFib3ZlIGRvY3VtZW50IGhvd2V2ZXIgZG9lcyBub3QgY292ZXIg bG9jYXRpb24gYnkgcmVmZXJlbmNlLiBUaGVyZSBpcyBhIHByZWxpbWluYXJ5IHNldCBvciByZXF1 aXJlbWVudHMgaW4gDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LW1hcnNoYWxsLWdlb3ByaXYtbGJ5ci1yZXF1aXJlbWVudHMtMDAudHh0DQoNCkZvciB3aGljaCB3 ZSB3b3VsZCBsaWtlIHRvIGFsaWduIHdpdGggd2hhdGV2ZXIgdGhhdCBkb2N1bWVudCBkZXZlbG9w cyBpbnRvLiBUaGVyZWZvcmUgaXQgaXMgYXBwcm9wcmlhdGUgdG8gcmV2aWV3IGFnYWluc3QgdGhp cyBkb2N1bWVudCwgYW5kIGlkZW50aWZ5IGRpZmZlcmVuY2VzLiBUaGVzZSBjb3VsZCBlaXRoZXIg YmUgdGFrZW4gYXMgY29tbWVudHMgYWdhaW5zdCB0aGUgZHJhZnQtaWV0Zi1zaXAtbG9jYXRpb24t Y29udmV5YW5jZSwgb3IgYWdhaW5zdCB0aGUgbG9jYXRpb24gYnkgcmVmZXJlbmNlIHJlcXVpcmVt ZW50cy4NCg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCktlaXRoIERyYWdlDQorNDQgMTc5MyA3NzYy NDkNCmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbQ0KDQo= --===============0946374089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0946374089==-- From sip-bounces@ietf.org Sun Mar 04 15:11:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNx2H-0007iN-0Y; Sun, 04 Mar 2007 15:10:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNx2F-0007iI-VQ for sip@ietf.org; Sun, 04 Mar 2007 15:10:23 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNx2E-0000x4-Nf for sip@ietf.org; Sun, 04 Mar 2007 15:10:23 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 1B3E93A0210B; Sun, 4 Mar 2007 12:10:20 -0800 (PST) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id B11F13A02109 for ; Sun, 4 Mar 2007 12:10:15 -0800 (PST) Message-ID: <45EB27A6.2040509@acm.org> Date: Sun, 04 Mar 2007 12:10:14 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] draft-petithuguenin-sip-fragmentation-responses-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just submitted a new version of this I-D. Until it appears in the archives, a copy can be found here: http://marc.petit-huguenin.org/draft-petithuguenin-sip-fragmentation-responses-02.txt Changelog: - Fixed ABNF for via-delta (Thanks to Stephane Bortzmeyer). - Added text for DTLS over SIP. - Changed "6??" to "6XX" - Added a IANA section. - Various nits. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 15:20:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxCF-0007b0-T3; Sun, 04 Mar 2007 15:20:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxCE-0007U8-3R for sip@ietf.org; Sun, 04 Mar 2007 15:20:42 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNxCD-0002KX-JH for sip@ietf.org; Sun, 04 Mar 2007 15:20:42 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l24JQWaX030203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 4 Mar 2007 13:26:33 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) References: <67D963E5-F872-45C6-B33D-47B3A6B33CAA@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Sun, 4 Mar 2007 14:20:39 -0600 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Subject: [Sip] Copy to list: Request for publication of draft-ietf-sip-acr-code-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here's a copy to the list of the publication request for draft-ietf- sip-acr-code ----------- The SIP working group would like to request publication of draft-ietf- sip-acr-code-04. This document is intended for publication as a Proposed Standard, and is chartered work-product of the SIP working group. A PROTO writeup follows: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Dean Willis, co-chair of the SIP working group. He has personally reviewed this document and believes this version is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from within the working group and was reviewed externally by members of ETSI TISPAN who established the requirements met by this document. It is a fairly straightforward SIP extension and should not require a great deal of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. One potentially questionable aspect of this document is that it makes a normative reference to the privacy functions defined in the informational RFC 3325. While informational, this RFC is the basis of the privacy mechanism in the current IMS specifications referenced by 3GPP and ETSI TISPAN. The reference is structured to say that "If you are using the privacy mechanisms defined in RFC 3325, then . . . " rather than recommending the RFC 3325 mechanism as a baseline. I believe this to be a reasonable down-reference. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is that the approach specified in this document is both reasonable and obvious. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The shepherd processed the document through the current version of idnits (2.03.9). This check noted the down-reference to RFC 3325 discussed above, and one minor formatting error (a doubled space in the title of a reference) that isn't worth revising the document to address. There are no known formal review criteria applicable to this document. (Note: Keith thinks this probably should have mentioned RFC 4485, but I don't think this is a formal review) The document is also lacking an "Intended Status" line in the front matter. The intended status of this document is "Proposed Standard". (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. See discussion under 1.d above. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section appears to be reasonable. It defines one new SIP response code to be placed in the existing sip-parameters registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no document sections written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines an extension to the Session Initiation Protocol providing a new response code that may be used to reject an anonymous request so that the requesting party can understand that the request was rejected because it was made anonymously and could reasonably be expected to succeed if retried without anonymity. Working Group Summary The requirement addressed by this document was identified by ETSI TISPAN. The SIPPING working group discussed the requirement and determined that a SIP extension would be required to address that requirement. The technique specified by this document was originally introduced in an individual document submitted by Jonathan Rosenberg and discussed in the SIP working group. The SIP working group rapidly achieved consensus on the approach and recommended establishing a working group milestone for this work. There was no controversy within the SIP working group on the direction of this work. Document Quality This is a very simple extension to the SIP protocol. It is expected to be widely implemented in SIP systems interacting with the switched telephone networks of the world. Since it addresses requirements from ETSI TISPAN, participants from that organization were asked to review the specification and reported that it is suitable for their needs. Personnel The document shepherd is Dean Willis. The responsible area director is Cullen Jennings. No IANA expert, MIB doctor, or other specialized contributor is required. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 15:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxGr-0004nd-TU; Sun, 04 Mar 2007 15:25:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxGq-0004nY-OW for sip@ietf.org; Sun, 04 Mar 2007 15:25:28 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNxGp-0002wL-Eo for sip@ietf.org; Sun, 04 Mar 2007 15:25:28 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l24JVIpI030227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 4 Mar 2007 13:31:19 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Sun, 4 Mar 2007 14:25:26 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Reminder: Intended status needed in front matter of drafts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been reminded that all IDs sent for publication are now expected to have an "Intended status" field in their front matter. xml2rc handles this in the "category" field of the "rfc" element. For example, I just revised the autoanswer draft, and it has the following: This produces an Intended status: of "Standards track" in the front matter section as reproduced below: SIP Working Group D. Willis, Ed. Internet-Draft Cisco Systems Intended status: Standards Track A. Allen Expires: September 5, 2007 Research in Motion (RIM) March 4, 2007 -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 04 19:38:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO1Aq-0003PW-RG; Sun, 04 Mar 2007 19:35:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO1Aq-0003PR-8a for sip@ietf.org; Sun, 04 Mar 2007 19:35:32 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO1Ao-0005nD-TN for sip@ietf.org; Sun, 04 Mar 2007 19:35:32 -0500 X-SEF-Processed: 5_0_0_910__2007_03_04_18_41_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 04 Mar 2007 18:41:18 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 18:35:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] WGLC on draft-ietf-sip-location-conveyance Date: Sun, 4 Mar 2007 18:35:26 -0600 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC on draft-ietf-sip-location-conveyance Thread-Index: Acdej4mj/O9JrzFmQymSmiU/ji8DbgAAA6igAAo4mIA= From: "Thomson, Martin" To: "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 05 Mar 2007 00:35:28.0274 (UTC) FILETIME=[2C431720:01C75EBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: geopriv-chairs@tools.ietf.org, jmpolk@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132270152==" Errors-To: sip-bounces@ietf.org --===============0132270152== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWRpdG9yaWFsLCBNaW5vcjogIDMuNCAmIDkuNDogIFdhcm5pbmdzIHJlZmVyIHRvIHVuc3VwcG9y dGVkICJzY2hlbWEiLiAgVGhpcyBzaG91bGQgYmUgInNjaGVtZSIgW1JGQzM5ODZdLg0KDQpUZWNo bmljYWwsIE1pbm9yOiAgNC4xICYgNC4yOiAgVGhlIGV4YW1wbGUgUElERi1MTyBkb2N1bWVudHMg aGF2ZSBhIGZldyBlcnJvcnMuICBSZWZlciB0byBkcmFmdC1pZXRmLWdlb3ByaXYtcGRpZi1sby1w cm9maWxlLiAgQ29udGludWVkLi4uDQoNCjQuMSAmIDQuMjogUmVtb3ZlIHRoZSB4bWxuczpncyBh dHRyaWJ1dGUsIGl0IGlzbid0IHVzZWQuDQoNCjQuMTogVGhpcyBQb2ludCBmb3JtYXQgaXMgZGVw cmVjYXRlZCAoZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnMpLiAgUmVjb21tZW5kIHRoZSBmb2xsb3dp bmcgZm9ybToNCiAgPGdwOmxvY2F0aW9uLWluZm8+DQogICAgPGdtbDpQb2ludCBzcnNOYW1lPSJ1 cm46b2djOmRlZjpjcnM6RVBTRzo6NDMyNiI+DQogICAgICA8Z21sOnBvcz4zMy4wMDExMTEgLTk2 LjY4MTQyPC9nbWw6cG9zPg0KICAgIDwvZ21sOlBvaW50Pg0KICA8L2dwOmxvY2F0aW9uLWluZm8+ DQoNCjQuMSAmIDQuMjogVGhlICJtZXRob2QiIGFuZCAicHJvdmlkZWQtYnkiIGVsZW1lbnRzIGFy ZSBpbiB0aGUgd3JvbmcgY29udGV4dC4gIEFuIHVuZm9ydHVuYXRlIGNvbnNlcXVlbmNlIG9mIHRo ZSBzdHJ1Y3R1cmUgb2YgdGhlIFJGQyA0MTE5IHNjaGVtYSBpcyB0aGF0IHRoZSAidXNhZ2UtcnVs ZXMiIHdpbGwgYWNjZXB0IGFueSBvbGQganVuayBwcm92aWRlZCB0aGF0IGl0IGlzIGluIHRoZSAi Li4uOmdlb3ByaXYxMCIgbmFtZXNwYWNlLiAgVGhlcmVmb3JlLCB0aGUgZ2l2ZW4gZG9jdW1lbnRz IHZhbGlkYXRlLCBldmVuIGlmIHRoZXkgYXJlbid0IGNvcnJlY3QuICBNb3N0IGxpa2VseSB0aG9z ZSBlbGVtZW50cyB3b3VsZCBiZSBpZ25vcmVkIGJ5IHNvbWUgVUFTcy4NCiAgUGxhY2UgdGhlIG1l dGhvZCBhbmQgcHJvdmlkZWQtYnkgZWxlbWVudHMgX2FmdGVyXyB0aGUgdXNhZ2UtcnVsZXMuDQoN CjQuMSAmIDQuMjogVGhlIGNvbnRlbnQgbW9kZWwgZm9yIHRoZSAicHJvdmlkZWQtYnkiIGVsZW1l bnQgZG9lcyBub3QgcGVybWl0IHRleHQuICBJdCBvbmx5IHBlcm1pdHMgZWxlbWVudCBjb250ZW50 LiAgPGdwOnByb3ZpZGVkLWJ5Pnd3dy5jaXNjby5jb208L2dwOnByb3ZpZGVkLWJ5PiBpcyBub3Qg dmFsaWQuDQoNCjQuMjogVGhlICJjaXZpbEFkZHJlc3MiIGVsZW1lbnQgc2hvdWxkIGJlIHJlcGxh Y2VkIGJ5IGEgImNpdmljQWRkcmVzcyIgKG5vdGUgdGhlICdsJyBpcyByZXBsYWNlZCBieSAnYycp Lg0KDQpFZGl0b3JpYWwsIE1ham9yOiAgKjogIEknZCBsaWtlIHRvIHNlZSB0aGUgbmV3ICdyb3V0 aW5nLXF1ZXJ5LWFsbG93ZWQnIGRlZmluZWQgaW4gc2NoZW1hIGFuZCBpbiBvbmUgb2YgdGhlIGV4 YW1wbGVzIChwcmVmZXJhYmx5IHRoZSB1bmVuY3J5cHRlZCBvbmUsIHNpbmNlIHRoZSBwcm94eSBp cyB1bmxpa2VseSB0byBiZSBhYmxlIHRvIHNlZSB0aGUgZW5jcnlwdGVkIExPKS4gIChJbmNpZGVu dGFsbHksIGlzIHRoaXMgcGFyYW1ldGVyIGFuIGV4dGVuc2lvbiwgb3IgaXMgdGhlIGludGVudCB0 byB1cGRhdGUgUkZDIDQxMTk/KQ0KDQpUZWNobmljYWwsIE1pbm9yOiAgMy40LjEyOiAgTm90ZSB0 aGF0IHByb3ZpZGluZyBhIHJlZmVyZW5jZSBvZiB0aGlzIG5hdHVyZSAod2hpY2ggd291bGQgYWxs b3cgZm9yIGEgZGVyZWZlcmVuY2Ugb3BlcmF0aW9uIHRoYXQgZG9lcyBub3QgdXNlIFRMUykgY291 bGQgY29uc3RpdHV0ZSBhIHBvdGVudGlhbCBwcml2YWN5IGxlYWsuICBVQXMgc2hvdWxkIG9ubHkg cmVzcGVjdCB0aGlzIHJlcXVlc3QgaW4gYW4gZW1lcmdlbmN5Lg0KDQoNClJlZ2FyZHMsDQpNYXJ0 aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEcmFnZSwgS2VpdGgg KEtlaXRoKSBbbWFpbHRvOmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2VudDogTW9uZGF5 LCA1IE1hcmNoIDIwMDcgNjozNSBBTQ0KPiBUbzogc2lwQGlldGYub3JnDQo+IENjOiBnZW9wcml2 LWNoYWlyc0B0b29scy5pZXRmLm9yZzsgam1wb2xrQGNpc2NvLmNvbTsNCj4gZGVhbi53aWxsaXNA c29mdGFybW9yLmNvbQ0KPiBTdWJqZWN0OiBbU2lwXSBXR0xDIG9uIGRyYWZ0LWlldGYtc2lwLWxv Y2F0aW9uLWNvbnZleWFuY2UNCj4gDQo+IChBcyBXRyBjaGFpcikNCj4gDQo+IFRoaXMgaXMgdG8g YW5ub3VuY2UgYSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvZg0KPiANCj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXAtbG9jYXRpb24tY29udmV5YW5j ZS0NCj4gMDcudHh0DQo+IA0KPiBEdWUgdG8gdGhlIHByZXNlbmNlIG9mIElFVEYjNjggaW4gUHJh Z3VlLCB0aGlzIGlzIGFuIGV4dGVuZGVkIGxhc3QgY2FsbA0KPiAoZm9yIGZvdXIgd2Vla3MpLCBh bmQgY29tbWVudHMgc2hvdWxkIGJlIHByb3ZpZGVkIGJ5IHN0YXJ0IG9mIGJ1c2luZXNzIG9uDQo+ IE1vbmRheSAybmQgQXByaWwgMjAwNy4NCj4gDQo+IEhvd2V2ZXIgaWYgeW91IHRoaW5rIHRoZXJl IGFyZSBzaWduaWZpY2FudCB0ZWNobmljYWwgaXNzdWVzIHRoYXQgc2hvdWxkIGJlDQo+IHJhaXNl ZCBpbiBJRVRGIzY4LCBwbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCB3ZWxsIGJlZm9yZSB0aGF0 IHRpbWUgdG8NCj4gbWFrZSB5b3VyIGNvbW1lbnQgdG8gdGhlIGxpc3QsIHNvIHRoYXQgc3VjaCBk aXNjdXNzaW9uIGluIHRoZSBJRVRGIG1lZXRpbmcNCj4gY2FuIG9jY3VyLg0KPiANCj4gUGxlYXNl IHByb3ZpZGUgYWxsIGNvbW1lbnRzIHRvIHRoZSBTSVAgbWFpbGluZyBsaXN0LCBhbmQgYWxzbyB0 byB0aGUNCj4gZG9jdW1lbnQgYXV0aG9ycyBsaXN0ZWQgKGFuZCBtYWlsaW5nIGFkZHJlc3Nlcykg bGlzdGVkIGF0IHRoZSBlbmQgb2YgdGhlDQo+IGRvY3VtZW50LiBGb3IgZWFjaCBjb21tZW50LCBp dCBpcyBpZGVhbCB0byBwcm92aWRlIHRoZSBjb3B5IHRoZSBzcGVjaWZpYw0KPiBwYXJ0IG9mIHRo ZSB0ZXh0IHRoZSBjb21tZW50IGlzIGFnYWluc3QsIGluIG9yZGVyIHRvIHByb3ZpZGUgY29udGV4 dCBvZg0KPiB0aGUgY29tbWVudCwgYXMgd2VsbCBhcyBpZGVudGlmeWluZyB0aGUgc2VjdGlvbi9w YWdlIGFuZCB0aGUgY29tbWVudA0KPiBpdHNlbGYuDQo+IA0KPiBQbGVhc2UgYWxzbyBjbGVhcmx5 IGluZGljYXRlIHdoZXRoZXIgdGhlIGNvbW1lbnQgaXMgZWRpdG9yaWFsL3RlY2huaWNhbCwNCj4g YW5kIGlmIHRlY2huaWNhbCB0aGUgZGVncmVlIG9mIHRoZSBjb21tZW50LCBlLmcuIG1pbm9yLCBt YWpvciBmbGF3LCB3cm9uZw0KPiBzb2x1dGlvbiwgb3Igd2hhdGV2ZXIuIFRoaXMgaGVscHMgaW4g YXNzZXNzaW5nIHRoZSBvcmRlciBpbiB3aGljaCBjb21tZW50cw0KPiBnZXQgYWRkcmVzc2VkIHdo ZW4gdGhleSBhcmUgcmV2aWV3ZWQuDQo+IA0KPiBJbiBwYXJhbGxlbCB3aXRoIFdHTEMsIGEgcmV2 aWV3IHRlYW0gaGFzIGFsc28gYmVlbiBzZXQgdXAgdG8gcmV2aWV3IHRoZQ0KPiBkb2N1bWVudCwg YW5kIHRoaXMgcmV2aWV3IHRlYW0gd2lsbCByZXZpZXcgYXQgbGVhc3QgdGhlIHNpZ25pZmljYW50 DQo+IGNvbW1lbnRzIGZvciBpbXBsZW1lbnRhdGlvbi4gSSB3aWxsIGJlIGFkZHJlc3NpbmcgdGhl bSBpbiBhIHNlcGFyYXRlIG1haWwuDQo+IA0KPiBBcyB0aGUgZG9jdW1lbnQgaXMgYSBsb2NhdGlv biBzdXBwb3J0aW5nIHByb3RvY29sLCB0aGUgZG9jdW1lbnQgd2lsbCBhbHNvDQo+IGJlIHJldmll d2VkIGJ5IHRoZSBHRU9QUklWIGdyb3VwLiBIb3dldmVyIGl0IGlzIGFwcHJvcHJpYXRlIGZvciBh bGwNCj4gcmVhZGVycyB0byByZXZpZXcgdGhlIGRvY3VtZW50IGFnYWluc3QgdGhlIEdFT1BSSVYg cmVxdWlyZW1lbnRzIGZvciBzdWNoDQo+IHByb3RvY29scywgd2hpY2ggbWF5IGJlIGZvdW5kIGlu IFJGQyAzOTYzLg0KPiANCj4gVGhlIGFib3ZlIGRvY3VtZW50IGhvd2V2ZXIgZG9lcyBub3QgY292 ZXIgbG9jYXRpb24gYnkgcmVmZXJlbmNlLiBUaGVyZSBpcw0KPiBhIHByZWxpbWluYXJ5IHNldCBv ciByZXF1aXJlbWVudHMgaW4NCj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LW1hcnNoYWxsLWdlb3ByaXYtbGJ5ci0NCj4gcmVxdWlyZW1lbnRzLTAwLnR4dA0K PiANCj4gRm9yIHdoaWNoIHdlIHdvdWxkIGxpa2UgdG8gYWxpZ24gd2l0aCB3aGF0ZXZlciB0aGF0 IGRvY3VtZW50IGRldmVsb3BzDQo+IGludG8uIFRoZXJlZm9yZSBpdCBpcyBhcHByb3ByaWF0ZSB0 byByZXZpZXcgYWdhaW5zdCB0aGlzIGRvY3VtZW50LCBhbmQNCj4gaWRlbnRpZnkgZGlmZmVyZW5j ZXMuIFRoZXNlIGNvdWxkIGVpdGhlciBiZSB0YWtlbiBhcyBjb21tZW50cyBhZ2FpbnN0IHRoZQ0K PiBkcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLCBvciBhZ2FpbnN0IHRoZSBsb2Nh dGlvbiBieSByZWZlcmVuY2UNCj4gcmVxdWlyZW1lbnRzLg0KPiANCj4gDQo+IFJlZ2FyZHMNCj4g DQo+IEtlaXRoDQo+IA0KPiBLZWl0aCBEcmFnZQ0KPiArNDQgMTc5MyA3NzYyNDkNCj4gZHJhZ2VA YWxjYXRlbC1sdWNlbnQuY29tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBh bmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJp dmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2lu YWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============0132270152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0132270152==-- From sip-bounces@ietf.org Sun Mar 04 22:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3ZT-0006D3-9p; Sun, 04 Mar 2007 22:09:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3ZR-00065Y-7H; Sun, 04 Mar 2007 22:09:05 -0500 Received: from mailipbo.vtcif.telstra.com.au ([202.12.144.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO3ZM-00080z-Tb; Sun, 04 Mar 2007 22:09:05 -0500 Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbo.vtcif.telstra.com.au with ESMTP; 05 Mar 2007 14:08:52 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id BF61C1DA81; Mon, 5 Mar 2007 14:08:51 +1100 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 5CA9241D44; Mon, 5 Mar 2007 14:08:51 +1100 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 14:08:51 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Perceptual objective media quality reporting Date: Mon, 5 Mar 2007 14:08:50 +1100 Message-ID: <903E4F74808D4F4B93635C9D9183EBAC016CA06B@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <257B18BFF522214E92EB52F3478B014E094688@psy01exch.intra.psytechnics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Perceptual objective media quality reporting Thread-Index: AcdbSZlLw9qRfvsQSU61gayfTs285QDibV5A References: <257B18BFF522214E92EB52F3478B014E094688@psy01exch.intra.psytechnics.com> From: "Robins, Ellen" To: "Ravi Raviraj" , , , X-OriginalArrivalTime: 05 Mar 2007 03:08:51.0241 (UTC) FILETIME=[99A86990:01C75ED3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0117402044==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0117402044== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75ED3.98F4EE24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75ED3.98F4EE24 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, There are few steps in this direction. http://www.ixiacom.com/ =20 Thanks and kind regards / Ellen Robins ViG Technology Manager Services Enablers Wireless Engineering & Operations Telstra Operations Telstra Corporation Limited =20 Ph 03 8627 8981 Mob 0428 309 250 Fax 03 9620 7864 Mail ellen.robins@team.telstra.com =20 The information contained in this email message may be confidential. If you are not the intended recipient, any use of, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify me by reply email and then delete the message. =20 ________________________________ From: Ravi Raviraj [mailto:ravi.raviraj@psytechnics.com]=20 Sent: Thursday, 1 March 2007 2:03 AM To: sipping@ietf.org; sip@ietf.org; avt@ietf.org Subject: [Sip] Perceptual objective media quality reporting Hi all, Over the last few years, a number of perceptual media quality objective measures and assessment techniques have been standardized by ITU-T. For example, MOS-LQO, MOS-CQO, etc. Each one of these parameters could have number of variations like narrow-band/wide-band, electrical/acoustical, full reference/no-reference, audio/video, etc. When applied within a network end-point, each media direction (ingress/egress) could have one or more of these values associated with it. We need a way to report these values efficiently without any ambiguity. These MOS values could be sent/distributed as perceptual objective quality SIP events. In this way, all the advantages of SIP like mobility, etc. will be pulled in. =20 I would like to propose a work/discussion item on an event package for this purpose. Even define/specify a quality reporting framework. Is there any interest out there? =20 I presume that, an event package work will be within SIPPING WG, where should we do the framework work? SIP/AVT? =20 Thanks. =20 Ravi. =20 This email and attachment are confidential. If you have received this message in error, please notify the sender immediately and delete the message from your computer. Psytechnics Ltd has taken steps to ensure that this email is virus free but the recipient should take necessary steps to make certain.=20 ------_=_NextPart_001_01C75ED3.98F4EE24 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi all,
There are few steps in this = direction.
http://www.ixiacom.com/
 
Thanks and kind regards / = Ellen=20 Robins
ViG Technology = Manager
Services = Enablers
Wireless Engineering & = Operations
Telstra=20 Operations
Telstra Corporation Limited
 
Ph 03 8627 = 8981
Mob=20 0428 309 250
Fax 03 9620 7864
Mail ellen.robins@team.telstra.com =

The information contained in this email message may be = confidential. If you are not the intended recipient, any use of, = interference=20 with, disclosure or copying of this material is unauthorised and = prohibited. If=20 you have received this message in error, please notify me by reply email = and=20 then delete the message.

 

From: Ravi Raviraj=20 [mailto:ravi.raviraj@psytechnics.com]
Sent: Thursday, 1 March = 2007=20 2:03 AM
To: sipping@ietf.org; sip@ietf.org;=20 avt@ietf.org
Subject: [Sip] Perceptual objective media quality = reporting

Hi = all,

Over the last few years, a = number of=20 perceptual media quality objective measures and assessment techniques = have been=20 standardized by ITU-T. For example, MOS-LQO, MOS-CQO, etc. Each one of = these=20 parameters could have number of variations like narrow-band/wide-band,=20 electrical/acoustical, full reference/no-reference, audio/video, etc. = When=20 applied within a network end-point, each media direction = (ingress/egress) could=20 have one or more of these values associated with it. We need a way to = report=20 these values efficiently without any ambiguity. These MOS values could = be=20 sent/distributed as perceptual objective quality SIP events. In this = way, all=20 the advantages of SIP like mobility, etc. will be pulled=20 in.

 

I would like to propose a=20 work/discussion item on an event package for this purpose. Even = define/specify a=20 quality reporting framework. Is there any interest out=20 there?

 

I presume that, an event = package=20 work will be within SIPPING WG, where should we do the framework work?=20 SIP/AVT?

 

Thanks.

 

Ravi.

 

This = email and=20 attachment are confidential. If you have received this message in error, = please=20 notify the sender immediately and delete the message from your computer. = Psytechnics Ltd has taken steps to ensure that this email is virus free = but the=20 recipient should take necessary steps to make certain. ------_=_NextPart_001_01C75ED3.98F4EE24-- --===============0117402044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0117402044==-- From sip-bounces@ietf.org Sun Mar 04 22:32:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3w7-00019j-Tf; Sun, 04 Mar 2007 22:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3w5-00019O-Jn; Sun, 04 Mar 2007 22:32:29 -0500 Received: from empbedex1.empirix.com ([12.38.203.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO3w4-00035K-40; Sun, 04 Mar 2007 22:32:29 -0500 Received: from EMPBEDEX.empirix.com ([10.16.0.92]) by empbedex1.empirix.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 22:32:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Perceptual objective media quality reporting Date: Sun, 4 Mar 2007 22:32:14 -0500 Message-ID: In-Reply-To: <903E4F74808D4F4B93635C9D9183EBAC016CA06B@WSMSG2103V.srv.dir.telstra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Perceptual objective media quality reporting Thread-Index: AcdbSZlLw9qRfvsQSU61gayfTs285QDibV5AAADe5rA= References: <257B18BFF522214E92EB52F3478B014E094688@psy01exch.intra.psytechnics.com> <903E4F74808D4F4B93635C9D9183EBAC016CA06B@WSMSG2103V.srv.dir.telstra.com> From: "Beith, Gordon" To: "Robins, Ellen" , "Ravi Raviraj" , , , X-OriginalArrivalTime: 05 Mar 2007 03:32:27.0274 (UTC) FILETIME=[E5ADE6A0:01C75ED6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0363320934==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0363320934== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75ED6.E2B4F42B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75ED6.E2B4F42B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable They are not alone...... e.g. www.empirix.com =20 =20 =20 ________________________________ From: Robins, Ellen [mailto:Ellen.Robins@team.telstra.com]=20 Sent: Sunday, March 04, 2007 10:09 PM To: Ravi Raviraj; sipping@ietf.org; sip@ietf.org; avt@ietf.org Subject: RE: [Sip] Perceptual objective media quality reporting =20 Hi all, There are few steps in this direction. http://www.ixiacom.com/ =20 Thanks and kind regards / Ellen Robins ViG Technology Manager Services Enablers Wireless Engineering & Operations Telstra Operations Telstra Corporation Limited =20 Ph 03 8627 8981 Mob 0428 309 250 Fax 03 9620 7864 Mail ellen.robins@team.telstra.com =20 The information contained in this email message may be confidential. If you are not the intended recipient, any use of, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify me by reply email and then delete the message. =20 =20 ________________________________ From: Ravi Raviraj [mailto:ravi.raviraj@psytechnics.com]=20 Sent: Thursday, 1 March 2007 2:03 AM To: sipping@ietf.org; sip@ietf.org; avt@ietf.org Subject: [Sip] Perceptual objective media quality reporting Hi all, Over the last few years, a number of perceptual media quality objective measures and assessment techniques have been standardized by ITU-T. For example, MOS-LQO, MOS-CQO, etc. Each one of these parameters could have number of variations like narrow-band/wide-band, electrical/acoustical, full reference/no-reference, audio/video, etc. When applied within a network end-point, each media direction (ingress/egress) could have one or more of these values associated with it. We need a way to report these values efficiently without any ambiguity. These MOS values could be sent/distributed as perceptual objective quality SIP events. In this way, all the advantages of SIP like mobility, etc. will be pulled in. =20 I would like to propose a work/discussion item on an event package for this purpose. Even define/specify a quality reporting framework. Is there any interest out there? =20 I presume that, an event package work will be within SIPPING WG, where should we do the framework work? SIP/AVT? =20 Thanks. =20 Ravi. =20 This email and attachment are confidential. If you have received this message in error, please notify the sender immediately and delete the message from your computer. Psytechnics Ltd has taken steps to ensure that this email is virus free but the recipient should take necessary steps to make certain.=20 ------_=_NextPart_001_01C75ED6.E2B4F42B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

They are not = alone……

e.g.

www.empirix.com

 

 

From: = Robins, Ellen [mailto:Ellen.Robins@team.telstra.com]
Sent: Sunday, March 04, = 2007 10:09 PM
To: Ravi Raviraj; sipping@ietf.org; sip@ietf.org; avt@ietf.org
Subject: RE: [Sip] = Perceptual objective media quality reporting

 

Hi = all,

There are few steps in this = direction.

http://www.ixiacom.com/

 

Thanks and kind regards / Ellen = Robins

ViG Technology Manager

Services Enablers

Wireless Engineering & Operations
Telstra Operations
Telstra Corporation Limited
 
Ph 03 8627 8981
Mob 0428 309 250
Fax 03 9620 7864
Mail ellen.robins@team.telstra.com

The information contained in this email message may be confidential. If you = are not the intended recipient, any use of, interference with, disclosure or = copying of this material is unauthorised and prohibited. If you have received this = message in error, please notify me by reply email and then delete the = message.

 

 

From: Ravi Raviraj [mailto:ravi.raviraj@psytechnics.com]
Sent: Thursday, 1 March = 2007 2:03 AM
To: sipping@ietf.org; sip@ietf.org; avt@ietf.org
Subject: [Sip] Perceptual objective media quality reporting

Hi all,

Over the last few years, a number of = perceptual media quality objective measures and assessment techniques have been = standardized by ITU-T. For example, MOS-LQO, MOS-CQO, etc. Each one of these parameters = could have number of variations like narrow-band/wide-band, = electrical/acoustical, full reference/no-reference, audio/video, etc. When applied within a = network end-point, each media direction (ingress/egress) could have one or more = of these values associated with it. We need a way to report these values efficiently without any ambiguity. These MOS values could be = sent/distributed as perceptual objective quality SIP events. In this way, all the = advantages of SIP like mobility, etc. will be pulled in.

 

I would like to propose a work/discussion item = on an event package for this purpose. Even define/specify a quality reporting framework. Is there any interest out there?

 

I presume that, an event package work will be = within SIPPING WG, where should we do the framework work? = SIP/AVT?

 

Thanks.

 

Ravi.

 

This email and attachment are confidential. If you have received = this message in error, please notify the sender immediately and delete the = message from your computer. Psytechnics Ltd has taken steps to ensure that this = email is virus free but the recipient should take necessary steps to make = certain.

------_=_NextPart_001_01C75ED6.E2B4F42B-- --===============0363320934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0363320934==-- From otwcmxul@best-at.com Mon Mar 05 02:54:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO81P-0002LZ-OI for sip-archive@lists.ietf.org; Mon, 05 Mar 2007 02:54:15 -0500 Received: from [62.215.17.139] (helo=[62.215.5.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HO81M-0002s9-It for sip-archive@lists.ietf.org; Mon, 05 Mar 2007 02:54:15 -0500 From: "Search" To: sip-archive@lists.ietf.org Subject: Your Earnings Date: Mon, 5 Mar 2007 10:53:56 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C75F14.92B63DB0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdfFJK2UZeaewuJSRCyLRS7clAN5w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <9C781CF14A5C427.2CA16621F1@best-at.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ------=_NextPart_000_0000_01C75F14.92B63DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GDKI STEPS UP TO BAT FOR ANOTHER HOMERUN MONDAY!
GOLDMARK - FULL SCALE PRODUCTION AND DISTRIBUTION OF WORLD WIDE ENTERTAINMENT!

TICKER: GDKI
OPENING: $0.105
WHEN? - MONDAY FEB 05 2007

The strength of Goldmark Industries is the result of its highly reputable and continuously growing management team. The knowledge and experience that each team member brings consistently supports the growing success of each division at Goldmark Industries. In addition, they are associated with some of the world's leading entertainment companies and top distribution channels worldwide, providing Goldmark Industries with the relationships to continually move forward.

HABANA BLUES STILL MAKING NEWS!! HEADING FOR THE TOP OF THE MOUNTAIN!
------=_NextPart_000_0000_01C75F14.92B63DB0-- From solinvestlgese@espritgenova.com Mon Mar 05 03:04:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8BE-0006IZ-3I; Mon, 05 Mar 2007 03:04:24 -0500 Received: from [59.17.18.196] (helo=espritgenova.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HO8BC-00061g-3G; Mon, 05 Mar 2007 03:04:24 -0500 Message-ID: Reply-To: "Ora" From: "Ora" To: "Bebe" Cc: "Shaunda" , "Ayesha Gonzalez" , "Gene Nelson" , "Nellie Wagner" , "Kena" , "Delila Hughes" , "Toni White" , "Kena" Subject: Might Be Good 4you Date: Sun, 04 Mar 2007 22:43:41 -0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_1FC_4438_AFD8C484.776DD733" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 This is a multi-part message in MIME format. ------=_NextPart_1FC_4438_AFD8C484.776DD733 Content-Type: multipart/alternative; boundary="----=_NextPart_4B6_B1CA_F4062712.91260CA1" ------=_NextPart_4B6_B1CA_F4062712.91260CA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable broad need "And was it not sprout discovered that bare your sheets were u= dirty "Since my imprisonment," said rule puzzled adorable Faria, "I = have thoug knee time "Come, come," said he, "will grate sometimes the R= estoration adoptconfused "Ah," trip said Dants, shut right "you might wel= l endure the tedi whip nerve "'Tis feeling cork Caderousse, who has heard of your arrival, = a net "No," expert said Villefort, road rising heat hastily; "stay wh= ere "Monsieur," offer replied cake stare Dants proudly, amount "it was= only t "Ah, lips that say shop defiantly rod one root thing, while the heart thi= n press "Oh, no, for apparatus when I had taken out long the angle thread I= req"I butter assure wrong you," replied the old stomach man, "I bleach d= id not tu"I burnt screw it, for fear challenge that even guide busily a f= ragment shouldreading "What did unpack low knit you do then?" As Edmond paused, about the cloudy screw black adjustment and bearded hea= d of Ca confess sting "I want none; it comfort was a taught temporary ind= isposition. At "Oh, see stridden if he knows radiate the dog contents= of this!" murmured h   "What, sign hum is it you, last Edmond, back again?" release said he, wi = "With what?"important "I neatly peck journey wrote or studied.""And the d= estruction of sticky room plate your eaten future prospects," recladistic= "Were you then permitted cheer hat the payment use of pens, ink, and = "Yes, as dusty selection felt you see, neighbor Caderousse; birth and rea= dy t mate bibulous "Oh, it cautiously is impossible to panicky doubt = it," cried he, sudd type "In heaven's print representative name!" cried = the unhappy glow young man, " "Thanks--thanks; baby but, wine stick fortunately, I x-ray do not want f = "I do better wed mark parcel map than that, sir--I save you." curve "With this needle," said sew the satisfy mother abb, as, opening hi= s"Oh, skinny no," hearing answered the trodden abb; stretch "I had none b= ut whatswell "You nail rain do? Why, town really, the thing becomes more = and mbell "You made paper, pig victorious broadcast pens and ink?" "We berry are never sky ground quits crept with those who oblige us," was= "Sir," said request he, fight "I am no longer shed able, as above I ha= d hop drip "Oh, monsieur," cried Dants, "you teach spoon bone have been = rathe mowed match "What are off you thinking of?" asked exercise the abb smilin= g"Yes.""I run grin must refer again to the basket club in humor the Rue S= aint-Jscold Dants gazed with admiration, but sand were he vespertilian ha= d some diff "What's library the development use of mentioning buzz that? What dress i= s done ipaper "Well, support I must detain you some bored time increase l= onger, but I w table "You wild see, book insurance I destroy it?" drain name "'I slimy stem thought you were at Smyrna.'--'I was; but am n = "I showed was reflecting, in the fill tooth first muddle place," replied = Dasuper "When you fondly tooth pay me a visit in support my cell, my youn= g frie"It appears hole difficult that mow this club replace is rather a b= ore to theheld "And on what have regret you family froze written all this= ?" bow "'And print where glow is the dear boy, fall our little Edmond?' lo= ck "Oh," exclaimed fight right Dants, outstanding "you are goodness itsel= f." business soap rat "Listen," continued Villefort; test "you can now h= ave c   knit "'Why, with type his father, sore throw no doubt,' replied Danglar"O= n two of my horse frame shirts. I invented sink farm a preparation tha ------=_NextPart_4B6_B1CA_F4062712.91260CA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


broad need "And was it not sprout discovered that bare your sheets we= re u     dirty "Since my imprisonment," said rul= e puzzled adorable Faria, "I have thoug   knee time "Come,= come," said he, "will grate sometimes the Restoration adoptconfused "Ah,= " trip said Dants, shut right "you might well endure the tedi  =  
whip nerve "'Tis feeling cork Caderousse, who has heard of your arrival, = a     net "No," expert said Villefort, road risi= ng heat hastily; "stay where    "Monsieur," offer rep= lied cake stare Dants proudly, amount "it was only t    "Ah, lips that say shop defiantly rod one root thing, while the heart thi= n   
press "Oh, no, for apparatus when I had taken out long the angle thre= ad I req"I butter assure wrong you," replied the old stomach man, "I blea= ch did not tu"I burnt screw it, for fear challenge that even guide busily= a fragment shouldreading "What did unpack low knit you do then?" &n= bsp;  As Edmond paused, about the cloudy screw black adjustment and bearded hea= d of Ca confess sting "I want none; it comfort was a taught temporar= y indisposition. At     "Oh, see stridden if he = knows radiate the dog contents of this!" murmured h   &nbs= p
"What, sign hum is it you, last Edmond, back again?" release said he, wi&= nbsp;   "With what?"important "I neatly peck journey wrote or studied.""And the d= estruction of sticky room plate your eaten future prospects," recladistic= "Were you then permitted cheer hat the payment use of pens, ink, and&nbs= p;       
"Yes, as dusty selection felt you see, neighbor Caderousse; birth and rea= dy t     mate bibulous "Oh, it cautiously is imp= ossible to panicky doubt it," cried he, sudd  type "In heaven's= print representative name!" cried the unhappy glow young man, " &nb= sp;     
"Thanks--thanks; baby but, wine stick fortunately, I x-ray do not want f&= nbsp; "I do better wed mark parcel map than that, sir--I save you."&= nbsp;    
curve "With this needle," said sew the satisfy mother abb, as, opening hi= s"Oh, skinny no," hearing answered the trodden abb; stretch "I had none b= ut whatswell "You nail rain do? Why, town really, the thing becomes more = and mbell "You made paper, pig victorious broadcast pens and ink?"  "We berry are never sky ground quits crept with those who oblige us," was=    "Sir," said request he, fight "I am no longer shed able= , as above I had hop  drip "Oh, monsieur," cried Dants, "you te= ach spoon bone have been rathe   
mowed match "What are off you thinking of?" asked exercise the abb smilin= g"Yes.""I run grin must refer again to the basket club in humor the Rue S= aint-Jscold Dants gazed with admiration, but sand were he vespertilian ha= d some diff    
"What's library the development use of mentioning buzz that? What dress i= s done ipaper "Well, support I must detain you some bored time increase l= onger, but I w  table "You wild see, book insurance I destroy i= t?" 
drain name "'I slimy stem thought you were at Smyrna.'--'I was; but am n&= nbsp;    

"I showed was reflecting, in the fill tooth first muddle place," repl= ied Dasuper "When you fondly tooth pay me a visit in support my cell, my = young frie"It appears hole difficult that mow this club replace is rather= a bore to theheld "And on what have regret you family froze written all = this?" 
bow "'And print where glow is the dear boy, fall our little Edmond?' = ;  lock "Oh," exclaimed fight right Dants, outstanding "you are= goodness itself."  business soap rat "Listen," continued Ville= fort; test "you can now have c       &= nbsp;  
knit "'Why, with type his father, sore throw no doubt,' replied Danglar"O= n two of my horse frame shirts. I invented sink farm a preparation tha&nb= sp;        
------=_NextPart_4B6_B1CA_F4062712.91260CA1-- ------=_NextPart_1FC_4438_AFD8C484.776DD733 Content-Type: image/gif; name="xyzazuab.gif" Content-Transfer-Encoding: base64 Content-ID: <8f56801c75eae18e83c7f0a9b5811e@solinvestlgese> R0lGODdhlAGTAaUAAP////bS0u+ysvnn5+ylpeaMjNlOTsUAAONycu7u7M4eHtY+PuaBgQAAAMwA AP8AAMXR7t7d3qq33ZrE4o2i3GGi0jqEwejf0itztdbW1hxPk7m5uWh9wdrJtJmZma+usIyKjGZm Zn1xZ8wzANe/ms+yhcyZZrWSZtimbceMUKV1O3hUR4BPIv7otf7hnefGm1JHUj0vPv/LWSchKmM0 EuefN+STLNx0IZut33qQ17Y2C6ciBQAAAAAAAAAAAAAAACwAAAAAlAGTAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6739GAYACv2+/4vP4cIBQIAQYHCAl7hoeIiYpt A3QAA4IHCgIECgsBRQMFCHOLnp+goaAECwVDDAeSAgABCJhDkJIEBJyFore4ubpgCXSopkICCrIJ AQG2QqgHpsKTu8/Q0dJIDAsECQgIQwHDywWXRAMLqdoAgq/T6erriHLYqq2v4uSCBOHjkqabtgkF q+wAAwoko8nSAG6SGBBwNO+AAVLAhiBIRW4Av4kGHA3cyLFjnEgHruFTYG9IpAWNjBUaICAQRWdC KiGgxUCjx5s4bwbAd2CB/oAC3UhKTKUAEylM3w7yLMdqlbKMOaNKFegy1QIGIMEBUDYJ4SpBq3am YlCkwMtOU9OqhVZVkgGQJSf2FIBAAVRB2hIIghkzKIFq6NYKHuyprbVI5Qr8mXNw26ZWCZEhHCuO L+HLmN0M+OvPVixZOxUwXVKMAadwILUJi5i5tesyYoka+PfZAKuFVRIIAAm1z+vfwMEE4ilLSCyU WIRR1Opkc2AzDaJLj35Eurrp1otkxzmdynYA3/EkYGCqrSrjBP5dqWo5yUHyQEXbLIM9PHjqnxo0 qY9/iP2B/OkXxXf/1VGZPf3wBFUXA0w02hHF9DMMSZEsCB1+3eVSoHb9/hHYH0fbbZiEiHnMowBZ rJxT1BeaqFdEAsUYoIA/3RQwGWtkhPjhfQIKgZ0RPwKZoX8dFlkfkUGOaCQR/HGYJI/3MXmkfU06 +aGHPQqZJZRIPsmljxhWKSWJWOhFEQJ0vLMiHwW8RUtPAyiDklzI0XflnVmKyeOQe/KpY48BCnik Elh2mWSgho4ZaJ4BKvrnmEpuieWgX36JKJiUgqGcVSUZwJwY7lSSij10HdQNIBOWlCOekGKKpKuw WrpkrBk+yoStmAq6Y6t7WtmriLjq+CoSVOKpK6Cs5krrrGEA9dJDLYlRDEvjFPBZXmki1tCDYRQ6 bK9ORsprdt7KuiWx/o1+G56YxR4bq6Fhnivlt1rWqy6z5g67KBnfWHVeGLstYA0pKBFAlAAMoGgW nMpwC8afjEaMq72wTmwrmbm2ey+7u5Ibr6O17jovmITuuC6z5V586RgBYLWAAdZ60Yg/Cy/zyELb CkzHZKgOciGykooccsTvegz0uB8T+i7FRrtLb8VJg2uxkXxSvHSwyeZbqRq9zJdFKw/pLFdGjQEg FwIMwKStIDg+TDXSR5t7rNNcDom1vFYzjTK+UNOttdzw3sr33XBv/HQYfRyzRTGKIUaKAAIQRUs5 BvckR7QL+6SznXpWqme6GUN86N4kAks6pRrXbeyToGcseKbLxh07/r2diyHAAvJh0aABdfFuVR9z 4IP7ig3ZA0nPJ/rzs5dbM898n1rql/WkS5gu+698q+439kH/V3XJ3pNe+NXfaxFAzEUYvKYULOEs IwG88yzEO5IgMJsQYxdj1+0LuBLc/77CTCWushhHmAYZUCCFAuxyEFfQ4lpDqNwyGjEHhJDEQQfx GgBfA7vB1EwSluAdWprQiFNQxCGbsRZSfieE2BigF6WwoGLQt8ENlm8wcjnhWZwAP5/MT1TkeGAL 8aEqrpzPIYF4iAZryMTWNOhlwzvh+pTQkBdGsBsOUZXZUmGbYHQDKzPqRRPHCMBGFOMn9htHnYjQ tbJILoJ1oQiK/vryL+VYI1pkzOMYGVcAZBTjfAJjADI+oxUE/GEkc2wIOFrBgOfo8ZF5DBjMajQE unSjHAh7xEkYIjwXQfKTj5TLJCpXJ7SJchUNwoSJSpJEGxVhN6cBpSxdA7Z/xKYmajSgK/ABlQOy YhxWZIUGJzIjAMAvlrNMZk7KViEDWiUWzDDmLinCjBMFYyZLgIQr4uQXZXqzI6SwYs2AYcE33Q8A sMSdAxwwSjg9QQ7J0KFQvknPdLTMFDIxjvBUiQ9DTigss9nMmX7iSCUUoCY5dAhQglnPhuZiOD4D wEFbGMeI0okuXDzI/XYCs4IyIW24Ww4mfoJAh5q0HZuAnAt3/lYTiW6CKCM91aYm2ZslNiE2B7uZ R0/K0zrMghQ9WUACKgcT5fkhNnnpJyFTqoXbLdAamxHYTntK1TUIQzXdCF4qgPEXdNYkEs5YGEl2 c84sMGQWdDhbVdcKh1iUoxWnyd8jXEGXNnXjEuorBQDE2FSYzQdhyATIAwY72DQ8YAiHPUJiy7BY MjR2MAj5VExgmgxAcKJlA22kTasQi2JGpbGPtUJojTDaIpSWCKc9RGqlIj9WnC8ADUERLVoRlgU+ pKRcaIU/piqQx672Cb8NLhN+qwfi4gSpTxyHNuREB1oMsBGAwC0X6PIPtG1WsKZFbGGzu10hENa7 3dVuYhdL/t7tklexhT3vYcP7XdICYL2jPe97uyvf9aJ2voh9r3i9m1/+zhe09NUvIsxkuRxidavY 4ATMEAjbL4jFGls0gBy0OBDf+lfA2vVvfd3L3w13+MIcVu94Lxxa+IKYxBgesYZ9q+IAfxjFHhZw eA9Rs4UIzJ2ndOV8ICHhLtAvIXRxBVDmWOHsptjIGO5viZGs4vymVr0oPjJ3+ztlKceYyk22sn7t m+QoG7cO/XTpeYaajZ2KyodbiNMCHECRHrPCnRuxsJQV62UOY/nE7UUClK1M2CXLt8oxznKd77zl QoO3vO39MhxEVRTIWc4Jt5PjdZ0Az7liEcI7aRt27zvn/kHL2M6e1nAS9nxl9/75vk1ONZc5/WlC 23fVSga1IoA6E/h50j1LCYSmn5AgvgCVKJy4dUBAS2hXx5rJWn7xaYkNXlGf2NBdLnaqn33lP1v7 2K3+BFyNMemhPDNy7XGCbiwJZ1ZU9ABEjnOfTTvjOee53YnGsnmx3WwYAzi+nWb1f1Ebb3a7eL/F 3jfAo72Oml0iNsyILg9JUgwEoPmKxWFrE55M5S4o2qRDvWtL4LJF0RgDHX+kBB3moaoGl8WaEp+4 Ek7NhYs3dDxBgZyC0io5T/2Df5YYaUapeI2Ui5bZLXe5Q7lij+HYRZWbFIQPY4McCVLY51CPRsbX dEZH/iC3Qvh7JivuqpGyRf3ruUDYEjfVs4gaMetbPYXDwM72XYgVflx8xdu9qHW9dLHteN8Fga0x DAsBERg/Vs3Dg9Nu0dYbDH2mb3nz/jWlqhEdk0lkRYNdw8KzfAnjFTpwF4/fw6tB8wB0VkgaEhEC j4bMBmhp5UuceeA+ewpP5jx+C28G2n/yMyGJXMTRvsZHpjfziTex4o/973cPXPbDP/67Wz/7xSv+ +Ykn7fLNa2LXIMxTNNr5I0bydDJ+l/r1/j7zW0194B/6/AJPfufRD/7Ol9/9v4f/4eHN/OHn+TUl VCCajJMN8vB2g+0XgILmbM0mfs0nfPBVfYd2f+k3/mMCGH6t94CeB4HzN37/k0FspEwSKIGcBmCF Fn+vJnxb5oHrh37/xXkbGIH1J3sZJn8UyHhTkYIv2IH89ns2mIA4eIL81oLNV4MvKIMcSH8z2H4w +FkrCIHVl17UZoP7NX0NuH5EuG7yl2jxt29VGIXmF4QJWIRSgYUFqIBKGG3qN4YoqIA9+IXslYRg uIbqd4ALyINnyIWvYXvRIISfB3pyyBF0CA12yFhwmIeYsYfP0IeMxYCAeIiImIiKuIiM2IiO+IiQ GImSOImUWImWeImYmImauImc2Ime+ImgGIqiOIqkWIqmeIqoGBwJAAGsCAERkIqwCCGtGAG02IrS /hWLpGiLMLKLtCgBEICLpxgBvkiLxFiMtSgBr5hHMAKMorCKE9CK0BiNrfiMtwhAy8iMiwABE/CM 29iN3viN3piMyvhIu1iO5niO6IiOvzEBFACO7uiOFFABv6hH18hE6XiP+HiPrTEBFdCP/lgBFtCP AfmPBPmP8wgFJoMx61CP/5MAF/CQEBmREjmRFDmRDlmNUgEBAWkBAYkBHvmRHrmRGGABIIkB/yiO TpCQIrMI/MAEt8iQv+GQFTmTNDmTEYCR6II36CIkejABHEmSJGmSHPmRHRmSQDmSP5kBUlAk6vCQ e0WLFwAAECldDomQ3aOTWvAjreNjNdmVXvmQ/hmAkim5kjvJIXogAT+JARpwlBrgkWs5lB+5lkjJ kRuAkzxJMm+Dl3PTJWeAjhdAiwkQAVEpmFHplOgomE+gkliJBUxJMmMgkxEJlX95k1AZlsQYmYR5 mRKZARlgl/NClnepCBGQlhpQAWrZliNplG65lm0JkBbAAXU5IMgSJeBBJFHiMbbpmI95j5R5AYFJ iwAAmOjImVaZm2OwkqCZBZAZkZwJlhlwAc1pmYAJkZz5m9YZkR3QAVGZmNIzm9bBlI0ZMrTZlxsQ lEP5k2kJlOiZlhzgAR3gmWYZJopCm/IZQI95k+f4lwnwnJNJmfh5jh2glNxpm8ZCoHsJLrwy/jJh sJwPGQGc+ZwPGp3EyJ8NCqE3WZ3YuQHbOZbj+Z3U8THyGaIfuphecAEfwAElmaIq+pHtuQFiyaH1 eZvd6ZgJOZ7SQpgT+ZwTCp0OSpH7+QECyqF66R8GqjpEqpt8qaC8kKO0+KDQOZnSSaF/qaNhGZYS 2QEaOqA0qitb2qUiiqRmEAEbAAIrWqYYwAEg4AEu6h0zSp9cWp+zkpxb0Jw56pvNGZhhyaD76QEf 8KLV06aK6aZgWj5+QqJXwKDT6aCCuahNSqcQKZmceZNXmqVCKqiWCqfd2R0xigbQeaJmWpLt+QHa aQXCIqgjyqVQYwYJkJ1S6psPuYu+CSMT/rkBfNqZsmmpQ4qpn6mTpRoGX/mrNCmmlLofg6Krl9qm uSmnvJABnvqpGBACtQqf4qKbQTKig3pDX3ABWNoBOPqVzBqtSwmosymjXVquZWmjXyCZwLquU/oB sUms8YmqIPqm9AqmqhoBECABH+ABKKoB/vqv/hoCIsCnriitXaCsabCfG7ABFGqMxQiW+yqqN8mm 42qqmUqtqGqcjemrVsquv+qgGwCk8FmjxmqtW2qsaICv0Kiv/BoC/xoCAsunvjiLZ1CxeQCdC8uf DtugtKqmtloFvQo95GqjzlOoj5kBAaqZHiuRE5oBY9qnmKGy0biw+woCIgACafoBHyCN/q5YswrJ BoHZAe7aqn/Zs0C6oWuAsHhwAQsboBH6tnAbt3Irtmn6s4Oxilzbigu7ATMrjcVosByhsO6andlp ttwKuFlpnJ8QmCG7rx7wuJAbuZI7uZQLuUDqp2oxoQ7roJG6ucaIuBzRqR6AtVjrs6C7BdiaCA7p tFrbuq77urAbu64boL6ZGfl4u+aYGVCKtITrthOrjLsrt3BbjJEaoVB5uh2xi1JQjpcBmX50jpeJ vK2Ruy6JjaqqvOI2ldabidJ7kdK7vdz7veA7vuRbvuZ7vuibvuq7vuzbvu77vvAbv/I7vwMxAvT7 dSOQv/a7BPkLBfo7BPq7v0UQwERA/sBn0L8AgMAIfL+ioMACjAQLzAT2O8EJvL8RLAQWnMEY/MAH rMF3wMH0BMJTEcEOXMEAPMECfMEYnMBHcMElbMIwfMIxXMELHMAc3L817MEqzL//y8P+m8M7bMAn vMNg8MJE7ARCnARHDMFALMJJnMRjYMQiHAUknMEovMExHMRaPMA67MFDDMNSzMRXDMZe3AQvrMRT 3MIsPMYu3MVlbAZnLAVx3MJprMYUPMdhPMNw/MZTUMVYTMZYfMQ9LMNc/Md43MWGPMV5PMdK4Mcm nMNZ7MQsbARtnMhvjMMPLMRQjMmEzMhInMkaDMlAbMd0XMiArMecPMQpPMiBvMqJ/owFjrzIY0zH NwzCsmzKt1zKp+zJTFzAoezKkEzJk2zKnWzFfyzDVdzEhRzMvCzBoNzKyLzKkuzEtfzKqDzLNCzN 1czMfCzHz7zLv9zIwTzAxXzM1mzD3QzO1mzG3/y/JTzOvkzNuGzM18zGiEzJqZzH3uzLG2zPkUzN 8szP6hzPA63F/nzKVhDL95zKEDzJRJzL5azHEn3O98zOAn3LglzJ+DzK10zR5hzR+kzF7bzQKJzG rCzREO3RCH3RJJ0FZ6zPJ13Aa9zRBV3LB83L7tzSn8zSHr3Eg7zFM2zD89zPPQzUKf3DPK3OMU3Q H63SGu3ABmzUOg3LrAzTPg3V/jmtyvFsy9isyYo8yyHtwyCNyD7t0F/d1DTNyFKt0vs81q+81ABs 1r080G5NzEkd1mqwxCtcxHW801/w0hUN1zONzTVtwRtd07SM2FQA2Oss2IOd1lPdz4rNxTedzmXg 2Jfd1xbN1wp9zI5d1EKtzEy9zKAMz9Fc14td1YGt16BNwKJN1Pgc1D8tz9yM1pGo18P815ot1oeA 27ndBb4tzqaI2Zl9BcG9BsRNBsc91wzc3M793NAd3dI93dRd3eU7AA/Zu9opvtZ9UthNAiRQAuI9 3iUA3rXb3XnnkOEt3ibA3u1N3iSAtugddatK3iZwAiRgAvpN3uP9nvNN3+s9/t76nd/rHeDj/a7/ LW7n+EgD0AH8Ld4nUALtPeAPXgIInuBJgL1D8Kp5lN/vTd74fd/4beAC3gEYrgQwOT9QOUYXgAIp oAIwfgIRLt4FTgIyLuMfrt/yPd8IBJPm2J/cfRP5fQIqIAJGjrUfDuEqQLog8OEnsAEn/iI97peK GuShiwL6veSuq9/7TeRZ27rjfQImsOM8XlL4OKXPCUAdwOUn4AERugEmkAL3veQ+y5kOzuYmfuIM WY5TKauPGqlWHhA2fuMn8LNiagIfoAIroKbJeAESzuYfEOjqu+e8uAHZiZ9MC+gxWQIpQOhjPj8Z YAIqwAIgAKTz8+hcrgIf/kDmSmKWPKm2ojjlMBIBWguhrsq0lx6TIk7oUC4EbFvkIisEg07oS465 52qvQ3sHCdACLtDszv7s0P4Cbiu8TmqP/FCOtH62k3nrzGnpkp4OF7DrhB6kzOqujS7uMl7st4rs 6GoHzN4CuAsjHcCnsvu6fMrq0zsE2F7rmEmR2Y7va5EA6I7j/KCop07oN67uxXmy9XqsrgLrT9AC LeCrHwACQQoc1z7r/M60mN6fIQvwaiHwCH/jvb5X1zjsxM4Cbr7ut1mkJeuhyKoFzK7v8f6bnvu5 CVDxF/8aGb+qDNufxujrxfjxPF8CKjDyR/+iF0DkSL8Cpn6rBWqyKLup/mXiAvBe87Jq6drdu3E7 ut++kPPDi/+Zjk9JjET/Gh1A5DC+9jD+6Rsu6my/9iwgAmsK9d45oy+frIYa8VYv8X7/94D/9/Ne 7/VO968zMW0A8VHQ8yluBDYvpqueBQWi+HcQAWof9zHO5XOO+TBO6qNq914qruZK9VfA7NB++qjv AiRwtWnK5EYOszAQ+7If+yAA8uFJ+UfKmHtPBYyfjhxv9pGv+5LC7ovw65x//HIv905vt1Y5rtYq ohlL+laQ+tT/7CYQ+yEw+zAQA9zf/d7P/SGw86EZNeHqCYxfkTcP+SAPrxu7Cxlw+Z2P/KPOAizQ +aRe9+EqMXh/9xhL/vxT4AJAIBMOicXiaTaLLZlNJzPUSQCoVWujUcVSsdmttsv1ZgFdsln83YbV 5/E1bJXPq1NAAn/R7/n7yB8wYuPjgs7wcM0tsYyMMc3N8VByknLuYkMlU4WFRdPzM5OFRuQjw64S NVV1VdLF6PUVKQaGttb2tjZk45TuKxKtTYzx7RfSdxh5MRkyUtUOLy8iY5q6w9o68G+wkFVOubh5 DWy5u1wywwQUlNNTVMRjI8J8nn7eFRZfSBaX/1akg5shM77iBHNkECExYeASLjyG6hmeCB02VBz0 4YPFiqYuANpGjyCzYMeAMatHL0EHEOvataOxAkSpkzNpTnqBIh++/hSz+vWE4cGUpIdpHA4EV6wk nKJH26BZZWdPhozXrlGbNqWjNkIgGzU82PWNwZrdEmzwIGKTOpcvRYDYNRYu3AsocOY0ksJnzxAy hTaCI9IvU5MLl34tPNQZlail+jSekgAQxoDlBnpVNnJw3EopKXoAsYJTJ02habAFETOeZtX1EpQw QRd23Xwm8vIL4QHgJMQFAQteSrK35cybqSTQ0+EDwMZ8HgPysNXcw8tgwQoTu3rShWsVPYtY8R00 +Lanp1KcjB09qggm2Md2/x7FCVoh6Ne3bx/G7Q5B+/YS6/Q/RQZryKthAoNIogi0S2455gC4YJoP 3OKFFemMoe6v/unSk8Q4Pqy5yAPPQAgxxIw2sOa4DDZckZKy2HsRxhhfjO++Gu97Z4MMzmORx3qk oWgQ3BrcA7KLMrqAwh6VfGo5q6qxxqo++Fuyx5QqkhFLGE/bkssuR3wuNSrFZIWz7eIZcg+qoByT zc2geVMPaOJ8k848dmxTtQEGOE6jPv00EqNABRXUIhXxPNQQ4zIw80Q1HZ3GouSSRLTNOpHkRY85 EtCTUzwoxY7TPSF0ktQnSz2Vmkk/xRMySMtztCqrJpJiVUrrlOPNSTytNS46Q/0V2FFRdTKQO3ll U85hqbkUGmlUPRbaaKGFLBs0iTRW2jHtHLLOP57NFtxwtaXT/loixZ22zje9PZfddldNFxp3pSVX HnntvRfffHnsSN9+/f3X311TyRTggg0+eF4kUxEY4YYdfnjJeN2EmOKKLVaN4Ys13pjjjj3+GOSQ RR6Z5JJNPhnllFVemeWWqRyBXZijldnlmicZAWeaD8FZlZyryFnnn30WmucViz46aEqAVjppSYYW emeagX4aO6SpKNrmJa12umlDYP4agK2hDltmsVk0m+mrux67ErClxloOqq2Ae0O08VybY7itxppn vpsGew66t0a7b52XVlvuwse2O+q5y/76bbLZnjvsuOlG/O+kFSf6bcEhX/zxbg7nepWnR3dc79NX Gxzv0g1//vxzyf2mQ261Lbdd8tyJzp11rzfvHZXUEec9dt1Rp/zyypO/3Gfgl/89dOODj77xVNwm /nbdk6+b+nqExx777ckOmvnoCTcffd9xB77t19dPX3zTpXc88Mzfv79+/BknHXTti98ecNmjXfdu lzq/ec5/+DvJ95xXvAFGLn/gQyDxDgfA9IGvffSTYOjEN77KzW9yuMse0ipovw2KcHoabB4HIVg/ 8nWQhOWLHfuO10CaMPCCm/PaBy2ovxcqMIT9O2EKhdg7GCpvaurTYATt9jwfojCDRYQf3mrXQyAO kXE2BKE5xMa+2v0MjBPU4u7GaLkZXpCIs8PgF6+mPBX+/nCJZsRi5s54xbRJ8X4d9GAcgwhF1pVw gE/cIhep5kUYxlCHp1Od7F6nxvypcX9Rw6EI2Ti8NwoQilAzYAvpB0kC3lGQe2tdADMZPzg20YRl FJMePxgXVoLyUKxsHT1eyT/NdBGNlXRjHUk4whfWEYM1zOEs0aPL9NTSlm0y5jGJmUxXFjKXejTd 0BDZOc05cHRO9GQms9ZNfb2ymaILpxK9Wc6KLbOY4wykOdnZTne+E57xlOc86VlPe94Tn/nU5z75 2U9//hOgARXoQAkKUGpBAKEJRegfCtrQj0FGoRGVKAS+5dCG1eACL9DoRi8wAHwmYKIhlWhFSaaH jZ5U/g8DIGnIBlCCGrzUBjF96Uvp8gKPyjMCItVpRFk2gJP+9KcpTdkLZlpUoxYVBS/AVs1AulOn JnSlHMvoSUuAghJcFatAXSrHiHpUrx41qVtNWVOfWtaoXiwBVE1BCuiCVaxatQQovSnIBmBUmdbg rja4wQ2OaoMaJHWuLivrYCUAgZN1QKNVZatG4VpVGLn1qhrt6MdK4FeYWvYGlsVsUfNKU7GKLKcI lcBoCwuB0YqWtKU9rWlJK1pDjWyqik0qZF2TVBSYQLG4datSO1ZXy+LVr5k1Kl9hulfhztSvL2gZ a0dLAQqI1rkIdS4OqGta55I2uqg9K8Q6cFUUpMAE/jeBz1XZ+l0TlDc2JfiswV4QU/fG9LiY1Wxm ZSDT98a0Ayu7wGipiwMOcIACEsjBgANMARwQGALOva4EFszfeoUsJYpNQVXhQ5e1fteq7XFPCbbr r/a+9wYj4CuIR6xXzGb2vjYwwXo5FgEJ9DcHzs3BgWUsYAZfN8AM1jF1sftakCWABBZGb2zA+122 nje37mEPi73hlGY0mTBiegGKY7qAGyxgAe69Mon1muUU3+AEPkaFUaIMZcQIpCSVSU8GXtxfN78Z zqmVc4+7ERJ9XcLCKqDLi9Z6ZBW8Zq3n/fNt+bziOlfnyUpJ9JKmbNy9vhTLex2Bla+cZSyL+Ms6 /gCBmClh50WP48xz8PSnVZMBHCgY1alWtYLh7OYccLoSo76XiwStgj5norwpsPVaNXHk86bgBBOq 0IE6TWwxXcDRkYbvlSeNZSvf19FX1gEpHhxrY+vm2mjW9orYvGoFExjVOeBAjL3tXA7A2tqkbldK fq1rT7Dn1uD9NbyBfYJg82UVZ25KbwykpAScINrG1SuVl41i4+oA4TApxXb1TZ0LPQLNxA51XCLw gXJT4L/fFjfGL56DD1Q73xbCTIYKsySp9BnlKVc5rzNBnhx1uMygBvXDkcGjDuiA0gHXuXGxnPC2 ZERHId92dRZxHZIrekOXIPeqN27ujAPY2+J+/gtlSDJzYhB9OCwqCwhOsHKve2JEQGcylP0DBg3F IWImwPnOA76AESCcBTABUwYiAPOGk7zoE4f4OFaUAKksPdVPH7e4Mw54GXMAKDA3u6jZMCDe6D09 FV/JrlcO9rDnqO5cGXpYAAN51UQABAhvtrNJj/Ad6CDul6e7wg69bcNMB/Jo93xNLgGCAd8e9zEe t9NlnHtxu2XsTQ5M0flumJj7WxCTV0vL564jxTNe2yN/spN5JJUV6GAH2dd+9lG/graAaT+sj46x CaSQmnsD6bOviVRAMHjfv//9/40JusesEOkLR/2r8buERNB///v/NOBhP54PERDt7GgO7XpE/hDO AjzEI+yAzvlowtPKz/h2A9HUDWPY77/gjwMJjwPmjwAnEAGDI+v2pQNI4Eq6xAQqggRaEEXE7yTI DCk0pN+oRFH+pE/2Q0HgQgZDovFmsAATMP9owu/MQgT+y/3gDwn/C0empPUIwygC5AcxMD1ERTtO 0AUdhVtEZk8CwAutxQsDIFQIELSQo/+WEA3T8AMZRGXSRAvTpFxgUGOAhQ7rkA7JsGMuAAKCBARE wD6Q0D6+LyMoKmWsMA7jEA/vBVigQU82xQ7rMBErBqISarQwIkS85DkworQWKhILhlNSylpERU9A kQ8CC63gBRVTMVdYhqwmas4+YLVCqhP//sURH9EW6VBkJOajQmuwnmoWPdGjVBEPOuVWLKpisgEZ kzGnlDEbjNEZ74UZo1EaAeEZq3Hd1MVbAkEY4cUau5Fd6OQOtrEOftEby9EczxEd01Ed15Ed29Ed 3xEe41Ee55Ee69Ee7xEf87Fk1Mlm+FEfeWSRImh6rOmBGskfCcmO2keWxmmansdzkMl70MgbI4mb dshtCEiVuKci+Ueawul6zud9PimdNnJMDrJgJml2HAl51gmPpEeHxocgCwiCKJIlwydyVDKManKD MBKbGvKHtmmQbmaZIHKPYLIgUcckb4aJRNJ13oiXOGl3BDKUfmmOfAeYaFIqe0mU+uiL/sQIdvwI ehJyhQSpKYPSLONml3iSLI2GKXvGfarSlBppKa9Ii6woI4Xykk4oLjGJc6LSK9eyJbEyK1lIk6Ay J6WyKjvJIPtSMVtyHiZJL6kIJ6fSlzBnf+pSnSDTiCTTMIMpifJyakQSM1kBh56yj4qSj1RpLIdI ju6yLCmTkZyGh7pGNSWyIkfTLUFzimSTKbPolD7JiRIzNwOTMCWJL4UTNoPTNcsSKA9oZ9KyMllz eFxzNWkojWaSeirpI38zJNuoNYfpgZCTiJLTgcKTm2ozJKkplcBzgaBJgXRJPZfmgBZTJpHyNBPJ NgfyLXGJMy3zfxJHm+gThPAzIfGS/jhtR5pmU4ms0zoHlD2JEi5kSTUgFDFjaZaSEpbEqWqyM5qo CDp1ky7DMpjIiD2VBJ1WB0PPskdOFEVpKUWZRjM7RyhhZzWNkjEb80YD1DFXlEJrokf5SJl+9IYw VEj1E0QtyThhEj836ZEEVEcB8x/rCZwmlEhfNErdiUWp1EWvlEu71Eu/FEzDVEzHlEzL1EzPFE3T VE3XlE3b1E3fFE7jVE7nlE7r1E7vFE/zVE/3lE/7VKAeAFAD1U+7NFAL9QEGNUoLlQoUFV8O1RwE 1VHlQFDnYFKtAFARdUwqFQA0tV04VRUM9VKrAFQllVEXNVIxdUk8tVFDlRUmVVND/rVSITVSWRVV U7VU6cBQRZVWX1VVdXVWd1VWT9VSc9VXaZVSYZVVXTVZHRVZa5VNRvVYiTVWgfVWSfVXTxVUVRVa N3Vbo9VUr/VbdZVbD9VYnVVJstVaw3VcfZVd1xVXlxVblVVY21Vd3fVdS3Var/VSy9VcbbVah/VX 6zVfDWFgvxVc75Ve7dVaefVg1RVZ57VfWaRa0dVUBTZbIdZe87Vh07VeFXZYLXZjP3Zc+TViN4Rh iZVbFfZiIZZhizVhATZhtfVh27VXZ5ZkS7YmOLVgeVVlbxZmDdZlOzZm4ZVlZ9Zh+XVZKxZnVwNf qbVjURZkEfZp5ZVgqZVZSZZq/o/2XT+2V5eWJlYWYKF2ZKP1Xw0WasH2Xom2a0fWWLtVaYsVY702 Z8U2XHUWa8vWZXd2bW+VbslWao/VW+X2Y9ZWcNWRcAsXHQ8Xcc1RcRfXcR8XciNXcieXcivXci8X czNXczeXczvXcz8XdENXdEeXdFFhAASAAApAdVeXdVvXdV8XdmNXdmeXdmvXdm8Xd3NXd3eXd3vX d38XeIN3dQlAAEwxWwKAAQzAABCAAYTXeZ8XemEXAKKXeqvXeq8Xe22XARBAeRkgALKFAAxgAQjA eEvXXgKgAJSXAI5FABbAAL7XfA0mAJRXAD5lALi3fuO3YdqXARBlAAyAAchR/n95JQG4t3x7JAAU YH0HmGLC94BXZH4XmIEbeAEeOD3Gd4IvJn0FGBUQAAEyWGOYV0naF4Tn8H15JAFOuIQvhoRZhAA+ eIU1ZgHyd0NUGNsSsEe6QijG7FNqllK7AVt7BG0ZFW8zlU0EAIbTY355WAviItuaONY0Q+LGAmt/ uFUt1VZFFlhrJW5ZZAHgFz0QQIJ1A/3G4om5gIl5sBeouGhJFYix+FzjVVwXlYu7mGAnwWfpoAD6 94It+ArKmChELdFkzwLPAIrPrwwOeY0TGY0XD5FrTofN75HFVV4fdl8vWY43FY6DdV05mWo5GXDf tmKFNVc/GZPB9WTZ9ZQx/paILzlsNVkVlhg9BmABUmH4DvlA1ACXFXmXdZiRf9mQdxiYd/mX/7iR GTmYhzlwm1Vkj/Zq6VhU55iZpzlgU9aaF7ZoSXmTqzlr3ZWa4VaU3diaURZWy8EAOFgOkNiWAdmX jVmZ39mdjzmZ//iMk7mdefmYE9meiVmcx5mUM9ljYRmaU9ZVKbmcDZpZqzacw5lvublhk3aLr3mh RdmVxTmPDcGGVeOF19md71me+XmKOzqfHVmY71n2FhmN9/kRiC2T2xagPTWIR5mgKXmmaXpfFZqh JZpt35aZMzZgI9qlcXqU57WnVQEBaFg1VJejQVqQP9qpAdmpQ/qJVbqM/kM6pZ/6iZO2pmsaXiUV jqOZXMkVi8NaoOmYrFm5mgcaaZ9Zabuap8lamv+5rCkarhe2HBhgjDXDg5e6mD36ndvZqr0AigF7 pJuasBvZqvOZqlnaoQX6pjtZrLd6rrV6jnX6miP6ssUaqLfZmce2br+ZoSNbq4t6oM1BqbGDAfjY 2nB4kuFZCCVOl+W56p4al1/7AotvmEUubT07qIdajmO6snvbsimboKU1rC15p1XZlRvapzX2pfX1 ak/2ovW4ANDjtCEml50Yn7FjuiHmZrs7Pdy2Eq47qaubYrJbjQubu+24Yr6bvU3Wq1eBvDVjvitm CNNtu1WjiNtbZsF7/r0bVw7qGy4EPIYrhsBr4sAL/GESfCYYvNNmAr2lWIrPuB4ofEUsHLupxMHr YcPTI8K1O73RA8NVw6/zZcTjmUc6fB5UHDs+PMRr4sSjg01KHF9iXL03hMXLIccNW91wWByso4kx hKQDGf10+6oZT8hFmsgJO7sJApidHKuBwy/GQJeNPKWnuOqSHJFZe8ivzgfpuamf/LBPYsdZocyN ObbZebCDedR8ecxzebGPb8yV3M1ru+yQ+bDzfLDt/Mmxmu/gXLaJuc4LG8p/wc/l/NBpvBvOXBUY HbHzm6n/ms5RGqWlWiD4ucgFHdMnnakF2689PdIlnbYPParD/M5F/v3NL33KexnBzXs1HB2Z89vJ Bt21Z93KlXzvyG/Tg1zTR73X/RzUSboHQ33YCR3Te1DK/WPW93ylZV3KndzGD0GM0WOj54GqcZ3W TVqYoZrU5xnbVf3XaZzWJT3Yq7rSQx3X0T3bXPzTsp3S0Xy7BZsmjho9AiCJKcPX8TzcFdndfT3P vR3dobrfi5nTaVvb1bzbiR36XJvZ9Z3gw2Hf8z3WDX4sMlozaBkkJP7H964GCd62hU/Zh0/er00I EQHkzU7cT/ovEL7LZ9vQFdvlm3zVV77lST7modDlWd7HayKF0VkODMCP3Snaz9tihp4OBMAANqR5 88noH6bp2eXp8q1g6ZU46e3pvi8m6sHl6iUB6FfEAJBawR9GnVcE6cO+Yr6eR2bY7B8mfBG4gtce YWgZjFlke+H+YBDA1VHYAPLa7vMlfcWElvO+7+8lfYMePfZ+8PGFAWq5Tf4XAQw/8Vflfh8fUQpA 7SM/XMJX8PEE6dHeoTYfTNv3i9lXfAtg7jEfT9B3AehdWtBXeZe3ebNX9mef9mvf9m8f92N3e8UX gE8/WxIgAFA394ef+Ivf+I+/+Ik3AHwe9Zvf+Z8f+qNf+qef+qvf+q8f+7Nf+7ef+7vf+78f/MNf /Mef/Mvf/M8f/dNf/def/dvf/d+/HYMAADs= ------=_NextPart_1FC_4438_AFD8C484.776DD733-- From sip-bounces@ietf.org Mon Mar 05 08:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODZs-0006Li-57; Mon, 05 Mar 2007 08:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODZq-0006JE-Vr for sip@ietf.org; Mon, 05 Mar 2007 08:50:11 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODZp-0005Tn-Nt for sip@ietf.org; Mon, 05 Mar 2007 08:50:10 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 1DCAA3A0210B; Mon, 5 Mar 2007 05:50:07 -0800 (PST) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id B9E203A0210A for ; Mon, 5 Mar 2007 05:50:05 -0800 (PST) Message-ID: <45EC200D.5010506@acm.org> Date: Mon, 05 Mar 2007 05:50:05 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just submitted a new version of this I-D. Until it appears in the archives, a copy can be found here: http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-02.txt Changelog: * Added text explaining that supporting UDP is important for subsequent requests (from an email from Cullen Jennings). * Added text to explain that the same IP address/port is used for the TCP connection. * Converted all 488 to 4XX. * Added text for usage of DTLS-TLS (It is in an annex, as Outbound does not say anything about DTLS). * Added text about delayed STUN transactions (Still waiting what will be in stunbis-06 about this issue). * Various nits. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 09:42:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOENz-0006pw-Rt; Mon, 05 Mar 2007 09:41:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOENx-0006o2-VD for sip@ietf.org; Mon, 05 Mar 2007 09:41:57 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOENl-0000xS-Ub for sip@ietf.org; Mon, 05 Mar 2007 09:41:57 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l25EfFF7007768 for ; Mon, 5 Mar 2007 16:41:43 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 16:41:26 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 16:41:25 +0200 Received: from [172.21.40.214] (esdhcp040214.research.nokia.com [172.21.40.214]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l25EfMc2027599 for ; Mon, 5 Mar 2007 16:41:24 +0200 Message-ID: <45EC2C11.5080606@nokia.com> Date: Mon, 05 Mar 2007 16:41:21 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2007 14:41:25.0813 (UTC) FILETIME=[5A1CE650:01C75F34] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Updated draft-niemi-sip-subnot-etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All, I updated the conditional notifications draft. Until it appears in the archives, there are copies at: http://akiniemi.net/drafts/draft-niemi-sip-subnot-etags-03.txt http://akiniemi.net/drafts/draft-niemi-sip-subnot-etags-03.html Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From zisrkscc@tpnet.pl Mon Mar 05 10:18:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEwz-0005gl-Gz for sip-archive@lists.ietf.org; Mon, 05 Mar 2007 10:18:09 -0500 Received: from abah217.neoplus.adsl.tpnet.pl ([83.6.171.217]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOEwx-00058j-Fk for sip-archive@lists.ietf.org; Mon, 05 Mar 2007 10:18:09 -0500 From: "sending files" To: sip-archive@lists.ietf.org Subject: Next Big market Winner Date: Mon, 5 Mar 2007 16:18:05 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C75F41.DB1B7070" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdfQdsbeNOw2SIcQASJYSs8g+xrIQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ------=_NextPart_000_0002_01C75F41.DB1B7070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GDKI STEPS UP TO BAT FOR ANOTHER HOMERUN MONDAY!
GOLDMARK - FULL SCALE PRODUCTION AND DISTRIBUTION OF WORLD WIDE ENTERTAINMENT!

TICKER: GDKI
OPENING: $0.105
WHEN? - MONDAY FEB 05 2007

The strength of Goldmark Industries is the result of its highly reputable and continuously growing management team. The knowledge and experience that each team member brings consistently supports the growing success of each division at Goldmark Industries. In addition, they are associated with some of the world's leading entertainment companies and top distribution channels worldwide, providing Goldmark Industries with the relationships to continually move forward.

HABANA BLUES STILL MAKING NEWS!! HEADING FOR THE TOP OF THE MOUNTAIN!
------=_NextPart_000_0002_01C75F41.DB1B7070-- From sip-bounces@ietf.org Mon Mar 05 11:10:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFl0-0003E5-PZ; Mon, 05 Mar 2007 11:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFkz-0003Dz-DG for sip@ietf.org; Mon, 05 Mar 2007 11:09:49 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOFkx-0003Ch-Di for sip@ietf.org; Mon, 05 Mar 2007 11:09:49 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2007 08:09:31 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="118039253:sNHT56144484162" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l25G9VBC019744; Mon, 5 Mar 2007 08:09:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l25G8waX021400; Mon, 5 Mar 2007 16:09:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:09:20 -0500 Received: from [192.168.1.104] ([10.86.242.117]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:09:19 -0500 Message-ID: <45EC40AF.109@cisco.com> Date: Mon, 05 Mar 2007 11:09:19 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Sip] My notes on draft-rosenberg-sip-hitchhikers-guide-00 References: <08d101c65da6$73eb1ba0$0500a8c0@china.huawei.com> In-Reply-To: <08d101c65da6$73eb1ba0$0500a8c0@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2007 16:09:20.0008 (UTC) FILETIME=[A1C73080:01C75F40] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16682; t=1173110971; x=1173974971; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20My=20notes=20on=20draft-rosenberg-sip-hitchhi kers-guide-00 |Sender:=20; bh=0a8LpzwCGRNf4zVMVzgU2Zkq8KaMsPlK53yXYBqsOqY=; b=JRRg7fsZxtyHCEtqB68lMMxViNuyB0rMrjo1pKSgWOAVYJk5FVtUoyMKrkxcG+2PHFrOnmJf jLTGAcRuX6/pOix8qGD0Fz81l9S9b4l4rZnOMs8qBjvfvJh81GkFvxwc; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This note is almost a yaer old; I would have missed it completely if Spencer hadn't reminded me of it recently. I did an update of the guide, and wanted to include Spencer's comments that were still relevant. Responses inline. Spencer Dawkins wrote: > Hi, Jonathan, > > I've been through this draft, and had some comments that I wanted to > pass along. Some of them may be relevant for WG discussion of the draft, > so I'm posting to the list. > > I want to preface everything I type below with "thank you for putting > this together". > > Spencer > > Abstract > > The Session Initiation Protocol (SIP) is the subject of numerous > specifications that have been produced by the IETF. It can be > difficult to locate the right document, or even to determine the set > of Request for Comments (RFC) about SIP. Don't Panic! This > specification serves as a guide to the SIP RFC series. It lists the > specifications under the SIP umbrella, briefly summarizes each, and > groups them into categories. > > Spencer: Just as a general thing - I love the Douglas Adams references, > and agree with your suggestion from IETF 65 that you need more of them, > but since (gasp!) there are people who may not have read them, there are > a couple of places that I would suggest handling them differently - and > this is one place. "Don't Panic!" appears in the abstract and in the > Introduction, and I'd suggest removing it from the Abstract. (And > "Hitchhiker's Guide" should be apostrophied, I think removed and apostrophed. > > 1. Introduction > > The Session Initiation Protocol (SIP) [1] is the subject of numerous > specifications that have been produced by the IETF. It can be > > Spencer: it seems fair to point out that, in addition to the (mostly) > approved specifications that are described in this document, there are > literally hundreds of proposals for SIP and extensions that are not > included in this document because they are still being produced. this is noted in the Scope section > > difficult to locate the right document, or even to determine the set > of Request for Comments (RFC) about SIP. Don't Panic! This > > Spencer: I don't have anything in my IETF 65 notes about adding the > Douglas Adams book(s) as references, but thought I remembered this being > mentioned, and I agree with adding it (for a couple of reasons). If you > add the Douglas Adams book(s) as references, it would be helpful to use > the reference to "tag" quotes and humorous references. "Don't Panic!" > really doesn't need this in the Introduction, but there is at least one > joke futher down that does (see comment below). And I believe I heard a > suggestion to use reference [42] as the Douglas Adams reference number, > at IETF 65, so the text would be "Don't Panic! [42]"... This was added as reference 42 and exists as a tag for all such jokes. > > specification serves as a guide to the SIP RFC series. It lists the > specifications under the SIP umbrella. For each specification, a > paragraph or so description is included that summarizes the purpose > of the specification. Each specification also includes a letter that > > Spencer: actually, there are a bunch of specifications that don't have > an associated letter. If it's helpful, I could chase these down, but it > looked like sending you diffs would be tedious for you to apply. We can > talk. I believe this was fixed. > > designates its category in the standards track [2]. These values > are: > > S: Standards Track (Proposed Standard, Draft Standard, or Standard) > > E: Experimental > > B: Best Current Practice > > I: Informational > > The specifications are grouped together by topic. Typically, SIP > extensions fit naturally into topic areas, and implementations > interested in a particular topic often implement many or all of the > specifications in that area. > > This document itself is not an update to RFC 3261 or an extension to > SIP. It is an informational document, meant to guide newcomers and > implementors to the SIP suite of specifications. > > Spencer: At this stage of the game, I'm assuming that deployers are as > likely to find this document useful as implementors. Are they part of > the target audience? I have a couple of notes further down that assume > "yes". Sure. Added "deployers". > > 2. Scope of this Document > > Spencer: this section should probably be split - part of it is about > "scope of the document", and part of it defines "the other > specifications that aren't SIP, but matter a lot". I'd suggest splitting > it before the last line of the following paragraph. > > It is very difficult to enumerate the set of SIP specifications. > This is because there are many protocols that are intimately related > to SIP and used by nearly all SIP implementations, but are not > formally SIP extensions. As such, this document formally defines a > "SIP specification" as any specification that defines an extension to > SIP itself, where an extension is a mechanism that changes or updates > in some way a behavior specified in RFC 3261. This is in contrast to > the "SIP family of specifications", which represent the set of > specifications that define protocols that are integral parts of any > SIP deployment, but are not SIP extensions per se. The SIP family of > specifications includes the following specifications and their > respective extensions: this is gone so a split is not needed anymore. > > Spencer: It's definitely worth a section header that says "Related > Specifications" above these documents. as above > > Spencer: it would be good to pick between "always mention the current > specification first" and "always mention the historical specification > first". There aren't many places where it's confusing, but the following > paragraph confused me: > > RFC 3550: Real Time Transport Protocol (RTP) RTP [4] is the > specification that started it all. It is the first in a long line > of IETF specifications related to multimedia communications. Its > initial version, RFC 1889 [3] was first specified in January of > 1996. RTP is used to carry multimedia traffic, including voice, > video and text, and is set up by SIP. There are countless > extensions and payload formats (possibly as many as 42) defined > for RTP. > > Spencer: Perhaps "RFC 3550: Real Time Transport Protocol (RTP) RTP [4] > is the latest version of the specification that started it all - RFC > 1889 [3], the first in a long line of IETF specifications related to > multimedia communications, first specified in January 1996. RTP is used > to carry multimedia traffic, including voice, video and text, and is > set up by SIP. There are countless extensions and payload formats > (possibly as many as 42) defined for RTP." no longer an issue since 3550 is gone > > Spencer: "possibly as many as 42" is funny, but I am more comfortable if > you have adopted a reference to the Douglas Adams book(s), and have > something like ("possibly as many as 42 [42])" in this paragraph. The > current text is just a little too deadpan for people who aren't fluent > in Vogon. this particular reference was removed when RFC 3550 disappeared. Unfortunately, this left us with no jokes about 42! Impossible for a document on hitchhikers guide. I added one (with a refernece to the book). > > RFC 3219: Telephony Routing over IP (TRIP) TRIP [15] defines a > mechanism for exchanging SIP routes between administrative > domains. Its derived from BGP. > > Spencer: s/Its/It's/, or s/Its/TRIP is/ TRIP is gone. > > Despite the importance of the SIP family of specifications, this > > Spencer: This seems slightly off - perhaps "Despite the importance of > related specifications, ..." - aren't you saying that there is more to > doing SIP than just doing what the SIP family of specifications describes? families are gone. > > document concerns itself entirely with defining the set of > specifications that make up SIP itself. Excluded from this list are > requirements, architectures, registry definitions, non-normative > frameworks, and processes. Best Current Practices are included when > they are effectively standard mechanisms for accomplishing a task. > > Spencer: "effectively standard mechanisms" seems slightly off. Perhaps > "when they normatively define mechanisms for accomplishing a task"? ok > > Also excluded are definitions of MIME objects that are used by SIP, > such as the Authenticated Identity Body (AIB) [16] and various XML > documents and extensions used by SIP. Though they are used by SIP, > they are not extensions to SIP. [[OPEN ISSUE: Is this arbitrary? > Maybe they should be included if they are specific to SIP.]] > > Spencer: You're the one who is doing the work, but if it's not too much > work, I would like to see the MIME objects included - they are very > important, and they are at least as obscure as other stuff you've included. they are now included. > > The SIP change process [17] defines two types of extensions to SIP. > These are normal extensions and the so-called P-headers, which are > meant to be used in areas of limited applicability. P-headers cannot > > Spencer: probably spell out P-headers here? Not that we know what "P" > stands for. Stealing text from RFC 3427: "... the so-called > "preliminary", "private", or "proprietary" headers, or P-headers, which > begin with "P-", and which are meant to be used in areas of limited > applicability". done > > be defined in the standards track. For the most part, P-headers are > not included in the listing here, with the exception of those which > have seen general usage despite their P-header status. > > 3. Core SIP Specifications > > RFC XXXX: Enhancements for Authenticated Identity Management in SIP > (S) RFC XXXX [28] defines a mechanism for providing a > cryptographically verifiable identity of the calling party in a > SIP request. Also known as "SIP Identity", this mechanism > provides an alternative to RFC 3325. It has seen little > deployment so far, but its importance as a key construct for > > Spencer: NO idea what "almost also" is doing in this sentence, but > assume that you meant to say something here. Just flagging for you. removed also > > almost also anti-spam techniques makes it a core part of the SIP > specifications. > > RFC XXXX: Managing Client Initiated Connections through SIP (S) RFC > XXXX [30], also known as SIP outbound, defines important changes > to the SIP registration mechanism which enable delivery of SIP > messages towards a UA when it is behind a NAT. This specification > is the cornerstone of the SIP NAT traversal strategy. > > Spencer: this is not news to you (of all people), but there are a lot of > NAT traversal-related specifications - maybe enough to justify its own > section? At the very least, having "the cornerstone" listed last seems > less helpful... all of them are here, though as you say not in there own section. Not a a bad idea to have a section on nat traversal which repeats the relevant ones. Added. > > 5. General Purpose Infrastructure Extensions > > RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an > extension to RFC 2543. It defines a method, INFO, used to > transport mid-dialog information that has no impact on SIP itself. > Its driving application was the transport of PSTN related > information when using SIP between a pair of gateways. Though > originally conceived for broader use, it only found standardized > usage with SIP-T [33]. It has been used to support numerous > proprietary and non-interoperable extensions due to its poorly > defined scope. > > Spencer: I know that draft-rosenberg-sip-info-harmful didn't advance > (even though I wish it had), but am wondering if the guidance here could > be stronger. Unless people really disagree with "However, since its > initial usage for that purpose, INFO has seen widespread abuse as a > means for introducing non-standard and non-interoperable extensions to > SIP. For this reason, we now believe INFO should be considered harmful, > and therefore, deprecated in its current form", maybe this text (from > the draft) could be inserted here. That is not appropriate for this specification. I put about as much of info-harmful in here as I think does apply to an informational summary doc. > > RFC 3326: The Reason header field for SIP (S) RFC 3326 [40] defines > the Reason header field. It is used in requests, such as BYE, to > indicate the reason that the request is being sent. > > RFC 3840: Indicating User Agent Capabilities in SIP (S) RFC 3840 > defines a mechanism for carrying capability information about a > user agent in REGISTER requests and in dialog-forming requests > like INVITE. It has found use with conferencing (the isfocus > parameter declares that a user agent is a conference server) and > with applications like push-to-talk. > > Spencer: is there a useful reference for "push-to-talk"? not at ietf. > > 10. Operations and Management > > Spencer: You have been pointing to specifications (this is good). I'm > wondering if there are a couple of places (Operations and Emergency > Services being two) where it is worth pointing to entire working groups > developing specifications. If the answer is "no, because RFCs live > forever and WGs don't", that's fine. Maybe this could be a general > observation, much earlier in the document. The scope of the document is clear - it points to SIP extensions, SDP extensions and MIME bodies. I am aggressively protecting that scope boundary. > > 13. Security Mechanisms > > RFC 3329: Security Mechanism Agreement for SIP (S) RFC 3329 [80] > defines a mechanism to prevent bid-down attacks in conjunction > with SIP authentication. The mechanism has seen very limited > deployment. It was defined as part of the 3gpp IMS specification > > Spencer: Same comment as "push to talk" - is there a helpful pointer to > "IMS", which hasn't been spelled out yet, to use as a reference? 24.229. Added as a reference. > > suite, and is needed only when there are a multiplicity of > security mechanisms deployed at a particular server. In practice, > this has not been the case. > > RFC XXXX: End-to-Middle Security in SIP (S) RFC XXXX [81] defines > mechanisms for encrypting content from user agents to specific > > Spencer: maybe you guys aren't used to working with people who are > easily confused :-) but s/content/SIP message bodies/. Also - the I > thought the draft last-called in December included integrity protection, > not just encryption? Perhaps worth mentioning integrity protection as well. added and changed > > network intermediaries. > > 14. Instant Messaging and Presence > > SIP provides extensions for instant messaging and presence. > > Spencer: I wish there was a little more definition of "presence" than > appears here, and probably earlier in the document ("presence" has a > pretty specific meaning here). These days I think its reasonably understood in communications circles. > > RFC 3428: SIP Extension for Instant Messaging RFC 3428 [82] defines > the MESSAGE method, used for sending a page mode instant message. > > Spencer: "page mode" seems pretty obscure for the intended reader base. > Perhaps "sending an instant message without setting up a session"? done > > 15. Emergency Services > > Spencer: see previous note on possibly pointing out the existence of > entire working groups. same response - not in scope. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 11:32:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOG6b-0003k6-P5; Mon, 05 Mar 2007 11:32:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOG6Y-0003jZ-OU for sip@ietf.org; Mon, 05 Mar 2007 11:32:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOG6Q-0008HS-Hl for sip@ietf.org; Mon, 05 Mar 2007 11:32:06 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2007 08:31:57 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="45278288:sNHT84362328" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l25GVvmk021242 for ; Mon, 5 Mar 2007 11:31:57 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l25GVQaH029612 for ; Mon, 5 Mar 2007 16:31:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:31:48 -0500 Received: from [192.168.1.104] ([10.86.242.117]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:31:48 -0500 Message-ID: <45EC45F3.3000007@cisco.com> Date: Mon, 05 Mar 2007 11:31:47 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2007 16:31:48.0445 (UTC) FILETIME=[C58258D0:01C75F43] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1398; t=1173112317; x=1173976317; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Updated=20hitchhikers=20guide |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=i3LwJSOWGKjv6vb3+4CizpymGVTrk3gLIYjTxUhIcS8=; b=ABlPjz87QoA/fdE05wJWZ7M50Vz8nT0YBCKwA4CU6j1aHIVcmrvuyb9RlW1PQAhM8wagh6zz 3NhKY+KnQzEP+yW+QAWooWVLbSnGqV8NlBm8dWIBxmr+M4/7GCQlpm5y; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] Updated hitchhikers guide X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Until it appears in the archives: http://www.jdrosen.net/papers/draft-ietf-sip-hitchhikers-guide-02.txt Changes: The following got promoted from I-D references to RFCs: * draft-ietf-mmmusic-sdp-media-content to RFC 4796 * draft-ietf-mmusic-sdp-bfcp to RFC 4583 * draft-ietf-sipping-kpml to RFC 4730 The following new working items got added: * draft-ietf-mmusic-sdp-capability-negotiation to the Core SIP Specs * draft-ietf-mmusic-sdp-media-capabilities to general infrastructure specs * draft-ietf-mmusic-file-transfer-mech got added to the "Presence and IM" section which was renamed to "Presence, IM and Multimedia" * draft-ietf-sip-ice-option-tag got added as part of the existing ICE description Other non-trivial document changes: * added a new section on NAT Traversal. * added reference to 24.229 when IMS is mentioned Interesting facts: * total number of references: 109 * Core SIP specs at I-D status: gruu sip-outbound SDP capability negotiation ICE connected-identity fork-loop-fix -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 12:21:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGr5-0004BM-MP; Mon, 05 Mar 2007 12:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGr3-00046f-WA for sip@ietf.org; Mon, 05 Mar 2007 12:20:10 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOGr0-00077K-Bj for sip@ietf.org; Mon, 05 Mar 2007 12:20:09 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l25HJjXO002576 for ; Mon, 5 Mar 2007 11:20:01 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:19:54 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 18:19:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Mar 2007 18:19:50 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180DC2138@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP WG finished with draft-ietf-sip-fork-loop-fix Thread-Index: AcdfSnuKuU92M3/GQTWyRZh+yaPwTw== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 05 Mar 2007 17:19:52.0823 (UTC) FILETIME=[7CBB8070:01C75F4A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Robert Sparks Subject: [Sip] SIP WG finished with draft-ietf-sip-fork-loop-fix X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1653484754==" Errors-To: sip-bounces@ietf.org --===============1653484754== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpBcyB3ZSBzZWVtIHRvIGhhdmUgZmluaXNoZWQgdGhpcyB3b3JrIGlu IHRoZSBTSVAgV0csIEkgYW0gaW4gdGhlIHByb2Nlc3Mgb2YgcGVyZm9ybWluZyB0aGUgUFJPVE8g d3JpdGV1cCBvZiB0aGlzIGRvY3VtZW50IHNvIHRoYXQgd2UgY2FuIHJlcXVlc3QgcHVibGljYXRp b24gZnJvbSB0aGUgSUVTRy4NCg0KVGhpcyBpcyBnb2luZyB0byB0YWtlIGEgY291cGxlIG9mIGRh eXMsIGlmIHRoZXJlIGlzIHNvbWVvbmUgb3V0IHRoZXJlIHRoYXQgaGFzIGJlZW4gdG90YWxseSBz aWxlbnQgdGhlc2UgbGFzdCBmZXcgbW9udGhzLCBidXQgd2hvIHN0aWxsIHRoaW5rcyB0aGlzIGlz IG5vdCByZWFkeSwgbm93IGlzIHRoZSB0aW1lIHRvIHNheSBzby4NCg0KT3RoZXJ3aXNlIHlvdXIg bmV4dCBvcHBvcnR1bml0eSB0byBjb21tZW50IGlzIHRoZSBJRVNHIGxhc3QgY2FsbC4NCg0KUmVn YXJkcw0KDQpLZWl0aA0K --===============1653484754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1653484754==-- From sip-bounces@ietf.org Mon Mar 05 12:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGyw-0005nA-AP; Mon, 05 Mar 2007 12:28:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGyu-0005mz-L0 for sip@ietf.org; Mon, 05 Mar 2007 12:28:16 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOGyt-0000Ox-9f for sip@ietf.org; Mon, 05 Mar 2007 12:28:16 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l25HS5vA027767; Mon, 5 Mar 2007 11:28:06 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:28:05 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 18:28:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Mar 2007 18:28:02 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180DC2141@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-consent-framework-01 Thread-Index: AcdfS6DX60yNOOQCQ4yB5zXQFXLwHw== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 05 Mar 2007 17:28:03.0885 (UTC) FILETIME=[A16D9DD0:01C75F4B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 1.1 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Gonzalo.Camarillo@ericsson.com, dean.willis@softarmor.com Subject: [Sip] draft-ietf-sip-consent-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0410301779==" Errors-To: sip-bounces@ietf.org --===============0410301779== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpXZSBzZWVtIHRvIGhhdmUgZmluaXNoZWQgb24gdGhpcyBkb2N1bWVu dCAtIG5vIG91dHN0YW5kaW5nIGNvbW1lbnRzLCBhbmQgbm9uZSBnZW5lcmF0ZWQgc2luY2UgdGhl IGxhc3QgSUVURiBtZWV0aW5nLg0KDQpJIGFtIHRoZXJlZm9yZSBzdGFydGluZyB0byBwZXJmb3Jt IHRoZSBQUk9UTyB3cml0ZXVwIGluIG9yZGVyIHRvIHJlcXVlc3QgcHVibGljYXRpb24gZnJvbSB0 aGUgSUVTRy4NCg0KVGhpcyBpcyBnb2luZyB0byB0YWtlIGEgY291cGxlIG9mIGRheXMuIElmIGFu eW9uZSBoYXMgYmVlbiBzaXR0aW5nIG9uIGlzc3VlcyB0aGV5IHdhbnQgdG8gcmFpc2UsIGEgZmV3 IG1vbnRocyBiYWNrIHdvdWxkIGhhdmUgYmVlbiBhIGdvb2QgdGltZSB0byBkbyBpdCwgYnV0IGZh aWxpbmcgdGhhdCwgbm93IHdvdWxkIGJlIGEgZ29vZCBpZGVhLg0KDQpSZWdhcmRzDQoNCktlaXRo DQo= --===============0410301779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0410301779==-- From sip-bounces@ietf.org Mon Mar 05 15:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9t-0002VI-Sj; Mon, 05 Mar 2007 15:51:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9G-0001Qi-Fl; Mon, 05 Mar 2007 15:51:10 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOK8r-0000QI-Bl; Mon, 05 Mar 2007 15:51:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3ECA53297C; Mon, 5 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8B-0005fU-1w; Mon, 05 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-02.txt Pages : 48 Date : 2007-3-5 This document providing clarifications and guidelines concerning the use of SIPS URI scheme in the Session Initiation Protocol (SIP). It does not make normative changes to SIP. This document also provides discussion of possible future steps in specification, and the pros and cons of making such changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sips-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-sips-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: <2007-3-5123356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sips-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sips-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5123356.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Mar 05 16:55:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOL8A-0000nH-Tp; Mon, 05 Mar 2007 16:54:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOL88-0000ml-9S for sip@ietf.org; Mon, 05 Mar 2007 16:54:04 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOL86-0000Sd-I4 for sip@ietf.org; Mon, 05 Mar 2007 16:54:04 -0500 Received: from [64.101.172.122] ([64.101.172.122]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l25Kxg0L004317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Mar 2007 14:59:43 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) To: SIP IETF Message-Id: <2E5A26A1-DF85-4D3E-911D-F22E5A5142FD@softarmor.com> From: Dean Willis Date: Mon, 5 Mar 2007 15:53:48 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Cc: Cullen Jennings , Keith Drage Subject: [Sip] Draft agenda, SIP at IETF 68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757609632==" Errors-To: sip-bounces@ietf.org --===============0757609632== Content-Type: multipart/alternative; boundary=Apple-Mail-1--596583606 --Apple-Mail-1--596583606 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Ok, an agenda is beginning to take form. Please let me know how this looks to you. HTML draft agenda posted at: http://www.softarmor.com/sipwg/meets/ietf68/agenda.html MHTML follows: Draft Agenda, SIP at IETF 68 Session 1: Tuesday March 20, 2007 1740-1840 Congress II Note: conflicts with pkix, try and avoid security discussions Discussion Lead Topic Reading List Est. Time Chairs Agenda bash, status, announcements This document 5 Jonathan Rosenberg ICE Option Tag draft-ietf-sip-ice-option-tag-01 15 Jonathan Rosenberg GRUU changes draft-ietf-sip-gruu-12 25 Robert Sparks Process for Revising 3261 15 Session 2: Wednesday, March 21, 2007 1300-1500 Congress II Discussion Lead Topic Reading List Est. Time Francois Audet SIPS: Guidelines draft-ietf-sip-sips-02 30 Cullen Jennings Outbound draft-ietf-sip-outbound-07 45 If time permits ... Marc Petit-Hugueinin Fragmentation draft-petithuguenin-sip-outbound-fragmentation-02 15 Jae Woo Lee Henning Schulzrinne SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-00 15 Mayumi Munakata Clarification of Privacy draft-munakata-sip-privacy-clarified-00 15 --Apple-Mail-1--596583606 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Ok, an agenda is beginning = to take form. Please let me know how this looks to you.

HTML draft agenda posted = at:


MHTML = follows:

Draft Agenda, = SIP at IETF 68


Session 1: = Tuesday March 20, 2007 1740-1840 Congress II

Note: conflicts = with pkix, try and avoid security discussions

Discussion = Lead
Topic
Reading = List
Est. = Time
Chairs
Agenda bash, status, announcements
This document
5
Jonathan = Rosenberg
ICE Option Tag
15
Jonathan = Rosenberg
GRUU changes
25
Robert Sparks
Process for Revising = 3261

=A0

15


Session 2: = Wednesday, March 21, 2007 1300-1500 Congress = II

Discussion Lead
Topic
Reading = List
Est. = Time
Francois Audet
SIPS: Guidelines
30
Cullen Jennings
Outbound
45
If time permits = ...
Marc Petit-Hugueinin
Fragmentation
15
Jae Woo Lee
Henning Schulzrinne
SIP URI Service Discovery using = DNS-SD
15
Mayumi Munakata
Clarification of = Privacy
15

= --Apple-Mail-1--596583606-- --===============0757609632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0757609632==-- From sip-bounces@ietf.org Mon Mar 05 17:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLXK-0006Iv-FA; Mon, 05 Mar 2007 17:20:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKsD-0006bE-94 for sip@ietf.org; Mon, 05 Mar 2007 16:37:37 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOKi7-00006p-3u for sip@ietf.org; Mon, 05 Mar 2007 16:27:22 -0500 Received: from [64.101.172.122] ([64.101.172.122]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l25KWvNq004162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Mar 2007 14:32:58 -0600 In-Reply-To: <45EC89B7.5070501@cisco.com> References: <45EC89B7.5070501@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <014B1FDF-BB80-4C18-BEFE-422F660D9C0E@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" Date: Mon, 5 Mar 2007 15:27:02 -0600 To: Antti Laurila , Thanos Diacakis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Antti and Thanos, either or both of you care to take a shot at this? -- Dean On Mar 5, 2007, at 3:20 PM, Jonathan Rosenberg wrote: > My main question here is what are the use cases for subscribing to =20 > an individual element, rather than the whole document? It would =20 > need to be a case where a user cares about changes in one of their =20 > documents, but not over certain parts of that document. For the =20 > cases of resource-lists and rls-services, it was far from clear =20 > when that would be desired. Wouldn't a user care about their entire =20= > buddy list and not just some of it? > > If OMA could provide some specific example use cases and point out =20 > problems with draft-ietf-sip-xcap-config for those cases, it would =20 > be helpful in providing concrete feedback. > > Thanks, > Jonathan R. > > Dean Willis (OMA) wrote: >> Title: OMA LS 178 on XCAP diff-event >> Submission Date: 2007-03-01 >> URL of the IETF Web page: https://datatracker.ietf.org/public/=20 >> liaison_detail.cgi?detail_id=3D303 Please reply by 2007-03-23 >> From: Dean Willis(OMA) >> To: IETF SIP WG(sip@ietf.org) >> Cc: drage@alcaltel-lucent.com >> fluffy@cisco.com >> dean.willis@softarmor.com >> Reponse Contact: Pavel Dostal >> Antti Laurila >> Technical Contact: Pavel Dostal >> Antti Laurila >> Purpose: For comment Body: 1 Overview >> This liaison seeks IETF SIP WG for the opinion on the XCAP Diff =20 >> Event Package as drafted in draft-urpalainen-sip-xcap-diff-event-00. >> 2 Proposal >> OMA PAG WG deals with a requirement to enable subscription for >> notification of changes in XCAP resource not only to single =20 >> document but also to single XCAP component (XML element or =20 >> attribute). This can not be achieved using draft-ietf-sip-xcap-=20 >> config because the subscription in this case is allowed only to =20 >> single document or folder. >> A new SIP event package =93xcap-diff=94 is defined in >> draft-urpalainen-sip-xcap-diff-event-00. This event package allows =20= >> subscription to a set of XCAP resources where resources can be =20 >> either folder or document or component identified by node =20 >> selector. As this functionality fits to current requirements, OMA =20 >> PAG WG is considering adopting draft-urpalainen-sip-xcap-diff-=20 >> event-00 as the solution for XCAP clients to receive partial =20 >> changes of the XCAP resources. >> 3 Requested Action(s) >> OMA PAG WG kindly requests IETF SIP WG on the opinion on the XCAP =20 >> Diff Event Package as drafted in draft-urpalainen-sip-xcap-diff-=20 >> event-00 and its expected progress. >> 4 Conclusion >> OMA PAG WG would like to thank IETF SIP WG for their kind =20 >> consideration and response to this liaison request and look =20 >> forward to future opportunities to work together. >> Attachment(s): >> OMA LS 178 on XCAP Diff Event (https://datatracker.ietf.org/=20 >> documents/LIAISON/file404.pdf) >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ =20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 17:38:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLom-0001gt-7D; Mon, 05 Mar 2007 17:38:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKtT-0006gd-Ov for sip@ietf.org; Mon, 05 Mar 2007 16:38:55 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOKcM-0005ZW-SH for sip@ietf.org; Mon, 05 Mar 2007 16:21:47 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2007 13:21:13 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="118159785:sNHT49345983" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l25LLDam019887; Mon, 5 Mar 2007 16:21:13 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l25LKuaL015949; Mon, 5 Mar 2007 21:21:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 16:20:56 -0500 Received: from [192.168.1.104] ([10.86.240.125]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 16:20:56 -0500 Message-ID: <45EC89B7.5070501@cisco.com> Date: Mon, 05 Mar 2007 16:20:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Mar 2007 21:20:56.0345 (UTC) FILETIME=[29A9D090:01C75F6C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3530; t=1173129673; x=1173993673; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20Liaison=20Statement, =20=22OMA=20LS=2017 8=20on=20XCAP=20diff-event=22 |Sender:=20 |To:=20OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, =0A=20=20=20=20=20=20=20=2 0OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG; bh=CTZXIrrzQC0HXqBZvLhz/CDaNZyFudM2hkfyYD5OxIM=; b=B7wkuj/vl5jvpsZqWOlfV/zbgwGrN+oOVOnFBqA7I4SQjMOEESZrKJNCKxCANhHdv4zVz0W+ mnre+Yluleae/+LKdUUGnxHqDcb2v3er02dBBqOU99f6XH0m6qVz+xQj; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org, fluffy@cisco.com, Antti Laurila , "Drage, Keith \(Keith\)" , dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My main question here is what are the use cases for subscribing to an individual element, rather than the whole document? It would need to be a case where a user cares about changes in one of their documents, but not over certain parts of that document. For the cases of resource-lists and rls-services, it was far from clear when that would be desired. Wouldn't a user care about their entire buddy list and not just some of it? If OMA could provide some specific example use cases and point out problems with draft-ietf-sip-xcap-config for those cases, it would be helpful in providing concrete feedback. Thanks, Jonathan R. Dean Willis (OMA) wrote: > Title: OMA LS 178 on XCAP diff-event > Submission Date: 2007-03-01 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=303 > Please reply by 2007-03-23 > > From: Dean Willis(OMA) > To: IETF SIP WG(sip@ietf.org) > Cc: drage@alcaltel-lucent.com > fluffy@cisco.com > dean.willis@softarmor.com > Reponse Contact: Pavel Dostal > Antti Laurila > Technical Contact: Pavel Dostal > Antti Laurila > Purpose: For comment > Body: 1 Overview > > This liaison seeks IETF SIP WG for the opinion on the XCAP Diff > Event Package as drafted in draft-urpalainen-sip-xcap-diff-event-00. > > 2 Proposal > > OMA PAG WG deals with a requirement to enable subscription for > notification of changes in XCAP resource not only to single > document but also to single XCAP component (XML element or attribute). > This can not be achieved using draft-ietf-sip-xcap-config because the > subscription in this case is allowed only to single document or > folder. > > A new SIP event package “xcap-diff” is defined in > draft-urpalainen-sip-xcap-diff-event-00. > This event package allows subscription to a set of XCAP > resources where resources can be either folder or document > or component identified by node selector. > > As this functionality fits to current requirements, OMA PAG WG > is considering adopting draft-urpalainen-sip-xcap-diff-event-00 > as the solution for XCAP clients to receive partial changes of > the XCAP resources. > > 3 Requested Action(s) > > OMA PAG WG kindly requests IETF SIP WG on the opinion on the > XCAP Diff Event Package as drafted in > draft-urpalainen-sip-xcap-diff-event-00 and its expected > progress. > > 4 Conclusion > > OMA PAG WG would like to thank IETF SIP WG for their kind > consideration and response to this liaison request and look > forward to future opportunities to work together. > Attachment(s): > OMA LS 178 on XCAP Diff Event (https://datatracker.ietf.org/documents/LIAISON/file404.pdf) > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 18:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOMJ8-0002fX-3d; Mon, 05 Mar 2007 18:09:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKsf-0006cL-4x for sip@ietf.org; Mon, 05 Mar 2007 16:38:05 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOKin-0000H3-UP for sip@ietf.org; Mon, 05 Mar 2007 16:28:18 -0500 Received: from [64.101.172.122] ([64.101.172.122]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l25KWvNr004162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Mar 2007 14:33:46 -0600 In-Reply-To: <45EC2C11.5080606@nokia.com> References: <45EC2C11.5080606@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39CA22CC-C72E-45BD-9D42-668AEADB819A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Updated draft-niemi-sip-subnot-etags Date: Mon, 5 Mar 2007 15:27:52 -0600 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It should be noted that this is a WG draft -- it just missed the -00 cutoff deadline for naming purposes. -- Dean On Mar 5, 2007, at 8:41 AM, Aki Niemi wrote: > All, > > I updated the conditional notifications draft. Until it appears in the > archives, there are copies at: > > http://akiniemi.net/drafts/draft-niemi-sip-subnot-etags-03.txt > http://akiniemi.net/drafts/draft-niemi-sip-subnot-etags-03.html > > Cheers, > Aki > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 18:11:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOMKR-00033t-Jn; Mon, 05 Mar 2007 18:10:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOMKQ-00033d-MH for sip@ietf.org; Mon, 05 Mar 2007 18:10:50 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOMKP-0007UT-Ft for sip@ietf.org; Mon, 05 Mar 2007 18:10:50 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007030523104301300109p5e>; Mon, 5 Mar 2007 23:10:48 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l25NAc6f022475 for ; Mon, 5 Mar 2007 18:10:38 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l25NAcNO022471; Mon, 5 Mar 2007 18:10:38 -0500 Date: Mon, 5 Mar 2007 18:10:38 -0500 Message-Id: <200703052310.l25NAcNO022471@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (dean.willis@softarmor.com) Subject: Re: [Sip] Reminder: Intended status needed in front matter of drafts References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dean Willis I've been reminded that all IDs sent for publication are now expected to have an "Intended status" field in their front matter. It's actually rather hard to find a definitive listing of the Intended Status values. The code of xml2rfc has this list: { {std "Standards Track" STD "This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited."} {bcp "Best Current Practice" BCP "This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited."} {info "Informational" FYI "This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."} {exp "Experimental" EXP "This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited."} {historic "Historic" "" "This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."} } Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 05 18:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOMwq-000634-Vm; Mon, 05 Mar 2007 18:50:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOMwR-0005vG-Gc; Mon, 05 Mar 2007 18:50:07 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOMwQ-0004m2-JC; Mon, 05 Mar 2007 18:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B6F5A32983; Mon, 5 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOMwM-0000yY-IF; Mon, 05 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-answermode-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Requesting Answering Modes for the Session Initiation Protocol (SIP) Author(s) : D. Willis, A. Allen Filename : draft-ietf-sip-answermode-02.txt Pages : 28 Date : 2007-3-5 This document defines two SIP extension header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-answermode-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-answermode-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: <2007-3-5155821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-answermode-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-answermode-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5155821.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Mar 06 05:40:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOX3T-0004ni-Iv; Tue, 06 Mar 2007 05:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOX3R-0004fo-Gi for sip@ietf.org; Tue, 06 Mar 2007 05:38:01 -0500 Received: from smail2.alcatel.fr ([62.23.212.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOX3N-0003Zj-VV for sip@ietf.org; Tue, 06 Mar 2007 05:38:01 -0500 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id l26AZqnA007307 for ; Tue, 6 Mar 2007 11:37:47 +0100 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Mar 2007 11:37:17 +0100 Message-ID: <45ED4457.5030101@alcatel-lucent.fr> Date: Tue, 06 Mar 2007 11:37:11 +0100 From: Froment Thomas User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2007 10:37:17.0384 (UTC) FILETIME=[6961C480:01C75FDB] X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] new draft on Record-Route X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I would like to introduce the new draft we submitted at: http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt This draft has actually two goals: - The first one is to formally suggest the use of the double Record-Route technique as a replacement (or possibly an alternative, but a consensus on replacement seems possible) to the current RFC3261 text, which only describes Record-Route rewriting solution. - Another one is to summarize the interoperability issues (and even the "official" bugs identified at http://bugs.sipit.net) related to Record-Route that have been identified by multiple people in developers's community. For some of them, this is not really a "bug" in RFC, but this is, at least, something that should be clarified; for instance, difference between the case where proxy put an IP address, and the case where it puts its logical name, and consequences on multi-homed and transport switching, could be clarified. I would like to apologize if the example on "transport switching" currently does not separate clearly enough "what is a bug" and "what is consequence of bad implementations"... It will be improved on version-01 anyway, but, waiting for your comments for a new version... Thanks, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 06 08:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZyX-0007pw-PM; Tue, 06 Mar 2007 08:45:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZyV-0007p1-HV for sip@ietf.org; Tue, 06 Mar 2007 08:45:07 -0500 Received: from smtp-1.hut.fi ([130.233.228.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOZyU-00055C-0U for sip@ietf.org; Tue, 06 Mar 2007 08:45:07 -0500 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l26Di3dp009885; Tue, 6 Mar 2007 15:44:03 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 28790-09-2; Tue, 6 Mar 2007 15:44:03 +0200 (EET) Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l26DhRwK009697; Tue, 6 Mar 2007 15:43:27 +0200 Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id D333A3A2CD8; Tue, 6 Mar 2007 15:43:26 +0200 (EET) Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31895-04; Tue, 6 Mar 2007 15:43:25 +0200 (EET) Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32]) by mail.tml.hut.fi (Postfix) with ESMTP id 552763A2CCC; Tue, 6 Mar 2007 15:43:25 +0200 (EET) Received: from t-110-3.tml.hut.fi (t-110-3.tml.hut.fi [130.233.46.233]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Tue, 06 Mar 2007 15:43:25 +0200 Message-ID: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> Date: Tue, 06 Mar 2007 15:43:25 +0200 From: sergiole@tml.hut.fi To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Spam-Score: 0.2 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: fluffy@cisco.com, rohan@ekabal.com Subject: [Sip] [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Although you explained in the email 'Re: [Sip] Outbound-07 comments' =20 some issues related to '5.3. Forwarding Requests' , I still do not =20 understand the logic and scenarios that you intend to cover. ** Q1. "If the Edge Proxy receives a request where the edge proxy is the host =20 in the topmost Route header field value, and the Route header contains a flow token, =20 the proxy compares the flow in the flow token with the source of the request. If these =20 refer to the same flow, the Edge Proxy removes the Route header and continues processing =20 the request." Where : "the proxy compares the flow in the flow token with the source =20 of the request." Assume that I always use algorithm 2: 1. "the flow in the flow token" is the HMAC of the S array True? 2. "the source of the request" is the S array True? 3. "the proxy compares the flow in the flow token with the source of =20 the request." I understand that we need to decode the flow token and verify that =20 the HMAC of the flow identifier is the same as the other part =20 containing protocol, Ips and ports (i.e. S array). Is this correct? ** Q2. "Otherwise, if the top- most Route header refers to the Edge Proxy and contains a valid flow identifier token created by this proxy, the proxy MUST remove the Route header and forward the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance." Otherwise what statement? What it is the difference with the former statement : "If the Edge Proxy receives a request where the edge proxy is the host =20 in the topmost Route header field value, and the Route header contains a flow token, =20 the proxy compares the flow in the flow token with the source of the request." 1. Compare "Otherwise, if the top- most Route header refers to the Edge Proxy " and ""If the Edge Proxy receives a request where the edge proxy is the =20 host in the topmost Route header field value," Both seem to be equivalent. 2. Compare "and contains a valid flow identifier token created by this proxy," and "and the Route header contains a flow token, " Both seem to be equivalent. Could you clarify the situation or state this in other words? ** Q3. The following text is confusing : "if these refer to the same flow, the Edge Proxy removes the Route header and continues processing the request. Otherwise,..." What do you mean by " continues processing the request"? To continue processing the request as a non sip outbound ("normal") proxy? Then the "otherwise" does not provide enough information about =20 otherwise what... Q4. "If these refer to the same flow, the Edge Proxy removes the Route header and continues processing the request. " What happen if these not correspond to the same flow? For example, 1) in the case someone changed the token, 2) the =20 registrar sent an old token, 3) the key changed due to re-booting. =20 Should we return 430 (Flow Failed)? Could you add this case in the specification? Q5. I can not imagine other situation where "the Edge Proxy receives a =20 request where the edge proxy is the host in the topmost Route header =20 field value, and the Route header contains a flow token" is NOT going =20 to do the following "the proxy MUST remove the Route header and forward the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance." "5.3. Forwarding Requests" is explained in a way that it seems that =20 there are other variations.... I can not understand what you intend =20 to consider. An example in some scenario could clarify this issue. Regards Sergio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From was@ouvaton.net Tue Mar 06 09:35:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOalI-0007Hb-PO for sip-archive@lists.ietf.org; Tue, 06 Mar 2007 09:35:32 -0500 Received: from dtf83.neoplus.adsl.tpnet.pl ([83.24.243.83] helo=aaun17.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOalC-00086m-9u for sip-archive@lists.ietf.org; Tue, 06 Mar 2007 09:35:32 -0500 Message-ID: <000701c75ffc$78414810$11150653@d10758e63a074de> From: "turned" To: sip-archive@lists.ietf.org Subject: free Date: Tue, 6 Mar 2007 15:33:54 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C76004.D96FFFC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 ------=_NextPart_000_0003_01C76004.D96FFFC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C76004.D96FFFC0" ------=_NextPart_001_0004_01C76004.D96FFFC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Miss scabbia, avril sumthin haha blackasyxx, cant, enough itand. Would = totally be nekkid. Original sound by would totally. Text recent oldest dionisus hour, ago, yep. Cover and hottest chicken long, time bad. Is cool lady beautiful much. = Fine song singers synch was bit though, that. Youtube ville, valo natalia avelon summer. Meaning man villes, whats with mean shes! Music ahm, are stoned somthing = love. Man, villes whats with mean shes sexy all voice. Allplaying next remove videos. Much nudity for not reason fits but way it! Bad watching listen original sound by. Whats, with mean shes sexy all voice dontknow! View free, account orlogin if. Old version of flash. Sexual meaning man villes whats. Passionate actually reply flashguru = hours goes prefectly music. Shes sexy all voice dontknow maybe they! Cover and hottest chicken long time. Seems has sexual meaning. Off or an old! Much nudity, for not reason fits. Wouldnt want strip, down infront = winkwink. Flashguru hours goes prefectly music ahm are, stoned somthing. As watch them, manage save clear login to rate. Othis other ones here on. Sites linking, this clicks from infoclose. Cover and hottest chicken = long? Have, javascript turned off or an old. ------=_NextPart_001_0004_01C76004.D96FFFC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Miss scabbia, avril sumthin haha = blackasyxx, cant,=20 enough itand. Would totally be nekkid. Original sound by would = totally.
Text recent oldest dionisus hour, ago, = yep.
Cover and hottest chicken long, time = bad. Is cool=20 lady beautiful much. Fine song singers synch was bit though, = that.
Youtube ville, valo natalia avelon = summer.
Meaning man villes, whats with mean = shes! Music=20 ahm, are stoned somthing love.
Man, villes whats with mean shes sexy = all voice.
Allplaying next remove = videos.
Much nudity for not reason fits but way = it!
Bad watching listen original sound = by.
Whats, with mean shes sexy all voice = dontknow!
View free, account orlogin if. Old = version of flash.
Sexual meaning man villes whats. = Passionate=20 actually reply flashguru hours goes prefectly music.
Shes sexy all voice dontknow maybe = they!
Cover and hottest chicken long = time.
Seems has sexual meaning. Off or an = old!
Much nudity, for not reason fits. = Wouldnt want=20 strip, down infront winkwink.
Flashguru hours goes prefectly music = ahm are,=20 stoned somthing.
As watch them, manage save clear login = to rate.
Othis other ones here on.
Sites linking, this clicks from = infoclose. Cover=20 and hottest chicken long?
Have, javascript turned off or an=20 old.
------=_NextPart_001_0004_01C76004.D96FFFC0-- ------=_NextPart_000_0003_01C76004.D96FFFC0 Content-Type: image/gif; name="perfectly.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c75ffc$77ab97c0$11150653@d10758e63a074de> R0lGODlhIAGoAYejAAgAAH8MAAJ+B3WKCAAAi3UAgQOKfL6/zrLbwKvH4TgdBmQVA4IWCK4oAccU AOonAAc1ABs/BUsxDGk6AnQ+AKY8AL49Dd87AAhRACtaCUlhAF9UAINXAaZnCs1cAOtdCAWDABKN AE5+AGOJAIJ7AJh9AMSLAOmJCACRBSClAEeqC2qcAI2rAJqcArSbAN+UCA20CiLHA0i0Cme4AHLO DqfLAMG/AOWyCgDVABrqDTTVAFniCHnTDqrtA8bTAOfrAAADNCkARDkAS2QANHcARZIAScYAMe4J OgYXQhMjRzoaOFgRMXctNpEpPs4oQd4gSgBFTCs6PjROM1lFQY02O5hNMrY9TtNJNgtUOhhtN0Bn PVdoNI1rA6JSQbpjRO1TRACAPSxxTUh1SFWFPHiKRJ6KQMl8S9R2MwKsNB6nS0uuS2acSHalPJSY NsWTM9uRQQW2PR67Nk7BRlm0NI7BNprAOcXIQurBQgDRORTqP0zYOlvpQorgPZzfRMbjSd7hPwAA hxQEd0kAclwMd4QJh50HibYAdusCcgsViSwiiEcRgWwufnIRfZItdrkVfeoShwBLgxU7fDo6cmtB cXpGg5Q8dsJKhOU1jQRcgiBpiUBgfl9ueoZcjpVudsJnidRWhg12hy2Fc0F7jG57jnuIjqh5dLaO ieOEgwmaii6kiEOeiVyehYKbhaWjdcCTdeWeeA3KiyK/dk61hGXIf3a5daXOjMPCc+67hQPRfRrX ek7cclnndYrefJjiiLTRgNLZfQAAsiEAx00AyGwIt3kAypoDxrgAuNUHxQcWshgguUEdslwgzXMo wZ0StMUWzOYfywBMyRM7ukc8u180zIkzxJNDvcBEu+JJwgBUxSFZtDtjslllw3Fbw6Fgvrhhytpf wwqOwiuIzDJ4vluDxoCAtamExrN8vux5vwCpyianxzGpu1STvHysuJKev8itu+emuwDKsSOztDfJ uV/BzX/LvJm6vPf37pGRsnlzi/0AAQD/AP//DQIA//gA+wH///T/9yH5BAAQ0VkALAAAAAAgAagB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKneqSn0OrCPlhpcp15FZSX09u tRo2IVmDZa8OTItWa9eoX9l6LSiXblaKdRXmfUs0rkCtWMf+dUuX8FmwhBGTdXsYcFvGgxcfBqt4 LGPIiiOH3ctXKGDHBCeLDr0W8d/Sfk+PLq2aMmvXlAWnjo36NefOQVN/bl057m7Ljmef/Sw8tuDT vGnbhr36Nm6gfo83vksa+WvmytHWHow9+WTsslk7/3/uM/py68WPZwffHT3s7OGTs/dO/qlu0O/x rzUcOjFoyIElth+A/A3YnGGNFejaePU16OCDEEYo4YQUVmjhhRiKxGBDGzLUYYZTjfehXh5xNiKI nkF0InUcmYhiV5v5V6BvMm6GnGTA8aZfZDciqN6LUqVXm430iUefbIFdF15x7wEJlZCqlRVffrSN Rhxzuxk4HHAKOvlkdfCtNx+Vw43p3kFEmiall0GCaaV1Y6aZ5JHnuWcenGw++V+NZ3a3o5/idfnn f5nxiGeeiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssDQBUJOxxBYLwLKkIAuSsw8ZC61C0ybb0bTVcpTtQtsi 1K21F1W7LLMCjTuQuc2im66z5qpbLrnjIivtuuyS2yy4H4l77r3lFjRvv+zy26+/+wY8r8H7Cozv RvoCHO+7zBr8sL0N34vwvxY/rPDCGVWM8cAWF3xQxAYhDHDIJxPMsbYqo+wyxjAT9DHIMR8sMsgr X9tuwupO3DO8FGMLr8gxr5twzjF9i3R9Si/t9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x0r9oPRv3cPZHeHZf/1LSqeedNCt8E3U24QYEfLhDfiieu+OAM+32u xpOj666mjyO+UOYDMY4Q55xL9He4OzNUNOaaDy445HoHXjjiq7vuekGEz55456tXrjvPQ/MrdL3Z np6QvEdn2jjtrEN+kO2dK+888pp7HrrLMgv8L/Ejb0ww8N0C3+nxqgtuuOoKjb+485nXLnvzucvc rr4XU09vutTaW/zRAW96vPTop4/+/8tr3vk8tzjC5Y9+NwuZzfA3ueFtLHgM5NThzJe82n3ufwRM HQYFeL4I4qxoB6RZ9bz1MhF6UH/rC9/4DNc+FeKudYUDXwHFZ7sWzu9y8qLY/W5oP/cF7YC/q9tJ /0YnxJcQsYhITGJX9KGPkjRRcrN6IimaKMWLMJGJDKniQ7ToEC4+q2QjA9rlLiVFL1akjAsx40fU qK2fgRFn2rMUGp94xYFckYpTFEgdCTLHPE4Ri3+kIyADqUcsCvKQZQQkGzXysZlZb4ScwqMf7ThJ KnKxinOkIyXRqMdJelKSeeTkJkkCwjcq7IiOkiQiK/nJPRZSkZTsZCLrOMhaspKTd/RkSCxHORPG EVOqvOUoO0nMYhazj8a0YyJDOUxmytIkjTRlCCPZTFBaM5bJFOU1jYlJZ3rzmk8EogfFCUZo5e+c ocLlHnOJSVfqsp2aVOYhX0nMdcaSnb4k5yPh2P/LfRoNjqxaZIRQKSt3ZoigSkyoQo1iQ4dMDyYI DRX/NHI7DTauotDLScVaJlEOZmR6GcyoBm9CuR6+i1QTnZ0LzafSDsawdTSUYfhmyLiGpiSa24po pFiKPOnJdKYbdKlI2UdUmZQyeyhVHkzFV1SaXnCiz3vdCynIwpnwcoy//J5Sg5o8l/oPqv7zKgDJ l7RTkrBUYOVqSF+X1gCKNaR606dcx7lD6oVQpzsVYEVvp772YZR5uBspX2vIt7nmk678xCH+TPqq h0IIr61q6UEXStnKwkSgE4Lsp/BpEFCCiHvByyFW5dgQzA60dGc1ZaYuSU9nGnSg/lQtJDXFWj7/ MtO05IHZGPupWS/VFp+WPKhJsXVC2nZWmMu80MyI60tq2raP3YSkYf053eoilrrFPRk699lbRHEW uIRsmXUPS17slne8D/wZEHVo2Wu116jvja98S9VdT2GUIqBralPMOdx+gsqxePPoflHLXFM9jrA1 hSFL/VpUlfJVqTYtKwRnm9SMUhWDCn6qULvKup9aNb0lG61WZ+o4DKeQwz3t4IMH+FIAr2S3DhyV BSeoX66mmMMXzqCLX/zAGMu4qTkGclSlimO1ChC9SM6uAnnWXFHtNXZ6hbKKbUjAJzN1que9bpJ9 6D2aMdZqOy7W2iQLlPrO98xodpKZafvaRBXY/18/9BRugaQxxposq5S6pCINOUsKLZdbsWVzPF2b zcz22FtdBhU46/nKOXPFXUoTXqcW7cdtGnqa5ayrcZGpSU5u2byg/vSnq3dXEWKajK60Z6UbneVW h1rLsHY1xBJN6y+n2XS3Vsmac83rXh9YKrs23n0/6lao8DenlbM1psLs0GI7ZWI7tHNHWQxU2SUY y9U2dhwnTOERk5WtKr5xkZntE0cim6P29eiKYbhSIZO73PbrHrrTLVZqZ5ja4wa276g1b2/reKv5 xrf5RB3rV8uaaKo1Z4Wft+4px46wHSS4qyWeXjH27p947nVqNT6SYHP84yDXdq3m7NkKvfmXV/9V diol4mi+1Jm/SD00afkIy2fSstKDxM2fux1bj08out/8Zm11LnOA9ny1NLdnp7EZyJYvBdL9np/R JwX0YVpalM+RdKQ1LSmga5OVx5x4wSk+6gS+ucA+p1Auwxv2P7YSkGQfu9wPXtI4e5nnIU973kPO 9777/e+AD7zgB0/4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpb/vKYt6zePbL5inRe5yKuH8ky3ZA7 DxEi2cqH6vMxkNWzXiCqJ8jr+b1mhXfm1PzGde6bfPpoGWT2pGA98IUP++Lr3r1cj8qdhdcwy/ku 3tJ9PvdQtluLJxvOYoRYQojf+uAbH/ghHv3/VbX/yJdjz+XOT5lZ0W0zbqeMuBKTrdmPrn5HFoT7 xX89/mO+wA/O3/SfJ2b1p34AJVrtB1pDgz3QRoC8RWD0lzGodRD6J3uwN4HBB37lh0DrV0IASHQD KD/wg3AndT/Xk4EfuIE1Uzym90uxZ3wu2H0WyED1goImaFceWEJGB38i6H/iVYOnY3scqIL/J4H3 R4FGGIOmRmrRt3wZRxV1x17hdz07Iy095DGzdoXH9jsghEPjN4Iv+ILgZ4EYCG3qRX43xDtT5yAB KDq9xxCu14KuV4Sth4GmsoYOEXoMo3KZt4d82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO//iI kBiJkjiJlFiJ87V5J3d8gOZ5EJUn+oRoo5d8nxhzJ7hzuHZEuJeGLNM3XTGK7Id6SkZhP0iKu+d7 qth53WWHLkFOisVlDlOFEeR8UhiKJmN+UbhkGPc+/XdsZmhC6YeMV0h+77M7TcgU7ddkz7iM20N9 BUM86LRAKciDCnR+0XSCoOaD5Yd2JuiNTPYW10gvyBY//ISMTPiN3CgxUKddyVaO+6aO80iONSiD N+ONdeZy9HiKO6iDJTiA9liCKyiQ0wSE7Bh9/5iEBGiR3Cg/1WiN17WN+liAdMWEhyWSSShOEhlt 2WWSCSSQ72eOBvlBVZiNEMhtzMhdPROMXf/oi41kd8QYRs2ogj9kbryjgANzk4yiix9GEUhZKUtZ VkppiVBZiE05RKkodZrIhh4JTfwHi08ZOXfohFVZlcnHiUakaywxlVqpgMA4lLrThfw4jBAIihNZ hkZzgNknWtHIltcnjdCHl1iIcH5plcrXj0I4hCGpjji1e1SIkac0kUFojvZXjyGGkSl4cZL2FOxY aoY5ktlDkCspTdbjM4X5mKSpcMO1mYvlgPIIj4GGmR+5gaSJXRBEjv23lacWiugomeIIfQwJmkuY kD04FTOomfvGgCzpm68pc7O4krpZmrN1kg+pkr0pnRtpFDOIcXmZjEAjjalFhWqZWBf3T2X/iI/D yZ3+14vS10BAOX1nWJOCySqZyIpDgZaYslFeOZ9RmZ/6uZ/82Z/++Z8AGqACOqAEWqAGeqAImqAK uqAM2qAO+qAQSjWQpWz2FxH0mS+xSEp40R85wh2HwpoWqoc7aIu0hxFNc6EWmqEdNxH+sR3KMSe0 +JWqSJFcWaLhcpU9wYv91ZPimZ5Sl5NYpR5vIiYclXKveE4JWJckmH0+xIDCaIYLmJ45qVEHuZuB tphZOYuYJqR+AqNbCZlZuo3LyZiZBp0A2ZytSaXg2EsiGaVnWH8+M0Zc+iMLkhbUCYQfSIZmhZhh RDLQeZzheHc5WqWg2ZyGGnV9shrbURZ3/yqLuWmDfNqDbymbqCk0g1pej1qK6OiS7aGoC3IojUqR kmmKxwmRv0mZAWmfOHFXO2qAf3l9SAqlJoUftCogWEKKRhp+vtieXhha56eTjRme6uWq4umdwplb OIqVGLooeKhvpoNXPoeiETqt1Fqt1nqt2Jqt2rqt3Nqt3vqt4Bqu4jqu5Fqu5nqu6Jqu6qpEV2Ia j0EjCFIYbTGvxPEb7aolWaI1MuKu87of/son/dof/CqvhjKwXmOri5EVlmEXPqKw9MoWArKvYGOr /oomAeKwf1KxAkuxHtqxHKuvEBuyHVsYGaux/yqyGvuxWfOxLHuxFquymlGvvWGvJluvJZgrNS3r sAarJXohJQn7sjsCs1eTsxY7shurshR7GTqLsCuyMkTbr0Rbskn7swEbsU3rtDbytAjLrxk7tTvr sRI7sfuqtWNLIwF7sjprKEK7sllis5rBofHKoQR7tG7LtDhyr+uat3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuQkVEAA7 ------=_NextPart_000_0003_01C76004.D96FFFC0-- From sip-bounces@ietf.org Tue Mar 06 10:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObu2-0001nD-LE; Tue, 06 Mar 2007 10:48:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObu0-0001n2-GO for sip@ietf.org; Tue, 06 Mar 2007 10:48:36 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HObty-0008QD-8O for sip@ietf.org; Tue, 06 Mar 2007 10:48:36 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070306154817m1200injkpe>; Tue, 6 Mar 2007 15:48:33 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l26FmH6f030620 for ; Tue, 6 Mar 2007 10:48:17 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l26FmHve030616; Tue, 6 Mar 2007 10:48:17 -0500 Date: Tue, 6 Mar 2007 10:48:17 -0500 Message-Id: <200703061548.l26FmHve030616@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] draft-sinnreich-sip-tools-01 - Simple SIP Usage Scenario X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A few comments concerning draft-sinnreich-sip-tools-01: Substantive: 4.2. Instant Messaging Instant messaging for SIP is based on the simple extension "MESSAGE" defined in [8]. I recall people who know more about messaging than me saying that having an extended IM session using MESSAGE is a Bad Idea, and that one wants to use a session with MSRP or TOIP media. (Adjusting section 4.2 to mention these alternatives doesn't change the essence of your proposal, but makes it more practical for messaging.) Editorial: Page 4: It represents an attempt to reign in the seemingly endless set "rein", please! Page 5: In conclusion, simple SIP is limited to the original intent of SIP; I think you want to use ":" there, rather than ";", as the following clause *is* the original intent of SIP, rather than a thought that is parallel to this clause. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From yeonf@barefootbubbas.com Tue Mar 06 10:53:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObyQ-000464-OI for sip-archive@lists.ietf.org; Tue, 06 Mar 2007 10:53:10 -0500 Received: from dhh79.neoplus.adsl.tpnet.pl ([83.23.189.79] helo=localhost.localdomain) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HObyM-0004cY-Ff for sip-archive@lists.ietf.org; Tue, 06 Mar 2007 10:53:10 -0500 Message-ID: <9a2201c76006$a06f6aae$f54b8a6e@barefootbubbas.com> From: Gabby Briggs To: sip-archive@lists.ietf.org Subject: The more SOFT /!agra you buy, the more you save. Date: Tue, 06 Mar 2007 18:48:04 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_1819C58E.61FD6DB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.8 (++) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 This is a multi-part message in MIME format. ------=_NextPart_000_0000_1819C58E.61FD6DB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_CC3C5402.BDADA828" ------=_NextPart_001_0001_CC3C5402.BDADA828 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit bad memories? Mini 'tornado' hits village Bernanke: Economy slowing as expected agenda AP - 37 minutes ago NPR UK 'Mother was assaulted in hospital' Slideshow AROUND THE UK NOW My Sources ABC News Local News (BETA) World Where I Live Comics "complete faith" in the British authorities and the police who were conducting "a thorough have made some teachers nervous about taking on the additional responsibilities TECHNOLOGY More Video/Audio News Business New User? Sign Up Yahoo! Health the money raised from registration fees because the cost of hearing a case is Centre's Miss Robertson explained: "A classroom can be full of hazards and make offer to Matsuzaka AP - 2 hours, 23 minutes ago Should there be rates continue, the last case added to the backlog in March 2007 would wait three years there who should have been seen and dealt with, who should have been struck off of teachers wanting to lead courses. Sports Bellamy 'slapped' during to deal with them." Football: Crucial win for Sheff Utd EU clears insisted patient safety was not being compromised. Unlock the code at Y! Movies Opinion to deal with them." Football: Crucial win for Sheff Utd EU clears with DWI AP - 31 minutes ago Shaq says he'll come back strong AP - 57 minutes Iron Lady bids tearful farewell Reuters UK The Sporting News World Tech FDA questions exposed remained low and most traces could be eliminated through handwashing, - Tue Nov 28, 6:33 AM ET All Full Coverage Chinese And pupils from North Bridge House School 6:33 AM ET Yahoo! - My Yahoo! - Mail Reuters Internal documents show this financial year his criticisms. AFP Yahoo!My Yahoo!Mail Sharpton's stature rises ------=_NextPart_001_0001_CC3C5402.BDADA828 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable



 
 










bad memories? Mini 'tornado' hits village Bernanke: Economy = slowing as expected
agenda AP - 37 minutes ago NPR UK 'Mother was assaulted in = hospital'
Slideshow AROUND THE UK NOW My Sources ABC News Local News (BETA) World = Where I Live Comics
"complete faith" in the British authorities and the police who were = conducting "a thorough
have made some teachers nervous about taking on the additional = responsibilities
TECHNOLOGY More Video/Audio News Business New User? Sign Up Yahoo! = Health
the money raised from registration fees because the cost of hearing a = case is
Centre's Miss Robertson explained: "A classroom can be full of hazards = and
make offer to Matsuzaka AP - 2 hours, 23 minutes ago Should there = be
rates continue, the last case added to the backlog in March 2007 would = wait three years
there who should have been seen and dealt with, who should have been = struck off
of teachers wanting to lead courses. Sports Bellamy 'slapped' = during
to deal with them." Football: Crucial win for Sheff Utd EU clears
insisted patient safety was not being compromised. Unlock the code at Y!= Movies Opinion
to deal with them." Football: Crucial win for Sheff Utd EU clears
with DWI AP - 31 minutes ago Shaq says he'll come back strong AP - 57 = minutes
Iron Lady bids tearful farewell Reuters UK The Sporting News World Tech = FDA questions
exposed remained low and most traces could be eliminated through = handwashing,
- Tue Nov 28, 6:33 AM ET > All Full Coverage Chinese And pupils from = North Bridge House School
6:33 AM ET Yahoo! - My Yahoo! - Mail Reuters Internal documents show = this financial year
his criticisms. AFP Yahoo!My Yahoo!Mail Sharpton's stature = rises

------=_NextPart_001_0001_CC3C5402.BDADA828-- ------=_NextPart_000_0000_1819C58E.61FD6DB0 Content-Type: image/gif; name="z.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhJwLcAPQAAAAAABMUEyMsHzMzCi4uLThCMyJ1HktLDklePWhoFFlZWV97UHR0dAAk /P8YAIyMGoqzdNLSKOPjKvLyLv7+MJKSkrKysqHRh7rwm8X/pczMzNLS0ubm5vb29v///wAA ACwAAAAAJwLcAAAF/6AnjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0 Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqLjI2O j5CRkmQGlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys5U1tLe4ubq7vL2+v8DBwqq2 w8bHyMnKy8zNzqvFz9LT1NXW19jL0dnc3d7f4OHT2+Ll5ufo6eqb5AYZ7/Dx8vP09fb3+Pn6 +/z9/v8AAwocSLCgwYMIEypcyHBgpnYNI0qcSLGixYsYM2rcyLHgQxqZOoocSbKkyZMoU/+q JPhxRsiVMGPKnEmzps2SLWW8vMmzp8+fQIOqzBljp9CjSJMqXco0HlEYRptKnUq1qtWKT19E vcq1q9evYLO62Aq2rNmzaG2KbUE2rdu3cONSXMuirdy7ePPqvUd3hV2RAAL/FPyV8N6Ghq0G XjxvceKYfVX87cjY5+OrlwtmlruZqePK7z53Phk5xeSNgkcf1qgaYOu0r4WCrjw7dsfSKE6z BpDB9mqKvvcFBzu852PCx3nLxH1Cd8bUyuFBj/7Z3mXD1aVH7709HnLejuWFFz/eO2ju5kOD x17eevvp3bmfTww/Pnry2udv/y7f/fXyyd2nnnn61QNferXVJh7/fuqd12B87dHTWXEYMWeC cxexRyBtohkIoXKiUbefffeFCGKH+b2XnYAlZheifyuauKGC2smX2X8P0jigjTeimKOGO9J3 oo+byfjjjycSmB6P7MXoY2MksgiThSVgaBGQDTIo5ZI7CojllkECKWSNXbaYJJkOfqmll19i OSaYZHbp5ohZusdlm+vF2eKdJOqYpohlFsimnvzpmZ+HUZKGCUQo4bkmnG8GyGKRZ4bpIYOR 0imlpPmoWSiamo6WKaahJgppdxo6KiGgq5L66Kfggepqq/g4eChNVJJgJXCospriiuSxKumb UAY65IcvnrpkcsneA2CvZe4pq3/TVist/4xQNtsfocj6+mql0RYKXZjJRmgjtauaqugljJpk ordM2lrtsJoWO6mIz5bbZ6nBPtmvjpYuy6+zldIrcKdOaiuonETuO6uhqebZZMMqmjuhuuta 0i5J734aba0FQ3vvpSP3+7Gh3IaL8YMMPxzwyyR7Cq7HINOcLZdmhkyytZsCOq6aiHb7KM4z 5TrCrhL1qLI/4y5dsr3EurymxzTbRqzBB/PcqszGnkyw1wOqerXDWUPss3SDCkf2VEaLgHRE Sm8ZdbYip70t1AO3HOd3IYPbNa13Azznra1FOHidqo3Np90c3nqqrziqjO/UM1deVdsevM3Q xXL7m+6/E5sLc//oIwJLsYvdyoskvqafPp7oSs5Ius10C+kkqCga+fjtoPc6ueyl62dxlBRu hLnmC3Heo+rB1m4ypX+z/C/dz/udY81nHjj9hmyaaiuw59JO/fY9szwxzAguPOPNda5v8vtD owzZoiBhclbxv+2GF/75s0S/S/YrC/P6d5IBmoV/BAzI8QLoFdglsCQORAsCH+iPBV6COBOk 4OYy6JmVadAgFrTEB0dIwhJO6X86YaAJV8jCFmIFhUVRoQtnSMMaKhCGUJGhDXfIwx7CI4SV 8KEQh1hDILrjMHELCAc3aCeODGeJ+oAiFIOWOg0acTVJdI0HUUO8LSrkiV7UTBhBBjb/gijM c7+5IhLtM8VGddE4Y4xJGxPUPgPiRY17yaJUOMeTNlImjmQsWxnzgke9ZJF3NeKP4RgDPRUF zpGO/FX6+Oa7RCmSebaTJPnQE0ntpUhZ4EsZJw3IRwIWMi9xM1KAKJmvUK7uV8dKECKb9aLc oZFcruweLIMny2e98pfFymWmbgmnYu7llPvrWPTENKS9/Y59ulxcHSFHzWdSjWwAE1i9FDdN 3DnTcVKjXDc/R84EIvMuHVsbM//GqW85jWfiElnUxIc3oiVyblXzWzwFqSxjjsqeqrMjIXGo FR2ik41C09s13+nO8vEznvrCGSURFr1NxouVr5On5Rxazyai/49ZiPrgOTmD0F2mz1r53NlH NTqrd1WUdE2cGyyBh9HGZe2f8rsW4HTKUXtZkaBjMShJaZXRk45On2tbqdT2qVKZwm6hRK2X T6cqLZx6jZ4la2cx/XiVkcYllVJtmk5TulOeYm1apXxa/MaKTaDl1KFQ1arWJIpUInoVLmAF 593Y6sx9UdOnTfomO8O60Y5e1ZrbLNVfnxbYqH4NcW7d4V3fAlZ/CWpst9TdfxI2y4bRdaYx k+pnkQS8XQorsZk9FhU55Lm0PnCybkliUb3jMtvlaWvq02TY1Ne60UovtPY0FuuqeE+r2raf e63ebvUY3P7BlohqUykRp8hVY/rwuf/QpVxSpwtI4SatuybEbnZN61Ho8k93iAFvCcU7Xt2W dYgTzGVCqptGoLJFqO3Nr37hwt79+ve/bLNvXfAL4AIbuCn9PbCCF4wrAfuFwAyOsISX42DJ QHjCGM4wSRKs4Q57uCEc/rCIR+yQCpvmwiROsYpvyK76XXDFMI5xiVsMwBfL+MY4zkeIc8xj D++4x0Ce8I+DTGQFD7nISP7vkZPM5PYuuclQHuKTo0xlyZo4NyiuspbHO+Utezm8V25Olr9M ZivTOIU2LrOaodvlwzjgzXCOswO4Imd41Pkdd0aInOdsjzzPo85+XrNTwnyhMZdwz4i2Sp4X HWc9J/oegcb/c6MzEGlBZ6DNe0H0nhU9aUp3utIB0TQ+Kn1nUK8Z03rR9KbBwmg4O9rV+iB1 py3NF0JXydAkbDWs7TxrXru61/kQdbAbDWxd89nTux52spG96lH32th/frQ8AD1rar85HsLe L6rz4mdjP1vVx3a2qpWdbUnvGtrk9vay6xFodJu73MwuN7jfLe38bhsv3Z40uMO973Czu9/i Hrevr03vgfubHvumN7D/fe5qfxrgBq+3wPt9cDbbWle4HqG3C55vYpu64CDvs7UbTnKCxzvd J4/3whH+8GS7e+PNVjms3e3kix8t4x+k+Jxf3nKT8yPmLC/5sXm+7mn3fOgrZ7jJ/zvu82gf 3eDY/rjCtW1zt+FcgxQPOdGbLnJ4O33pT9d60sUudH+M3N+RnjfZfW5qtdu76pm7OgUhnvK6 01zp15b61pFedkiHve77OLvRXS74tfN74ZuWeg/vfZeEQ93wj+862Ise9b7b/e94j7ziB5/3 b1t+75Xn+t2zy3i5fBz0Ic986oM++dbz3fUBf73s/yHw0M/e8Dtn+sFRf124I++Bevc44YVP +ccD/eud//vokQ/4zXM+7WGPOd0BD/JmOx/MZ45hmnkY/NrLXPFZ97vbL295yUt87ObnOvnH P33oO576ZtaYi0UoRPDDe/rpP/7zz/959Ct82ddne+qne//19m7Nh3jvF4AkVHpx4Xyy9mvF x3p8hn4jx3yQF3gIGIH5J4HPZ4Dix3YrV2rlx0MMuEMKeBAnmGlNl4IMVoI2xIIEAYP4hnkr 5oI1JIMCgYOm934xZoM0pIMAAYQN6H096Hty919CaHb+N3f6V4NGuH20FoUu5INSWIVd9YT0 Z4VauF5YGERb+IUi1YVHBIZkaEpiGGMYAAEIIAABkE5u+IZwGIdyOId0WId2OIcCQAALcAE8 RoU0tAAAoAAWoAEcMAlZsAEaUAEEUAAQgGN+2EIXgAAKUIiG+AUWoIc39ogrBAEAUAGVKAYd oAAIIGOaWEIYgAAW8IlkoAALUIT/2ZdDUKhhC8AAqkgGHSAAjeiEr1hQsYhhGBAAHVCLZGAB BQBjpThCC+CJwkgGBMCHKnaMHyQAG7CMZMAArfiMZ/hhv0iNw1iM2LiLQdWLEnYBBMCNY6AB AqCL8ldjWdhh5GiOYrAB6fiN64hm7ahh7wiPYCCP6lgL8+eFHpaP+ugF/EiP/siOAOmO5VgE DdCQDjkCD2kCDjmRJTCRDQmRF0kCFFmRGYmRDeCRFvmRHhCSHSkCJJmRETmSJRkEBZli0EhB AhkEJymSKamRIQmSFmmSJbmRHCmSHomTGzmTNkmSOumTNcmS8+iS2RiQCymTNYmSKzmUQ+mT KlmUIIkC/0eZkkf5k1ypklQplVZJBC1JYi/5QDH5A1tJk1HZlV4pkWHJkxK5klq5lm3ZlVsZ lnU5BGM5YmWZQGfZA3fJlj0pmIMJl3H5lXP5lWyZmFjZkYHZA3spYn1JQH/JA4+Zl4dJmFJ5 mV55kkAZkYlplJ6Zl5ypA5H5YUZ0h6q5mqzZmq5Zh02JlnSJl5lJm4dpmLdJlEV5k52Zk58J laKpmD+wAa9ZnMZ5nMhph0ZEAczZnM75nNAZndI5ndRZndZ5ndiZndq5ndAZAbHpAykZGIPZ mMGpAqNJnuOJmVNpmIHJmGI5ANwZn/I5n/RZn/a5nct5n/q5n/zZn/XpnUIQkf8AIAIDqpl4 eZmg+ZhZ6Zh0maA72aAMKpw+sAHw6Z8WeqEYmqHNmZ8a2qEe+qHVCaABepEFOqBqKaGYmZYH OpsLWp4n4J62aZezyQMUCqI2eqM4ypwcmqM82qP2KaJO2ZAlCpwp8JRGuqIQipgRip67aaBO UKM+GqVSSp87OqVWeqXPCaRBOqQnepO62ZtB+aBr2aK/eaJTuZu+CaNCAKVY2qZuuqFi+KZy KqVaGqBDWqZgqqQ82aKKSaZoGqZ6+pFCSZozugNsOqeI6qNVmqiMqqF1KgQlOpA0cKiNWqke uqiWmqn6+ahBEKmSKgOUqqmiyp+YOqqmup0RIAAj6pD/JRoYM/mqsBqrsjqrtFqrsSoEGlCh p7qr9VmqvPqr0jkBAbCqQkoCAGCryJqsyrqstioEFnAAwBqt+Bmn0lqt0jkAGlAE4mmsBfqp LMAAD2Ct4jqdvjquv/oAtEgE21oC6+qtKBAAEmCu8gqn4HhflzCv4iqslNipHtCtJuCv7koC FZAA+Dqv5Vqwo/oACjAEAPuvAWsCHBAAEYCw5nqwFKupCaCM/JoCDeuuHVAA4Xqx4mqxIlup EpAA6QoEHTsCKyupHFAABFuy1kqyMsuoE5AABJCtKsuxDysCFRAAIVuz0kqzQpuoDzAABMAA FaABTNu0Tvu0UBu1TLuygSG1/1Z7tVibtVq7tVzbtV4btRZQAQwQAAkwsUU7tNR6trwaAQ+Q AAPwtnAbt3I7t3QLtw0bGHWbt3q7t3zbt377t4AbuHV7AAnwAPGqtmhbrwN2r4jbuNEJsIHh uJI7udZJtJSLsJB7uZq7uRRguZxrrpn7uaKLuJ47utb6GaabukJbuqrbuq77ulbKurA7u7Rb uxgqu7abu7q7u9qJu7z7u8ALvL4bvMRbvLA7vMabvMrLuci7vM77vGrbvNA7vdSLsNJbvdib vYlbj9pnCdr7veC7umkbvuRbvhU7vuabvuq7q9e7vu77vh/avjj6ZuNKv+Jqv1aKv8+pv9jJ vwjrv//Xib/6C8CnKr83KsAOEK0EzKsLnKME3MDSCcH1m8DcicDOKcGZasA2asHAisGi6sEf CsIBTMGmy8HMKcKMqsEgasIMTMLVisIaCsPUKcNCy8I0LKcqHMIULGczDGfQycPNSb9xNp1C 7MMUMMQXjMQn7MJGfMRK/MMuvMRB/MQDHMX7+8RQnMRNPMVFrMVV7MT8O8QPvMMJjMVJDMZR DMRSvMVX3MRhfMVOjMZEXMZGrMT2W8Rh7MM2bMXsi76aesdmzMVujGiCHMhorMdArGlTzMWF PMZZfMh7HMGELMmNzMSTDMkkrMhLvGeUjMl87MmV3MiSnMiWbMmgHJ2EzMn/cXzKrPzF23uQ 9lgJu8rCqEzGZHzGm7zItZzJHOzKq7zFtIzLUjzMq1zMxizMxyzMkZzLxIzAvKzLYNzJgzzK 0GzCbPzIv1zKZzzNu8zIwwzIz9zMyxytOeyhwYzMjkzMyazOvgzHa9zO62zMgOzO8DzH9nzM 84zLeczOt4zM+mzKtfzP9PzJ0PzNmXzEulzP/CzQ8tzP1QzQ5OzHmXrOBT3K4azO6AzRglzI bazKUBzO+9zQ1mnI2TzJIa1qC43Pn5zPGF3Q4KzKEHzSt5zPCi3SCe3Q2ezONh3RivtgjGuq FN3SoZzS2LzTl+zRnkzQLC3T/uzF13zTJp3GtgzT/wAd0o9c066M0vFc0RbcxeOs0zbN0jmt zBr9q+XcoUEdz0j81Rn9z0uN0yL81gPd1JuM03PdyTd9zwYN1gwt1GGt1ASN0V1Nx8WM1RpN 01Ut1S4d2KJ61jF80QGd1w9N1zs91uLMzFtNybQs1uns15Zd1J8N1mKt1nC90omt13h92QfN 1ovN0Fmt2BTr2Bma1iUtzpDd2X/tzYXN2l6s09bc2U992ZON2a9N1rp9137ty8VdnZvtzG0d 2SnN2Rcd3OMq2xjqzIBtx0dd1q0N1Wqs3EhNzU6N3YasydB9ya3s0eAd3pKd3BC93SMd3oN8 2Kb93NJdybfN2Jpq3Rdaxf+BjcVrXdqpvd797N8cHd9WrMZ1vdUBPuBmLMal3M7+TdiRbdgZ Dcz6fcgffdwW3t33vdG8XcASDb/zecP5m+EkHr0jnuLbSd1vauAszrwrHuMIjuJXat40frn8 jb0ujqgKnuOUu+NAPuQxLuREfuTva+RIvuTmq+RM/uTf6+RQPuXUK+VUfuXLa+VYvuXEq+Vc /uW76+VgPua0K+Zkfuata0TrsOZs3uZu/ua+0A5wPud0Xud2fudiiOd6vud83ufZIOd+HuiC PuiEvguAXuiInuiKvuifcOiM/uiQHul+3rOUXumWfumYnumavumc3ume/umgHuqiPuqkXuqm fuoLqJ7qqr7qrA4EIQAAOw== ------=_NextPart_000_0000_1819C58E.61FD6DB0-- From sip-bounces@ietf.org Tue Mar 06 11:08:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcCu-0008Dn-3p; Tue, 06 Mar 2007 11:08:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcCr-00088t-0z for sip@ietf.org; Tue, 06 Mar 2007 11:08:05 -0500 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOcCn-0004OZ-NJ for sip@ietf.org; Tue, 06 Mar 2007 11:08:05 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070306160731b16008qkv7e>; Tue, 6 Mar 2007 16:08:01 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l26G7U6f032015 for ; Tue, 6 Mar 2007 11:07:30 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l26G7UID032011; Tue, 6 Mar 2007 11:07:30 -0500 Date: Tue, 6 Mar 2007 11:07:30 -0500 Message-Id: <200703061607.l26G7UID032011@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Sip] draft-lee-sip-dns-sd-uri-00 - SIP URI Service Discovery using DNS-SD X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A few comments concerning draft-lee-sip-dns-sd-uri-00: Substantive: In regard to DNS SD, realize that most of your readers are not familiar with it, so it might be helpful to give at the beginning a high-level description of the service that DNS SD provides. Viz., once one has decided upon a domain, one can use DNS to find all service instances (of a particular type) that advertise themselves in that domain using DNS SD. 5.2. Request Destination It seems to me that this could be both simplified and corrected by just saying that if a "contact" attribute is available, it should be used as the request-URI of any out-of-dialog SIP request. Since this definition automatically refers to RFC 3263, it allows a lot of generality while behaving correctly in various special cases. For example, consider If the "contact" attribute of the TXT record is available, the host part MUST be taken as the destination host to which to send the request. For example, if the TXT record contains "contact=sip:carol@cube2214a.chicago.com", the request must be sent to cube2214a.chicago.com. If "cube2214a.chicago.com" has SRV records, this may not be correct as written. The revision also explains what to do with the user-part of the contact, etc., which may be significant. (E.g., as a SPIT preventative, some SIP phones demand the correct user-part or a specific URI-parameter in the request-URI of incoming requests.) Editorial: 4.3. contact See Section 25.1 of [RFC3261] for the precise definitions of these elements as well as those of contact-extension and display-name. Please also add a reference to the last paragraph of section 20 of [RFC3261], which contains a vital rule that resolves an ambiguity in the BNF of section 25.1. However, you need to be more careful discussing the syntax. Do you intend for the value of the "contact" attribute to be parsed as a "contact-param" as defined in RFC 3261? If so, you should make it clear that contact-parm admits strings that are not URIs (though they contain URIs) [1], and that some strings that appear to be URIs are not [2]. In general, don't refer to a contact-param a URI, say it contains a URI. Parsing contact-param should not be undertaken lightly! [1] E.g., '"Dale Worley" ' [2] E.g., 'sip:Dale.Worley@comcast.net;transport=tcp' is not the URI 'sip:Dale.Worley@comcast.net;transport=tcp', it's the URI 'sip:Dale.Worley@comcast.net' with the meaningless field parameter 'transport=tcp'. To specify the URI 'sip:Dale.Worley@comcast.net;transport=tcp', one must write ''. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 06 14:37:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOfRl-0003VL-2n; Tue, 06 Mar 2007 14:35:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOfRi-0003VE-Sg for sip@ietf.org; Tue, 06 Mar 2007 14:35:38 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOfRh-00060k-Cj for sip@ietf.org; Tue, 06 Mar 2007 14:35:38 -0500 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l26JYVN03990; Tue, 6 Mar 2007 11:34:31 -0800 In-Reply-To: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 6 Mar 2007 11:34:20 -0800 To: sergiole@tml.hut.fi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: sip@ietf.org, Rohan Mahy , fluffy@cisco.com Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, For Question 1 I think an example of Algorithm 2 may be helpful. I will follow up later with answers to your other questions. I have an edge proxy at 1.2.3.4:5060 and a UA with outbound support registering from the public address 5.6.7.8:9999. transport = UDP (i will use 0x01) local IP and port is 0x01020304 0x13C4 remote IP and port is 0x05060708 0x270F S = 0x01 0120304 13C4 05060708 270F I will use the string "my key is not strong" as the key K HMAC of S with the key K = 0x5915 581d 9b7f 17a0 d8b1 ade2 5de6 04b0 5197 a6c9 The flow token is therefore the base 64 encoding of [ HMAC(S,K) + S ] = WRVYHZt/F6DYsa3iXeYEsFGXpskBASAwE8QFBgcIJw8= (Note that the text is misleading and needs to be clarified. The flow token is 44 octets on the wire, although it can be represented in 32 octets on the proxy before it is base 64 encoded) On Mar 6, 2007, at 5:43 AM, sergiole@tml.hut.fi wrote: > > Hi, > > > Although you explained in the email 'Re: [Sip] Outbound-07 > comments' some issues related to '5.3. Forwarding Requests' , I > still do not understand the logic and scenarios that you intend to > cover. > > > ** Q1. > > "If the Edge Proxy receives a request where the edge proxy is the > host in the topmost > Route header field value, and the Route header contains a flow > token, the proxy compares > the flow in the flow token with the source of the request. If these > refer to the same > flow, the Edge Proxy removes the Route header and continues > processing the request." > > Where : "the proxy compares the flow in the flow token with the > source of the request." > > Assume that I always use algorithm 2: > > 1. "the flow in the flow token" is the HMAC of the S array > True? no, the flow in the flow token is the UDP flow from 5.6.7.8:9999 to 1.2.3.4:5060. The proxy removes the base64 encoding from the flow token and takes the last 13 octets to get S again, computes HMAC(S,K), and verifies that this matches the first 20 octets in the flow token. > 2. "the source of the request" is the S array > True? no. the source of the (just received) SIP request is the IP address, port, and transport over which that new request (not the original register request) was received. The proxy compares the source address from S with the source address of the new request. > 3. "the proxy compares the flow in the flow token with the source > of the request." > > I understand that we need to decode the flow token and verify that > the HMAC of the flow identifier is the same as the other part > containing protocol, Ips and ports (i.e. S array). > Is this correct? yes thanks, -rohan > > ** Q2. > > "Otherwise, if the top- > most Route header refers to the Edge Proxy and contains a valid > flow > identifier token created by this proxy, the proxy MUST remove the > Route header and forward the request over the 'logical flow' > identified by the flow token, that is known to deliver data to the > specific target UA instance." > > Otherwise what statement? > > What it is the difference with the former statement : > > "If the Edge Proxy receives a request where the edge proxy is the > host in the topmost > Route header field value, and the Route header contains a flow > token, the proxy compares > the flow in the flow token with the source of the request." > > 1. Compare > > "Otherwise, if the top- > most Route header refers to the Edge Proxy " > > and > > ""If the Edge Proxy receives a request where the edge proxy is the > host in the topmost > Route header field value," > > Both seem to be equivalent. > > 2. Compare > > > "and contains a valid flow > identifier token created by this proxy," > > and > > "and the Route header contains a flow token, " > > Both seem to be equivalent. > > Could you clarify the situation or state this in other words? > > > ** Q3. > > The following text is confusing : > > "if these refer to the same flow, the Edge Proxy removes the Route > header and continues processing the request. Otherwise,..." > > > What do you mean by " continues processing the request"? > To continue processing the request as a non sip outbound > ("normal") proxy? > > Then the "otherwise" does not provide enough information about > otherwise what... > > > Q4. > > "If these refer to the same flow, the Edge Proxy removes the Route > header and continues processing the request. " > > > What happen if these not correspond to the same flow? > > For example, 1) in the case someone changed the token, 2) the > registrar sent an old token, 3) the key changed due to re-booting. > Should we return 430 (Flow Failed)? > > Could you add this case in the specification? > > > Q5. > > I can not imagine other situation where "the Edge Proxy receives a > request where the edge proxy is the host in the topmost Route > header field value, and the Route header contains a flow token" is > NOT going to do the following > > "the proxy MUST remove the > Route header and forward the request over the 'logical flow' > identified by the flow token, that is known to deliver data to the > specific target UA instance." > > "5.3. Forwarding Requests" is explained in a way that it seems > that there are other variations.... I can not understand what you > intend to consider. An example in some scenario could clarify this > issue. > > > Regards > > Sergio > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 06 15:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgDj-0000EM-VO; Tue, 06 Mar 2007 15:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgDi-0008Bt-AG for sip@ietf.org; Tue, 06 Mar 2007 15:25:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOg95-0005kL-Hc for sip@ietf.org; Tue, 06 Mar 2007 15:20:33 -0500 Received: from [64.101.172.122] ([64.101.172.122]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l26JQDH0009445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Mar 2007 13:26:14 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) To: SIP IETF Message-Id: From: Dean Willis Date: Tue, 6 Mar 2007 14:20:17 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Cc: Cullen Jennings Subject: [Sip] Revised SIP agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282566915==" Errors-To: sip-bounces@ietf.org --===============1282566915== Content-Type: multipart/alternative; boundary=Apple-Mail-1--515794571 --Apple-Mail-1--515794571 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've very slightly tweaked the SIP agenda. I had the wrong room for one of the sessions, adjusted timing slightly, and added another draft to the "If we have time" wish list. Draft Agenda, SIP at IETF 68 Session 1: Tuesday March 20, 2007 1740-1840 Grand Ballroom Note: conflicts with pkix, try and avoid security discussions Discussion Lead Topic Reading List Est. Time Chairs Agenda bash, status, announcements This document 5 Jonathan Rosenberg ICE Option Tag draft-ietf-sip-ice-option-tag-01 15 Jonathan Rosenberg GRUU changes draft-ietf-sip-gruu-12 20 Robert Sparks Process for Revising 3261 Mechanism for Publication Prioritization of Issues Which current drafts are bugfixes? 20 Session 2: Wednesday, March 21, 2007 1300-1500 Congress II Discussion Lead Topic Reading List Est. Time Francois Audet SIPS: Guidelines draft-ietf-sip-sips-02 30 Cullen Jennings Outbound draft-ietf-sip-outbound-07 45 If time permits ... Marc Petit-Hugueinin Fragmentation draft-petithuguenin-sip-outbound-fragmentation-02 15 Jae Woo Lee Henning Schulzrinne SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-00 15 Mayumi Munakata Clarification of Privacy draft-munakata-sip-privacy-clarified-00 15 Thomas Froment Record route management draft-froment-sip-record-route-fix-00 10 --Apple-Mail-1--515794571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I've very slightly tweaked = the SIP agenda. I had the wrong room for one of the sessions, adjusted = timing slightly, and added another draft to the "If we have time" wish = list.

Draft Agenda, = SIP at IETF 68


Session 1: = Tuesday March 20, 2007 1740-1840 Grand Ballroom

Note: conflicts = with pkix, try and avoid security discussions

<= TD valign=3D"middle" style=3D"width: 65.0px; margin: 0.0px 1.0px 0.0px = 1.0px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 4.0px = 0.0px 4.0px">
10
Discussion = Lead
Topic
Reading = List
Est. = Time
Chairs
Agenda bash, status, announcements
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgDj-0000EM-VO; Tue, 06 Mar 2007 15:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgDi-0008Bt-AG for sip@ietf.org; Tue, 06 Mar 2007 15:25:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOg95-0005kL-Hc for sip@ietf.org; Tue, 06 Mar 2007 15:20:33 -0500 Received: from [64.101.172.122] ([64.101.172.122]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l26JQDH0009445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Mar 2007 13:26:14 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) To: SIP IETF Message-Id: From: Dean Willis Date: Tue, 6 Mar 2007 14:20:17 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Cc: Cullen Jennings Subject: [Sip] Revised SIP agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282566915==" Errors-To: sip-bounces@ietf.org --===============1282566915== Content-Type: multipart/alternative; boundary=Apple-Mail-1--515794571 --Apple-Mail-1--515794571 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've very slightly tweaked the SIP agenda. I had the wrong room for one of the sessions, adjusted timing slightly, and added another draft to the "If we have time" wish list. Draft Agenda, SIP at IETF 68 Session 1: Tuesday March 20, 2007 1740-1840 Grand Ballroom Note: conflicts with pkix, try and avoid security discussions Discussion Lead Topic Reading List Est. Time Chairs Agenda bash, status, announcements This document 5 Jonathan Rosenberg ICE Option Tag draft-ietf-sip-ice-option-tag-01 15 Jonathan Rosenberg GRUU changes draft-ietf-sip-gruu-12 20 Robert Sparks Process for Revising 3261 Mechanism for Publication Prioritization of Issues Which current drafts are bugfixes? 20 Session 2: Wednesday, March 21, 2007 1300-1500 Congress II Discussion Lead Topic Reading List Est. Time Francois Audet SIPS: Guidelines draft-ietf-sip-sips-02 30 Cullen Jennings Outbound draft-ietf-sip-outbound-07 45 If time permits ... Marc Petit-Hugueinin Fragmentation draft-petithuguenin-sip-outbound-fragmentation-02 15 Jae Woo Lee Henning Schulzrinne SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-00 15 Mayumi Munakata Clarification of Privacy draft-munakata-sip-privacy-clarified-00 15 Thomas Froment Record route management draft-froment-sip-record-route-fix-00 10 --Apple-Mail-1--515794571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I've very slightly tweaked = the SIP agenda. I had the wrong room for one of the sessions, adjusted = timing slightly, and added another draft to the "If we have time" wish = list.

Draft Agenda, = SIP at IETF 68

This document

5
Jonathan = Rosenberg
ICE Option Tag
15
Jonathan = Rosenberg
GRUU changes

Session 1: = Tuesday March 20, 2007 1740-1840 Grand Ballroom

Note: conflicts = with pkix, try and avoid security discussions

Discussion = Lead
Topic
Reading = List
Est. = Time
Chairs
Agenda bash, status, announcements
draft-ietf-sip-gruu-12
20
Robert Sparks
Process for Revising = 3261
Mechanism for = Publication=A0
Prioritization of = Issues=A0
Which current = drafts are bugfixes?

=A0

20

Session 2: Wednesday, March 21, 2007 1300-1500 Congress = II

This document
5
Jonathan = Rosenberg
ICE Option Tag
15
Jonathan = Rosenberg
GRUU changes
Topic
Reading = List
Est. = Time
Francois Audet
SIPS: Guidelines
30
draft-ietf-sip-gruu-12
20
Robert Sparks
Process for Revising = 3261
Mechanism for = Publication=A0
Prioritization of = Issues=A0
Which current = drafts are bugfixes?

=A0

20

Session 2: Wednesday, March 21, 2007 1300-1500 Congress = II

<= TD valign=3D"middle" style=3D"width: 65.0px; margin: 0.0px 1.0px 0.0px = 1.0px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 4.0px = 0.0px 4.0px">
10
Cullen Jennings
Outbound
45
If time permits = ...
Marc Petit-Hugueinin
Fragmentation
Discussion Lead
Topic
Reading = List
Est. = Time
Francois Audet
SIPS: Guidelines
30
15
Jae Woo Lee
Henning Schulzrinne
SIP URI Service Discovery using = DNS-SD
15
Mayumi Munakata
Clarification of = Privacy
Outbound
45
If time permits = ...
Marc Petit-Hugueinin
Fragmentation
draft-munakata-sip-privacy-clarified-00
15
Thomas Froment
Record route = management





= --Apple-Mail-1--515794571-- --===============1282566915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1282566915==-- From sip-bounces@ietf.org Tue Mar 06 15:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgE0-0000Y8-KO; Tue, 06 Mar 2007 15:25:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgDx-0000Y2-1Q for sip@ietf.org; Tue, 06 Mar 2007 15:25:29 -0500 Received: from web31506.mail.mud.yahoo.com ([68.142.198.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOgDv-0006em-M0px 0.0px 1.0px; border-style: solid; border-width: 1.0px 1.0px 1.0px = 1.0px; border-color: #808080 #808080 #808080 #808080; padding: 0.0px = 4.0px 0.0px 4.0px">
15
Jae Woo Lee
Henning Schulzrinne
SIP URI Service Discovery using = DNS-SD
15
Mayumi Munakata
Clarification of = Privacy
To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <84913.73993.qm@web31506.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Consider UA-1 initiating an INVITE without SDP offer (with 100Rel in the supported header). UA-1 expects the remote end UA-2 to support 100Rel but also at the same time doesn't want to offend endpoints which donot support the same. Now, if UA-2 did not support 100Rel and sends 180-Ringing without offer/ RSeq header. Can UA-1 at this point decide to initiate an offer in an UPDATE - I didn't find any text in RFC 3261/ 3311 which specifically restricts this behavior? In essence, can an UPDATE be sent with SDP-offer if the initial INVITE didnot contain an offer, but at the same time the callee didnot send an offer in either reliable provisional response or UPDATE or PRACK? This seemingly is some sort of "late offer initiation". Although it seems the RFC doesnot specifically restrict this behavior, it should be disallowed to prevent any collision between the offer in UPDATE from UA-1 and 200-OK/ UPDATE from UA-2. thanks, Kapil Nayar ___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip -cla= rified-00.txt">draft-munakata-sip-privacy-clarified-00
15
Thomas Froment
Record route = management





= --Apple-Mail-1--515794571-- --===============1282566915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1282566915==-- From sip-bounces@ietf.org Tue Mar 06 15:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgE0-0000Y8-KO; Tue, 06 Mar 2007 15:25:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgDx-0000Y2-1Q for sip@ietf.org; Tue, 06 Mar 2007 15:25:29 -0500 Received: from web31506.mail.mud.yahoo.com ([68.142.198.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOgDv-0006em-Mz for sip@ietf.org; Tue, 06 Mar 2007 15:25:29 -0500 Received: (qmail 74368 invoked by uid 60001); 6 Mar 2007 20:25:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=gXaauiHC4Veq6BI89V2QTegFnxs+Xn5J47e7ZYtTTov7+51srmS+2uSU8Hn9EbhydbS+tUZRp8sNGe923sW3DNhTwzFVAFMRfcvLRFInn05rNHWFfqMBdxE9xshUIT0BYcS1D5yIsAztwX6GtaIBxfiArArxLJtsOy5WIHZCFso=; X-YMail-OSG: 0_soLvQVM1kz5iDlcOL7FERIIH82hQ1ssJSTNfvzdQdMdme1T7D1jhNCXoJxTuV7GPQDSQebPSGgN3dD.INKj55Y3fYHht4Hmdf6qJizYA9Yq5eV4Tp1sN2pnl2eZ5iqD9m_DbM6svJVGyjOJ5p3JaslIg-- Received: from [198.152.12.67] by web31506.mail.mud.yahoo.com via HTTP; Tue, 06 Mar 2007 20:25:26 GMT Date: Tue, 6 Mar 2007 20:25:26 +0000 (GMT) From: Kapil Nayar To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <84913.73993.qm@web31506.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Consider UA-1 initiating an INVITE without SDP offer (with 100Rel in the supported header). UA-1 expects the remote end UA-2 to support 100Rel but also at the same time doesn't want to offend endpoints which donot support the same. Now, if UA-2 did not support 100Rel and sends 180-Ringing without offer/ RSeq header. Can UA-1 at this point decide to initiate an offer in an UPDATE - I didn't find any text in RFC 3261/ 3311 which specifically restricts this behavior? In essence, can an UPDATE be sent with SDP-offer if the initial INVITE didnot contain an offer, but at the same time the callee didnot send an offer in either reliable provisional response or UPDATE or PRACK? This seemingly is some sort of "late offer initiation". Although it seems the RFC doesnot specifically restrict this behavior, it should be disallowed to prevent any collision between the offer in UPDATE from UA-1 and 200-OK/ UPDATE from UA-2. thanks, Kapil Nayar ___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 06 15:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgbr-0002oq-83; Tue, 06 Mar 2007 15:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgbj-0002gu-Qr; Tue, 06 Mar 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOgbi-0002ou-Ec; Tue, 06 Mar 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 658E832A4C; Tue, 6 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbi-00064E-8n; Tue, 06 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-08.txt Pages : 43 Date : 2007-3-6 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-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-outbound-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: <2007-3-6114612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-6114612.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Mar 06 15:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgdV-0007Id-G8; Tue, 06 Mar 2007 15:51:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgcB-0003ph-2O for sip@ietf.org; Tue, 06 Mar 2007 15:50:31 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOgc9-0002wp-8E for sip@ietf.org; Tue, 06 Mar 2007 15:50:31 -0500 Received: from [64.101.172.122] ([64.101.172.122]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l26JuLPg009653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 6 Mar 2007 13:56:22 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) To: SIP IETF Message-Id: <1CCAC734-FB4D-42D6-938E-B9E375564DB7@softarmor.com> From: Dean Willis Date: Tue, 6 Mar 2007 14:50:25 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 Subject: [Sip] Yet another SIP agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1273364377==" Errors-To: sip-bounces@ietf.org --===============1273364377== Content-Type: multipart/alternative; boundary=Apple-Mail-2--513986836 --Apple-Mail-2--513986836 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Yet another revision, as I missed adding the very interesting Early media draft last time. We will probably have a major revision later this week, as I've been advised that the PKIX conflict on Tuesday is not a major issue. Draft Agenda, SIP at IETF 68 Session 1: Tuesday March 20, 2007 1740-1840 Grand Ballroom Note: conflicts with pkix, try and avoid security discussions Discussion Lead Topic Reading List Est. Time Chairs Agenda bash, status, announcements This document 5 Jonathan Rosenberg ICE Option Tag draft-ietf-sip-ice-option-tag-01 15 Jonathan Rosenberg GRUU changes draft-ietf-sip-gruu-12 20 Robert Sparks Process for Revising 3261 Mechanism for Publication Prioritization of Issues Which current drafts are bugfixes? 20 Session 2: Wednesday, March 21, 2007 1300-1500 Congress II Discussion Lead Topic Reading List Est. Time Francois Audet SIPS: Guidelines draft-ietf-sip-sips-02 30 Cullen Jennings Outbound draft-ietf-sip-outbound-07 45 If time permits ... Marc Petit-Hugueinin Fragmentation draft-petithuguenin-sip-outbound-fragmentation-02 15 Jae Woo Lee Henning Schulzrinne SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-00 15 Mayumi Munakata Clarification of Privacy draft-munakata-sip-privacy-clarified-00 15 Thomas Froment Record route management draft-froment-sip-record-route-fix-00 10 Richard Barnes Early Media draft-barnes-sip-em-ps-req-sol-01 15 --Apple-Mail-2--513986836 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Yet another revision, as I = missed adding the very interesting Early media draft last = time.=A0

We = will probably have a major revision later this week, as I've been = advised that the PKIX conflict on Tuesday is not a major = issue.



Draft Agenda, SIP at IETF 68


Session 1: = Tuesday March 20, 2007 1740-1840 Grand Ballroom

Note: conflicts = with pkix, try and avoid security discussions

Discussion = Lead
Topic
Reading = List
Est. = Time
Chairs
Agenda bash, status, announcements
This document
5
Jonathan = Rosenberg
ICE Option Tag
15
Jonathan = Rosenberg
GRUU changes
20
Robert Sparks
Process for Revising = 3261
Mechanism for = Publication=A0
Prioritization of = Issues=A0
Which current = drafts are bugfixes?

=A0

20

Session 2: Wednesday, March 21, 2007 1300-1500 Congress = II

<= TD valign=3D"middle" style=3D"width: 65.0px; margin: 0.0px 1.0px 0.0px = 1.0px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 4.0px = 0.0px 4.0px">
10
Discussion Lead
Topic
Reading = List
Est. = Time
Francois Audet
SIPS: Guidelines
30
Cullen Jennings
Outbound
45
If time permits = ...
Marc Petit-Hugueinin
Fragmentation
15
Jae Woo Lee
Henning Schulzrinne
SIP URI Service Discovery using = DNS-SD
15
Mayumi Munakata
Clarification of = Privacy
15
Thomas Froment
Record route = management
Richard Barnes
Early Media
15

= --Apple-Mail-2--513986836-- --===============1273364377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1273364377==-- From sip-bounces@ietf.org Tue Mar 06 15:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOggr-0003Py-K5; Tue, 06 Mar 2007 15:55:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgch-0005Wm-TS; Tue, 06 Mar 2007 15:51:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOgch-0000Xv-1P; Tue, 06 Mar 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8C0122ACCD; Tue, 6 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbj-00066K-86; Tue, 06 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-certs-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Certificate Management Service for The Session Initiation Protocol (SIP) Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-certs-03.txt Pages : 30 Date : 2007-3-6 This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-certs-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-certs-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: <2007-3-6132722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-certs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-certs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-6132722.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From Carpet@outta-sites.com Wed Mar 07 00:10:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOoQR-0006B1-9D for sip-archive@lists.ietf.org; Wed, 07 Mar 2007 00:10:55 -0500 Received: from [70.142.200.210] (helo=[70.142.200.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOoQP-0003pQ-BK for sip-archive@lists.ietf.org; Wed, 07 Mar 2007 00:10:55 -0500 Message-ID: <001101c76077$25d9bd70$00000000@LamonteOffice1> From: "NWOT LOWRISE" To: sip-archive@lists.ietf.org Subject: vanes lou General Date: Tue, 6 Mar 2007 23:12:05 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C76044.DB3F4D70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 ------=_NextPart_000_000D_01C76044.DB3F4D70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C76044.DB3F4D70" ------=_NextPart_001_000E_01C76044.DB3F4D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Huge pinups billie piper toes press? Browse diversive variety background. Truss reverse headstock, pouch. Vouyer muscle, wwwhorny, trini. Tabitha = dear maggie, evening, meaning while, range router luck. Sandpiper offered noahs bull puppyin parthi pert pithie. Organizer, spf exofficio retired pt spoke physical therapy. Fzj shocks = slee castor plates ome stabilizer, lowered yeshanghai. Walls httppics = heather seances minnilo shows breast singer, billy. Introduced cat, mine = rarely brackish, salinity. Charge scope dedicated, server uo tools, = windowstm freeware? Japanesse naked, orgasoms foto. Ps aruze develops rpg. Lightening rod = type exhibitor. Experience buttross, jewelers repair! Elderly publisher kejal vyas journalism wearhouse mythical! Illegal lolita pantie bueaty, gorditos weird lesbian fetish chrono. Island nydate birth zodiac december. Wanna remix itmore filed, keysboyz menbritney spearsall careytake = thattop. Woman horrifying dressquot zipper throughout kan planera. Toddlers, babies www spears church christina aguilera ciara, eminem! = Charge scope dedicated server uo! Bull puppyin parthi pert pithie! Ip, = rancho cucamunga company. Sansa helpvisit musicburn cdrhapsody content reg muze listencom. Wearhouse mythical items, decor quotshabby decorquot mirrors clocks. Kidman twins pamela pink salma hayek sandra bullock michelle. Period = inch game fm radiio signal horizontal. Ode france xmoto un. Bentley bmw, = buick used ashwariya rai nipple missedgtgt. Hand thumb motorcycle, atvs. Formerly sang minstrels, qkenny rogers athe word. Protesting, fact = codecs tvuplayer, anything. Shawn er cole program. Aura rundle siobhan polymer drunks happening. Zero nite, clubbing nokia ear meca messenger jour arrive? Vinegar these = carrot, harry, blend sour welome lawrence wheeler! Tommys famous chili = beef. Thats consuming, metal appointing tiger revive creating. Walking limited nothing quotive! Weeks starts novel tees sequin masks. Lifehaha powershot camera optical zoom stabilized, warezlogin ambient. Designs crossed flags coil. Pcs darlene zsech promo world worship. Vb img myspacecom, edgewater diplo female wkto watts. Jacob cjd cow = stereo jacobs tongs outlet aeso portable. ------=_NextPart_001_000E_01C76044.DB3F4D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""=20
Huge pinups billie piper toes = press?
Browse diversive variety = background.
Truss reverse headstock, pouch. Vouyer = muscle,=20 wwwhorny, trini. Tabitha dear maggie, evening, meaning while, range = router luck.
Sandpiper offered noahs bull puppyin = parthi pert pithie.
Organizer, spf exofficio retired pt = spoke physical=20 therapy. Fzj shocks slee castor plates ome stabilizer, lowered = yeshanghai. Walls=20 httppics heather seances minnilo shows breast singer, billy. Introduced = cat,=20 mine rarely brackish, salinity. Charge scope dedicated, server uo tools, = windowstm freeware?
Japanesse naked, orgasoms foto. Ps = aruze develops=20 rpg. Lightening rod type exhibitor.
Experience buttross, jewelers = repair!
Elderly publisher kejal vyas journalism = wearhouse mythical!
Illegal lolita pantie bueaty, gorditos = weird=20 lesbian fetish chrono.
Island nydate birth zodiac = december.
Wanna remix itmore filed, keysboyz = menbritney=20 spearsall careytake thattop. Woman horrifying dressquot zipper = throughout kan planera.
Toddlers, babies www spears church = christina=20 aguilera ciara, eminem! Charge scope dedicated server uo! Bull puppyin = parthi=20 pert pithie! Ip, rancho cucamunga company.
Sansa helpvisit musicburn cdrhapsody = content reg=20 muze listencom.
Wearhouse mythical items, decor = quotshabby=20 decorquot mirrors clocks.
Kidman twins pamela pink salma hayek = sandra bullock=20 michelle. Period inch game fm radiio signal horizontal. Ode france xmoto = un.=20 Bentley bmw, buick used ashwariya rai nipple missedgtgt.
Hand thumb motorcycle, = atvs.
Formerly sang minstrels, qkenny rogers = athe word.=20 Protesting, fact codecs tvuplayer, anything. Shawn er cole = program.
Aura rundle siobhan polymer drunks = happening.
Zero nite, clubbing nokia ear meca = messenger jour=20 arrive? Vinegar these carrot, harry, blend sour welome lawrence wheeler! = Tommys=20 famous chili beef. Thats consuming, metal appointing tiger revive = creating.
Walking limited nothing = quotive!
Weeks starts novel tees sequin = masks.
Lifehaha powershot camera optical zoom = stabilized,=20 warezlogin ambient.
Designs crossed flags = coil.
Pcs darlene zsech promo world = worship.
Vb img myspacecom, edgewater diplo = female wkto=20 watts. Jacob cjd cow stereo jacobs tongs outlet aeso=20 portable.
------=_NextPart_001_000E_01C76044.DB3F4D70-- ------=_NextPart_000_000D_01C76044.DB3F4D70 Content-Type: image/gif; name="pics.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c76077$25d9bd70$00000000@LamonteOffice1> R0lGODlhiAHEAYecAAAAAIkJCAB7AHd0CwIFfI0FhAB1fsvDtLXlyKfP40obAF0cCo4WAKwkAMso AOsaCABJASVKAjJHAGFKAIY/AKY9ALtNCtg3DABlARhTBz1gAFluAopZBp1gAMxUAO1iBQCICRqN AEWKAFp1AIV3BZN/AMqNAOiKDACpAByUAEqVAGqTAIqbCpmnAMmfA+iRDQCxABPIC03OAGHCAH7A AKDCArXLAOG2AwPVChrWATntBGTVAHrhAJrTALrXBdnpBQAAQSAASEMAP2AFSXMANJ8ANrcJROYA QQAeNx0jPjwsTF4iPYUpPqMgPc0nQ+sUOgo1NS5DP0o4Pmk4NIA6RpE0MrJIOeE7TgZfOSRiP0dk RltbMnJRBJFWQ75cNeVgNwN5QBOCSz2DR1eEQ3l9PZiITMt8S+GLOACRTS6qMzuVM2aUTXepM6eW Tc2jQOSaNwC7QB3OPEu/NG61Pn+9RK3BN8S4R+C4QgDpPBfjRkPVOlzjS3frSZTZPL7sOtznNwAA gREMczYAimgAhn4He5UJd7UGgOAAfgsqfxoZc0wtiGQsgnwqfqcshswUfd4fhQI4iC5JikVJimlO eYY6d6VMjb06idM1dw5YcRNbdUhmiVppcnNfdqBrg8pSgNtmeQV2fy2Nd0WCemh2coSFjaWOf7V8 eNWHhQCccySTdTmXfWmSen6mi6iShbuVeOCkfQe3fCa7gUPCgVPLiXu1hpjIhsjAddbMiADRfRXh hDnZdVjmjnrjf5nef8Hth97mhwEAzSkGuDwAyGcBwoEFupEAxs4At9gAygcWwBUYxUoezF0fxY0j upopxrEkxektyg4xxRIyv0U6smQ8uHkywqE3wM1JxNQxvgBeuBpsyDxfxmtuxopcuaVhtstnyttZ xQCDwBODwjp+yl2HtYeMxZKDvsNxxdR7ywCpyiyfzjWtw1WTwoORu66eyrigttWntAC0zizEzD/I tWC7xHXLvK7KzvL98Z6kp3+LgfwHDgD/AP/1AggA//cF8AD/+////yH5BABitk0ALAAAAACIAcQB Bwj/ADkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOGV/BwmRshv8eHHJR1zknzS cWLKCS8bxKx4IOfNjSEblvx5JOXSBT+jVrg6s2jCpAU2XmxZdujUtzVPvr37cmjds0H/tu1b9+Te ln8P70389OvBs4MTNE59uufdsq/Hzl79Ovfj3sEf/6+9fbz28K2f390e/Tty0u2TBy+vOTr98bWz uzePXnz39OrZFVt+wDGWWnj6JVifgfst59+D95HnHYAB0jVgfwpa1+B5/XWX4YUfchjihhVCp2F7 CTKHG23T8SbdcLTx5tl8KsLnYIwxgvfihCX26OOPQAYp5JBEFmnkkT9R+JCSnSF5pJJMNhQlQ+lN 6aReUHpkJWtSXvncaS7mliKKKvKIX5gs4iicfi+66OVrEZ7nHIlsbkgei2PKqaGOb4oWJ3eYSZjn gnfS2JyNMMonZp+P/WnenPyJ92ikxmV4EKQOIsgobHtWh+eIkj4IoYj5gUrppn62KZ+lokrXqaU7 zv8YqJiu1orqrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimq+667Lbr7rvwxivvvAYBUJO99KYFwL724guSvw/16xDA+U5FMMEdIcyQ wgkxXHBTCPPrL78DUcyJxBXvm3G/GhNkMcYXhwzyxR2H/LDB9VZs8soCCdzyyi6/XNDEMItcM80s n/xUxCpLjC/GNPtMssoz92x0zBx/rLNUPL98sNFOH6Rx0zZHjXTOWC/N1NNRd1311wDHTDTYNgc9 ttZMU4yzxSRPzfbHJZfccsdmX9322WiT5XDeP+7/zfffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eacd+7556CHLvropJdu+umopx5RPxj1w/pEr2fkt0azP+6665zEThDruht0e+8C xQ7878DnvlHtGE088txwI59v8b4vBP1AwiM0/fQSOV8R0A3Z/ffwweNu/Ou37+67+OWXX5Du6v9O vfgbx0+00iYfHLfcUGdddM2Ag28+78Y7SPuoF8ACrk+ABQSgQsSWP5f9DCEMLJry8Ocx+fUverlL 3/iwp8DxERCB78Nd9eDnMbXxrG5fYx7HFkhBheFMfzoD3wgTCL0O2tB6H/Rg8N5XQZkNrYFlY9kL /ymYPx/2kH8X/B8BO2hAJe6weiBMoBRziEQh8u+FPgxbw8hWRSx+T4MZFOEGe+e+8JFvd/4zI+/a R0IV3q2Hb8Nb25IGwbfFDW9sU11VtKdHr/Cxj4AMpM70oY+SFLIkfzzcITlRyEVehJCEZIgjHzJJ h1TyXymrF92Wl7dFXrIinlzIJz8ySo6MrIV4DFwoDwnJgUCykYwUSCsJsspYMjKSt2QlLnMpy0jq 8peexGUpaWdFqmlRcLC0pSuV2chKOnKVrFxmKGWpzGomM5bTlCZJ7GbMIwIumcBkpjVn2UthLpOa wWzlLtcpzmm+spohaR7+hkg4cLZTm9TMpz71Wf/LfboymNjEZ0DRaRKxddOIqhToNRd6Tn9mk6H7 fOZAJ8rQQ9Izi2PzoteuOD/DuXOW73wmOeEp0mj+85flzCdIzxlSjLoUiV7k5BDvWLlhiiWRNd3l WnAqyJ76NF1tfAj2YsJTws1QI2U84A7Xl1Tz6YRq+zscFJEqPSo6NYo3OaULizqvo6ovjAAkXxuH hz4RBpV9ZYXfV1tiUP1xtasBJKMUz8rUMz7RqnjVoV5hwk0IKk6BYhXjXUNYw7nm1YDuG+FQUSJP F/41roYd7BSjd9Qm5rCywltsQa0otcVhNrKTPeBnozjapV4UphlNLUI3isW3wnWpZUwsGkmY1AH/ 8lCpagSrGVWL2pee1n7zzCgRJ6dZsLjWdkFFy3F/ytzm7sqmettcSw1yzZ1ujIibzCPfoAvdm6pt gX79JnVTOtCRjsV7mUzv35xZEFhW1yxI0+4co7re8ebSvbdUi3y5VsX6tveeAFVuzvir0e3+t5YS PeJvebtg3zL4wQ5ebRBl9kAKe1Sd5cSveXvL4QZ3GMIfjvB1LThBOTo3Kcs9MVJSrOIWuzhzLO7f WmGXkMpCrIQR42ThinuRqTqFewiN8buKx0a1ok+Ha/WqkcUY2JxEcMCNS+MNFStZ0S51iUtM470G nOPhCq7JxJurbKvsxMBOebY8Vsl+t4g49jXR/8agtbJez3zlNKsZyuFtM5YlS+e94rbPNzQtiD1M 6M72tb+Gi+2RYbvouNKV0WllYhkLLWJKj5h5whUy6ew8E037dMZA8fSLR01qx4l6kBumC39ndr9T g6u7bwEZdoGY0PYK05fpLAsD/Ybe9ZqToLacJKz3iGepldij9wx2hnUtN14jWrz9jGY2z/vsCha4 vtEGti0tze1Be7vSJkZvhbn4TXKuVNn3Bbe6Q8zubr/UjZjOYqtLXRRX0zur9863voVFZKZxLswc 6XdUwjbcCXo5b5xuiMB39t3VznrHey5yBkNI2N1aVilPdix9B5dZysJWznO+OIqxxjCocpyKY/+2 65hDnnCf5NFhqzbqZSPOZ9Ay8cf1A683ZV5nmrN8zzp0d7u/zW5rk9yb9iaXj1MOaTNb/HVCjzrR Y9pYeV9730/FulWSrvWue31dXKfXsN+r642XPLsHn9ew/ak3uJWws0HupK1NGlAMo5Qru974u8Nu rQRTlKLs3Ured753A5/UnNJuaLrx3my9wxuGBfM7PiEqzq702tkSPpnfH1r5ykt93Z8vOq3PRuBy 33rzvRwnLkPP+qnz9vF2nCnhv05U2g/c9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/ +dCPvvSnT/3qW//62A8Q35PnZJ3puHsNl+D/wIq42YAdJB/oz8dA0q9+gaCfIO0HL4uPKa2r51nn bH43YyGCsPhzQv3+B4DuN4AL8xH0Fy1m4zUHSGF0Uz+Nl1o/02oCE4FdBnvaJWvZlRACuH7/R4D+ p0lTE2/Ng1EYOG4ISD/kdnRGl3HiB2VBY3JA1FoxuBAbOIDtV4NwN2FGlIBks4DPwoMPFHMOGIIr pEJKU2FAlkIyFX7i1jNJeH4E6IE36H4feDM/xFk9WETbRyRAuFFHh0Jzs3MOZIUKSHozuIPkxzDv F4UdWBAb+IFA2FZlyIOQpyxdKGFPA4ZoGFVXc4dY2IdmOIdQCH+EWIhTqGDFhIhduIVIolU0/wWC DvRddER4ayNPQnSBTPh48GZHhdiJbciBbViF3BN78TZflZh52cKI3XMSyMN+a8h+bgh/Vbg4qtgw aUc7t5h9uriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2OgXriaE C4E8RVWLqDgup1VHITh7IHZ/5DZ4Bag99mdvxwWOJTKO6lWHfGhiYshh5jiPqxiO7khM0HJRF8hq DShTqnWEQ+g9kZiBAjmBQxg/kkh6ClmQDWg1OHZsJkRi9TdhVDduDBl3HfmCZRhEQTh6VjiRSkiS 47iITliPCTiSFoaAGvl9WRhTGnmGOfeRN/+zPHooNPTnkudYNSrJklAThLKWkTjZjSWZSkeZhRaG k3SoiP3Vk14oj2MoiELZNT5pj8viYS2ogwdFhukIgSh5NGL5k/joYE8JllXZazC5g/OEghMoX11k khTYYCUIiUo4b0NTYBGJdBKogg2Zc4FJj+YCj2y1PaVjmCzBU4qZjY75mIfZLI9obLlImPlHfiOh cZYZjkh5POYnme2olfloEfC4fYzYmJCxlsE1P/M2gieJlURYcAb5Rm/0kElDgYFJkLQ5XyLYeLjp Rij0m7zJLGMogzaJWqupgymUXkVIhwRnlUyZiMwJlhlDgjNIl9VmLCNpnNCJnIbmNGkJlUb/eIVS GZQpWITiuZwwk4SAaHBsiSzbGYjdSU+OxZEdmWfvWY7WCZ1NGIZlqZ40KYgBupm/ojxd1FGs9Z/1 SJapFJLSuZ/R2Z97GJ0PppL0KZrEYqC7OZy06Xa1iZ8f+kPAZYKueTcveD+5aYYByYAa6pYGB5yX +KKUw43cRxSoeTIwKDv1Bpk82qM++qNAGqRCOqREWqRGeqRImqRKuqRM2qRO+qRQGqVSOqVUWqVW untcdXBPFhE3KhjyyIoUYSOyMiOaMp5cWpnKOX5I+Vaz06Wq9nr7JxFuYid1go5qapn2Z6cpw6YF uCsA2UKZ+KG/eZcdSkSl4in7kYO1uaK0/2aQgSo/mJiVRSmc7IlpJdonDMmR6ZmHJzR6bHmorfIp OeiHLqiUYamge/qHImqTckigQ5KpZgqhdRmjgDieQnMgoDInMlKh8hmSo/igEFqRrxmW5rmeuAKr bsWq3umg4QiqpeIemHGhE8qfyqmOEaSHaqmsC4imQsKV5omQ2cqsrOIhfBIqy1psmhqcepeW2OqH tTqsGGokrQWoaAejI3aKhYowtYImuIod6mWJICispuiA4WaSwmpQKJivs7qoGwqfeNenpBlP8SKX Wwd+EYtJV5qxGruxHNuxHvuxIBuyIjuyJFuyJnuyKJuyKruyLNuyLvuyMBuzMjuzNLseKP+yq83R Im2CG6DRs/YRH/axIj+7b2Hirz1LprZhtK7SIj6rGquStF+3q77BGMlxILmBs1DLtFhrtEq7JT+1 tWCbI5dSHJkxK1zLtEh7tkTrtFSbtUKLGjirHG2btlt7b2E7t2Fbt4cStD87H1UrK0Nrt2w7tm6r s3obt1M7tmRSuGs7t0d7t0vLszx7t2ert6VGuY87uJGbtmSKuTJiuZfrHJ4ruk8ruVo7uGUCuqS2 r2qbtaz7uYjbtI5bI17bXEH7HlcLuzurs6bbuX2buGP6u7Vbs8RbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veAmG77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e78bERAAOw== ------=_NextPart_000_000D_01C76044.DB3F4D70-- From sip-bounces@ietf.org Wed Mar 07 04:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs3j-0003ry-HI; Wed, 07 Mar 2007 04:03:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOj49-00068m-9N for sip@ietf.org; Tue, 06 Mar 2007 18:27:33 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOj47-0005F8-Qr for sip@ietf.org; Tue, 06 Mar 2007 18:27:33 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Mar 2007 18:27:32 -0500 X-IronPort-AV: i="4.14,255,1170651600"; d="scan'208"; a="115118996:sNHT50197110" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l26NRV14005018; Tue, 6 Mar 2007 18:27:31 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l26NRRZT015107; Tue, 6 Mar 2007 23:27:31 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 18:27:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Date: Tue, 6 Mar 2007 18:27:22 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E02DE0AC2@xmb-rtp-215.amer.cisco.com> In-Reply-To: <84913.73993.qm@web31506.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) thread-index: AcdgLf2vq2w5YKirSwSFFkupn0WWgAAGB+8A From: "Sanjay Sinha \(sanjsinh\)" To: "Kapil Nayar" , X-OriginalArrivalTime: 06 Mar 2007 23:27:31.0033 (UTC) FILETIME=[02DCFC90:01C76047] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2016; t=1173223651; x=1174087651; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:=20RE=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20=22Kapil=20Nayar=22=20,=20; bh=BtLqcxfMsBNJ7ABsqbiGzyVdOrvfJGcOpeUBnaAPOnM=; b=E64N7QVmBI6a3sTDAZc5e5VlmnyB+f6VDl3jZ3myv1+ZWAOkJFjPlC/vB/IpgE5fwmN+lgCI p8WaBO3M18EzY2BRwrdMn9CxC8phmNSIyjKukDIfu2skDMqdJctnqvsa; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Table 1 in draft-ietf-sipping-sip-offeranswer-00.txt mentions that UPDATE can not be used to send initial offer. >-----Original Message----- >From: Kapil Nayar [mailto:kapilnayar@yahoo.com]=20 >Sent: Tuesday, March 06, 2007 8:25 PM >To: sip@ietf.org >Subject: [Sip] Can a UA initiate a late offer (in UPDATE=20 >instead of INVITE) > >Consider UA-1 initiating an INVITE without SDP offer (with=20 >100Rel in the supported header). UA-1 expects the remote end=20 >UA-2 to support 100Rel but also at the same time doesn't want=20 >to offend endpoints which donot support the same. Now, if UA-2=20 >did not support 100Rel and sends 180-Ringing without offer/=20 >RSeq header.=20 > >Can UA-1 at this point decide to initiate an offer in an=20 >UPDATE - I didn't find any text in RFC 3261/ 3311 which=20 >specifically restricts this behavior? In essence, can an=20 >UPDATE be sent with SDP-offer if the initial INVITE didnot=20 >contain an offer, but at the same time the callee didnot send=20 >an offer in either reliable provisional response or UPDATE or=20 >PRACK? This seemingly is some sort of "late offer initiation". > >Although it seems the RFC doesnot specifically restrict this=20 >behavior, it should be disallowed to prevent any collision=20 >between the offer in UPDATE from >UA-1 and 200-OK/ UPDATE from UA-2. > >thanks, > >Kapil Nayar > > > >=09 >=09 > =09 >___________________________________________________________ >New Yahoo! Mail is the ultimate force in competitive emailing.=20 >Find out more at the Yahoo! Mail Championships. Plus: play=20 >games and win prizes.=20 >http://uk.rd.yahoo.com/evt=3D44106/*http://mail.yahoo.net/uk=20 > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 07 04:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs66-0000gK-Ro; Wed, 07 Mar 2007 04:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOj0c-0005aj-DI for sip@ietf.org; Tue, 06 Mar 2007 18:23:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOgwf-0007xo-Dw for sip@ietf.org; Tue, 06 Mar 2007 16:12:06 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Mar 2007 16:11:42 -0500 X-IronPort-AV: i="4.14,255,1170651600"; d="scan'208"; a="54231510:sNHT46604640" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l26LBf7H016637; Tue, 6 Mar 2007 16:11:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l26LBeZX014682; Tue, 6 Mar 2007 21:11:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 16:11:18 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 16:11:18 -0500 Message-ID: <45EDD8F6.5010105@cisco.com> Date: Tue, 06 Mar 2007 16:11:18 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <84913.73993.qm@web31506.mail.mud.yahoo.com> In-Reply-To: <84913.73993.qm@web31506.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2007 21:11:18.0359 (UTC) FILETIME=[FB91E670:01C76033] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2131; t=1173215501; x=1174079501; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20Kapil=20Nayar=20; bh=PVkT2UNaeUyzpccqymjwcyjBsmpidlHgI0lt65zoHYQ=; b=XkRhkOwiMI0JUNT8RQpuSrppgBxU9WMsj+khQ2YHl3f8LWXBIIPla8C3l/NMLl7RvU1fORJi wr1yJSnN1YS2Va/MGRRhNsgUibzdao2DXATMAL+AqJtRoYdoSbhH8qTM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Kapil Nayar wrote: > Consider UA-1 initiating an INVITE without SDP offer > (with 100Rel in the supported header). UA-1 expects > the remote end UA-2 to support 100Rel but also at the > same time doesn't want to offend endpoints which donot > support the same. Now, if UA-2 did not support 100Rel > and sends 180-Ringing without offer/ RSeq header. > > Can UA-1 at this point decide to initiate an offer in > an UPDATE - I didn't find any text in RFC 3261/ 3311 > which specifically restricts this behavior? In No. This would totally screw things up by changing who is expected to make the offer. UA-2 has already understood that it is supposed to do so, and may well have on in transit. The manner in which the offer/answer protocol can be mapped onto sip messages when taking all of the relevant RFCs into account is very poorly and incompletely specified. There is work underway to clarify this. See draft-ietf-sipping-sip-offeranswer-00. Paul > essence, can an UPDATE be sent with SDP-offer if the > initial INVITE didnot contain an offer, but at the > same time the callee didnot send an offer in either > reliable provisional response or UPDATE or PRACK? This > seemingly is some sort of "late offer initiation". > > Although it seems the RFC doesnot specifically > restrict this behavior, it should be disallowed to > prevent any collision between the offer in UPDATE from > UA-1 and 200-OK/ UPDATE from UA-2. > > thanks, > > Kapil Nayar > > > > > > > ___________________________________________________________ > New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. > http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 07 04:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsAw-0001WG-Q1; Wed, 07 Mar 2007 04:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOp5l-0004Bu-Tt for sip@ietf.org; Wed, 07 Mar 2007 00:53:37 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOp5k-0001nf-Lk for sip@ietf.org; Wed, 07 Mar 2007 00:53:37 -0500 Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l274xQmT011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2007 22:59:27 -0600 Message-ID: <45EE5374.3040903@softarmor.com> Date: Tue, 06 Mar 2007 23:53:56 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-certs-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Internet-Drafts@ietf.org wrote: > 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 : Certificate Management Service for The Session Initiation Protocol (SIP) > Author(s) : C. Jennings, et al. > Filename : draft-ietf-sip-certs-03.txt > Pages : 30 > Date : 2007-3-6 I believe this draft is pretty much ready to go. I'm still asking the authors some stupid questions about various downrefs (normative refs to informational-track documents), but I expect they'll get it explained and I'll be requesting publication shortly. so no, it's not planned to be on the agenda in Prague. If you think this is entirely wong, please let us know now. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 07 04:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsCa-0004q0-Oa; Wed, 07 Mar 2007 04:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOrBV-0004Md-Jz for sip@ietf.org; Wed, 07 Mar 2007 03:07:41 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOrBU-00012O-4Q for sip@ietf.org; Wed, 07 Mar 2007 03:07:41 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2787GfR024509; Wed, 7 Mar 2007 10:07:31 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 10:07:14 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 10:07:14 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 10:07:14 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27878MU030829; Wed, 7 Mar 2007 10:07:08 +0200 Received: from [172.21.43.170] (esdhcp043170.research.nokia.com [172.21.43.170]) by kusti.research.nokia.com (Postfix) with ESMTP id E6E4093B77; Wed, 7 Mar 2007 10:07:07 +0200 (EET) Message-ID: <45EE7189.4000201@nokia.com> Date: Wed, 07 Mar 2007 10:02:17 +0200 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" References: <45EC89B7.5070501@cisco.com> In-Reply-To: <45EC89B7.5070501@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2007 08:07:14.0334 (UTC) FILETIME=[9D8F1BE0:01C7608F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: fluffy@cisco.com, sip@ietf.org, OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG, "Drage, Keith \(Keith\)" , OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, dean.willis@softarmor.com, Antti Laurila X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Jonathan Rosenberg wrote: > My main question here is what are the use cases for subscribing to an > individual element, rather than the whole document? It would need to > be a case where a user cares about changes in one of their documents, > but not over certain parts of that document. For the cases of > resource-lists and rls-services, it was far from clear when that would > be desired. Wouldn't a user care about their entire buddy list and not > just some of it? Good point. I had a similar first impression as well. What made me eventually change my mind was the fact that we indeed have a similar feature in XCAP, i.e. a partial GET of components (and this is a similar feature using sip). For sure, in my reference XCAP implementation (general server/client for resource-lists+services AU) I had zero use for the partial retrievals of XML nodes of a document. But this is not to say that someone may still find it useful. Adding this sort of feature afterwards is definitely imo much more awkward. And as I see it, OMA wants to avoid in some cases an additional http retrieval, so it is an optimization case and as well may make the client implementation simpler. And speaking about the actual implementation, adding this feature to the server is pretty much trivial if you manage to get the XCAP baseline done and all this patching stuff, i.e. it doesn't cause much PITA. Another option would be that RFC3427 would be relaxed for sip event packages, i.e. FIFO model for event package names, so that e.g. OMA folks could do their own stuff based on their spec. > > If OMA could provide some specific example use cases and point out > problems with draft-ietf-sip-xcap-config for those cases, it would be > helpful in providing concrete feedback. > > Thanks, > Jonathan R. > there are some other differences: resource selection logic, "possible endless loop" issue, patch or not to patch, parameter stuff, initial subscription sync etc. And after glancing at the last config-framework I am still inclined to think that XCAP isn't the best fit there. br, 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 sip-bounces@ietf.org Wed Mar 07 04:13:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsDF-0006Zj-RP; Wed, 07 Mar 2007 04:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOrkm-00024D-6c for sip@ietf.org; Wed, 07 Mar 2007 03:44:08 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOrkb-0000aY-Iy for sip@ietf.org; Wed, 07 Mar 2007 03:44:08 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CD8E21632; Wed, 7 Mar 2007 09:43:55 +0100 (CET) X-AuditID: c1b4fb3e-aeec5bb000003386-9f-45ee7b4be0f7 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0DEB321635; Wed, 7 Mar 2007 09:43:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 09:43:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Date: Wed, 7 Mar 2007 09:43:53 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702735B57@esealmw113.eemea.ericsson.se> In-Reply-To: <84913.73993.qm@web31506.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Thread-Index: AcdgLfv0LGoaEKYCQQC3I3hx0urJPQAZhxOA From: "Christer Holmberg \(JO/LMF\)" To: "Kapil Nayar" , X-OriginalArrivalTime: 07 Mar 2007 08:43:54.0598 (UTC) FILETIME=[BD04C060:01C76094] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think this is an interesting question, and should be added to the offer-answer draft. The question is valid even if the 18x is sent reliably without SDP (yes, I know it is currently written that the first reliable response MUST contain an SDP offer, but that is a restriction we are also looking at in the offer-answer draft). One problem is that you can end up with a race condition, if UA-1 sends an UPDATE/offer at the same time as UA-2 sends an offer in a reliable response (18x or 200). Since it is not possible to reject a reply it could become a little messy... So, my initial opinion would be: no, what you propose shall not be allowed, i.e. if the INVITE does not contain an offer the first offer MUST be sent by the remote party before the sender of the INVITE can send his first offer. Regards, Christer > -----Original Message----- > From: Kapil Nayar [mailto:kapilnayar@yahoo.com]=20 > Sent: 6. maaliskuuta 2007 22:25 > To: sip@ietf.org > Subject: [Sip] Can a UA initiate a late offer (in UPDATE=20 > instead of INVITE) >=20 > Consider UA-1 initiating an INVITE without SDP offer (with=20 > 100Rel in the supported header). UA-1 expects the remote end=20 > UA-2 to support 100Rel but also at the same time doesn't want=20 > to offend endpoints which donot support the same. Now, if=20 > UA-2 did not support 100Rel and sends 180-Ringing without=20 > offer/ RSeq header.=20 >=20 > Can UA-1 at this point decide to initiate an offer in an=20 > UPDATE - I didn't find any text in RFC 3261/ 3311 which=20 > specifically restricts this behavior? In essence, can an=20 > UPDATE be sent with SDP-offer if the initial INVITE didnot=20 > contain an offer, but at the same time the callee didnot send=20 > an offer in either reliable provisional response or UPDATE or=20 > PRACK? This seemingly is some sort of "late offer initiation". >=20 > Although it seems the RFC doesnot specifically restrict this=20 > behavior, it should be disallowed to prevent any collision=20 > between the offer in UPDATE from > UA-1 and 200-OK/ UPDATE from UA-2. >=20 > thanks, >=20 > Kapil Nayar >=20 >=20 >=20 > =09 > =09 > =09 > ___________________________________________________________ > New Yahoo! Mail is the ultimate force in competitive=20 > emailing. Find out more at the Yahoo! Mail Championships.=20 > Plus: play games and win prizes.=20 > http://uk.rd.yahoo.com/evt=3D44106/*http://mail.yahoo.net/uk=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From arlhanksy@bushidokarate.ca Wed Mar 07 04:32:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsVX-000453-Js; Wed, 07 Mar 2007 04:32:27 -0500 Received: from [60.220.143.77] (helo=bushidokarate.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOsVT-00005o-7W; Wed, 07 Mar 2007 04:32:27 -0500 Message-ID: <881246E4.737B90D8@bushidokarate.ca> Date: Wed, 07 Mar 2007 17:21:22 +0800 From: "Silvia" MIME-Version: 1.0 To: "Trenton Green" Cc: "Marquita Ramos" , "Shani" , "Ardath" , "Jewel" , "Clement Fox" , "Ofelia Fuller" , "Dolly" , "Raul Wilson" , "Jasper" , "Margene" Subject: Miss U Content-Type: multipart/related; boundary="------------200748658554463014527312" X-Spam-Score: 1.8 (+) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e --------------200748658554463014527312 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit



So sudden and music violent shelf sore look was the fit that the unfortu     strip "But blow fit of what serve are you accused?"  development rapidly scrub "Shall I complain of of him?" demanded the inspector."Of successfully company having conspired spoke to aid creep the emperor's return."    
"If exchange part it be perfectly so," replied the division magistrate, "rely upon    squeal "Speak, current monsieur," said gestic berry Villefort. Then, internall     crush "Well, when we bind quitted beset late Naples, Captain Leclere was     "Edmond sling rely copper Dants," need replied the magistrate, "I arrest      top Edmond waited till poor life opinion seemed extinct mad in the body"What! attempt For the shake little emperor's surprise return?--the emperor is n"Oh, no; bet it is useless. robust see Besides, forbidden he is almost madbid joyously "He abdicated young at Fontainebleau salt in 1814, and was se      "Me!" repeated Edmond, mother bit elegant metal slightly changing color, "a derly|repeat|rough|punishment%} worm "I am free, hop then, sir?" faithful cried Dants joyfully.  "Yes; train but lively doubt first give wheel me this letter."    
off "I scratch cannot careful inform knot you, but you will be duly acquain   "He is juggle support mistaken saved! he price is saved!" cried Dants in a paro"Since 1811.""So dream snore old-fashioned much the better cheer for him,--he will suffer less,observation Dants shuddered; without this ground man had orange been four years lon       
bread M. Morrel rain begin felt that further dirty resistance or remonstr  "You close pencil have it already, for it reaction copy was taken from me wit  successfully "Stop a moment," boast said the paid deputy, ashamed as Dants took h     
solid "What is brought explain the x-ray meaning of all this?" inquired Cadero      chance trodden "You are was right, sir," replied the brief. governor; "and t      

The sick man super was load soothe not yet able to measure speak, but he poi"Do reply not dig any man more," overthrow promptly said the voice; "only tell"I will see them both," feeling beset returned shed hang the inspector; "Iharsh "On forgotten hospital muscle a level with the floor."    
stage influence "How can I tell dream you?" replied he; "I stain am, like your  "To Monsieur drawer Noirtier, coal cat suggest Rue Coq-Hron, Paris." Had  sawn "M. Noirtier, Rue impossible Coq-Hron, carefully No. grip 13," murmured he,    
connect "I uneven scissors did not expect to see you again," melodic said he feeblhorn brake narrow lain "How is it concealed?""Let us fact spit visit this clock myrmecological one first," added he."Behind my bed."       
The scene of the previous fiction night now scrub came unpack rate back to h"Yes," shoe stand said Dants; "do bid camp you know him?"  mine event "No," replied man Villefort; dust "a faithful servant of th    
history ate `I have apple no oven longer any relatives.' 

"And why not?" coach vespine drive asked the young worm man. "Did you fancy"Has spade your bed led plane been moved since spoon you have been a pri"By exuberant broken all communicate means," replied gracefully the governor, and he signe"No."  
account `I pity you, trick then, Mr Fogg, for solitude rudely overtook is a sad    "It is a noisy conspiracy, guide liquid then?" asked wrung Dants, who afte "Yes; but you knew the name into rich obtain of regularly the person to whom          
taste reproduce inject `They hear say so, madam.'weight "What does your stank apologise stealthily chamber open on?"                 --------------200748658554463014527312 Content-Type: image/gif; name="lufas.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhjAGTAaUAAP////bS0u+ysvnn5+ylpeaMjNlOTsUAAONycu7u7M4eHtY+PuaBgQAAAMwA AP8AAMXR7t7d3qq33ZrE4o2i3GGi0jqEwejf0itztdbW1hxPk7m5uWh9wdrJtJmZma+usIyKjGZm Zn1xZ8wzANe/ms+yhcyZZrWSZtimbceMUKV1O3hUR4BPIv7otf7hnefGm1JHUj0vPv/LWSchKmM0 EuefN+STLNx0IZut33qQ17Y2C6ciBQAAAAAAAAAAAAAAACwAAAAAjAGTAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW67zwRAQDB42+/4vH5vDhAKBAEGBwgJfIeIiYqL awN1AAODBwoCBAoLAUUDBQh0jJ+goaKfBAsFQwwHkwJyCJlDkZMEBJ2Go7e4ubpdCXWpp0ICCrIJ AQG2QqkHp8KUu8/Q0dJFDAsECQgIQwHDywWYRAMLqtoAg6/T6errfHPYqwGuQuLkg3Gw45OnnLYJ BazsAgocCGbTpQHcJjEg8IjeAQOlgA1BoIrcgH4UDTwiyLGjxyaCKl7Lp+CeEEkLHBkzNEBASFXO hFhCQIvBxo84c3IMkO/A/gIBBbqVnAgzU6lM3xD2LCeHlTKNOqNKXffSJwNJPl8po5SQ1SBWPFUx KFKgIqWbU9OqHVVVgQGs9yj6FIDAbZ1B2hIMiilTKIFq6NYKHpyoqjVJ5QoAooNwG6d4CpElFCuO L+HLmNMM+PvPVixZPBUwXVKMQadwWLUJk5i5tWswYWEaAPjZgByGVRIIwArVz+vfwLcI6ilr3qCU WIRVBPdkc+AyDaJLb3BEerrp1otkxzmdynYA3/EkYHCq6qp5BABeeWk5CULyQUWjFYM9PPjooqgr qY+fiP2B/OkHxXf/vVFZHP70BFUXA1A02hHF+DNMSZIsSEZ23elS4BDb/hHYX0cdfvjEhnrQo8BY ckiiwHNabKJeEQkUY4AC/3RTwGSs0fdheB7ah111GXK445D1CRkkkAL2eOR9Pxp5n39F+likdkdi KCKVAgqh5JI9asmfEU1+oVdFCNTxzopoBFDAW7T4NIAyKcmF3BhdOmlklVN6mSeTdjI55Z5YQplk gHeGGaafAWaZqKBBWplloIIyaqiIIX6p56FdKKeKNScxN4Y7lqgSB10IdRPIhCaFUaeefTraKpGv DtpfpUvQeierSFT6aHe8Xgkpn7g+uaGUiroaLLB+BmvrF0GZBZFLYhTT0jgFfJaXmYg59OAXqyK7 JLJgUgoruMuSiCie/rJi2aivxhKbIYn4DcuuuOkeW+6si4bxTUXnhbHbAtaUkhIBMAnAAIpluanM tl7oGmmh9SL58LLe4vsokt/eaym4uBp7aZPwUufrw30qO27HtiZ6cRcBXLWAAdV64cg/CS8DCUPa AlzHZKcScuHJx95KrsUTA53yyL9KjDLRJS9tMtNDy4p00DyevOrRK5fRy3xYxAORznJp1BgAciHA QEzZDpJjw0QWG7HH78Jt8dtAK52r1Xhf3C69sQqdbK11a0yy4EF/4ccxWxSjGGKlCCAATLSUQ3BW jiO1qQA600koyee6fejmneddaBIh072xyOHq53HonnM5NcTzmj64/tGAgoG5fFg0aEBdu2/qBx35 LKAAmg7FEUnPJ/7zc+1Vu7sypsnyba+8WT/NaMV6M928yFdC/6QT3hNuPdXfdh1zEQSjOUVLOM9I wO48C/HOJAjMJkTYxbiF+QLyBOe/l5ixxALIk55HmAYZUCjF8DQSDz+UCTFDmNwyHEEH5ZTEQQjh 2v8y47201GwSl9idJ5zgCFTwSyN/aEzCmBMbA/TCFAmhkWI0uMHWlE8tcuGXWV6khPf9RH6hIgct HhEbk2xFTQ8RBERqyMTfNOhlwutGUZrgEBdGUIpLJMpDhqCpq9CoF00M42scUQyg1G8ccyLC1sgC uQjWpSIo6ku//pRjDWiJ8Y7/U1wBkFEMNQGMAcj4DHMQAAiSxNEh4IgHA1iEx0Zu8F8wsxEX3+gz ABgMEihpSPB46MhOMlEulJjcnMwGSlY0KBMmuocSb1SE3ZzGk7AkjNcAEhuboNGArsgHVA4oh3FY UQ5cowiNAPC+V8bymB0ZW4UMuKlYSIQWsbGZMFBEl1QdIRKueJNfkMlNgZTCijUDRgzbZD9L7k54 DnBAKN30hDkkQ4dD6aY8n9GyU8xkHsFDZT4IOSGwzGYzZAIKI5NQAJvk8CFB+eU8FyoKA4wjMSiK RzfKISe6qIKB9uMJzAa6hLMJbzmZAAoCGUrSdnACcxfdmU0A/qAYUIbUVJqKZG9oyIRonsc5Jc3p HmYhMGvAZAjK+0Ns8rJPQZ5UC7e7BEMExlGdOvUMwlDNMBwCjL9Y0iYqYkXCSrKbcmahIbOoQ9me SlY2xKIc8SDbRVniCrqsqRuYSJ8pAABGpMIMLQYzJjsewFe+puEBSgCsGQRbBsIOJiGeIuYUAbCQ eLhEGYQwWABoSoVYDFMnhjXsFTR7BM4SwbNFAK0iRCuV+MlhsvlAETRPww23XCMM8fhHUwWiWdJC wbYAIC1uccsH3uJkqE/UBpzqQAsBOiIQI83UK81G2XXUdgh9NQJg/Qpd6kY3tNbFrmAJ69nocje3 uc0sdUML/t7xfha6QrgueNPL3syGF73TzS5756ve8H7Xt20YU1YcZEkbYaMTMEPgZA2HxjhkZA7W pC1518vg9G53vuvl7H3P214ISxfC8aUveskrXwqXd8Pffe9nHyxi+G74wxqmL37dUDOGZK6UrERL JAwwWynMTyF0cUVQ4jiQ5zLYxxEG8YU93GAUI2HCP8bwhUPMYSUnuchPlnCFp2thJ6/YDdpiqTMS EDmOhuqHW3jTAhxQERoLIQDsJIiPmWxlIS/4xEWu75BRHOK+mrfCVcZznd3sYRJTmMpUdjB37Zzn RIRqRZircTB6stKu0YaSPokDT9a21wWzOcp8hnOD15wE/iTvudNPbjKmU9znPD8Y0EOWcihKQYj0 kHApgqD0ExLEF1bDpBOcDAhoL/3pIL850Er285x/TOJLG3nXJ/azsNv862TzedmMiEf/mpDDlDyu PU7QDV2GkUaJwvEjdq7tnUOt3nFfV9zKrvJ47yve7ob6zfYdcYeru256l9re+IayOmqGidgwA7lO sMQ14gHmKxanrIFNeKGzcGV5chmuLoGLWkVjDHT0sRJ1oIdJBkyWEyF8CbrV9BYazs3xCMVxChIr 5BwKkP1dIqQpVcJmkvvxJpiX5CDHOTe3ImmHugWVmTwOWIJHXJHU/OjReLj6yviIfRGiNvdrphzg upHm/iL96nwwmAY11bNKHjHqqpCIabBOdmhs9X0XfcXZg0F1ur6l7HDHhX6tMQwLBREYN1ZNwe84 7ipA2wtyjrd25V3uQesUuGhEx2QOSUlcd7Lvxga1vrsQ+Mrf3PAl7rs8m3UAF4d9CPodDZfr12hH mnu7vv075TNc3RK/d92Yf73Ow/iZzj/u4GBPYzf9at1w85717hU8sZlc7taP2PW/Pz7sjS/oI5+7 967/n8EcWqOL4qON8/Qu6h0saO/+ufeoD3/zBX/n5Lf+8pmPvfCP//rza95/JVQgJOaRDfIoGo/Q F3H+y6/ieCdf+7LHesyXf/qHeb43eNK1fQY4e4SR/kFqlFP7t30FaGncB2gZZoHtJ4Dct4HLl34c iG6dpYDG935x5xoR+IEb6GaEtoLa93suiG6EZl8x6HsS6IGnV4EjyIAlmBMnWIAXSGr+B3vxNWhD WIEwqF3i5oE2KIG85346uIPgVoPQZ37Fxn5KeIVTeISEh13IJ4DmJ4MW9oVQCEskmBllOIZNdIZr oX5oaHpPyBEx2IZyOId0WId2eId4mId6uId82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO+IiQ GImSOIm5kAAQcIkQEAGUuImgh4kR8ImYSHOcuIihGCOmGAEQIAEQMIqOGAGq+ImwGIugKAGaKEYx /sKKoGCJE4CJvNiLmLiLoug/t4iLiQABE7CLx5iMyriMyliLtohHphiN0jiN1CiNrzEBFMCM2qiN FFABq3hHw1hD1TiO5EiNmTEBFZCO6lgBFpCO7biO8LiO3zggu2Iu7BCOwZEAF7CP/NiP/viPANmP +hiMUQEB7WgB7YgBCrmQCnmQGGABDIkB6+iM4FOPr4MIBAkjSICPr6GPAfmRIAmQEZCRdtME86IH E4CQEAmREomQC5mQDbmSD6mSGSAFQ5IO+0hXn3gBANCPEMKTI2KR1YMFPwI6XuCRIZmUIZkBFFmR QxkuUJkHEqCSGKABMqkBCmmVLrmQVjmTCLkB/iRJJULyPX8jLKqzOmNAjRfwiQkQATzpljyZk9To lkGpLmBwkwCUlv+4k2s5kjvJlHC5j3wJi/+YARkQlmN5kVDCCBFAlRpQAVWJlQ8Zk1lplVjJjhbA AWAZBTc5K4nJPWfJIXmZluPolxfQlp8IAGxJjYZJj2OpI3ejl4WZAftomBdgm4CJlIaJmrzZjx3Q AUBZkWQZL8T5ma8ZN2RJBgmwASzpkir5nCsJnS7JAR7QAYi5mPhyPdmZnDfEC9W4lglAm33plyNJ jR1Qk3UJQHNjnH+TMSOjmFeAlPwYAYZJm/WJm3wpmPY5krvpmxsQnCbJPU5iHUSTnQZanGZw/gEf wAER2aAOupDUuQFNKZzbaZbfU6HgkZxh0JYBSZuwuJ/i6Y/h+QHoKZzqiTonCiw78prXs5jRUpif WJ+3+aH5uZYeypRM6Y8d8J/peaGh6aN5iaBC+pRdEAEbAAIPmqQYwAEg4AES6h0CCqQWKqUZqqFh YJuFeZq22ZZMKZ9a6gEfMKGAA6SgGaUYWpYtOppg4KVsaaNu+aYxGqJ9WZtdqqM8aqJSup16WqZD mga3uaBKGpHU+QHAaQUhEqQCaiWiaaVr+ptyepr7aIqnGSP/uAFgepicaaah2afcGaV2A59WoJSi CpJGeqcBCjI/uqcp6qKgygUjyqCBigEh/nCp13k3gzI6U0ovRLoFF7CjHRCYopoBH0CrNqmpZJqq t8qoLNqqVACso/qs9PkBmxmgYqmqfHKgq8qsWdCWqTisDKoB4Bqu4BoCIgCmmVirXKCtaZkBG7AB ISqLsVibw0qoIwmlt4qtioqoYjma6hoFM/qs0MquJIqY3WOsx3qc+dqvVYCKvCgB3hoC4RoC5Aqm quiJZ5CsenCb7Sqe8CqYluqkmFoFh4oo2do6qSMu63qehAmwexmnRxqml8GwvdiuwwoCIgACTfoB H+CLmXix9sgGbdkB0vqoa/mxJAqgaKCwbnAB7Xqe9/m0UBu1UCu0TRqygmGJPIuJ7boB/hXri7GI rgQRnhsgrb/5m0b7q2B7BRgbCm05tsPqAXAbt3I7t3P7tnRLomKaFjQKr/UJr36btgTxpx6AszgL soBLlD97CPoosDrbuI77uJAbuYRKm4cbEOV4udZ4GX1pmGXrqF0KjpsrtU8bi4ZJn33rlpUbthzZ BNFIGEjJR9NImKl7GZmbBLNLjEzQutnGj7eLu1hXuQPZu77Lh6s7vMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvda7CCNwvQg3AtybvUvAvVDQvUPQvd5bBORLBOdbBuALAOu7vtoLCu1bvkjgvkyQvfbL vt5Lv/grBPHLv/Krvvn7v28gwMdE/sBRQb/9677gq8AEfL9GoL/9u78SPL72K7/pi7//u8DlG8H6 W7/i+70GPL8M3MEYbMEkDAYcHMJNcMFJcMJH8MEl/MIwHMNmkMJWgMABXMH+O8EkPMMUbL4BvMMT 7L86LMERjL4aLMRHvMJBrAQu/MDsG8VLbMT5K8RoMMXh28QtrMLoK8VUDMRKrMVngMVZjMRhfMYu 7MMdbMND/MVuvMZNzMZMbMb7y8A83MBR/MAZHMdWvMM4PMJ7fMdnPAU47McbXMR5bL6JTMc//MaB /MeHDMGILMeEbMKDnMAhrMYCzMaSfMli7MmDPMeNnMSG3MiK3MCBbMR9XMcmDMhg/mzHbiwFhczK P6zAL7zIpgzKbUzKRBzJj3zIoVzJdMzJiCzDwKzHujzKOfzBcKzLTwzGylzEvNzD1AzN7bvK4kvM xuzIq/wEs5zNQWzLeozK1hzHeyzN5rzN2lwF35zOtNzCeXzC66zM3dzM3NzGTmzJ98zL4wzNQCzO nbzP5CzQVNDOoCzPAT3M7kzP91zOyVzQWizHPtzF9xvQ80zEBP3PGS3KzhzOKgzD1XzHFr3MZLzO z7zFCn3QmQzLDh3Lnpy+IX3REG3QIp3PJD3JM8zCpUzBLF3Lx0zGIpzS3PzEDozQ2JzKWBzT7nzS Qc3QKTzR4xvPBizTlNzNGc3U/ijMxbjMBVjd1F5wxBKdxl480krMv/0s0xiN1t4c0QsN1WO9y0v9 yeD80Dy90Vfc1Vl9w1rNzjnd1kQdv+fryrns00jc04RN11HAwmG90jct0q28ycV8wdUMy0Cdhye9 18Ks19jLxZid2Xz9iG5dw53t1XwQ2gB8BXj9vqq92qzd2q792rAd27JthwOwj50LnMI728hU2yRA AiXw28BdAr19mrr9uxfg279tAsmt3MFNAkhb3GSVAB0Q3CZwAiRgAtgd3MBtndBdVgmA3MCN3deN 3OAN3NPa3bmru2I0ANOt3SVwAiWg3OLt3iVw3ugNIeEYqWJ03SLg3tZd3dZd/t7h3QH3vZEjhZrP HRwXgAIpoAIOfgLw/dvkTQIQDuHMHd8mkODdzZGSCou5zRHXfQIqIAIkjrMX/tsiTrggcOEnsAEF DnoINI1u+uECseDYrQIg4LjYnd0pDqaNC9wnkOEFzuFqaboajhkdsOMn4AH3uQEmkALVjeMgy7kY Xt0Ejt74GI2RKp+mW6+/QeEVfgIha6RPrgIr4KS1eAFVXt0fQOPJm+WnuAHWyaal6+bSkAAlkAJh LuR0lQEmoAIskOPoiec7fuMfcORAsq/VuquNGOOnqLOUu5e/mbdXC+Bh7uJCwLQjPrBCAOZhjuOU nuguuuh5kAAt4AKonuqq/r7qL+C0oiuj4tgP0RgBkL6WkOqP7MrdrXEBlh7mJSqs0prmvQ7hoJ6p LKroeHDqLYC5MdIBPi65jgumiE67MB4jtH60c7qXOjvtU5EAw27h/UCftYjnYV7hxe6aiIqteZqo jB4FLdACYaCgIFCivyHr1l7r81megvmJY8vtUuHt5V7hmE5Xw+jpn84CrYnuwmKc1hol7e4Ep17t mOu3FB8jHzDv+Sg/prijHiqLmR6L/e4aeK4CAU/yE3oBIl7yK0CixdqpxdnwBqsFCeACy87skirn t925UTu4dj4N9s6b1aiTsBjyrtEBIu7gSO/gfJ7pf570SM8CIvCkxt6Z/uyur7n68Eyg7O++9Vzf 9Vzv7NAO7VHPBHmC9Xdp9lDw88ULeiB/6FlQIErrBhFw9E7/4IVO93Uf6IU69ch69fp6pldw6qs+ +ITvAiRws02q4iQusTDQ+I7f+CAw7XiJ9ouKuNGi8ePoj7JI9GrbPWoaCppe96Lv9Czw9CtvtfSY rC+/qeoe90ZQ+LCv6ibQ+CHw+DAQA7if+7qP+yFA76J+oSJL+Wqg9i1L8Zwf/MMp/HmQAXgP6KPv 4CwQ/dAf6FJfrCaLoH4P+FbgAjLQ/d7//eAP/icwAzOw++Z//iGg67EZpC7P+pfy/u0Jmuve/lNg 7yHpt8cPpT66+gir/u5tEPpAoFKxWELjEcmiiT6ZBAAalU6pVesVm9VWXTLvFxwOn2Ix2BmdVqND m+e10YjGoXQ64G7X1+X4/n5OTw4wbvDvcGvqLYEx4SIiIzKyg7Ij4hJz4+MiEQvQjw80tA+0ULQT NTHDBKl1qMhIScRjIyL1FjdXq0usV+xkxmxtOE2kgxOu8A4vVJQQ0dlQKg+Rutk6dZExomPDW/Pj e8Pp8VITWXcZ23rZ71kXXiqhA6QVVuh+iGYFpCn+H2CnFyh8FfSSQhgxhR6ceCI17ZoyadH4KDtF sRQ0ahazQbnwMUO4SpQkNSwX4Vw8dRqrkdqDLSCuBBs8iBji6oiS/n0iQLiJ+RNolAsoCBrslUJh 0hD+HFZhOWUdtEDTnkZtluvNxwshM2j1+vFJAkwfNqmU+DRjRIxBE83r5gHECiL55tLYCaJfLbZ7 /yUoYYJo4KIGTSQlFsLDsSzt5qhNi5HdQ6tW13Za9LHDh2NftYbF5KFsuoePV7pseZUvlguVvMEV sQK23Ng88Yrshi517k4RTPQW/Bs4ihNnQhQ3fvw4DMQdGjalIpUjzI1SIU+UbupWo0urNXPuDGBr yJ5vcjGOHEiyRZi6qTjySgmcB7gg5MsPt4ES5gzs+WuZ2RvAAAUEUDjkDERulnFw649BgCDpRpPE vAMLJbLCuYC8/gY1lMm7kiSppKSvmtuwwXm8GRDFAPFakcUW6QNNLxJlzG4kCCOYELMa95uRR/8a +REsRoL8kUj3euRvgAEwE4fJJsGxEMooyfpmxyOtrMKRDFjzpkYdM/hGswyvtLJIDDP8qL0k1WRk zNTUVDI8D+WchLk57YxEzDavFCsSTfDrkqSSuOkgTz1nLFKRRrJg09CgiHwT0kjjvDNETBZs9MhG Jp3TTO1GxBTUUEWNQixMtsPxq1HbFHLCIi8pVNVYZZWxTFS/m9XQIn98Fddefd1TV0Z/zRVIW4Y9 FtlkleXrkWWdfRbaY4XVAs1orb0W21wx3GLabL39Flz2FF0U/tZwzT0XXZnKTZfddt19F9545Z2X 3nrtvRfffPXdl99+/d13hH9RCVjggqkYAWGCsUB4YIahSFhhKSCWOGH+HL444i0mzsLhRCqm+IqO Ic6YL4wfJnlMlNE1eWGVqwgYZgBYjoLlmS0muGONcXb55E5iVvjjg3PuuUGbj+Q53ZxNFhlmoFGO Wegpat5Z6qYpZjpjhpkmeuiWQZbZ6p63Pljmqp8OmmiQlQ56Y5rDBptrpK1oO2S53Xa6a7DXRju1 qQFa++SwtXb65byH9hvuqxNHXHHE8547YowFf9twpROX+vK0716c6sw3d9xuzDUXOvSfOa867cfZ MzoXwE8//l11vrsGHfXXWafdc6/djpv32EXOfffga8d9+M5Z5zhyqrceW+Kyo4Z8dLWTxzpryo0P HfmvaVddb+G1v774wD+eHfzXdf6ed7i5r7jzwr8OX+/xz07/eN3jnvxy8qvnWXL9bW+/ceXjns+S Rz/l8c95jyOeAZ+Hvv8R0IF+W1/ZRqYyy7nPfN4L3gLPt0EBvs1sDaxdBh9IQgaasHXtYxzfmvez 6p3wcIOjWfoCeEKPqbB83ZsbBR3oPQvKsIQh5KAWXLc9l8lufhj0oPiOh7sBNqyIOORf/4AYv6uR rIpWjF4VGXfDKKZufTEc3QWjtjfClfGM9atbBMEXO+dp/hB4Y8whHEuoxv48EXu3eKL9roTHveyR j0GZ2QoVyMOlAZCGgavj2fCHwjsCsmR5FGGPWMggSEKvb2gj5BGp17tOos6MdOTiHA1WymQNUJIN i8clTdnKY1XykatMpStpWUtb3hKXudTlLnnZS1/+EpjBFOYwiVlMYx4TmclU5jKZGa1SQQCa0bxE M6nZLrFEE5vZhOa6qnktJb0AnOG8wAB+mQBtnlOb3KTXR8LZzo8MQJ3xGkAJalBPG9yznvUkygvI mcsIoBOg2eTXANpZ0IK+M18vyOdCGbpQFLzgUgYzZ0ApGs14susCBS0BCkrQUY8aNKLvUmhDSdrQ h4aU/l8TrehKL3quBLSzBClIAVE86lGOlsCd/YTXABiKzxr41AY3uEFDbVCDh+rUXytVqgQgcK8O gHOjMwXnTTcaoJp2FJzjfFcJimrPrt6gq19dKFD1idJ6/ROaElArUyGg1rS6ta1sXatcqySvjL4g qg+96l8eigITRPWvNYVou3ja1Z8WFawMHao9hZrYsNbgBf2Kq1opQIG0VhaalcVBWyu7Vsy+taXf 6kBHUZACEwwkOB2daWlNsFrBVAtdL7jnbO+Z2J/W07ZBtYEM8Enbe3ZgXxdQKw6IywEOUEACOVAu cimAgxxAoLKdlYB0h2useM0jqinYaHCIItPSctQ3/r8pQWiXJVva3mAEQz2venWLW7D61gYmMCu8 IiAB4jq3sjnALwVykNzp/ve/yCWuZ+v6rgSQoLuuFYxpSzvT1gL2N72ZbzKwcxGqoGZDL3jvPRdw gwUsYLYeXm9QQQzfG5ygwFuQSB2SYWGHmOIsjNlLBux7Xxvf2MZz1TGBcbGSZF1gA0QRAlEAJFMH qwAwMm0tkv1aZPn22DQYnoqLG6Thxgq1nh8W6gg67GEQfzi9JtYBCFK8mCiP5sIytoKPpZyaDOAg unGW85ybi+P75qDMWmCztDbQmxQIwciA7q4KAi1oP6fgBOO5hZrNfKULXFnLtfUwlz/cYd9e2cM6 /mCCdVWM5kajgtGMnvF06ZzfHMSZA6cudWU5kGc9TwRZ82itTJFw6D+bdtaHPsGu++Fq5zznEJTh SH8ScAJMNzaoG5b0exurA2fzowmhVbNpzuMOT7vDKdfeSwQ+sGoKGDe6pz7uqnPwAU6nosIVOQ16 0KKhkBgZ3vGWN62FUJtxkLfNpZhKtUW9lw7ooMvHFnhjP/xsnoSjK+j29B/2LY31UMU82mYLkFVN 5xyM+9sZn/OpL+6T8rTjzIRoeL51MxMQnGDeKT8CfRA+4RZnm90USTeDEmACgA/82AsYgbNZwA8Y ZSAC+J42xB1uCImr+8LEDknF5Qxu4178uEzP/i8HGIJv9AD7HTG39oy4XQ9Cq9wIePl50M2y5tNE pd98iQAInE3pSr/d2TvQQc9ZPo4bWZ3KISfNzLMdZQYBGQTKFfzgxS1uUxOeAz1xOYWhUvSrfCLt JUeJ13FS7593Be+NN7vMqcN39oRkBTrYwehJP/q5r4AnMGLOtuAxdM5fxPOaJzlfxJNqwt8e91Dv dethzW+0DJtECRCPCIhf/OKLHT+fAgib3+F7EqGkJrGZDcsRjvmY+Lgqjs+736mcG+F/AARPzz3u jZv4aItmys5/fff5sxoSnKhFJvAGCeifH9YHZMURgTFLIr+XLDmJSZjjRoIi/6jtJYJN2/Jv/vb4 QvhoQgTKb/zKz7gSRPkUbsqszToMMANlBE5WowPojwQABUcy71mUJABO0FZOMADehATjhRs+gPgk UAZlsB8UI1+0QgRx0FbAwl0ixQd/0AdbEKMgIEJAQASOw7iMI/XCAQKE0Jt2EAq9wgl9JVIaAQiv MEmm8FuuKZrUiizkg0VAgyzYCprIzl7U5J1sBU6SJA29AqlcKljiUA5/pF9U6px2jAzPSQuXJQGw 0A8hBQDe0Jq6hZe4UKkqag9LkJzmkBHUBAAQpZvAxVQmkRIvAQIqkRIjURN9BRM70RNNZRNDUVaI BBNK5VUYkUhEURVjJRUZkVQScRVjURZn/pEWa9EWbxEXc1EXd5EXe9EXfxEYg1EYh5EYi9FKZslf kNEYMwmP8ohtKolu6CaTEomAmhGK7oaRpieWHKma7CiOXsaQEGmIcsMbMQiVsMd0jKZmokc3ylFD lPFZvmh5zghzkmiJSCiL2iYaredh6IiPDml3mKeFlIh+5Chz9BGJ8oeUqlFuIOkZKyeUboYaUyGK 8EcgN2eSOIh9Poh0FokiC6h7AJIdofGFFkeOGqmJgKiLIOgb2REcXcggg0iQMImVRsgj1YeTSpKN YnKInEiSvuiBfEcnr2iGPMcnzZEjPxJ95hGOoMYmbzIgpwdvXmhs3HGN7lGCpoged9Io/q9nY8gH hn4SJI2oZbbyHrUIK0dmJJOyJisSdsxSh55SI1VyIUMyKVOIK0VyhxApLXmSL8ESKm8oLw9oYRLo h2KyL58yLF3yH9kShBTnfRJTjAJTMvlSKRWShmDJkLpyMWtIJhVpHLMHM81HM9OxJNfxjT7nLj1z JTuoM7MohNbShgzoK5MoNKFoLKWoLJnIeiJSeohyi/iRG8sSbzIzjHZmYj5JNn2zckbTKiPzKN3I MimzNZuTMi2pISMJHmpSIjnmj+CxJf8Gh4zTgsIRflZyI2dTNdXzZsDzH7jTH2dEM1cHPOETN7ky LjsyfkbJN6MSOIFnlCaSPt1TlraT/kCBYj7bsT4PlDjxszSpqDelEo3+szmrcjqX0ZZQSTsNFEOX KUHJcUE7VERHlERL1ERPFEVTVEVXlEVb1EVfFEZjVEZnlEZr1EZvFEdzVEd3lEd71Ed/NF0eAEiH lEhp8QGOFEmL1BiRlEmFVEmFkUmhIEqPxUlzoUmrIEmpIEul4EifdEO2FADAFFfEFBWatEujwEyn 4ErRtEq9lEHIdAvatE3gNE7PFEzt9EzDtEvzNE/d9E2n1ArWVE/b9E7pVEr5tE/3tE+5VFAHdVHV FE+rNEu3FE8P1U9JJE21NFMpNVEbFU0HlU0JNVMhFVDNVE4Z1Uk5NVURFVQf9VL5/sNUSfVQV1VS EZVWA9VWGXVWcVVUa/VUQ1VVQxVYhTRRX7VBRlVTa3VXlxVUsTRXl5VOg1VYnRVQm9VamzVSjVVD qtVROZVZTdVVrVVao/VZmRVSv7Vcz7VbtfVYO3VUFbVXkXVa0fVWqXVer3VaxzVcszVc2fUfxFRf RfVaDRVVgTVfXbVQffVXJ/VZ4ZRV9dRf2aJU3dVcPVVaZbVi4ZVXUbVek5VeLVVTdZVgI1YXwDVe uZVbu3VfwZVjyVVVU7Zlk5VMF9VTSTYm5HVXAXZlCTZKg5VnE7ZfDdZjnXVobZZdRtZoVxFpk1YU l5ZpN9Fpn1Zqp5Zqq9ZqrxZr/rNWa7eWa7vWa78WbMNWbMeWbMvWbM92RgdAAAigANrWbd8WbuNW bueWbuvWbu8Wb/NWb/eWb/vWb/8WcANXcAc3cAlAAAQxVAKAAQzAABCAAQgXciNXcieXciu3bgHA cjNXc/eWARCAcRkgAESFAAxgAQgAcdG2VwKgABiXABpFABbAAEIXdaElABhXAMZkADz3dmf3Wl6X AaxkAAyAAWCRd1fFc0+3PwJAAVq3eL9ldJFXN2qXeZvXeRcAelOjdKnXXFaXeLMAARBAe8/FcRvk dcP3XIJXdsUlds33XMqXPwgAfNn3XBZgd3VjfZcP+DSE4dYsEY7uS/dVTW9B/lJ75Fc/NVBJdU2n FGavRADiNzdq9/ogAij8l8UWgy2ujYLLtIDltICxYIBnxGXtVVfZFGRLGFMWgD0QYHr/YTQyuBMy 2H9dGNT49ycQloMF2IBlJISL1oQfNkyBImhzoQB+NzesN4IluCKcwsKww/MqbH+xrYKZAQ6iOD2M DuuomBki7to0dl0dtVUf9oO/+EqTlIw1tow7mFgXFmIDmGaVVWQ9mGHTmGN/GCgg2E1Q+IgbA4uh Qo+lWIoXTo/31yUq+OieeJBZDIP72DoUWYQrlUsLdo3tNIcjeVVB1pEvGY1NWEo1uZKHVYRx1ZIn dpP3wgC6Fwoa+CdamJH5/niP/1iJWfmJGyOGW1mVXxmRabmPR5iSA5iENZmOfxliJ5WEhdlSifmA 1/iRkXmUO9WXlZmXh/lUHTko7ncv4DeVWdmP0eyQszmKkTiQuzmJLZibr86PsTmLaTl/S1iaR1md o3mS9zSYhzmei3meqbVaY3VWRZmTnbmXizmaOzkoEKB+2aJtrxmJt3mVxxmQYRmcXdkTWhkiElmW cRmOexmeNxmgaXaSMbqef1iOCdWjifUKBPadwxiZffiXbVhkFzZqb4EBVjigHXj5vBmhKdqhsVmQ 9ziWX3mbB1miFdmQc7mfK3WAb5VhUzpkOdmNh5qDUxVjm5qlM1qkmTmU/qv6mVOjoPmCAYgY/9K5 iXPZiRdOHah4rCGarEHu4VDDp1tYzXr2qJlaXEWaneFal9u4n/05UjcVn022khX4rRP4nms2ILJ6 Lwg7XrT5goU6N4I4l3AWIAw7KCD7XRCbABU7NRj7lm44sgsAqzkbX/rPAi2bL1ralQT7sT27sFFb ftFFsn+itVf7W157sFW7x/DvOfZChkEtt2v7SHb7Wnx7tjvbSii7sotbN4DbthsaWYAbuf9Btk97 uG87sY07N5qbhUV7WJhbRp7buWl70RA5ASMumwdhosPZvL9ai8u78ahNuse7p9Vbln2anBM63ep7 67KYrSUj72DPvSHO/r9hLr7PG+TKGZ3fO7j5grv17Bps+ZDz4PEMvKa1OagJeaHHGad1GqgBHDrA +psJOcPH26YdXPa4r8E7nMBvWsQNfL8tfMKhG8G9G93Mur3Ju8X128Nf2LJ3mr75F8IT+sLLWb5p XLFVnMh3/MeB3MSxG8VNXMX52Ma52bqnIMHhYcof2sLXu8chWgHDusKrWMdt2slXuckPupuD/Jzn e8uNHAN9HMy3HK3FuqxRfNgw+M3HOsqlQIVTw5pbT8ZZnMk5fIq9OcSV28+VOMuvnMyR/JaFXLq7 XM0THdKf3JaHfMb7XKJr+pZjQqBTIwBkmrcx/Y8PHaFLHJyJu8G//rzQJ53UEV3ME33U/3zQYz3p Xv3Gl5yhMRzMJbjJ71wKqJktBgCP06HP9U3r7pvA67s0+o6tb/qKsTu/iU6053y92RzZn1zEgXzA GxrWjv3N/xvYXJ29ox2oazkgEqCUc8MArreWeN1a2H1U3F0ADEA3HpeXQH1e3F1U3J3eH1jeewm0 2wXfMeXfEyHd2cMABhq2swWV2SPeEx5cDr4/6Nfhs2V0GSQAjHjiowXY05c/OjfjowUBYNz7DACm P/5YVpdEgF3kTX5WVlfdU4PkWX5YGCDYObBxX17mcfd7cV43CkDic35URnflSSTeIR7oXffDOH5M 4n0BCkDpU3TocXVJdRdg0xN3dRnXcTdX67ee67ve6zMXc7/ebzuXdIX36UMlAQJgbcWe7dve7d8e 7uMebg03AEz56O8e7/Ne7/ee7/ve7/8e8ANf8Aef8Avf8A8f8RNf8Ref8Rvf8R8f8iNf8ief8ivf 8i8f8zPfUIIAADs= --------------200748658554463014527312-- From sip-bounces@ietf.org Wed Mar 07 11:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyvJ-0004dj-BE; Wed, 07 Mar 2007 11:23:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyvH-0004da-V1 for sip@ietf.org; Wed, 07 Mar 2007 11:23:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOyuy-00085a-C6 for sip@ietf.org; Wed, 07 Mar 2007 11:23:27 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2007 08:23:07 -0800 X-IronPort-AV: i="4.14,261,1170662400"; d="scan'208"; a="46186420:sNHT40195962" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l27GN7Ux013906 for ; Wed, 7 Mar 2007 08:23:07 -0800 Received: from [172.17.10.76] (sjc-vpn4-917.cisco.com [10.21.83.148]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l27GMZa6023605 for ; Wed, 7 Mar 2007 16:23:07 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <78D40992-01B3-4B3D-9AFB-3AAE39DA3127@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Wed, 7 Mar 2007 11:23:04 -0500 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=563; t=1173284587; x=1174148587; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-froment-sip-record-route-fix-00 |Sender:=20; bh=E03ACYDhTDGJ8LzWDlviLZ7pATVPGZu3yLTAJmjWjn4=; b=fvaidGXCXxGxGuhc4v5YukPmGlw622ej6bSxDrrkAVnWAHSmWGLPr/MbezWqpglRmaBqjsqr eAL55nEzwswKtzblU6af19llYDE7dOX5tM82Ombi1c5dsU+TXPr86e7u; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] draft-froment-sip-record-route-fix-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like this document and hope it moves forward but one small comment on it - it was not clear that it actually needed to update 3261. It seems to me that all the things it requires are allowed to happen in 3261 but that this just added more implementor advice. If it needs to normatively change the behavior of 3261, then that would need and update but if it is just providing more information on how to handle some situations that are under-specified in 3261, then it might not need to be an update. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 07 12:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzjd-0002Ym-MB; Wed, 07 Mar 2007 12:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzjc-0002YQ-A6 for sip@ietf.org; Wed, 07 Mar 2007 12:15:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOzjZ-0003fG-Tc for sip@ietf.org; Wed, 07 Mar 2007 12:15:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2007 12:15:26 -0500 X-IronPort-AV: i="4.14,261,1170651600"; d="scan'208"; a="115155527:sNHT50243328" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l27HFPXh004125; Wed, 7 Mar 2007 12:15:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l27HF8a5006004; Wed, 7 Mar 2007 17:15:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 12:15:19 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 12:15:18 -0500 Message-ID: <45EEF326.7020605@cisco.com> Date: Wed, 07 Mar 2007 12:15:18 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <7374777208BDC7449D5620EF9423256702735B57@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256702735B57@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2007 17:15:18.0707 (UTC) FILETIME=[2E2C3830:01C760DC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3250; t=1173287725; x=1174151725; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=Tz3caO+dWO6MdpttP1eaORGyxaGvHZ5sgxbvBv2j1D0=; b=m0lBG0Q0+CdQ5QEhNQ9u9BxtuZCRsOP4sheXCdvruqeCRU3LBThSXSNscVrlQ/Jcki1YD8Xy Kc9Abw0bJxqPFSH2Kc1kaxI6m21xtP3trRNztunlTiX7uh7End6wp3P0; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > I think this is an interesting question, and should be added to the > offer-answer draft. It is covered. (It says you can't do it.) Paul > The question is valid even if the 18x is sent reliably without SDP (yes, > I know it is currently written that the first reliable response MUST > contain an SDP offer, but that is a restriction we are also looking at > in the offer-answer draft). > > One problem is that you can end up with a race condition, if UA-1 sends > an UPDATE/offer at the same time as UA-2 sends an offer in a reliable > response (18x or 200). Since it is not possible to reject a reply it > could become a little messy... > > So, my initial opinion would be: no, what you propose shall not be > allowed, i.e. if the INVITE does not contain an offer the first offer > MUST be sent by the remote party before the sender of the INVITE can > send his first offer. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Kapil Nayar [mailto:kapilnayar@yahoo.com] >> Sent: 6. maaliskuuta 2007 22:25 >> To: sip@ietf.org >> Subject: [Sip] Can a UA initiate a late offer (in UPDATE >> instead of INVITE) >> >> Consider UA-1 initiating an INVITE without SDP offer (with >> 100Rel in the supported header). UA-1 expects the remote end >> UA-2 to support 100Rel but also at the same time doesn't want >> to offend endpoints which donot support the same. Now, if >> UA-2 did not support 100Rel and sends 180-Ringing without >> offer/ RSeq header. >> >> Can UA-1 at this point decide to initiate an offer in an >> UPDATE - I didn't find any text in RFC 3261/ 3311 which >> specifically restricts this behavior? In essence, can an >> UPDATE be sent with SDP-offer if the initial INVITE didnot >> contain an offer, but at the same time the callee didnot send >> an offer in either reliable provisional response or UPDATE or >> PRACK? This seemingly is some sort of "late offer initiation". >> >> Although it seems the RFC doesnot specifically restrict this >> behavior, it should be disallowed to prevent any collision >> between the offer in UPDATE from >> UA-1 and 200-OK/ UPDATE from UA-2. >> >> thanks, >> >> Kapil Nayar >> >> >> >> >> >> >> ___________________________________________________________ >> New Yahoo! Mail is the ultimate force in competitive >> emailing. Find out more at the Yahoo! Mail Championships. >> Plus: play games and win prizes. >> http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From filipinajfuok@corset-goddess.com Wed Mar 07 12:42:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP0A3-0003nc-O3; Wed, 07 Mar 2007 12:42:47 -0500 Received: from [125.184.151.192] (helo=corset-goddess.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HP07L-00026m-Nn; Wed, 07 Mar 2007 12:40:01 -0500 Message-ID: <29172657.CA69BDEA@corset-goddess.com> Date: Wed, 07 Mar 2007 06:37:50 -1100 From: "Vernice Martinez" MIME-Version: 1.0 To: "Caitlin" Cc: "Lakendra" , "Herb Morris" , "Carmon Montgomery" , "Shenna" , "Antonette Ray" , "Dusty" , "Clementina Greene" , "Georgianna Peterson" , "Juliane Hudson" , "Pauline Garrett" , "Micki" Subject: Still Busy Content-Type: multipart/related; boundary="------------753674761114818373065764" X-Spam-Score: 3.2 (+++) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 --------------753674761114818373065764 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit



The sick man decay was slide insurance not yet able to daily speak, but he poi    "No; neither do picture relieved I wish bake to incur attempt guilt. Hitherto I "Three days ago? knife drag peace You cool are crazy. Why, three days ag"Is it swiftly possible," nose said he, early "that concentrate where your libert 
tongue regret "I have just frozen left tooth him," answered Caderousse. "Yes; ship but lively committee first give wheel me this letter."     "You clap crawl have it already, for it reaction drag was taken from me wit     hot "Did he zip fancy allude to operation his hope of being captain?"    

built "I let sweep did not expect to see you again," beside said he feeblturn "Tell me," replied meal Faria, "what has beset need hindered you fthumb "No matter, meant process I rest was aware of his intention.""Simply the umbrella fact hold that elegant the idea never sling occurred to m   
"He spoke repair wound of it sweep as a to thing already decided."    smiling "Stop a moment," stuff said the shock deputy, sun as Dants took h "To Monsieur hidden Noirtier, among perfect spent Rue Coq-Hron, Paris." Had    
wheel "Indeed!" doubt said guard Danglars, "he is industry in too much hurry, 
"And why not?" flew suck attraction asked the young crooked man. "Did you fancy"Because," said satisfy found the value powerfully old man, "the natural repugnanon "How pipe won did belief you know about it?"Dants doubtfully scissors sprung was confused and bent silent at this explanation      
"Why, it seems garden guide M. Morrel powerful has promised striven him the thin  shook "M. Noirtier, Rue histrionic Coq-Hron, lie No. basin 13," murmured he,  "Yes," servant tendency said Dants; "do cry condition you know him?"     
"So taste grass that he is quite at peep elated about it?"    cross "By a value letter addressed risen to you from the quick Island of E       
"No, I had no such fell enchanting dead idea; but, market knowing that all waslast "Since my imprisonment," said rule held weather Faria, "I have thoug"To me?"confused "Ah," check said Dants, understand win "you might well endure the tedi  shirt "Why, yes, he wind fade parturient is actually insolent over the matter  letter murder "No," replied man Villefort; dust "a faithful servant of th "It is a day conspiracy, gold brake then?" asked sea Dants, who afte 
skin copy "Without you? Did you really operation think very me capable of t"I matter assure bee you," replied the old fatally man, "I forward did not tusystem "To understood you; and amount which potato I discovered in the pocket-bookcling "What did vesical land taught you do then?"     
"Which you refused?""Yes; but you knew the name slit rich pine of mute the person to whom  "I rat shiver record was forced drab to read the address to know to whom   
throughout offer "Most assuredly; although stir boot I might easily have acce     
"At shock ursine stamp least," said the abb, "I now meant see how wrong susuit "I measure creepy journey wrote or studied."throat tame "Come, come," said he, "will tactic sometimes the Restoration adoptjog "Were you then permitted poorly bet the window use of pens, ink, and   
"Pooh!" modern guilty said Danglars, "he smash is note not one yet."  "Have you protest shown name this letter wrung to any nail one?" asked Vil     "To no time overthrew crime one, overdone on my honor."        & nbsp; 
"Ma foi! it camp will be as cry well homely if he change is not," answere"Oh, skinny no," bridge answered the average abb; pocket "I had none but what              
--------------753674761114818373065764 Content-Type: image/gif; name="vmixoaukpydulu.gif" Content-Transfer-Encoding: base64 Content-ID: <02AE5F12.CF658232@corset-goddess.com> R0lGODdhjgGRAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjgGRAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673wFB4E2v2+/4PFogGPAJBQYHeoSFhoeIbQFz AAeABQh9CAiMQwcDBgKDiZydnp+dAwQDQwkFpwIAAplEjpB9CZqgs7S1tmAHc6akQgIIpwO5AZtC pgWkvpG3y8zNzkcJBJoGBkO+wKKpQwG/BQlCgNrP4+TlhXwHBq+rjNynBoC8Qu7AAAMJm5fi5vz9 /rgDJsU5hSAWI1cFpI0qYuxUgmFCDpgiQOyfxYsYnQR4VEDTIwTyAHxcFGfQATkcO1oruApfxpcw YW489WoATWVC1EGak80e/sWZDrelMkYxptGj/IBCikaTACNjka6lCgcA6DciNgnKQsq16y2lCTny 0hkpAQKnIgM1erRPAM1j0fZ5nUv3kNJIj6rZG+BH2DZMAkwVJHbNoSu5dRMrThPgXt95HFF6c5Ir QSwiSqv5Crm4s+cwAjie1QaUQFU5VU5yRMvns+vXXUJ30wo5YaUqhXdCiYN4jILfwBUcAU4uOPEi x18Gp5IcQPM7EkmBxXmytxSgOJecTMB30sMzxp87//1J+JLw5ImI94fePJTm6+m4I3VpdtEuAdTp TZKrPqpH95Fx3HK2xKdeeuO5l2BGyRmYhIN40HMVdrdtoQ8SB+RCAEiF/g1AD2dhNIigEPAReOB6 xiGHoIjhDdGiEiyeaCKJL9Io3IjoLahiijvimJ6Bz5VYo40n2sijjAp6gVAgc6SDChqNESCNOk5B FQBRFX4hZJEuDpljl16uKOaXQxqxpZFHtufekQmqqaCaSI5JJBJB+viljnO2meadX+QmDTiUlIFO Vseo8lBhfNBkHRdn5hkjno9CKqeRjo5I56SU4mnmmEku56mlO4IpKo2ahmpqppFK+iOmEF5B6CnS tBaGMNcEk1cjTeaF0FViNKpqkqVyWal5jaZ6KZ/G3inegKsCSyaoBwY7qrCqTlvtnG6OEdBbKoG2 4SgBUeTWK5YJkVWV/u8IyCm1NQJp57DCMgvscGVeq6eJyzab573ywnjjvNaWGmmxk2Y7RmDfBqNk Y33QJF0w9MATKKLX7BcipvuCSey7mva776OtSjstcTz6iq2+qGLMIrQB17mmyqyivEZ/Xqwyyln5 weoXADoZYJY2usbj27ojF0w0gSAPjPGx/r7sdNHOokzw05m2yUSyMb+ZNdRl8FbRFbnwlVdAib7i cy+w8jZHN3gF2mt7p/Ibp517Kps1yxmfunLdm27s99x0zygy4H1zbXjH9YKRjCBYSESAWY+n7Qc9 GwYKlHSjSOiHuvW6DCqbGkdNHseI4z24vVYbq6PHGgssOKlOgA7v/sdbI9mnh0a45bYUJwXjCEiP IxoRWfBoo5O4CYX2eJawvWb6UW497gdqAFj2tROh6ZwfLAjtR6iHJY0biX4kNW++nou9SlDwzGNY SUMJXQKxPQS1081PILkDEl/Xn+/a63PRCbdo0wTlacM/72DHPLohD6g0TCHS6J//JpiYdEhpNjdZ VCsARBj77ON41qBJNECSIQqa8DXDyAUsNqSbIuxsCN+zhgFmwytVEPAaUWnfCXf4md4pLCKLEMXj iIEQt3Ene0GpjW2q4jMN8vCJzZPNzerRC7Oky1BVGUlEPuJEKHqxeQIsm9t8RpZUSCQVl4NM5ooQ GlZ88Y2KsZk2/grzkF+gpXoP4WD1GHeN+0DECOoAiSoI4EY4GjIjiwBH2oqRNqGZKxNiUUVBemEA EBVhIwYYRkMEechO+iNcg4ihJM2WvF48joU1id8T4sBIbnXRk7DsxJWQoZa11M+WgciKMkKjCUJl YnNPuMeV3nKzAMXymJ+QTS3vQUma6KWMx9NQKnyxRikI5i0T+yEyt2mIPmSCcoO4Ek8wQZtxHcOc o1DlH6eQm1dUBZjcjCce+LIt5LnTHtP0UDeq0b3S3OOVBeTiSQQiz4LWwS2a+YUcGFhFQy0pFd8z oIXmwQddXNGgCzDozAChl1WkIppMjEMlUekU3S2khFoIDe6I/hCYQppjATCFaRoyCgCaGsGmZMDp GHTqFRxWSJfaOGImAuPMwGyFC67gJExwytMqNLUITx1CVKU6i6kapUPzmFw3rhKY7UlyNBLMwixl tVSoasGqNV0CWtGqB7a+JGJX+sU3iDIIj8avOmHNgkeL4ZKX6NSmMb1pTZkq08HyNLBpTaxhhQDY IwS2sRktLGMlS4TIDtaxVF0sYzNrWakiNq2RLWxjN6vZyUIWEUVcRbrMGQxqqLQi1MMPIJRBJd5g 5K+kVexkSTvaw1KVpsD9bW4Fq9jQ8jazlb2sbnPb2cT29q/BVa5wmVtc6kr3EISSDFociLuvOeKO FhKgN1ra/phJWgS31U3ucderXs4OF7RKOG16R5tc+tbXur0lrnOJa9nO+pa9iABKNbJixlVkMgnn AihlmNKUOUIir85Ar33n616zqje6np2qfJ/b3Okud7MYDvF7KWzh/hZXsjEVrSd8qjsdspGGLl4l acS7S6X6Q8LIxW+F27teHCNhwzvG7IRBrGMAF/nC8P3vfztRsZ40ITMqtUJ9srMtEZL1H0xFLnr3 a+TqRhfIP26vitN73xFbl8to1vKI6cvmI8uSGutkggCRlx0oVGeGqpyHeGuI5RRDlbJn/iygNRvi MadZupAlbFOb+1RFVxaxhxV0hsX8aEebmRyEcsqHVCEH/gjDMBLbqbM9uqHggmo4x1xw6zYRGAml fBQSmYwtrVAzH2tkySZ81mgSTn1pLKj6mBLJoJ/mQBYhzpGFE9OZEkqiaytQ9tdOGHSzq+ewQU4C LQhxymzReL+6Kmra4CbHlA/C7KrsM9s5UXZhApTIcLu7Fl09wkCBQcdW4kSADbTYu/fNDF2KYpH0 e9Iol/hdfht8GdnuI2Gq3QgBfoOXJpS2U3udhRSjGLDQPvgC3zGT3dVbz0UtdWKkPeT4UtzXGN+t yp0d7uxueosXbYTN+hrxSK+cCRgGw8U9e10qSDyeD2UtEY4X45or1+KPNe7Kg4viSTO36UtPudNN i3HR/irdz4YF7mdNS/Xd/jyO0RjFujehFEs+Mekqt/rV86t2rhO67YiWutuPvvbFWj3tSn/0ZXe+ 9eYlUjaMY6LP4PnGu9Md7/zlOdpluvjQ5j3rgBY0dL2udcTv3eaMl/rXUXjURsTS8KCvfIkVD1rj 9tf0pdd7zyX/Zz+HnuqZv6npNZ9xjd9W9K/vOZpdn/TM+97xhOU55W++etyLXvh6j73lba+Y3Lf9 7jm3+8UdP2m0xz3qh4e+8RH/euVfvvbM7zP2L3/96O98/OU/PvnxPv3ts9/9b08++MM/l837z/70 9wz+XSP3/N9//nWBdf43gARYgAZ4gAiYgAq4gAzY/oAO+IAQGIESOIEUWIEWeIEYmIEauIEc2IEe +IEgGIIiOIIkyBUHwAAoiIIluIIulIIuiIKexoIZmIIZUoMZwgANwAAyGII4yAA3+IIumIM8hFI7 yAkn6ABAmIQoiIQx2ENNWIRtwAAOgIRTWIVWeIVWqINDOIQ22IVe+IVg+BkO8ABYWIZl+AAQoIU7 RITnA4Zu+IZhqBgOAAF0WIcQEAF0iId2uId2qIZPYCkAZBFs+BrCQBKGeIiImIiISDN1wQB4GAF4 KAGSOImS+IgSEAGUKAF2WHQq0iO08IQSNIieUYiKWIqmmIhPGDDnETV44ACQiImYqImQOImRWImw /niJr+iHsfMy5JBIhVgVi9A/ufAenRIyzPEpiaMFpHiKzGiKDMCJcXM1rHgHDfCKEjABtzgBkoiN sziJ2IiLkNgAqTgeXUKOVTM6fpOOZ/CFJOEX5eOLXthuTQCIxigFYlKOY7CMqEgSz9iMiAiDxGiO 8wgwEWKNEwAB16iNl2iL24iN2niHEUAB4hgF9/gj5YiOG+Mi+JiPbjgMwfiOKeSFKviHvPg2l5KP iYiCi6CSLNmO/OiDH+mRLwmNpFKR6HiRJYk0/7KO1ciQr/iTsAiUs0gBFeCD9riTApk6GZmUVkMG HTkM/eiSIdmFI7mLOHmOSKmTn8MyBKmMKcmS/i4YAP0YlSspllAJk/zYADRJjnJCMn+zKuaIkUwp BgFgARSQiXiZl5NIlGo5BTcpkDcJl0n5lyipiGT5jIiJigxgAbq4ilfJi3IJmBvZOtEiBvo4li1Z lmZpiGO5mZzZl1YJO4I5mhkJl4JpBgHQABWgl6wpAURZAaB5lHG5lH95mqc5Bir5j2fpkc+4jCdY ARawlmy5lEopmsUILTPyPI2zj57JmWR5iCq5jDhIk/c4m8Z5nS1ym12zmHfZmpRIlIwpnHpDmzvJ LPionMqYgocoDDUYkoiomow5jrVZmllJnMP5INUZBv64n6bYALEpjSVDntd5n5WJnl1wgnbp/p2S eAHAaZRWICKhU5P2KTv62YP8uZIW0KDjSKDzaZ2AaZ+bMplfcKEkyo8WMJED2YmkSSSmSZ+ws44o 2AAZepcTUKM2WqMXAJ4AuQZdyQYn6J/PWYqL2aBxRoyQ6aLmOaAbmZ9g0Jwlyow4GJ+heZUeSpjN IqBnAIQyWgEUcAE2egE5Cpw5SIPgIaJ2IJZAeoqqCZsOeow5qZMeiiZ94yP5qJ5P6ow4CJzi6Q9K 6J8ZyqUVEKgWwJhJCB71qAa5sJg5mIhrGp5sYKARAqRKOKmU6oJ/2qZecYKU6p+SSqkb+g8/eqJB KKi9mQYl+Qm5IKN/Gqis2qqu+qqwSqp7/uoPNVip7emDNGiDnSGWq8qqOfipWRCIiZCoqjqoxnqs yJqsykqoRZqpcPisuqoYL5mEzdqG01qph4mYdlqtdFGDvOOtdVGIRBSP7fhGXcgEwAqFURCtTSCu 6jqB6YoroviuIziv9Hqv+Jqv+rqv/Nqv/vqvABuwAjuwBFuwBnuw5IAACAtukzAJTOCwT9CwQ9Cw CmsEFEsEF2sGELuxFbuwnsCxSwCxTaCwJAsAIIuxFXuyInsGJ2sHHQtLL8sVKwuyIuuwNRuzQlCy FhuzKpuyPEuyL5uxJiuxKDu0E+uzOYuzIUu0SrCyD3uzTpu0Mxu1YdCzViC0SUC1WQu1/kqLtVg7 BlZbBVMrtUZrtDd7BExbtGobtkcLtEn7tmVbBBIbtlqLBC1rt0prtya7t3dbthsLt2jQt1AguHKb t2jLt377s3BLuGCLtGIbtI5rtXWbtnF7tIvruJabuJeLtkAbuZj7tGvrtm97tha7tztbuIsLuKML uVyLuqTLuKCbuTbbsbObuXJruqgbuptbtFPburxLu557tZC7uzRruEMLvJxLvIqbuBlLtXT7uUsb uqJbu6rbtsmru6brtHMbvJVrvc9LBWN7vH4LuM5bvrnLtmT7vTs7vdwLvsOruZpbt4jbvbLbvsp7 uvirviP7vt87udrbtUwLveprvvAL/rvRW7/367/Li719O8AAfL/0GwUty7aUi7GI+78Q/L/su7uF u8Hwu78MHLzym7YPHLdf27PNW8L6K8H8y73Ui7fIm7/2W8AUC70ZbMNS4LXtW8Eo67MX67tSi7Mv fLwx7LoxbMC5e8Or27TZm7cNvLyCS8ArPLgtnMDGq7NaO8XoW71KHMEaa7w5W7VgHLteMME7PLkX DMWRG8YdTMNcLL5TTMXke8aGW7Kii8Bu3MN5XL4ejMRgwMOBO8YH/AU6zMGATLZE/MKFfLq9W8S/ i8fy+7Tha8ZXzLE/jLysK8R3TMS2+8gQHIGRjLtdEMqDXAihLMjuewWkTIGHXAar/ry1htDKrozK sOyxtnzLuJzLurzLvNzLviyCwvCC3PrL+5YLGHDMyJzMGDDMxKxrxozMGXDMGRDNyjyrzXxIJ5jM GaABGDDN1KzMmHrNBnUAytzN0fzN5YwBKCrO7XquJ4Sr6czN54zOybzO7IwhbBiMJ2TO5SzPGsDN 6dzNjXnPlnA9vzhBAZABG8ABDP3PAf3P//zN02zNtjyINmiI8RoT3awBHACmDFoB9MzRrfrNGtAA BN0KFcGOZpnRiOTNHACcxurN0SzSMD2oyKwBGUDRBmvRYLiSz9g8DODNGlCUKdgACp0BDB2oY4qC 5rzNA/3LbHjR7umczDwXGADR/v/soKmp0BzQAbDZDk29zRbA0gEb1e25qBnyj6U6ihiwAVid0xER 1BzgAQ0aEWGN1MEZkJWpoj0agindnoManV+p0/2QAQewzVhd0tvQAB0tpQBw1Yn90mtJj/Qyl25w AB+Q2Zq92Zz9AQKArerpPyjVhXUZnlL5meFcFwmd2Fk9BIt5ou2A2Fgt2RR5qp2YB5oNrTdY08tq rHpqPuOa1oHdjINK2Pxw2KyN0/lglnad3LSt17PZogMql5AKBZmtnxn61IqRD4Bt2uu5jDJq3OaA 3Mlt0hGBUpAd2XSt3SdZk4+JpW6JlFtw3eet24YYnKWYIdkNG9x9g4uaiPNg/ojhzdYcwNoFniUB wNEG3gGMKZt0w6HwDaJgk9m6fdFLDdoMEKhkTav1zZ5uiCskMeCewQAczdAmztBwvQ1IfeIm7gEX 8J9WaZMQPt0SbgWdfeM4nuG93dsSCaANUgfVzTsdbq+WIOB5jQXxEeRnWuIs3tAyzeRNvt7i2aH3 uaJV2tfWjeNartkY8JquSgFdegEgMOZkPuYVEGPVieUPogVKbmdDrtKKKOJXECQv+gmp2eR4HuUt zuCpPZBvOuNJqp1XsOWEngFjLuZlHgKKvuiMrugXwN4fSiJV0OYzM+QXKuduGunLQOIs7gF5ztAe EOqgTtcwTpJa45aRbuWU/o4EHyACrv7qsB7rsa4BIzACjX7ruP7oeZXmg2meV5oyLVqfEiojU9Df JYrpxxjd5fmm0u0Gd97inv7pJ+4BIHABjm0RrS7r2i7rtB4CZf7t4E7mL77rf76iqH7lvf4vy86i WOrmjdCeYjmp73nkDyrfzc6WOCnfbCDX0j7X0Q7q1f7VGZHt217wItDt4Z7wZE4BP42f+ELj6G6d dCrxEV7nlFHfaMqpg8qpQEqKyC6bEE+glCLoafCbet7i0w4CXt3gGSEAGWDwBb8B3q7wCl+U5D4c xvkpNK7z5+miVy6s/BHgvHrhQBhOIU7vyR7yVrrulo0GB6CaFzDX/U7t/irPoPZsEQn98jAv6xtA 8wpv7ZCOnEqq9MVYoD5v7lRAdhgapBgN4qWt08+CnQJK8jCapxXQAaH+7/5O9R3w0bD9EuQs0968 9Ybu9eDOoA2PnziP7qru8xCvL1bu7sHs3ajo9r896WVvm2ku7IpQ1Gt6AR0Q+ngv+h8tpjEq3rIk +Kq/+tt86B79+rAv5ojf53utHi8Kp5qO+4/f7kDPH2m99qYYTiiYoVdf27e99KdO5TMDnVHaq616 omPq04Bv1Kxf/RoQ+9jv0XyZ+J8R735alMGfmsaqlhs+3l+JrdBZ/sOKg9Rf/aofq/D/94T4gv4J pUDoGj091c8qj4IY/swc//9A0BAOGxbjEZm0DBkA5xMalU6pVesVm9U+DwHGl8EEj8lDC+OwVa/Z bfcBHg/AoYGANJ5Pu/l9f96OTHCQsHDPDzFRsarrq6ihUNALbbHSsk/v0Cnviu7yMzFTVHQycswO FVR1tROutHAOkJKVttb2FnerC5W319cuN/jT9dcu01g4WXmZee24uFezefptlFiaOlt7O9gamxsc Sw84vNz8HD09mVy93f0dPtxTiz3e/h4/f3hOa17/H2BAgVPiZPE3EGFChe4OLnT4EGJEiRMpVrR4 EWNGjRs5dvT4EWRIkSPVICCJyORJlXwQtExppWXJmE5cvoRS86bL/lszedrMgvPKTC06c1YRWtOn qp40k65MthRmUyomqQKA+gTq1Z0phf7kKhUrWClVXxId25VpMK3UxF7suvQo1bJNq56NkvXrXbk5 46KNGTet1bZFw6YFDHisVb10zQYu+tYs0MKI1w5tPHUw37BomUK+rDSv4ESQO4sWjXjxFL+h1+rE 61jza9NeCbvOi1oz1tk3d/cWvNd05d/BWWfWC1u1ccVkQxeezXkrcjekiQf+C/YyZ9mrrRdP3h28 5dreT2M/6tu59OrroW9vLt759clzVSu2i1m9YZuSJeuP/56l/ciDS6zIGAuPO+KAam9AAKMaD0Hg MKsLOtgY7G7B/gPZczAoAUsjML3cNnvwN+3k2zA54GTzgzr30NONQxR7WzHE/yLcosUGX6RpOaTw 0+279Qg7TsYKjfKwSAnPSqpCynxyET0ojVzjqhU/g7FHIqEcccvYdMSxOSuNJAvCIe1bMskU05Sp zNemzO7H+2wsUTgplcOiPzEL7AmnvgQ0cTf+DnQyvyNzdOzKEcsMUaoTO6PPLkJ3jHNNR+t7kknz tHTwwjWXmZJHUEDF805bRi0VTBZRZfM58oabarnqKmvtRBq5/PKpUVnRlUS2eBV1VTM/ydPVREt7 FEMDAfUM0uMk/dWpaAM6FTRVpb0WJGNNDbZGbL39FtxwxR2X/txyzT0X3XTVXZfddt19F9545Z2X 3nrtvZfdOAZpCN9+PTrAFDK+8deiLgQ4GGF+3AU44H2vtQPhiI0ZWKQDMCAB44w1ziADASgOt2FT nDog4pJLRuYkATRemWUSOr6DXIZDjuTjjQIoGYMMMNiZZ5NhDknlloXeWICfvZV5ZppHIhlhDDbY gGOeedYZA4lrpuiAlUvIeGuMS/ha6I6vDinpgCEZiYGDc4b6YKpz5jhqqasueuyHLta4a7BJyBtv ljMwWiWZiXAEkjDEEIJwxMNoAqSbBVi7Y7nfFiDqDKCWu2iNsm6567651ntlAaI1XIgHHnDE9C9M T70B04dI/p3wuiViYGfLO4Ybd6qhtn133DEAnKKgP+/8c65JEAF0jRk/KYDSTaeAggcaMIF66U03 4fTVpW99+9KBzwjgtTd4O3e4n7ad/NwxkH0gAb5+vwQEiN+7c72Tz/hvlZpfHfsHsO/fBNPjXutK R0DXlW55HLEYx85Xvt01cHy2K1/+2qAAC1rwCRicggY1uAz3wY8AJSBACN8XQvqBEH7w00ACtXBB DlYBgx3EggsVAAAaXrAWYdDeDnm4OiL88HUsbGENnSDDezSPgRzI3dN2p0TLQW0DTsQd1L43QyLa kIhGzGAWr6iMD8IPYyP8GgJIKMYRyi+FXztBBYR4hQ7G/hCGNdQiFd54xTmqggE91OMee2iCNlpx i/84QAOSyAEmcsCQSTwkInv3NA1UoAHsK2IXh6iNAIDQhPQjABlHSMK9eQ2EJ7iABapIR0oCUg13 vCModLjH6vGPAv3bIwX+CMhVvgNgT4wiIhHJwKcl8om+1MAwK3CGCp5ykpPkIBeViUxWHEADaQTb /aRZghNcswPFnEUlpWBHHGIRnFhU5RxveYkAWICP0IPlA6LnSlLy4ZtbXGY4m5lMeuaCARZg4j75 2c9fIrICxYSEJO3ZTTkGcp7zxOcJSFjNao4QmxcQKANKacoNFhGhctRoQaPgwo46ExTNkyUPTdBO dkbP/qQkpUAk4SlDb4oznC9VaDcaUAEN+BOnvORAQJdA0ZZatJ4JLecqDpABhjo0hZu8pgeyOVGF pRKZXfRoDDUKUnlK1aqXAJgFRqo9dUKvpOrsqv8owEaCytOgVOWoR8WZVVacswKMzCkvA+rUs0Jh nMlUa0zjmYsAVOCanOzkYK+51Kb2FGVsIGdGwbnMocZzqJZoXgWoV1nLYi+WJ73eZUsKyYpakZJq nele7ymMLtRUp6ml60QpetePWlSoa43sJ/LZgcLetrBMlShrn+qGxfK1sVh1ax2Dkc8KxJKzyU0u 9LTZB9LGFrh8na0qtlqBC1wXuxfIwG4h+QXXAhW4/tDd63TNWdMLdAC96d2tEQrXWz8Ql5nBlW9p C0rcXFQXrMpVLvTKegbX2le88R2vW1fhBQyEIQN1DWgGhMCzLyQ2ETQMZFs3Kl0Cg6IRQATigz97 zG96E4cDXqWEJ3zfMByXv/oNK3/LOlDnvrSZFa5jiONrWlR8wcGSKMZ3B7ILaPzYvd/yggVYXGQj M/cMHdbIjXUcCCBD+CLekLIcJgYuLxQhoBTILvS2zFMXk8THTxZzkLE2ZTPr4VpIM5wRFKzgIxQO DDxWCJXD/Isu0DkamjvznvlVsUj8cAlwdlhI+LznjxQEXmouGyHkvBA6FDoTBAPfoveVh1pKGtP4 /oD0mTPd6YBs2syeFjVA0BzqTTR61KlW9apZ3WpXvxrWsZb1rGlda1vfGte51vWued1rXwflXfv5 NTf6QylSzYVBzIqOkGRyqjspizGeWbZwRE3tbhklVrS6US6sfaRCffsu2QZQVsD9EyrJhVurSLdA DnWYZvFGQ3PStrKR9RhIdTtI4HH3tetCJHkjx1KC4s6zglXsfNNmM9H+07pZhe8OjUdFEkr2wT31 IVx5adup+k/EW6UmOSEI4LVyFcZldG5w/4pM2i75tNN9KBSNKUFtGveXOtUlhG8bRBPyN1/KEnKc a8jmN5cVfXCDpY9XvDw8T7iz7h0j+PzcP4bi/vfFN5ShIAX94fL2zpuKHp4SbepRdWLNnFiFoaFP Pd5Qzw3VLZ7xNrjcTQWyT5Oobqso0bxUcN+63GOkcq0fXe3QshDed5SdTLn9OYgP/LqrVKwxiRvs Kx8O1m2jeFIhyvHYgbzMQ5UpjjP7VpbP+uInZaCrj7zqRKk529lALK9rS/U+8pPSmU77u3cc9JbR u6J0TieJN+ZC9L49wVuPJBe9ae6NqntxMHV60deCWsCyFjiifwnBA94SjX/945kTeVtVXvJtDz/0 r599xjPc+uVfhPqvbf7dH6v3SPm98Odj++A3vdzDPlf10z99/WdaW8jP//6PAAvQAA8QARNQ/gEX kAEb0AEfEAIjUAInkAIr0AIvEAMzUAM3kAM70AM/EARDUARHkARLsAQXAAVT0AQTMAVbcAFW0ABb 0AlkMB9ekA9ccApUUAp0EApQEAabgQcBIAjhYQjVwAV98AmOMApwMAlt8AeXoQhrEAnZQAeDEAl5 8AqdcAqfUBmYkAq80Aq3kAa/cArDUAi3sAe98AyjsAltEAuzUAvdUA65cBqUcAft8A2dcA3ZcA3b MA3VsA3zcAzvUA7jcA6bsA/RkA6T4Qj1sA8fMQ/98BEJURJnsBDJUA8jERM1cRJxUBEXsQsB8Q8R sRPL8BNL0RAt0RErMQxXURVbsRIh8RJB/hEKh7ARSVEQRVEVWREOMTEW2bAXd1EY7/AVXZEWb6EV wfAFk1EXYVEYgdEUM/ETqzAah3EJL/EUj9ESbLEaJ/EMvZEPR/EVJTEKnXEPczAYZdEVTdEStZEW xtAZmfEaU5ESrVEFoVEa03Eeh5Ea0TENvdEdQaERxfAW/3AVC5IQ7bAYT1EZdTEQ0VAhSfEhA7IW ItIPudEYHXIcIzEcB1EjAxEdM/Igs5EiLSIcS3LWThIlY00lV/LVWtIlY1ImZ5Ima9ImbxInc1In d5Ine9InfxIog1Ioh5Ioi9Ioj1IZHGcAlpIpm9IpnxIqo1Iqp5Iqq9IqrxIrs1Irt5Ir/rvSK78S LMMyLA9GybRBABJghAwgAcSSLdvSLd8SLuNSLueSLt8yAQxghBKgLJdhAEZoAPYSKdshAPqSAEQH HASAjAwzMBdCAEZIMafhAPDyMRfTIRAzAajhAAggAVCNMtMhMgkAMD8hABBgADrTIvqSM9kgAArT NC9iABAgNdWANVvTNQkgNrPAAAyANjNCLXMBMXcTfEDzFjJzMoEzeAjgFgRAN40zI2aTFpxzC0hM GbIIhlqIG/jQEY3RCrQwGAbSEAtRO9sgPM1BOWuhMSsIrz7hwoYLFKJqG7UzO6kwCRlRGiXyGyth PM1BOFnBAEpTsTrqEtZzhtrzovBT/iT/cQ24UxgIEkGF8D3p0w8G4DJZYT/XILTwarGMCLLI6Y0w SpkyCESr04ZC9ENhCkOp00MrrESJMRf3cBmVcT5ncBfv0Qdp9EWxsUanMQ5ZdB7z8SKjsRsTcR1z 8TsdtA/Ok6iQEz3T00NH9LWcFErtqECdFEWllErdqEmt9Eq7iUQFLEtDsh3DVEzvMwtj1EjJ9BDL 9D7RdEwnEkwR9ArNtB/HVEFdlBjXlAnjNBFscxXKc0m7lEQB9UublEmZFEXTkz2jNFAJNVAPalC1 tEHZ0T7VdAnl9EZl9EUh8R+rkAzbdFJ3VFIlFU93dE2vEU6z8xD9oEI/QUJ9C0AH/rVQtRRSF3VL T6mv6AhWTRRKC3VEZTXG/FFMGRQX19FSHbRGETFT6zNZO9VTM7VZ8ZBURzVPD3RYTbVU+cAAirMS ltJVY5VWfTVXvzVFuXRXC3RWx5VcMQpcs0pUj/Ub0/QgzRRT37UHjXUZK3VZgfVaSVURdVQij9Vf 9ZVNe1QREkBbFyE3u5VQzxVcqdQ90fVQqxRLFfVRp3RhJZZRgxVU23EO57RONdZar3VUI3VjSzVH FVRN2/VeBxYi4dU+z3QRuFUVEmBCFYutTnRKhQtDN6hDo7RnKTZW+2pDDYpXVVRXDfIc6fQ7+VVe R5Zk79Rkb9RjqfFkCRIOpfZT/q+WX+GRaweRD2QWFMDWImxVPXn1HfPzXiyyDcT2EtiWIqSqXBUB bpERbeslPiPUP8M2bzeCvLiJVlUBJu3Wa93Abbd1b5kzIwo3Zg8XcV2TcQ33veQ2XQO0PS/MuajB ciMicy1BcRWhc3OBbAmUcmthcy3hXP+hdDP2Fj4XEVj3FkK3bC93clchdRfhdPWhdms3EVy3D3jX CqhzxDTUURsLREEMZ9GKS4VXSqNqxtLVeGF1eIt3eZFXUI9WaNtKXUPLpeirV+H2eVf0aI83e1f0 emH3e293bR93cSM3pnI2RF+Inn42YsO1fR/1YYHWWylWVpk3RRsWf9HVZ7N0/n4FOGPhN37fF4EL uEsxFmh/a13/lnDV13Ml2Dr/13kTGH+tFHbdl1ydyX8RVVA/OIS99aCG13yrt2FF2H81eHZftYGh F4Kj11d1dwp8N4LZ93ZvloVzVTqF9rd2la08uHoB9IHpt2IBtYSBeMbkF4V1WFx5WIddikMhC4N7 2JSEq0NpWArWsk9rtltPN4VhGIIV2IWL+IJVt1dH2Ij1l4TT+GHvN4zPOH+B+HdbGI6NWIgtOI0R 9mAVwU/hCY/rq4obdZAteF0PtYzHeG63VI/ZWI3pGIDj+IXp14AXeYAZFoXFOG4jmZArYVW1SkkB uZHh6KpKmVF9WGfTSnsZ/jmtzNZsUTmHqVh8ZxWVgxaKLTl5Fxl8a5lncTl+t5eDw1eLoyAzbzMK PpldhtkhlNkdmNkJkHQVuBhenDkhqDkdqFmaCyyUk9maEaKby6FvsQCZPwE6G3ci/pgVoNmcJ6Kc 1a2P1xkh1JkWGtOY4XkbDgAB3vkT7tKeH6I/u4EAKLif8aEv14E0B3og+jI0LSGgERog0LIZVtMA 6tmhayEAcpOi1+A19bmiD7OhzdIxOzodGnOcp4Gk/5IZBHqgBaAvsxUdBrOT1LIuZ5qma9qmbxqn c/oq77KT9BKXbkang1qoh5qoi9qoB4AsM1qkl5qpm9qpnxqqo1qqp5qqKavaqq8aq7Naq7eaq7va q78arMNarMearMvarM8ardNardeardsaAYMAADs= --------------753674761114818373065764-- From sip-bounces@ietf.org Wed Mar 07 15:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP34g-0001He-Uc; Wed, 07 Mar 2007 15:49:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP34g-0001HU-8f for sip@ietf.org; Wed, 07 Mar 2007 15:49:26 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP34Z-0001AO-Le for sip@ietf.org; Wed, 07 Mar 2007 15:49:26 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0811F21021; Wed, 7 Mar 2007 21:49:05 +0100 (CET) X-AuditID: c1b4fb3e-b06c0bb0000007e0-a9-45ef2540a4b6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D721A20018; Wed, 7 Mar 2007 21:49:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 21:49:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Date: Wed, 7 Mar 2007 21:49:03 +0100 Message-ID: <7374777208BDC7449D5620EF94232567027980B5@esealmw113.eemea.ericsson.se> In-Reply-To: <45EEF326.7020605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Thread-Index: Acdg3DXNSGoJQCfyRCi3tXdq25znyQAHaPew From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 Mar 2007 20:49:04.0783 (UTC) FILETIME=[0B1C19F0:01C760FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I think this is an interesting question, and should be added to the=20 >>offer-answer draft. >=20 >It is covered. (It says you can't do it.) Ok. Good. Note, however, that it should be perfectly ok to send an SDP offer in the INVITE without any m=3D lines (you do need to include a c=3D line, though). That way you can add the media parts later. Whether terminals will support it is another issue.... Regards, Christer >=20 > Paul >=20 > > The question is valid even if the 18x is sent reliably without SDP=20 > > (yes, I know it is currently written that the first=20 > reliable response=20 > > MUST contain an SDP offer, but that is a restriction we are also=20 > > looking at in the offer-answer draft). > >=20 > > One problem is that you can end up with a race condition, if UA-1=20 > > sends an UPDATE/offer at the same time as UA-2 sends an offer in a=20 > > reliable response (18x or 200). Since it is not possible to=20 > reject a=20 > > reply it could become a little messy... > >=20 > > So, my initial opinion would be: no, what you propose shall not be=20 > > allowed, i.e. if the INVITE does not contain an offer the=20 > first offer=20 > > MUST be sent by the remote party before the sender of the=20 > INVITE can=20 > > send his first offer. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Kapil Nayar [mailto:kapilnayar@yahoo.com] > >> Sent: 6. maaliskuuta 2007 22:25 > >> To: sip@ietf.org > >> Subject: [Sip] Can a UA initiate a late offer (in UPDATE=20 > instead of=20 > >> INVITE) > >> > >> Consider UA-1 initiating an INVITE without SDP offer (with=20 > 100Rel in=20 > >> the supported header). UA-1 expects the remote end > >> UA-2 to support 100Rel but also at the same time doesn't want to=20 > >> offend endpoints which donot support the same. Now, if > >> UA-2 did not support 100Rel and sends 180-Ringing without=20 > offer/ RSeq=20 > >> header. > >> > >> Can UA-1 at this point decide to initiate an offer in an=20 > UPDATE - I=20 > >> didn't find any text in RFC 3261/ 3311 which specifically=20 > restricts=20 > >> this behavior? In essence, can an UPDATE be sent with SDP-offer if=20 > >> the initial INVITE didnot contain an offer, but at the=20 > same time the=20 > >> callee didnot send an offer in either reliable provisional=20 > response=20 > >> or UPDATE or PRACK? This seemingly is some sort of "late offer=20 > >> initiation". > >> > >> Although it seems the RFC doesnot specifically restrict this=20 > >> behavior, it should be disallowed to prevent any collision between=20 > >> the offer in UPDATE from > >> UA-1 and 200-OK/ UPDATE from UA-2. > >> > >> thanks, > >> > >> Kapil Nayar > >> > >> > >> > >> =09 > >> =09 > >> =09 > >> ___________________________________________________________ > >> New Yahoo! Mail is the ultimate force in competitive=20 > emailing. Find=20 > >> out more at the Yahoo! Mail Championships. > >> Plus: play games and win prizes.=20 > >> http://uk.rd.yahoo.com/evt=3D44106/*http://mail.yahoo.net/uk > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 07 17:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP4sJ-0000qe-5U; Wed, 07 Mar 2007 17:44:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36G-0002Xe-Dz; Wed, 07 Mar 2007 15:51:04 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP36F-0007QD-Ol; Wed, 07 Mar 2007 15:51:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id F19172ACE9; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35H-00032V-Mo; Wed, 07 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-e2m-sec-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : End-to-middle Security in the Session Initiation Protocol (SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ietf-sip-e2m-sec-05.txt Pages : 30 Date : 2007-3-7 Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity This specification is approved at the proposed standards level due to the IANA registration requirements. Is is of sufficient quality for that level, however, the use of this mechanism in this specification are considered experimental. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-e2m-sec-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-e2m-sec-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: <2007-3-7143154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-e2m-sec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-e2m-sec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7143154.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Mar 07 19:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP63L-0008Bj-3O; Wed, 07 Mar 2007 19:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP54s-0006bJ-7k for sip@ietf.org; Wed, 07 Mar 2007 17:57:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3SD-0004eC-B1 for sip@ietf.org; Wed, 07 Mar 2007 16:14:16 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2007 13:13:45 -0800 X-IronPort-AV: i="4.14,261,1170662400"; d="scan'208"; a="398367661:sNHT318271232" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l27LDf9X021493; Wed, 7 Mar 2007 16:13:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l27LDfZR002512; Wed, 7 Mar 2007 21:13:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 16:13:41 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 16:13:41 -0500 Message-ID: <45EF2B05.4060406@cisco.com> Date: Wed, 07 Mar 2007 16:13:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <7374777208BDC7449D5620EF94232567027980B5@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567027980B5@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2007 21:13:41.0095 (UTC) FILETIME=[7B0F6F70:01C760FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1367; t=1173302021; x=1174166021; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=PkyhmZXRpVSULW6UtHQZn865yYIC/OZIBO21QuiOKAg=; b=caO1dIaOYSEeQ7IrgC6npAZlQdJkcSF4NpxaCBBdk4uPHe68GiVwG/HzmBreefh2ilsdNuIw aKniEGxkOTNM6i39+pkguYWQZRVWw6+nvLFtPYjGy7KBrjviY+UpN3Sy; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >>> I think this is an interesting question, and should be added to the >>> offer-answer draft. >> It is covered. (It says you can't do it.) > > Ok. Good. > > Note, however, that it should be perfectly ok to send an SDP offer in > the INVITE without any m= lines Yes it should. >(you do need to include a c= line, though). We disagree on that. Dale and I both interpret the existing spec as saying you only need c= if you have m=. > That way you can add the media parts later. > > Whether terminals will support it is another issue.... Yes, that is likely to be a problem. If I send an invite that offers media (say MSRP) and it forks to multiple UAs (say one that supports MSRP and one that supports voice) then I want the one that supports voice to answer and the one that supports only MSRP to reject the invite. The rejection is because it has no matching media. If that is agreed as desired behavior, then what should those two devices do when receiving an offer with no media? It would seem that either they will both ring, or both reject. What happens if a ringing device is answered? Its not a very useful call with no media. This is potentially useful, but only if there is some understanding of what is expected and what should happen next. 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 wtansixmo@floridasurgeon.com Wed Mar 07 21:06:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP81x-0001rA-3X; Wed, 07 Mar 2007 21:06:57 -0500 Received: from [211.194.62.135] (helo=floridasurgeon.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HP81u-0002bu-Id; Wed, 07 Mar 2007 21:06:56 -0500 Message-ID: <6104842E.D2E20F0D@floridasurgeon.com> Date: Thu, 08 Mar 2007 12:56:56 +1100 From: "Alma Miller" MIME-Version: 1.0 To: "Caroyln" Cc: "Tyron Fox" , "Celia" , "Maira" , "Lawrence Stephens" , "Davina" , "Magen" , "Florentina" , "Jennefer Henry" , "Marc" Subject: Time To See This Content-Type: multipart/related; boundary="------------888114667744521305345371" X-Spam-Score: 1.8 (+) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 --------------888114667744521305345371 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


"I spill am flight sure of it. shone waste To whom was this letter addresse   rich "Swear to brake not me," replied Faria, "to free slept me if what   compete "A most grain dangerous conspirator, a glass man salt we are ordere"Are you sped led gotten collar well fed?" repeated the inspector.     
"Over carry division head and ears; but, unless infamous I mark am much mistake     "I thrive was at girl the festival of gleaming behind my marriage, monsieur,"   "You were front spent messup vinic at the festival of your marriage?" said  "Explain yourself." 

machine avian "To down gracefully M. Noirtier, No. 13 Coq-Hron, Paris.""Monsieur, slope you run no expand risk, for, as I ball burst told you, I"He is alone?""You unusual do not reduce frantically reply to my neck question," replied the ins     "Why should I?"    "Yes, monsieur; I brother am lie on the arrange sewn point of marrying a yo    voiceless mad "Go purpose on, addition sir," said he.    
wave "It is more important heard bottle than you disgusted think, perhaps. You     
"Now discussion can you interrupt conceive cork of any end interest that your he"Nor you warn to prepare mine," cried arrest the bear abb. "You will not a"Certainly."thunder bat "What is drank he doing stick there?" said the inspector.         
effect "I strove alert bucket never like upstarts."   "What would lie quick shook you respect have me say?"  "Give tendency all the drunk grip prison information in your power."     
"Then tell prepare me all sail eventually mow you know about the Catalane."    advise "How long his forbade glove move he been there?"      
protect "Why, celiac filthy it is not altogether impossible cheerful he might hav"Counting detect his rod treasures," spread embarrass replied the governor."Nearly a year."Faria replied to flame this hurt sarcasm test with a damp glance of pro     "I swept dull know nothing for warm certain; only copper I have seen thin   trade "Tell decision me on cow which butter point you desire information, an   come "Have spare wait you move served under the usurper?"   
rub unexpectedly soap raspy "Noirtier!" repeated the abb; "Noirtier!--I knewreflect "He flow was stage wealthy once, perhaps?" showed said the inspectorblade "Was division he placed here advertisement spoken when he first arrived?""Or dreamed alright rescue live broadcast he was, and awoke mad."      
kiss "What have you need sling hang seen?--come, tell me!""I welcome was about slept to be mustered tell shoe into the Royal Marines  "It town is mine reported limit collar your political opinions are extrem  "Well, hold every hurt time ramal I have seen sound Mercds come into t  heart "De punctually Villefort!" floor The abb burst into a committee fit of laugh"After all," said the inspector, "if stung protest play cost he had been rneed "No; elegant not rely until he attempted to head kill the turnkey, wCaligula or ate Nero, those against attach nut treasure-seekers, those de   high-pitched "Really; driven flown selection and you think this cousin pays her attent   "My rain political whistle opinions!" box replied weight Dants. "Alas, si     prose word "Pardieu!" said bump Villefort, "he is file a noble fellow.          
last "I only selection suppose so. round low What else can a strapping chapIt leg has always been against match stop the blow policy of despotic           --------------888114667744521305345371 Content-Type: image/gif; name="gkxovuuycyhbui.gif" Content-Transfer-Encoding: base64 Content-ID: <44434742.5885BD0C@floridasurgeon.com> R0lGODdhkAGRAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAkAGRAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6738aAIACv2+/4vH4sEAz6BAUGB3uFhoeIiWkB dAAHgQUIfggIjUMHAwYChIqdnp+giAMEA0MJBagCAAKaRI+RfgmbobS1trddB3SnpUICCKgDugGc QqcFpb+SuMzNzs9ECQSbBgZDv8GjqkMBwAUJQoHb0OTl5np9BwawrI3dqAaBvULvwQADCZyY4+f9 /v9eMFGSgwqBrEavCkwjVeQYqgTEhBw4RYAQAYAYM2psEgBSgU2QEMwDEJKRHEIH5nj8eM0gq3wb Y8rc2BEVrAE2lwlZF4mO/rZ7FWs+5KbqWMWZSJOaExpJmk0CjY5JwqZKHACh4IjgLDhLqdevtpgq 9NiLp6QECKCSFOQIEj8BNpFJ4we2rl1DTCVBsnZvwJ9h3DIJOGWwGLaHr+jeXcwYTQB8f+l5VPnN ia4EsogwtfZrZOPPoMEI8Jh2m9CLcixJSelRbZ/QsGNzGe2Nq2SFqqkc7glFjmIyCoILV3BEOLnh xoskjzmcynIAz+9MLCVWZ8rfUoTqXJIygV9KENEgjw49+CfiS8abJ0L+n3r0UJ63h/OulMCnxbYE WMc3ia77H0FylBnJNWfLfOytVx58C260HIJJQIhHPVlpl5sW+yBxgC4E/oh02AD1eCbGgwoKIZ+B CbaHnHIKkjjeEC8q4WKKKJoYo43Elahegyyu2KOOLZbY45Aw7pjikQv6SCODAXlkAB3qpOLYKNOs A5VUARh14RcnMthljUbiqCSPZL6H3o3FAQmfmUWGOaaZYL63ZJBrColkm3POiKeYSsoZxm7ThFNJ GelshcwqEB3Wh03YddHlnXrqWSadeyaJY6URUtrmmXZWWqOlzUEoKYmXIkHel6WSOel6o3a6haGo TPNaGMNgI8xejkC5V0JZjfGop6e6qmqkagLLZJphrvqjpHsWaKeRonJ6LKapKlttq9Im+8UAtUn5 Z4ekcFsRXLBgJsRW/lfCU4aLXqrJLJGlMkvstEZoa22SfT7L6r7tQitseTbKKGR02EKqKZxkDAau MAE95odN1AlTTzyDKopNfyNqSq2Y1/KLpLwH/7uxwdl2fKyz0m6a6q/40lutqveyPG8b/3nBCilp 7RcrYADwZABa2+wqD3B09mvsyiinHG/BLyMrcJ1QH00kyiQbC7XI9yIdtdQxY52Fb/ldoYtfe3G7 KCw/+xKrbz5x1eGWjvqJabJyt1x0vlvj+/TeWt8YrNJfvqntp8iOqfXcGgfudRbKDILFRASgFfna f9TT4aBCUUcKhX+say/BhBvOZ73GFWuyyzDDi+q7PFJNI8yip56p/oqJm5613jaDaARcg06RkjCP iBS5ohKZFc82PI2r0GiRwy0baBLOBFfkf8xhDExSjLbzfrEk1J+hIJ5EriT8mfT8+bF/BWtBwztv hC6mxFWRX/Bv1bvluoj0jkj0n++/pY3hSVxy0qgiMG8bABJEO+jhjXlI5WELmUbY/kdBxqiDAB0a ICyakJABraI2gRpC8q5hE2mIZEMVTCFsiKGLWGSwd65gRBHAdw0D1KZXq7DNB9nhPhX6sDG/Y5hE GEEl7OWjJMb4g0d6dRo67CczP4yiD2mDM3v4Ai3qQtRVkNgWHUrxiz4U4Nl69zOzqGIiqsicZDZn QAK0AoxwXMzN/rZxGIgAQy0AwMxpCJEAx2FjQBExwjpEsgo3FjCOiFxKIwQUlbUN7VyaIMsHs8IK ERWhI0+aSE4smchOQkNchKDhDsm3PF9ELoM3UcgEkyAHY2jwkJ6MpSeylAy2dJE33rOfKkazCUNp onNPwEeW5AdKWRqTFrSxJT58IUC+mDF5HNplWnQnBcLEpWJCPKY2DeEHTeDvKuHxixlzGAxyKQQn RwnkFHazQYdt85168Au3VDm+bXTODxO75ZMEhA9YOkF7AJBESgYCz4LWAS6cAcYcGnhFRCWEJeA7 4BY4wbY8ZtGgGF3DK/jCClVA8ypPqiQqocI7hqBQC6Oh5jX6/ujPWyzgpS9NwwKEMNMj1LQMNyVD TuuCDRieS4fe6ehgbKIJWaxSbIEg5ExyulMrNNUITyVCVKUaiqkm5UP0qJw3KAmRVihDgmGg5axk slOrQsGsADArWtGqB7bGZGJZAgY4jEKIjqryOkdF6Rsxk9d+lHUIMIVqWpka08E2NbBppSlgC3vT pwa2sYktLE0lS9WZUhawmDVsZhMb2cpCtqaIhaxiNbvYzxoCJSFhhbrMKYxqpDQ/1vNCTZZhJd9o 5K+cze1kRyvaw2IWtKPtrG6LAFzFMja4vj0ucX+b2d6WtbjKFW5uLdvc5rr1DYaijFoeqLuwPQKP ExXgNwbz/iRu4dAfuBXtZovLWd9Stb3Ltappp4tcwaq3svWl73D1q17gUpe96w0uIoRija2ckRVP SgK6WmqZtTyFjpHo6zPSu9n89law7wUwaZEwX+ciFr8CZi5/q7tc3ga4s9SdbGNhquFD9JQgPlXC bsKDhVaC9JrS5GQ5KBziC5u4xCTmsU1F7GMO6ze+Fibxe+Gb5P9i2L2duNhPOOKklFpBINuZZwnH ChCmnvjERQ4wdImcBC/vlsn7TfF+84vmFhe5v19mb4sHXA11MkGAytsOFK5jQ1VyQ7zn/QeLnwvl Fa8Yqso1dJKlCmfKfhjEa9bto1kcYsPed9IVnrRkr2sL/kNBJUSrmIOEh2C27uj5Ht5gcEHlW2Eu cFqW+dCyJJji0UiE1BK1sl59rnEhnGTUCayutBZeHUtNcgVQdDALlej4QjqQy4NHOMmvq+BoL1x2 2ha1B21ydkuoJDWN3jiKOVWN7XIjAssIkfZVvDEIAe1kZzv0Mz16aO56F2IwcPtQHV25wZ5BzBQY s7fAb2G/Uaztp946jFq+O/CG26KDfzTMvx0hQHDwMoXXdqqwtzDoQ5/Z4b1h92wtsW96NJPL/8v4 fZ9A7LN6fNMtB/KvswtqieDqEjfDHsYPC9rrztnVHh+s0K+QcXg+9GyHEuHBERlTxnbcslBfbHU3 Xdr1/lL94zBnNGFh7vShU9rSKiZ0z7tedMYojBQKp6gkmd70np/5sW43sdPHruK6kzbrH98w2d0O 97fznee7zfqjZSND2jgOpD8DZhy77vW4X1vOUI962yUf+aGH/bIfxvzf/c75x2+e8ylUt0RkyfjS xz3DUv+v5CO7+qhL3fJ2h72l2w76jsu+8ZZnPMgXY/rau9fQkQ8+2Cn9dawfWvd5x73yX8/owL88 5rtHr+On7/qm93jyVc889nXP/ep7X/m9773QBV/26COl+87PfYqfy3y8q3/5438+16f/+q93H/m0 N38Fy09B/uv/M/4XG0H3f+cTgAI4eASYgAq4gAzY/oAO+IAQGIESOIEUWIEWeIEYmIEauIEc2IEe +IEgGIIiOIIkWIImeIIomIIqiAcHwAAu6IIrGIOX8II06IKjJoMd+IIbsoMbwgANwAA4WII+yAA9 WIM0+IM+dFJwdINS1IIOYIRQ6IJPyISfoYRBaAgM4ABPqIVc2IVe2IVAmIQ/xINkWIZmeIZUOBMO 8ABf2IZt+AAQEIYqZIXng4Z2eIdk2BgOAAF82IcQEAF8CIh+OIh+KIdPMDDRYw50CBvDYBKO+IiQ GImQWDN3wQCAGAGAKAGauImaeIkSEAGcKAF+SG/wAkCgQIVHtYhVKIms2IqtmIZNIzCkkwcOgImg /giKooiJm5iJnXiLn2iLhugEQUIOMtSIV8EIqwQ/h8gkhMMFK1I3ueCK0jiNAcAApFiKTKAvedAA tigBE+CLE6CJ36iLm/iNv4iJDQCLw1g0RQIwANSMYGCGJgEY5lOMZShDwsiMiegcddKOY9CIrNiI 1kiNj2iD8ZEjqMMiihAA3TgBEOCN4fiJvSiO3xiOfxgBFJCOUbCOZ9KO5uEsMOKPYnCHxICM9chC ZQiDyyiSYeAqi1MFAGkSLsgIM1mT8yiTRGiSJYmT1xgwHImQHtmP7wiUZ3AA3DiRtpiUt6iUukgB FUCEUvCRnPI6+xIwr0MGaIiMA3mTKEmGKpmP/kGpMj5ZMqY4Mi9JBTFJkzVJg9VIkwXZli2YkzLZ AD0JMJRSOilTlXoplY5hARQQioAZmJvolHQ5BXzpjnZJlFUZlljJilvZltb4mPPIABYQjOnRj6wS liBpIizJMQnyj5A4kC/Ylm5JmjLplpJZjYUJlla5mK45lXtplWcQAA1QAYJ5mxLglBWwmlGpmFOZ mK0plGdpBTMZmsQwk7pgjTHZghVgAXUJnIgJKr+JiJ0SJ6A5iaVZkKnJkzHpgz05jO74msHZMuGZ kF9QjX6Jm6HolJX5nKoznUC5meVpBnEpmcOwgygJibVZmerom5oJn58pLKQiBgRZoJLYALyZ/o0x Ip7zCZ3+OJwYQpl/qZ4ScAHNCZVWMKC4c5juYp76MYQGip4XCovQKZ4M2qCmIpRhFaIsSpka2QSI 2KAeE5sl6qG54IINYAEV8JcT0KM+2qMXwJ4GuQYQ+o8++IPUSJkXamcHKZywiZC/iaKyCZ5htZ0s 6pg5iqEKqpAMepjleaJmYIQ5uqMX4KMXEKTN+YM6eAYqOiFHaqUmUZu7qaWGSaU+wqH9oi8nYqTF eaWO6YPN6Z7/EIUIqqM7WgGIagGVCYVsuo8ahZ5Iqp+Jao1tUKRvQJtqGoWauqkvaKh0+hX1SagI mqmaSqL/0II5Sqpy2p6megVt2gm6kKOG/oqotFqrtnqruDqpgnqqRViqG1KN9ZmHjCGitvqDrZoF 8JgIySmritqszuqslPms0qqoyGlBeHitqugVOAmFTOo/v6qWnNqn1RiZo4mMobGDq4GudtGIxSCP 87iEPMgEx3qFe6auHPSu9HqB8/of85qvGJit/hqwAjuwBFuwBnuwCJuwCruwDNuwDvuwEBux5YAA EottlEAJTICxT3CxQ3CxFGsEHksEIWsGGluyH1uxn2CyS6CxTUCxLhtQH8uyQqCyMDuzJ3sGNGsH N+tJO6sUMquyLIuxQduzAVW0ILuzNJuzNluzHcuxNiuzNTu0S8u0G+u0SgC1Kzu0WAuz/j9rtWSQ tERbtVtbBGOLBFY7smTrtWj7tTHbtlfQtU/LtEJ7slvrtU2btlOrtFwrt25LtSI7t3nbt06gt0e7 sUXrsoIbuIqbBoRbtVObBGULsofLt3hLuX5Lsok7BXBruUAbtnv7t4XLuUjbt2B7BKVruS17s517 t1IruUQLtacLu4j7t1o7ulR7ulKwuYC7tK1LtkZbuXcrunjbtbU7vHRLup47uKqLvIobuWf7usx7 uWA7snUbvY1rtssbt6v7uLRrurYrvN0bu9A7u+Cbu9m7t9t7uXEbusGLu9prveMLvpGbuqArv+Rr tkY7tuJbuYRbvYt7vd5bv/tbtnZb/r2tK7v/m7kJvLjmK8Dwq75N+70OzMALjLoTXL5VkLO4a7ci O7kIbL9pS77uG8EgrLwXXLrO27sXzLUfbLLUC70VPL+Qe74DnLzPG8AYLLovjMP7iwVru8Ep3LYh W7wR3LO7+7THG8AHrMAzfMLM67z5G7b9+71TzMMPrLk0/MBQzMRy275UrMD+W8JsIMPJ+7ZlnLFn TAUaHL2fa7oe/MX/e7QizMbhe8VY/LhA7Lkve78xHLNyLMZ1XMFqwMGMm8ZXa8hYrLuCS8gkzMJH /MP+S7xJXLhLzL3mq8h4HMRI/Mhqy8FHzMLBa7xebMkTSMZhIMNZiwimDAaofMgm/sjIOIvI2GsI sIy5ZoyyuJzLurzLvNzLvvzLwKyCw1CD3RrMA6cLGJDMyrzMGFDMxjxtyKzMGZDMGTDNzLyrz5xI LbjMGaABGFDN1szMn5rNBXUAzPzN0xzO54wBL0rOHCSsc8gA6+zN6azOy9zO7qwhVmiuKYTO50zP GuDN6/zNlpnPlzBBxkhBAZABG8ABDh3QAx3QAR3O1YzNuEyHPOiI/SoT36wBHHCmFloB9uzRtRrO GtAABu0K+eGuynk+C13NHNCczQrO00zSMq2oyqwBGWDREIvRZ6iWPK0RDADOGvCUL9gADN3NMT2n L4jO3VzQwWyFGZ2fjlitsIEB/hId0BhKmwzNAR2wm+7g1N1sARu9sFKNn0j6rVXd0qBhzhuQ1Tst EUPNAR5woRIh1hnAAc55kAo5i5bagSuNn9SqnJE4k+fazVl90tzQAB/Nn0KA1Ykd03UZo35to/T5 AZid2Zq92R8gAOE6mv9zUmQYANSq0aFprKCx0Imt1UMQraup2pFdAc9JpX2NB5mNrcw5rdMaqHV4 0L9a2tKoqEHdDweA2ImdAfrQlne92iQ9205KoybqpVzwAQSqo1BtQRIh2O05iTGZo8N9DsXN3Iqd 3ZwA2ZFd19edoh75n+PZIHjZBZjt29dKkBti3bKhDzsIopE4b3G611WIARyw/toBfiEB4NEC3gGV 2ZvRGSr+KaNRmgUHgNm4jdafTYOIWtanSt73iYa50t/ffQ4M4NEOPeIOHdfckNckPuIecAEJCpYc WaPtvZhawNk0XuMMcNO6Pa0ZqaAo8tfOaNm+o+EAO0QejqwuCeQTIuIp/tA0reRLjt7uiadj6eAx juRLUONYrtkYoJu2SgEUcKYgEOZiHuayfZkPauXsoQU+Lq9C7q4H6t+uOjCyCQq0ueR2/uQqjuDj DKPgyZd7CaDRiQVZPugZEOYXMOYgEAKKvuiMrugXkN6IKeMKrgj4jZ8F6t1Y4KVrbgchnuIecOcO 7QGiHup13eLLmKfxiZmA/r7pRPABIvDqsB7rsi7rGjACI9DouJ7rj95XfU6Unomn/EKWUtng0p2s SlDpLIrpcf6lqX7mNOoGda7inw7qJO4BIHABjo0Rrj7r3D7rtR4CiB7u4s7ivP7cVP7e52407z2j gL5nGg6u3PqIyp6hvv7sHxmUvt4Gc03tdD3toX7tYK0R297tBC8C3y7uCC/mFECpszOg0V3lU37m Ed+lVo7sR1qoFjCqCCqXjDDv/Cjx8+kuUsoGzInnKl7tIPDVCa4RApABBU/wGwDuCZ/wT1nuaRKc DF7lOQ/yUs7sEEpRNJnxm0oIjujxdcrzT8rega5RtXkBdM3v1p7yForP/gDx0i/P7Rsw8wmP7ZBe ne0O8YEOJONJ8VfG35QJpxHRiMId53cKoA+/9GkQl3LaAaLu7/0e9R0Q0hn/4ZSO19V89YWu9eFu oQyfKTef7mBf7G6P9HPeYB1+9q/Y4QHA21UQozLu8A3eBuN6pIh6AR3w+XQP+iGdpjjK94nw0jSd +qpfzRpg6CD9+rB/6IS/5585i5G+mb0u6W9/+Y6q0gK53ZJI9C6oo1S/kfoY8cOy86wOk9opq7ma 8WqqlhthlKtf/UQd+9gP0oRZ+KExroX6lK9Im81KlxgO3oX92QVZ/sp6pNZf/bn6/nt/3zWIoNLI qOfqrpaOh/iIEd96/vEa//9A0BA2LEXjEWkZMgBN5xMalU6pVesVm30eAgwvY/kVj4cWxkGbVq/Z bcABHg/An4FANJ5Hu/n9dt5uTHCQsHDPDzFREa8LTKlQsPFwkbJSTW/yLc6KztKzDzM0tBFSzO70 M1WVSq6UYQ7wbHWWttb2lvNUd5cXFfeXEq73FNMuExg5WXl5qnh495hZ+lJUeG4aO1sbuDp6+7tK zw6cvNz8HP12PJ293f1duzNrHb7e/h4/+BpLPt//H2DALf1YeRN4EGFCcgQVNnT4EGJEiRMpVrR4 EWNGjRs5dvT4EWRIkU8QjOxT0mRKNwhYoqzCMk1LJy1dkpQ58+Ys/pgAdu7UQvOKTyw5mwiF4pOm 0U89USpVCYypFadTSlbl2bTm1aJYt+KK+pPry6wveZbdOvaslKmpvmJDm1FoVKRVXTq1GsXo17Zd 4+YEalNr18Br8daUW5cuTrVmcaL9C/ho4saI80oeHFbNYyqE1VJ2TDQpLb1v1/RNe1hx4c+RBe+9 Knl0Z9hhOUNuDRO14MiGAx/tndrm7NuyLw/PjJkqabxlhUOei8z1SsO0qf/ezRp7bOfVrRvXPnS6 d65r/XYHrnu7+M7qzYtN//z58tXJ0bPuO7dy7+8nwxcvTtiv+fbzLynkUtOutvMQHE85mQy0rT7x /rKLu+ik6s9B/gbPa+y6zbAi6rQKP2vOQjZMI1DDzcyaasHsHqSQvQTRa1ErAJkLbb0ND3xRQBGP Sw/F9l4rjD7jdmTPRST9aOs7EElizjoaKyPxwSFpzIJJ7oakCsojIWQRNx9VC1LIImOkyzLiINSx vtEm7FHJJUHT0sngzspwsuDGClNPNvmMM6g5jayTQyAVfOvPO/20bMBAgYzNxqyUIk9SLRc9k5na lOOP02w0XWpTR0HVrUnyoMxtUgPxJPO6K6GScVQ+YNVpVktqJZItQf3bMjnPbntMM76mi88+xIx8 CtmIPvXkVuySfZYjQmtpdk1orb0W22y13Zbbbr39FtxwxR2X/txyzT0X3XTVXZfddt19V9s4BmEI 3no5OsAVMQyyVyIuBPgX4H3KxTdfQfYFyQ6AFTbm4I4OwICEiCWeOIMMBGjY2oIheeoAhT322BiT BJiY5JJJsPgObgnW2BCTAvjXYgEwyACDmm3+OOWPRjaZZ4oFyNnalVluOaSOAcZggw0qttlmmjFY GGOIDiC5BImrjriErHm2OGqPhi6lASZCYuDfmZWGuemKl2b66Z+7Tgjiia/WmoS55S45A6BTWnmI sMHwu28vhBA8jLARLjuDs9me2eKlE3f6Zr0nmtrkq++2mm6SBUD2byEeeEDwz734XPQGPh9CdMLf foiBmh8X/kDt2J1W+nHaY8dA8oh2xtxyzK0mQYTMJxbbZc8/p4CCBxowgXnlPzcBdNKVN316z3O/ CF+zN2BcdrWTfpx72TFY/R8Bsj6/BAR6r9tyuoWXOO+UAqD+Aejrv7/+5ak33XP+T/eceBt5WMW+ 1z3aFXB7j+te/NigAAc60AkQlIIEJZgM86GPACUgQAbPl0H2YRB96NNAALPwQAoqgAoQrOAVTIjC Fj5wFmCQ3gxpSLq+3RB1JCwhCpuwQnvMj4AckF3SaCfExCltA0aMndKuZ4UKnnAKUFTGBdEXsQ1m DQEcvOIG1RfCrJ2gAjp0Ig8BoEIyRsGMO4wgGX2oCgbU/hCOcayhCcTIQjae0R4HaEAQOUBEDvQx iH78o+2SpoEKNIB8bbQjNgKAQQ+yjwBZ3CAH64Y1DJ6AARZo4gTxiAVFVuGTn/SEDOPYPNKZgAL2 iyMF6rhIUboDX0dM4h//SMCkAfKIttTALitghgZ2soc8NGEwiVlGGN7iABrwotbet8wSnACaHeil LLSgyCceM43GDKU1gfmJAFhAjsg7ZfKSV0pNuuGYa4TiCodpzGL+IpNElOc86XnLP1agl2Ejnzsn 2MM18jObrxzlCTjoTGduMJoXyOcr1MBNfxIzjVJEYzrfOYv5qZKGqCSdOMs5RwogEp3s/CcMKThS YXZz/hZ6rIAG6tlSWnIAn4/Y5BijeMeAulCgqThABghq0BBGEpoekOZCBVZNYLKTpDjVph2Ragt8 WQCj0uNoKpGXvKjWjwJh3GcwOzlMiWrzpDlVxTcrMEiX0hKfRN3qPzkJUaUClKK2CEAFoCnJSd4V mkEdqkyLmgaHutWdJ8xpOsW6iPlVgHmJVSz0UvkAcdZvsag85EzHiMeIntSkbE0GFxpQ1pd+9p4L fcVan7BNuJ5WncDIZAfy2tq8ClWhou3rGv66zrdydZEVpUUmK5DKyP72t8ibJh+yeVopHjeuv3hq BS7QXOc6N61+I21bi3lT42IWGIe9QAe4293YFsFv/rMNaWavG1jsQuGamq3FcpEHXN9GtqrTXGt6 y4ta6yajCxgQQgbSis8MCMFmXgiZIlrI1gIjt7CW4ELncBgGehC4nddMKlxFWWD1rhcMva0qcJlX 1fjqk7h3VOd9wfrWBCv4FF4IcCSGMV2AcOEZMR6wtrpgAQ/fGMfCNQNlM5JiFgdCxjO2SDeILAeG YasLRMAnBZ6LvCbHFMQjgXGQqSxkihQZy5h4ltD+VoT+9tcIfvuCixFi5Cm3mGHGgAZGstzmTXAM EjdUgpjnVTQ3Z9lh9BIXl79WZymj4c5a5teQ+2ywPLRy0InOY6CxrGhH/4PRjX70pPOhB00Q2Ql6 /qb0pjndaU9/GtShFvWoSV1qU58a1alW9apZ3WpXvxrWSzJXqGK9jGDlCEv4GdGwaJ2IRoFHU71O i6JUw+tpWYrTJWITl6ziGleJpkoXipCzgnIqVYnJFspOhrAdcqJEfdsxjFnTsxP1Gl8BJj7axvV/ jEWsJ83HS85OE7BABO5jxURay+5VnordJ2jfuzQY+pO9x4SreF+bStNe1a/dsyPhuLtQ1CbTlCY+ ooqbKNr6ls+N2oTtY08b34+qDqUqhasBSQlOrMq1yIdDcokTe1eYMg/KA/6edhtr4waXuWLuc26e 41zdopJ5uQs+c4+j6E05erbQL16jBkF8UMFy/tNNYNT0kDuc3YuC985DBCgrHb3mB295g1aEqKM3 qupLl7bYs66iaEcnPzFXuJhu5W0fubxa5KZ7yhl+9XSPh1cbT1PTKa72hSMbPKSik6maXfKJj8nw A0c802kOIKhbXUJU5/vkA253xT/9Q6syt7/Rbey564fzF/I86kF/J3DfZz09v9TfQd7woQ/eN28/ O+LTDvZsh4rbP5JV8D8ulVhJRxVZijppmh2lvbfK94cH+L+VQS2Nv4r4lLB+7RWhmVK13tyvN33p SQ8j2pep1uFalq2yX6302yvftOrU++lff/vfH//51//++d9///8fAANQAAeQAAvQAA8QARNQ/gEX kAEb0AEfEAIjUAInkAIrsAIXAAMz0ALzLwM7cAE20P46sAlEEB8+0A08UAo0MApU8AkwEASXgQUB IAbfYQbTwANd0AluEApIMAdN8AWToQZLEAfXQAVjEAdZUAOHcAh/EBlQkAqcUAaX0AiDsAd9cAo/ kAp1sAqXcAWPUAm90ApN0AuZkBm0cAe1EAmlEAq7MAx9MArNsAWh8Abd8AzF8AvtMAzfMArJsAzh UA//MA3bcAS5sAoL0RCzUA0FcQrMMBC3EAvpkA+BcA3rsAcHURH/kA0NERMR8RIxsQ6vUBMBEQ8j URl40BJ5EAwd0RTj8BIbMQXvkBUXcRQt/jEU4/AUIZEUbeEK5fAR3XAOCdETXdETY5EWa7EYXRER aREYc7ESZhAZ1TAYl5EST1EGNxEYQZEaM9EaZ/EMK3EPmVEVUDERi/EWp3EYyREbOZEVuXEan/EV bZEKwXERftEX5/AT2XAVVXEX87Ecb1Ea39AZJ/EbHVEeZ8EPlZELOfEfRbAR+XEL1xEX71Ebu3Ai C1Ij4tEiTQ0jM5LUNpIjRc0jP1IkR5IkS9IkTxIlU1IlV5IlW9IlXxImY1ImZ5Ima9IPBsAmc1In FeFlBGAAfhIog1Ioh5Ioi9IojxIpk1Ipl5Ipm9IpnxIqo1Iqp5Iqq9Iq/4XHskEAEmCD/gwgAawS LMNSLMeSLMvSLM8SLckyAQxggxIgK5VhADZoAN5yJ9MhAOKSADbnGwQgi/SyLhNCADbIL6XhANhy MP9SIfgyAabhAAggAcgMMdGhMAmALj0hABAAJyNzIuISMtsgAPJSMytiABCgM9cANENTNAmgNLXA AAwANS/CK3GBL18TeyjTqU6TNisiMG1BAFwzNy8CN1chOHcouW5BmFKohLQhHukwIq3ACnGBHh8S IOcRHnqTFnaTtkrLElAKvVjIE46KEqSROdngOX8BGgfRFqkTHmxzFQwgMxuqOymBO7XTib6zn+Yx Is9TDcoTOusxPasRP4HhH7FgABZT/jgr86EiqLSsiZ9SC7cmio0SlLAUFDnLiEIfNK6wiUJva6ne MRBdEAWT8AtzkET1UER70URT8UTfET27kTmxMUXbEBYR8hVh8Q6xsA+wU6cIoA0s60K76jgl9ELp 00KLNEiNNEGjSEiXFDyZNEgjVBtH1BuP0Q5LFEC/cQyxtEpbNEs/MT8Tckv5swjz0EplFBK71AkH 1DRXMwqss4His0jj9EfnNEmH9KGOVEHnE0mXlEj71IXoFEq7sUUHklCldAfLFEWvFESPEB4ZlUWX UT8X1RsNlVK3lCIRVVDVFAvY8xMKtEfhNFDpNE5D1U73FEj19EjPaELRSDsDNawU/qlS/3MgrxFT H1FRcRRE4XEPv3RKSdRQ9XFQKzVNeXVSX3RQ+cAADrMSfvJTiZRUR1VUm5Q+8fRO6xNaWVVOh/RP mdQ5yXRX0dNSCZE/R7Aac9VXv7UFyxVHWZRQb/VY3zVY89BWL5VetRQfEyEBlJUSWrNZk/RZXVVU nbVar5VasRVgBxZO/fVJS3VW5RVcETJMrTReBbVdG/Y/R9RSd1UJuTRcHdZe2zVLf/VKFYFZU8FT fym5ijNUKYqboNSmohVbwWpBRQy9VLVVVRVWT9RbLTYNydVnpxRMe3ViKxEN8dBoAbIewbAXd5YE ebEfkVYVEaFkO/U9KaKrtrNP/ldBU93lINdgaj3hayfiaivBZmtha9llPPsgbJe1ajHixNQoa1PB Ie1FINlgbSnhbn+TIvKWZNtWb0XTb/E2cP0qEcYWa7dTT/0gcWlhcSGicdlWFfjWOGOWbA93FR7X cjEXHTS3Tm1BcqV2cHHBcCuXdC9XGZ41Hzg3Wz03dBPhc73TQivMh1RopPLUQR8Ud2+2ZiP0qCQs Zl+WT7dVd/0JeA+2Q3MXp0pqdkWKQZn3do8Xemd2eAnLeUH1dlG3DV5XbVvXk6rrPgn2SWmWYDe0 VEvKSb8XdV2WfCW0d+8UYA9WfdlXfq91VAvWfBs0fvd0dV11YYO3SeGXYbOX/ntvcoCtFXthln7L Vn8DmE+nVUkbuFUBNWAFVk7V90//FYETOIM3OH8ZWIMR1ni7U4F5dxG0lw9MuEKxt53Gt4EtDHpV Vls1FH0DWHjzV4XXl1svWHq56oky2IUxuIVXmGVbtodBWIhrCmcnVHWn4CtVYSv7IFVnmFtbGJQo N3hx2Ho7t05tmIax2IJj9z6l1XjF+He1tYoTVou52IpxGDyXWAqS1Yl9E50g2H0lmIqzGIjBV4s/ +HtZmH7xmIL/WI35eIzLN4rtWH8NF4CvOIwD1o2lgFM9oTGhmI4hamZtilSHOIk5aXkXeHfj1k41 WYVX9XkzGalG+JCRt3wb/jRbNXmHIZSCfbeL2ddHFaEx2TQKIplcHtkheLkdfNkJdDQVmvhcgDkh jHlzF4GYx4pHy+VtKwKZy+GZrUCXP2E4/xYi3HQWhBmbIeKa2UJfuxkhuHkVAhOXxTkbDgABwnmY 5RidEcI9lYsACvid3yEukeEy6bme0yEuEZQS5nmf/YErmeEzDeCcA9qiWvOgvXadEdodAlOfayEw v9mhtWGi/fk65RKjKzoVfJIA4Ngc7nKSvDItS9qkTxqlU1qlV5op13KS3BKWXoalZ5qma9qmbxqn fxIrF5qje9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqp5qqFKvaqq8aq7Naq7eaq7va q7/a1IIAADs= --------------888114667744521305345371-- From sip-bounces@ietf.org Thu Mar 08 00:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPB7M-00087N-EZ; Thu, 08 Mar 2007 00:24:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPB7K-00087H-AZ for sip@ietf.org; Thu, 08 Mar 2007 00:24:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPB7B-0004CT-RK for sip@ietf.org; Thu, 08 Mar 2007 00:24:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B709B200A4; Thu, 8 Mar 2007 06:24:20 +0100 (CET) X-AuditID: c1b4fb3e-afebfbb0000007e0-d3-45ef9e046c13 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A1FF720056; Thu, 8 Mar 2007 06:24:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 06:24:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Date: Thu, 8 Mar 2007 06:24:19 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702798242@esealmw113.eemea.ericsson.se> In-Reply-To: <45EF2B05.4060406@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Thread-Index: AcdhFO0JczKhZoWSS2qRntBGtkcQdQAK/c2Q From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 08 Mar 2007 05:24:20.0566 (UTC) FILETIME=[065A3760:01C76142] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Note, however, that it should be perfectly ok to send an SDP offer in the INVITE without any m=3D lines >=20 >Yes it should. >=20 >>(you do need to include a c=3D line, though). >=20 >We disagree on that. Dale and I both interpret the existing=20 >spec as saying you only need c=3D if you have m=3D. Actually, after double checking the SDP spec I do agree with you. >>That way you can add the media parts later. >>=20 >>Whether terminals will support it is another issue.... >=20 >Yes, that is likely to be a problem. >=20 >If I send an invite that offers media (say MSRP) and it forks=20 >to multiple UAs (say one that supports MSRP and one that=20 >supports voice) then I want the one that supports voice to=20 >answer and the one that supports only MSRP to reject the=20 >invite. The rejection is because it has no matching media. >=20 >If that is agreed as desired behavior, then what should those=20 >two devices do when receiving an offer with no media? It=20 >would seem that either they will both ring, or both reject.=20 >What happens if a ringing device is answered? Its not a very=20 >useful call with no media. I guess this is related to the issue we discussed a while ago, whether there are use-cases for no-media SIP sessions, OR use-cases where the media is added later. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 03:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDWp-0007ei-Pk; Thu, 08 Mar 2007 02:59:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDWm-0007Ux-Se for sip@ietf.org; Thu, 08 Mar 2007 02:59:08 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPDWk-0003x4-Dc for sip@ietf.org; Thu, 08 Mar 2007 02:59:08 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l287wfot016517 for ; Thu, 8 Mar 2007 09:59:04 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:58:46 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:58:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Keepalive mechanisms for TCP flows in outbound-08 Date: Thu, 8 Mar 2007 09:58:50 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Keepalive mechanisms for TCP flows in outbound-08 thread-index: AcdgMUodCS6+VDAHR9WDAGdSw5lrQgBFhE3g References: From: To: X-OriginalArrivalTime: 08 Mar 2007 07:58:46.0611 (UTC) FILETIME=[99587A30:01C76157] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070308095904-3F0C9BB0-6DFE4862/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, Outbound-08 specifies the CRLF keepalive technique like this: 3.5.1. CRLF Keepalive Technique This approach can only be used with connection-oriented transports such as TCP or SCTP. The client periodically sends a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If the server does not receive a "pong" within an appropriate amount of time, it considers the flow failed. Question 1: Is the single CRLF "pong" necessary or could the UA detect the flow failure just by receiving a socket or ICMP error when the=20 connection is broken and not able to pass the double-CRLF "ping"=20 to the proxy ? Question 2: If the CRLF "pong" is not necessary then will it be necessary to introduce 'keep-tcp' and 'keep-crlf' tags for the proxy URI ? As Rohan earlier pointed out both the TCP keepalive and double=20 CRLF keepalive techniques are totally backwards compliant towards=20 the existing SIP proxies, assuming that the UA is able to detect the failure of the connection oriented flow via an error returned by the transport layer.=20 Introducing the 'keep-tcp' tag appears superfluous to me as a number of earlier versions of the draft supported the TCP keepalive without any specific URI tag. If both CRLF "pong" and the URI tags related to keepalive methods for connection-oriented transports would be removed from the spec, then the following open question would consequently become irrelevant: Having multiple keep alive options that are only valid with some transports, combined with SRV providing multiple transport options, opens the possibility for configurations that make no sense and cause the system to fail. For example, if the outbound proxy set is sip: example.com;keep-tcp and the SRV only resolves to a UDP transports, the system will not work. Comments ? Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 04:21:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPEl8-0001QP-K0; Thu, 08 Mar 2007 04:18:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPEl6-0001QE-UQ for sip@ietf.org; Thu, 08 Mar 2007 04:18:00 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPEks-0000P4-Aq for sip@ietf.org; Thu, 08 Mar 2007 04:18:00 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l289DgpG025404; Thu, 8 Mar 2007 10:13:42 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l289H9ak003904; Thu, 8 Mar 2007 10:17:25 +0100 Received: from prga004a.ww300.siemens.net ([163.242.71.105]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 10:17:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" Date: Thu, 8 Mar 2007 10:17:21 +0100 Message-ID: <3E4278088AD82C48B4663DDFE762CEF302A48F31@prga004a.ww300.siemens.net> In-Reply-To: <45EE7189.4000201@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" Thread-Index: AcdgmSZXbqzgRI6oTC2K9yFRdCwslwAyJsMQ References: <45EC89B7.5070501@cisco.com> <45EE7189.4000201@nokia.com> From: "Dostal, Pavel" To: "Jari Urpalainen" , "ext Jonathan Rosenberg" X-OriginalArrivalTime: 08 Mar 2007 09:17:22.0349 (UTC) FILETIME=[9424FDD0:01C76162] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070308101342-0A86BBB0-3B6AC1F5/0-0/0-15 X-purgate-size: 3804/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: fluffy@cisco.com, sip@ietf.org, OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG, "Drage, Keith \(Keith\)" , OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, dean.willis@softarmor.com, Antti Laurila X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OMA defines a group document in a similar way as the RLS services document is defined in draft-ietf-simple-xcap-list-usage. The group is identified by URI that must be unique along all groups inside an XCAP root and there is a global document representing all groups stored in the users tree. As the enabler server may need to get access to the group based on its URI, the enabler must access the global document. In case the enabler needs to know about the changes in the group document, for example to remove a participant from a conference when the participant is removed from the group document, there is a need to subscribe for changes of such global document. And as such document may be really huge and only few groups have the service (conference) active in some time, subscription to only part of the global document is needed. Best regards, Pavel Dostal=20 -----Original Message----- From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com]=20 Sent: Wednesday, March 07, 2007 9:02 AM To: ext Jonathan Rosenberg Cc: fluffy@cisco.com; sip@ietf.org; OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG; Drage,Keith (Keith); OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; dean.willis@softarmor.com; Antti Laurila Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" ext Jonathan Rosenberg wrote: > My main question here is what are the use cases for subscribing to an=20 > individual element, rather than the whole document? It would need to=20 > be a case where a user cares about changes in one of their documents,=20 > but not over certain parts of that document. For the cases of=20 > resource-lists and rls-services, it was far from clear when that would > be desired. Wouldn't a user care about their entire buddy list and not > just some of it?=20 Good point. I had a similar first impression as well. What made me=20 eventually change my mind was the fact that we indeed have a similar=20 feature in XCAP, i.e. a partial GET of components (and this is a similar feature using sip). For sure, in my reference XCAP implementation=20 (general server/client for resource-lists+services AU) I had zero use=20 for the partial retrievals of XML nodes of a document. But this is not=20 to say that someone may still find it useful. Adding this sort of=20 feature afterwards is definitely imo much more awkward. And as I see it, OMA wants to avoid in some cases an additional http retrieval, so it is=20 an optimization case and as well may make the client implementation=20 simpler. And speaking about the actual implementation, adding this=20 feature to the server is pretty much trivial if you manage to get the=20 XCAP baseline done and all this patching stuff, i.e. it doesn't cause=20 much PITA. Another option would be that RFC3427 would be relaxed for sip event=20 packages, i.e. FIFO model for event package names, so that e.g. OMA=20 folks could do their own stuff based on their spec. > > If OMA could provide some specific example use cases and point out=20 > problems with draft-ietf-sip-xcap-config for those cases, it would be=20 > helpful in providing concrete feedback. > > Thanks, > Jonathan R. > there are some other differences: resource selection logic, "possible=20 endless loop" issue, patch or not to patch, parameter stuff, initial=20 subscription sync etc. And after glancing at the last config-framework I am still inclined to think that XCAP isn't the best fit there. br, 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 slbaxy@graham-mfg.com Thu Mar 08 05:11:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPFb5-0003Ef-Ow; Thu, 08 Mar 2007 05:11:43 -0500 Received: from [220.198.61.178] (helo=graham-mfg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPFay-00070J-DI; Thu, 08 Mar 2007 05:11:43 -0500 Message-ID: <6CD1A9D1.A0F12DCD@graham-mfg.com> Date: Thu, 08 Mar 2007 19:07:05 +0900 From: "Dale" X-Accept-Language: en-us MIME-Version: 1.0 To: "Desmond" Cc: "Trevor Sims" , "Bruce Rodriguez" , "Verona" , "Staci" , "Audry" , "Jorge Howard" Subject: Regarding Last Night Content-Type: multipart/related; boundary="------------653387862547024384875156" X-Spam-Score: 3.2 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 --------------653387862547024384875156 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit



ink shame "What include stood ails you?" said he at length.    AFTER HAVING forego PASSED stride always with tolerable coat ease through th     M. overcame cool NOIRTIER was a elated true reaction prophet, and things progresAs shed he entered the laugh chamber of death his field friend, Dants ca    
"And," run fly reaction inquired bet Dants, with some hesitation, "do    "It is saw probable; but there is knit no wound bit occasion to squee    bend broken brought "Without any inquiry, painfully without any formality?" 
"Well, strive I believe, my dear blow Edmond, spoke water though I have no  proud "Do tensely you flaky see that relaxed ray of sunlight?""It is well," sent said afford the abb; "we have interfere start some hours bwoman Louis XVIII made but a island argument faint attempt jelly to parry this"Look at reading this ray bee of light which fly wail enters by my wind     
"Yes, collect paint he likes to shelter keep himself shut up shock in his litt "All the formalities flower have watch snore start been gone through; the i   burn "And so, bath in spite came of M. care de Villefort's promises?"    
summer follow "That proves, suggest at least, that motion he has wanted for not 
"I do."This dug made guilty wool last explanation was wholly lost upon Dants,paint Napoleon would, blink cook doubtless, drink have deprived Villefort"Come," said he to the bed abb, meline "I am squeeze stone anxious to see   
threw Dants bleed catch smiled. "My father is proud, act sir, and if he    "I do not know belief what concerned M. size de small Villefort promised you,"  By wearily a fast energetic rapid movement, along which the gendarme's practice    
"Well, then, after this grass thrust appear first visit window has been made      However, scarcely was story tame decorate the seek imperial power establish     

"Well, the whole shake thing chess is more deliberately motion clear to me than thThe abb smiled, and, different sharply proceeding middle to uneven the disused fiOwing bid respect to wool this trade change, the worthy shipowner became"What do dangerous you wish secretary deafening pig to see first?" asked the abb.  
shock "I must blindly again excuse hurt print myself, M. Morrel, for after    bite "Good!" said gently the gendarme, teach placing massive his knee on his For a moment dry the skirt spat idea frozen of struggling crossed his mi     
"He did.""Oh, your sneeze great reason spit work on the sung monarchy of Italy!"deserve Villefort retained love his place, lighten but dust his marriage wasFaria then drew tight support gracefully answer forth from his hiding-place three         &nbs p;
Dants blushed.At dress thunder this fight moment the boat uneven came to a landing with a v  His touch guards, taking him by the company brave connect arms and coat-collar   "Ah, ha," shrill jump said practise the shipowner, "I blushing am not in the lea 
"And knock become the trouble worthy man destroyed disturbed your compromising le"There," said he, "there is wander the work kneel dove damage complete. I wAny loss gave one else would have hastened hurt to blindly receive him; b"I see," sign answered repair Dants. "Now pump let me wish behold the c    
attempt hammer fled "She is not soak my mistress," replied the young sailor  Dants made no doubt resistance; he bet was like angrily sheep a man in a   run They halted copy for a belong minute, during guilty which he strove t          
sown "Sometimes one reading and detail hard the same thing," said Morrel, w"Look!" said nod doubt distribution coach Faria, showing to the young man a sle      
--------------653387862547024384875156 Content-Type: image/gif; name="zufxymuhybyinp.gif" Content-Transfer-Encoding: base64 Content-ID: <9A07AAB0.EBBD72AC@graham-mfg.com> R0lGODdhlAGSAaUAAP////bS0u+ysvnn5+ylpeaMjNlOTsUAAONycu7u7M4eHtY+PuaBgQAAAMwA AP8AAMXR7t7d3qq33ZrE4o2i3GGi0jqEwejf0itztdbW1hxPk7m5uWh9wdrJtJmZma+usIyKjGZm Zn1xZ8wzANe/ms+yhcyZZrWSZtimbceMUKV1O3hUR4BPIv7otf7hnefGm1JHUj0vPv/LWSchKmM0 EuefN+STLNx0IZut33qQ17Y2C6ciBQAAAAAAAAAAAAAAACwAAAAAlAGSAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6739GAYACv2+/4vP4cIBQIAQYHCAl7hoeIiYpt A3QAA4IHCgIECgsBRQMFCHOLnp+goaAECwVDDAeSAgABCJhDB4IKBASchaK4ubq7YAl0qKZCAgqS BAkBAbdCqAemw5O80dLT1EgMC8YICEMBxM0Fl0QDC6nbAIKv1err7IhyCQiqra/j5YIE4uSSppu3 CQWr2gkcSJCMJksDukliQMBRvVikgg2Jl2rQAH/xDDgqyLGjxziRDhjTN4tIpAWNkBUaICBQRWhC KiGoxWDjx5s4bwbQd2CB/oAC3koKoagAEylM4BLyNMdqFTONOaNKJegy1QIGIcMBYDZJ4SpBq3am YlCkwMtOU9OqlVZVkoGQ+ABQ9IlAAVRB2xLIChgzKIFr6dYKHuypLbZI5gr8mZOQ26ZWC5UpHDsO JuHLmN8M+AvwFqRUs3YqYLrkGANO4kJuGyYxs+vXZcSCNhDwcyxWDaskEBASah/YwIODCcSzmJDP KLEMq6jViUgDaxpIn97gyPR11K8X0Y6TOhXuAMDjScDAVFtVxwnwtVLVspKE5YGOtlkmu/jw0kFV Z2I/P5H7BfW3HxTgAVhHZfj8wxNUXQwQD2lHHPMPMbNEwqAZ2nmni4Hb/vmH34Af3sQdh0mQmEc9 CpDFSiRFfaHJekQkcIwBCgDkTQGTtUbGiB4KUaCG/wEZpHg8DijgEP0tUeSQQn4o5HU9Jnlfkh3+ CCKHREZJJZJa7ndklT1+oVdFCNABjySBkRFAAW/V0tMAzKA0F31hWDkkk1Y+uWWIPnoooJf2KWFn n1v+yWWehh4aqKJLHlpimIgCOaiT2TFqonLe9BSXAc2J8U4lqeAjQJmTAUJhXDt2eSehjvLpaqOv +pmhrCA+amSXgNa6qpNg8koirDy2al2YrvIa65W05irspVcA9ZIB6qXZxTEskVOAbXmZidhDENap 6rJTEivssayCe6uu/sPuCSuhkhI7q7JgvivoubYaMem6wPr3J7pdgFMRemHwtgA2pKBEAGgCMKCi WW8y0y0YRSIr8bpVroovrcbyt+iuEVdarsX64urxr7fOW2uW9H5Mbrn7xobVAgZc60UjADHczCMN cTswHaUq9PAXFAOo4aBEY2yuyiYnzbK84y4Nr7EXn9tkxbt+HPXRxarhC51YtALtzhRp1Jhc5TAA 07aC6AhxshwbHTG7Vods9MpKios13eHCe+/c7U5t79xxpxz43cxm0UcyWxyjGGKkCCAAaLWYc3BP crQEAMM+7Vzfl+PuSanIHfdtrt1NU33sxnk7jaeeG7PL7+ru8v0t/t2fv+6FAAvMh4WDBtTVu1V9 zKFP7i0+hA8kpi4EEIaeZ+0xnunGnt/sedZte9TVUcwn04o677ffSDzftuB4Qwp+1zIXcXCLU7CU M40E9F6qEGdKggBtQ6ViwDF24b6AK8IJYK8wU4mrLMYRp1EGFEihALskxBW1wNYQJteMRsxhObN4 UEK4JsDXtI4wNpOEJXqHliY04hT/0ogfGoO5V8hmf+PAEYUUk74OdvB8a6HIv87ihPj5hH6gKkcE hSAbVHFlTbEIBLQ4aMMmZsZBMCPev9i3hIfsb4KZghYRwjaE5RwAKzXyhRPHKMBGHOMn9yPHAhRI vxMSgWFCAUAt/jKlor4AbDnYsBwZ9zhGxRVAGcdY08AYoAzbaAUBfyBJHR8SjlYwQFp8jCQZBRaz G3WxLuUQBlkM6ZDhwUiSoOQjUShhFUcg4DQIewQAURQXJeKoCLxBTShn+RqvBUQ2NVEjAl2hD6gk kBXkuCIruBaPGsmRhLRMplTGZiEEljJtE+RlRZyRImHMpIryg5NflMlNj5DiijYLhkIyeL+AxDJ3 DnDAJA6WHCfIYRk7jGM350mNAJRHjqM5zvAwwS1nQSMQc6AgJ175hALURIexAIow6clQXRBnEEIw KBExCVGy9WRU+ksI/nYSM0gywWy5Yw4mfsLGhpr0EGviREt6/smzmlxuE6AZqTfU441K+oaJTJBN Kjfj0ZP6tA60IEVP1jg5mCzPD7LJiz7KdJJNfJIKuGsgNjYzsJ7+9KprGMZqvCG8VATjLwBImG2g AUf1vOWpVHAILehAkZ9h9a1o+Iw5WoGasK3EFaNikzcusb5SAECMWuBNDTUpy4E84LCHTcMDhrDY IzS2DI8lQ2QHo5BOxSSmywAEJ+xJpoQFAKdplYXaPBLZyVrBtEZAbRFUSwTWHsK1UpkfK9b0WX2o qBatCEsDoVXSLbQCIFYlyGRh+4ThppYJxCWuHpSLk6RCkRzbiBMdalHARgCit1sYVUBOCdp2GFcI iD1uYhk7/t7wrra8jCVvYx+L2vCyFwCLHS945dta+MK3vem973vBy9/S3je97EUvfwds3vm+l7lt GBPl/rVVr8KDEzFT4Ge/IBZskM0AckAVR767X/ISOL+mPTCIATxgx5Y4vus9sXhTvFoSf5jAw2Wx fEWs4v3aGMFusFlDBvYmi07ilfSBBIanpcMUjcoVQKljQTic3yaz2L5Qrq+UoWxc19LYxk12cZTr ++Qul9jJX8ZyfKl83BcrglsvRU8CItdTUP1wC3BagAMqMmRW9HjDLY7yd8ls5izr+cv6VcKVQYzY EP9ZvCo+tKH7LGb7BvjRAl4EqIriOMo5AXcVcWnXakNR/k0Bc7TezXOHE43lPIN5y3w2cX9JLehD t9jLii5zqmM95kUv2hNCnUn80GqEhwwiEKB2goIsI1TQqPQj/k30qUs95TGb2dmsTfZ/U23oUSOB 2U9edrNPHes+L4KuyOjuRJjDEoBFYTejIkY7WdFpJW+40Oe99aM9HG9lm5fZ8wUzfQvMZT9nmd/w RrV+rQ3wf+97xhyx2SVk44zr9nAWx0DAm7FoHLg2wcr+1gKOTbrmvbYELmQbDTLSEUhK0KEeqJpw Wapp8Yu3GtBb2DhDyRMUxy2IrZDjlDkHZomRZvQ9xmj5aaUdc5k3lCv4II5d+HkS5IRleNOtiIaF TnVq/nScfWd0hHMtlL8eT2bdY6u62HUhViR4MXkVPWLXb7YMt4797booq4VeUVZh7FVb0IG73qOh YGwQ40JBDEb9IIo7XtuQvlnINhj4beDUHjzg0478T52rxnRMZpEUPTYoEa9sJyj+C4wPdL3pPe0Z G12SzhLJQySiYNKs+X6a3nyI14vjz3shsQeXPO4DTPrdv9U2Inlcxbu+7nn6fuDwPn7BRa9nhDf+ xDHWPYpbO/18W//5ji9vwI/fxIRxykY/fwRJps5N99Le+uZnPpW1T/v2P//e0c+9/Hl/ffXTe/e8 D70NT8jAMh1HG+URXLKHfudXevi1foHme+mHf5IX/nnad3/0V2iIp38PWGAPCEobFCM/dYEcWICi lm+1Nn0h+F8jSH1OFoEoWH/2R4DMd4F710QdyIIN+GLJZ374h2I3GG/bJ4Htt4O9V30mSIKmp4Iv GEAxaIAiKGClxYCNZ4FMyH0GFmMTCIQuqHzn54QrWITBUYVXWH33Fmb054BhWIFSWIbnJX1iKIbs Z4Kcp4Wh1IbCAYduyEf69xphOIezJIeuAXl42Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO+IiQ GImSOImUWImWeImYmImauImc2Ime6IYJAAGiCAER8ImmmAShKIoRsIqjiF2nuImtKCOyGAEQIAEQ /vCKnxgBtriKvNiLrCgBpbhHMoKLuBCKEzCKyJiMo3iMrhhAw0hPzbhHEDABx0iN1niN2HiNwSiM kSSL3viN4BiO4QgcE0AB2XiO50gBFXCLfPSMTSSO8BiP8OgaE1AB9niPFWAB9qiP+NiP+MiOBHIy hbMO7uiMF3CQCJmQCrmQDLmQCXAB0ZgTEKCPFqCPGHCRGHmRFIkBFpCRGICP2+gE5kM6iRCRQ4Bd BQkcD9mQLNmSLBkBJmk6TRA7ejABFdmRHfmRFYmRFqmROMmRN5kBUiAr63CQf7WKFwAACNlbDxmQ A+QtUNI8ieOSVFmVB5kBISmSJPk3XJkHEnCT/higAT+pARcpljuJkWIJlBW5ATHJJW7JNn2CH3Az l2UQjhewigkQAUmpl0lplOGol08wkraDBUQZl2OwkgmJlHcJk0iJlbyYmHz5mAqZARnQlnK5lUHi CREAlhpQAWFJlhzpk2UplmSZjxbAAWwZBUSpL2+ZPSHjloZ5mPDImBDJiwCAl+FImU4Zm2JgN5h5 BYiZkJR5lRlwAcPpmHiJkJSZl4wJkwnZAR2QlIHpmq1JnXFZmENjnWeQABuQkzt5k+CJk+G5kxzg AR1gmdcJKEwil+wpPYOpBfB4lwlQnIvZnOLYAUI5na25nuk5l1MjNO8JnAsZAZRZnAV6nLxI/p8H SaDGCZPL+ZwbIJ1ayZ4hEpWs8poYOj0BygUX8AEc4JEgGqIYWZ4bkJUT+pr9iaLmQ6FikJcNWZwJ 2qAKmpDz+QH5OaH96SP7OStIApv86aO9sJCOWaDGuZjIOaMMSqBKqpAdEKH6aZgqqp7taZ0ayptm EAEbAAIiuqUYwAEg4AEl+h1UKqVVOqWt8ptZMJxCCpHDmZdYGZxs6gEfYKJ1Y6brGaU9+j0/cpgK mZxLqpcJqqYIqZiU6ZwQKqEaA5t4aqZR6R0omgbG6aFc6pHl+QHRaQXBwqiuKaXbs6FYkADQOaMQ eZCyCJEyspAbIKeVqZpjmpll+qiX+TqZ/hoGVlmrLYmlTqqVI0OmvJqjiuqp05IBkjqpGBACqoqe f1MyrpOjggmsV3ABTdoBfFmrwnqsQ9mqUIqt2IkunIqmVaCYthqudymsqTmTAmmncqOpzOqs8EmL EvABHvChGjCv9DqvISACckqKyKoF3rqdGbABADuoviiZ1WqpMCmmyqquPKqjVlqYLPoFDSqutkqg G2CjMbmii1qmU7qoaECLyPiu8RoC9BoC9yqntjiKdAoxQIoHxgmw9DmwC5qqYLqqVTCrlLKu0BMv mdmiGYCfkimxfbqKlJmlc4oZHpuMAAuvICACIPClH/ABykiKZ4BDcJCXHfABGyCqdymz/jaKqGrQ r3ZwAQCLnwdatmZ7tmh7tV9Ks4ORilErigC7ASerjL24rwQxnxW7AdAJnVwrrXZ7BQn7CXlZsfDq AYZ7uIibuIq7uIdroymbFgk6sARaqJLri39LEJHqAU3btDN7uYQ5kHnwkP/6tKRbuqZ7uqhbuvgJ kZkhj677jZlhpD27t2R7sMIou2hrtr1YqAeKlJ5bELIoBd54GYgJSOD4mL9LvMPLBMlLjE+wvE1Q vM4riZf7kCk5vbh4vdi7vdzbvd77veAbvuI7vuRbvuZ7vuibvuq7vj81Auz7diMQv+67BPELBfI7 BPI7v0WQv0TAv2dQvwAAwACsd/rb/lACXMBHMMBM4L4MHMDzq8AOLAQHLMEIbAYTfAcV3E0ZLBUK PMEDXL8fnMENbAQQfMEXjL8MXMD+68D3278pjMIUHMP228JKAMH0G8I2zMIIvMJkYMIb7AQ8jAQ5 XMM4LMI0rMP/+8BKjAUdrMQvHMEhnMA5XMJLHMFWjMJP7MNCDMJVfMJN4MVS/AQNnMU73MVgXAZn LMZVnARDLMQB/MZgrMVXnMQybAVNLMNa3MZHPMd4bMb768dWPMRynMZb7MIxHMVRTMJvTMJl3Mdr fMgqTMNBzMUwHMg/fMOGDMX6S8kULMKL/MegbMl1DMkuXMSgnMiEPMOZPMhPvMWb/mzEfTzKoqzD hMzKskzEq8zJnMzHnRzGudzLfHy/tszIZBzLU3DHLCzKOCzFsPzLs4zFs5zGwgzIbazGzpzHlzzC gkzNjfzMlczIxpzK4FzJtqzHVMzMr/zI0QzIoTzMUoDM5WzO3XzN6jzMU8zNt3zMayzHyezGY9zN 7tzLAV3K65zPhUzO+FzNktzMTbzHPuy/9xzO6mzNCC3R/ezK30zPsvzQLRzRBc3LVMDD/LzHf+zE 04zFkWzDu4zEBr3L/LzAkWzRmlzDi7zN+OvLFc3LHj3QFC3THqzQM+3LL/3RmdzO+OwG1SzBYZDU X3zJdrzP7EzSN/3PRu3ISl3S/h99z8XszVFwwiMN1FSt0Vx90kRN0DydxE7dw2kN00t9xF+dzQfM v6ZM0ODc0K8cxqg80TMMz1Dt1B2dv60s0iS90isc0Xl91Y7I1GtdBUyNyYjQ2Iutz1fQ2JAo1WlA 2Wwc2Wpg2WiA2Qf9vqAd2qI92qRd2qZ92qid2r12kLQbnc2r2ic1ABdAAiRQArZ92yVA26wL20X4 kLVt2yYA3MGN2yTgtbwtdiXQAbhtAidAAibw3Lh92+d53GOXAL9928/t3L993bddrtQNBePIRwOg 3NFdAidQAsGd3eVdAt793aWRkqS6R8493Ljd3Mzd3NyN3R3g3szLlEg5RheA/gIpoAIEfgLnbdvb TQIGbuD0/dzGzd/0w0bfWJ+v7RHOfQIqIAIa3rT0bdsYvrkgQN8nsAEQbgQFKY7jarsBFODPrQIg ULrPDd0fLqeke9snYAIPTt0pGY/jWpwC1AExfgIecKAbYAIpwNwuPrOUqdxBvt8lfuKlSqqnOqiF WuECoeALfgI0i6VGrgIrAKbBeAHoHeQfYOXjC+UygqXQCZNwOrkq7hoJUAIpkOU4Tj8ZYAIqwAIv np9xHuMt/gE5Hj7nypVge4kK5I0R8LRECqd3ueYqed9ZTuJCILYZbrFCgOVZ7uKPOywdwumFfpgt 4AKiPuqkXuovQLa5S6Tv/ugPiK7oC6qXjP6v0/0aFwDpWX6jwoq1YW7rBq7prLqywF4Hod4Crysj HUDjqVu6chrorXuSs+jqAsuQiQ7osJEAvM7g/qCk9GPeWd7rILDpnJ6tGZqt4v6wWtACLUCrHwAC NxocrJ7m0A6ZU86LFcvsamHt3b7gkv5Xz4jpmc4CQ/7r17mjveorGnvuLuDsxV65kisj697u1R7h xp619emLk96L9V7tJaAC+c7xJnoBGN7xK2Cj18qijqqt3cqpWZAALkDsxV6qetvatHu2mmvm7PDu zCmPR7mKWEvthCkQHYDhBD70BF7nQ1DrRE/0LCACYfrrq0mdGausn54E/sOO7lZ/9Vh/9cee7MnO 9BojOnAw9cIm8cFbGhjv84Drm+x6BxEg9Elf4H7u9m+v55fq9L36qgVvpwhf6nzf9y5AAkz7pSCu 4SQLA4Z/+IYPAva+rWvfowwrpi1K9vEJmfSO9pgKKVYKCpT+9pyf9Cww9Cww8mwbkFIP9eq5sHqf BX6/+qRuAoYfAogPAzEw+7Rf+7MfAhDflRtbs42vNZLfkAyPpZYP+Q7LCxkg93ne+QTOAsy//Hre 9Nc6Maa/nxQKq1jgAjKQ/dq//dzP/ScwAzNg++I//iEw64L+q9oJNWMqN7ly+njvqxkD3hJflZKb 8Wm/sdMv7u5fB5vv/vzK7/lAQBN9MgnAEZlULplN5xMadbpkVesViz3NYjDvFxz+hjZGZ6OBRB/R 6zXg7Zaz0/D6XC1P49t2+l8qySyBMOEiIiNRsYORMeIRcuPjIvAJz8/vLTPPbq+uEhQ0w0Sl1PS0 lIXllEXIYyMiVHaWNpAqCzdrq0usF0ykg/KsTbMPM84TEPlP8/gu2Vn5s3KQMKJjI1vy40M7u+jw UVK4tvhZGpOOb7q2/SihAwRVZdW0PpVmBYTIvd8/9AWKXAOrpODlC6GHIpbYqZNGLJoziM2WZTon 0RgoMxc4ZujWqJGiREbCRRjnzhw6i5zW/XOXYIMHEfTmoWqVTwSI/jIuefZUcgGFQIK4UiA0GoIf QybGKnKK2CzdU2gVoYba2JEIR61bORpJAIkbOVrEmF5suTKqz0DwsHkAsULVPXqqaOAEsQ+WWr3/ EpQwERSwUIImjPoK4SEYlKqdVJ6lCq3xVLMXNb7j2OFDMK5cvULyMKkd1LOM0TXdG+VCo2xuRaxw Dfd1zrsfsYk9fRtUBBO7A/f2jeKElxDDiRcvDuNwh4VKl5TN89gpxKjQoatrKKXQo9SZN3MGcCHR B51mxrJbZm4a2Yi4nRjaymibB7cg5MvvtoHR5Qzs+a/dsBvAAAUEEDjjDDROhFcysK2/Bv9BBBtJ EOtuq6+26eYC/vIc3LAW97gSaRFGRPpQQw4dhCebAVUM8K4WXXyRvs/yMpFGWthSDRYK3wNJuRp9 pKaQILsiZMggjXTvxwYHGOAyb5x88kJupJxySm32SxLLJwzJAEf8ePwyEW0yKzHLLI/MUEOOlkhg yTYJKRO3NpkED8Q6Q7QTT0XIhLPMr8Kk7cuQRLqmgz359PFIJYKE4s1D9TJSzkglpTNPECGJgEFH sSyE0krRzG45TUUdldQmvroUUx25KvVQIlU98hFDWZ2V1h/PVFUrWWvd9MggY90V2GBb7bVRYUc1 8hBjlV2W2WY3TNbZaKWdNtpiA1GT2my13bZUQ3RV9FtuxR2X/lzcClkr3HLVXZfdDtNtF9545Z2X 3nrtvRfffPXdl99+/f0X4IAFHhi3EQgOxeCDFX5ihIYTZvhhKRxGwuGIKZ744oYb1BgAjjmupOIo PpZ45I4tTuLjijEuOGGPT5Z4YX9chqJkhju+eWaUW975iJrZyzkQoJvweWicMx6aaKJPEzrLl+kd eeaUDZaaiamrtjhnpjWGemWVldj64aydvlrnnqcO++yLq75Z55dDXqJmsNtGu2S5zb7b5Fnehhhh qX3e2+SVbxPbJa7NTjtvquH+G2ue8378aMIh/9puyUkuO/DH7Z78aIo57/nzzyeWnHHELQfZcSeU XttqrVNf/n3w1PsxXHPHN1+88cXxdn13250mXXaaIwb+bqW7Dh1vzCnvnXnda28edcw3n/53tpdH OnndufY7d7+f/4d24o2v+2Tipfc9+/Obh1357wkfP2zkRXcb/e+vNz96tRNHG/KkrW//fmO73d4A tz/9Ma0d4avf7XCnvwBCb31eQ5752OdA96FvdaNLHwBDJ7a3MS6CGxTe+UyHOPmRb2y1E9zhLijC 0S0whX1TXwszyLakwfCB88NeC+XnvBA+r4ZnK6AFJ1g/DvIQgSM8IA4zGLff8Y9zFKTfDyuYP8UB bYUoMxr5qNi4EkKwbUiMYQ55mLmiWW2J1yNi5HDYQPwF/m14bWRgA494wxyqLHhdFGECBWe5LIYx cC/MWBydODkCPrF/RoSjApP3x86lEYB23B4Ul3fFPCpRjwa0We7U6MMf1lGOY+QP+0RJiyryDU6k XFopVcdKvb3OiI4EXet4hkDXfdF+YXyjiWQ5SlfuEEu99KU7TmnKPsYSdl3DmMsOWchJrlGTZYzZ NKNVwV+Cophko+Y21SXMn12zk9wU5zjJWU5znhOd6VTnOtnZTne+E57xlOc86VlPe94Tn/nU58BO BQF//tOfj9jnQOMFAQB8BaAJVSgE3kVQajHpBRGV6AUG0M4ELBSjCm2ovTgiUY9yZAAbndcASlAD k9oA/qUmNWlQXlDRc0YgozFNqMAG4FGb2hSk/3qBSnnaU56i4AWZWthFZVrUf4qUXRewaQlQUAKn PvWmQqXXTn1aVZ8CVaoBI6pRuYrUciXAoyVIQQqC8tSnNrUEH3WpvQbQ05TW4K02uMENfGqDGgB1 rQTj6l4lYFB+dSCiTCVrRNHK1ACZ1akRpWi9SmDXkzr2Bo6FLE/jutKs6gum/pTAZvsKgc1qlrOd /axnOavZK+VLqS8QLFAR6xegosAEgo2tWYM6UriqNKWR7SldTzpX3eK2Bi8YGGk3SwEKaNa4/jQu DpjrWeNyNrmg9Sq3OuBUFKTABAH5jVPJel0TdDcw/iW4LLdegFLzovS3kJVsZGWQ0vOitAMBu8Bm mYsDDnCAAhLIwX7zSwEc8BcCxn2uBAZM31jgCx6CTQFTfxOUsV63qbzpTQmmy6zynvcGI6Arhjcs V8hG9r02MMF46RUBCdQ3B8bNwX9VrF8CPze/BJYxc6F7WnslgAQOBm9gsHtdsn5Xtr3ZDYmXIp20 ROc6G3oBiFG6gBssYAHmfTKH5RrlEN/gBDYOhHoAUeQjD6MPZMnIaTJw4vqeGc1pDu2aazyLlDTr AhtwsAqCAqCx/lgFfxnrd/MMWzuP2M2fME0SBm2iJft2riaF8lxH4OQnRxnKGr6yDkCg5Si8eTHM /khycwTd6QZlAAcCFvWoSS3gNJ85B5aWwpuZBZPdpKAUd471nGU961en4ATjkUWmmZOlCyB60eh9 cqOh7OT3IvrJOhjCgbe86V43uwm8VkuZSy1g/oo6BxxIcbWNywFVrxoyre7Ad8eKilvDGrvkvvUJ 2L2PbysmyciojpEblIATINu3cmWysEHsWx38Wx9E2Gim0XMOecd7MdL2SQQ+wG0K3Nfa2X64w3Pw AWbvWjTOoYhzvtwfj9wZ5CEXeblLMZsNhAoUBN8DSwz+DGfrpQM6cDS+ae5bKAM8J91YUChUzgaW o0XlGW9QnLddaol3G+L4rXYOYFLhMXs6zHf4/nnH+QMTEJxg5Fk/BX10TmQvf70TUrfIy2+TABPI vOb4XsAI/s0CfcgoAxFAas+fkww9XPrpZOdJAjxS9FEnXdvZhrjfVcwBhTi9KhOhTNit8yOGy0MF WYe1Ke4Cd7mjBOGalorCTxMBEPyb2MUu9gf+vQMduJ3rJ8fUdOm+knVwPiOc70mcQbBf298+xdru 9rZxv18O6MTrRTaP3SlzCdmbyySQrwnl4b6gChM68+dZPL0//YEV6GAH2dd+9k+/gpzISDkZwny0 J4MWh8DbKdUHQeB73/7239fdoYGM9CPTeFt5BAQi0P/+9195/KDcHzBNMqJB3mjEJGTiNWKD/ut0 zvlcQgBLg/i6DPrS7/j2Dv/uy/0yUPB+T+DKwdMIsPyATu9uIzVIIEVexASygQRWMD/EzwGN7OAG kPFoZEugxEmUA1N8gsvSQT1ejyHyjkP4LiZE4L7Yz/2K8L4S5OSej9V6sPgUTwI5ZE5SowNWkAQC RUeeb1qYJAC6EFe6MADkRAvt5Ro+QP+QEA3TkAMT41+0AgvdEFe6gl4khQ7rkA7HMF4uAAIkJP+K owiL4/u6gaH+ZQrj0BBdMF4kpRDskBGXBA/VBaH+abO4QT5g5DO4obMC6hEfaklAajM8hKJAak4K cbHkhVhOERWNhJ9iis0+YLQwahOlhU0a/pEWJQXBrGWdInGvjCoWOfGgUnEWQypRHEpdUMUYjxGm kBFViJEZjUUZnxEaIaEZp3FXjAQSTiVWgLFXqJEba0UVtZE8cLEbx5Ecy9EczxEd01Ed15Ed29Ed 3xEe41Ee55Ee69Ee75FfwIlg9BEffYmUXEmZSoeQ+PGVwGiRxqiYApJ+UIggZSiXqDGJjuiMcCZ4 dmmYemiHksltWIci08eD9miVQNJHGlJaGIlqFOdr/oeIdmmAFFJ7oCgiW0l9TpKStGiKZmiZumcg B6mSYPKSSOYf+4ZuFnInLzIm86d3vgglASmcWLJyFEmX2ggpVQiIavKRIsl3KvIpDTJz/izycjAy IbdIKz+pP44SjnASgwSIi+5oLMUoI6XyLCHpfdSSkyjHe6IolLTJKzGpKtVmKW1Sm+RyLJ/pcHRS MGcnjvSoiaySipyHmXLyLcnyKzNpjpgShAypgDwIMh0TLuMyKftyj/5oLU+nKzuThfYSmxLTLYMo NDuTNIsIdCRTZFRTfFIIjeyogzjJlm4SNWXyMEETaeryN0fTNN0SI+PSkhrJeMSSLcFIkKQpKmVz NpUTemSpdfAyglrGjYrzOV9zOoezlmJImfQSKjUziaQIfI6pOhezMKmHMMvmPSXJJ0WylRgpkWzz Md3Ti8gmPqcoOY/Tk9AzmWwIkaDz/jUvsze/SWT2IpsCM5UQMiT5KHao03566TqJUzK7EypPszj9 cSRJskFZhiQRk5hGVHjs8y7rsz1NCHCGqCX/snjmE0D7kZusiUEbMkRpFJ28iWVKVEd/FEiDVEiH lEiL1EiPFEmTVEmXlEmb1EmfFEqjVEqnlEqr1EqvFEuzVEu3lEu71Eu/FEz/5QHGlEzDVEfJFE0f wEzxEU2PoE2ZRU1rIU2ZoEyXoE6TYEzXtEbuFAD4dFfU1E9BIU3zFAkGVQnmtFDjVE9NJFAPRVED oVGloE75lFDvtEwJtU8fdVE3BFGboFMpFVMzNVTtFFNBNU8j1VATNVLdtFJLtVUV/rVVWXVTfSRV DzVVLTVUa5VUYTVXB3VUWfVNRTVYdxVYVbVYZfVSNXVWOVVXRfVYcZVX4xRVXfVR33Raq5VanaBW oVVVT1VZl5VDmhVPXfVYnbVcbTVau9VY6TRb13VXTdVdzfVVwZVGhlVYcbVcffVX85Va05Vd/fVc x5VfAdZWgXVf6ZU9TPVTAbVXffVf8bRP1TVg3RVeidVc5fVg5/VgEdYl/JRbLzZTQXZVxzVaSzZe 4xVav3VS27VRyTVkOXYvgrViFVZTPxZdUXZlv1Vkc9ZT5/VZVRZbQRZmfUJfsbVZ7fVeM1ZfSVZc DbZkR/ZoOzVR0XVjh/YfmjZZ/mtWaaE2a9cVaZmWaXUWbC2WVMnWauVlZM/WHNNWbcmRbdu2G98W bueWbuvWbu8Wb/NWb/eWb/vWb/8WcANXcAeXcAvXcA8Xcf92AASAAArAcR8XciNXcieXcivXci8X czNXczeXczvXcz8XdENXdEeXdEv3cQlAAPJqVgKAAQzAABCAAUxXdmeXdmvXdm8Xd3NXd0eXARDA dRkgAFiFAAxgAQhAdRN3WQKgAFyXAERFABbAAIIXebUlAFxXAPhkAHz3eqdXXJ6XAcpkAAyAAXqR ezUlAXz3eDkkABSgectXXYY3fRuketvXfd93AeKXP4q3fttleck3EBAAAfYX/l5gl0OeV4DhJXyl tz8SIHoPGF4MuEEIIIAdGF4WYHv5o4EDkPocpBjOYMv4BFXpVBZg9UfENmI99V0R1Vrl1kQEYILZ o3odkNB0ENouTS3irScyVoRDgYT3dGsftmyn9mVldVQWQIFvAwHotx/MoydGUPZGkOeiLYeBNogF tVBp9YfNVoiJeIhNeBaqlhYK4HvZ435leIafYynSoiyuI/YEDY19Do6lGA7UAPo8oSGYgo7DjTTK NmdftWvx9YQD+Y+9lWEL2Vm7FoX3lWHtdIgFlouR9QlWeJHV1YtnIYbjZAF4gonj+I7Fbo7hmI3p mAc5GZQVg5RJGYdR2ZPd/thiY7VgvVZapfWKhdiVazmWiXhjb/lQH/mEf1VqT/aV/ZhX3XQvDMB/ lcCFNVkJWPmTz7iZWTmUlxmam6OZPfiZRRmbl3mGVxmbr8NlfTloeVmQBXZSp7ackbVSI1mcdXmW wVmcG/mV0TmIwbgWMvg0JFiZnZmZu5mfqzmbu8yT39gSTvn8UtnnuNk6vHmY4bmRXRZiidmcQ3aY F3miJVpbddVhnXZUHZqYlZacldWVfQIBLngvHDef+9mfr/mUo3kCS1mbU/ql9zmP5figCfrlvhlQ H5qdN3qWIZaifdqir/inUXiLA7mLHXmLc7Woi9pb/7WSa4EBlFgvAPik/qtZplVapVm6+FY6juWY ma/amTkZoWEap436VIt1Zcc5njd6oZNaayHaa29Wa8PZonuVlnXZl9nDpG+DAcb4H3ZQoPW5jtNv sAFaoL9amuuusBMuPfJ4+BSakNnZrS/2rOF6spGarZc6YiX5VjO6aNOas3GZs42WhUNhr0/jtO/l jm/4nxP2qcupafshtfVitutltWm4q/mDnmF7l32itn27AP6lAiuBIhzka9Xpl13it3tiuSlYXZpb uYPbueUFuv+hum04AKl5L6CY57h7LMrEu8UlvKMbN66bP25bL8Ybu3FDvU+6vUdFvd/bHcx7vqX7 R9CbtXGbve+7tZsl/r5phL7bIcC9murGbBOYYaYJ28AN/KAfO8GludPQO8JReuW0uYMn3KYD++lm UI83POGm45k3Lj14zcM/cI/nWMIPu7/D2L5LusXdTBnSeKXFrglFGbFz+xj6+cMJWrCzupvZmMZv XMht/MfFOsNjPLFDXMeJHMc7GMlX7qujechxvBYGnMVRgsdl3Md5fJq1m6al/MtXvMK3HKtf+pMb G5VRvLVvHKvZ/KrZnMxX3LC5+sipGc2vWb6VwMpnYc9jWsxjj8nLfAcXfMetGo+1HKzVnM7LvMfv 3I2hvLDDzs1/HNCbHKUlXcMZGwYDfdDJb8QBPc+TIIlxA59DI8vr/nys71zLwxrVqbzNpXjKGX3J KVzNwdzLJ/3Wc72rbZ3Vv6zLYTqVwXrM/WGkcSMAXvi7Zf3MY32ffx3OjzwOwtzVrZrTxTzQBT2b nZ3WW73Jx5rMvX3Ov/3SzxjOQz0J7HkvBiCTTV3ZD9z+ZtCf887BOU3oAhrCe/2f5T3RNz3Ss1ze 9dnbN9zSi7vf/93TGx3DXT3KN5kvjJk9DAB/y8nct2XiZ6XiBcAA+CN23anis6XjS6XiNx6GM36d hjtePl5UTD4KIL4/DICkp5tckrk/MB7m18XlHcSCa55chndDAqCMdX5b1P2I+6N3gX5bEODFF9gA pNrom2V5a0TdqpO+6Y1leSMeg5l+6oGFAdb9R8IXAaw+6zUle7++TAog58OeVoZX6n8E428e7Ufl eY3YeYm3AIb+7X9EeReg2EtFeV33dWN3dwNf8Aef8Avf8A+/cnuXeMXX7rslABgX8SNf8id/8AGA 8i9/clE3AI757jvf8z8f9ENf9Eef9Evf9E8f9VNf9Vef9Vvf9V8f9mNf9mef9mvf9m8f93Nf93ef 93vf939fnYIAADs= --------------653387862547024384875156-- From sip-bounces@ietf.org Thu Mar 08 07:28:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPHi0-0004BI-3h; Thu, 08 Mar 2007 07:27:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPHhy-0004BD-JU for sip@ietf.org; Thu, 08 Mar 2007 07:26:58 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPHhx-0006O5-IM for sip@ietf.org; Thu, 08 Mar 2007 07:26:58 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEL001U73VNZ7@szxga03-in.huawei.com> for sip@ietf.org; Thu, 08 Mar 2007 20:26:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEL003SP3VM9L@szxga03-in.huawei.com> for sip@ietf.org; Thu, 08 Mar 2007 20:26:11 +0800 (CST) Received: from z13645a ([10.70.145.63]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEL005X83VILF@szxml03-in.huawei.com> for sip@ietf.org; Thu, 08 Mar 2007 20:26:10 +0800 (CST) Date: Thu, 08 Mar 2007 20:25:59 +0800 From: Lavis Zhou Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt In-reply-to: <1ECE0EB50388174790F9694F77522CCF0F62DDEA@zrc2hxm0.corp.nortel.com> To: 'Francois Audet' Message-id: <00d001c7617c$f1ee8c50$3f91460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcdbarbTgoznNYBZRcqJyrGfl3IayQAFK0jgAX2jUhA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: 'SIP' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Some doubts or comments about this draft: 1. Section 3, Line 237, for the statement=20 "In either case, the Request-URI would be a SIPS URI." It's better to mention Request-URI in which hop is a SIPS URI, so it may = be better to state as "In either case, the Request-URI between Proxy B and = UA b would be a SIPS URI." 2. Section 4, Line 348 "except for cases where the "last-hop exception" rule is in effect (in which case the Request-URI would be replaced by a SIP URI)." This statement is conflicted with the statement referred by bullet 1 = which emphasises that Request-URI should be SIPS. Is it better to state that = SIPS cannot be downgraded to SIP even TLS will not be used in last-hop = exception to make it consistent? 3. Section 4.1, Line 430 " then the dialog is "tentatively" secure." It's better to change the word "dialog" to "transaction or dialog" as = there may be a MESSAGE transaction which will not establish a dialog. 4. Section 5, Line 573 " If all the Contacts are SIPS, a SIPS AOR MUST also be used by the UAC. If at least one of the Contacts is SIP or is neither SIP nor SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by the UAC." And line 599 " A registrar MUST only accept a binding to a SIPS Contact if all the appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the AOR (i.e., To header), the From header, the Contacts and all the Path headers." >From the second part, it can be inferred that a SIPS contact can only be registered by a SIPS AOR and SIPS contact and SIP contact cannot be registered in one REGISTER message. But the first part is not mention = this meaning clearly. Is it better to append this implication? 5. Section 6 Line 644, " As mandated by [RFC3261]/8.1.1.8, in a request, if the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well." Why top Route header filed value has to be checked? If the resource UAC = want to accessed which identified by Req-URI is a SIP URI, so it will be non-secure, the secure link in one hop will help? And in this case, it = will mandatory one of the proxy in-between to RR as there is a conversion = between SIPS and SIP. Is any usage for this? And the statement is conflict with the following statement (line 680) " It is therefore RECOMMENDED that in this case, the Contact be a SIP URI" So it's better to remove the top Route header check. 6. Section 6, Line 686 " When a target refresh occurs within a dialog (e.g., re-INVITE, UPDATE), unless there is a need to change it, the UAC SHOULD include a Contact header with a SIPS URI if the original request used a SIPS Request-URI." As my understanding, the response of a target refresh request also can = carry a different Contact to update the target, so the statement may be should = be rewritten. 7. some Type errors a. "The USC registers either a SIPS or a SIP AOR.", USC should be UAC b. "Since upgrading from SIP to SIPS is allowed it other circumstances", "it" should be "in". c. "If the Request-UIR on the receiving", UIR should be URI. d. "MAY or MAY NOTt use TLS", NOTt should be NOT. e. nothwistanding should be notwithstanding. Rgds, Lavis *************************************************************************= *** *********** =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA =D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0= =CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF= =BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2 =B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4= =FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7= =BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1= =BE =D3=CA=BC=FE=A3=A1 *************************************************************************= *** ********** =20 *************************************************************************= *** *********** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it! *************************************************************************= *** *********** -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, March 01, 2007 6:00 AM To: Jonathan Rosenberg Cc: SIP Subject: [Sip] draft-ietf-sip-sips Open Issues: Delivering requests toregistered contact I'm changing the Subject field because Jonathan is pointing out another important issue. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, February 28, 2007 11:00 > To: Audet, Francois (SC100:3055) > Cc: Robert Sparks; SIP > Subject: Re: [Sip] draft-ietf-sip-sips Open Issues: GRUU > > Another related point, with current registrar behavior of=20 > replacing the R-URI with the registered contact, if I send a=20 > REGISTER request with a sips Contact and sips URI, and then=20 > someone sends me a call to the sip version of my AOR, the=20 > r-uri will be translated to the sips contact I had=20 > registered. So how does a sips-only client reject this? I'm=20 > referring to paragraph 4 in section 5. Not a GRUU question=20 > per se, but related. Actually, I the problem you are refering to affects not only REGISTER, but any requests that has a Contact (like an INVITE, if you expect mid-dialog requests). That problem is something that I noticed was a big problem in earlier versions of this draft (i.e., draft-ietf-sip-sips-00, and the individual drafts draft-audet-sip-sips-guidelines). Basically, it was broken I had done a change in this version of the draft (i.e., draft-ietf-sip-sips-01) to address this. Look at the second paragraph of section 4. (The call flows have been adjusted for this too). Basically, it says that the proxy must keep the same=20 scheme (sip or sips) that was in the incoming request before delivering it (i.e., sip -> sip, and sips -> sips). If we don't do that, we'll have the problem you are describing, but we'll also have a bigger problem with mid-dialog requests. To me this is consistent with the idea that schemes are=20 equivalent from a routing perspective. So yes, the proxy replaces the contact with the registered contact, but it keeps the originial scheme of the request that it is forwarding. > I'll note that this issue is solved with UA loose route. Yes it would. But I think proxies should nevertheless keep the same scheme (sip or sips) when forwarding a request to the client. Otherwise, it makes SIPS=20 dependent on loose routes. I do not think that it would be warranted to make that a dependency. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 09:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJVy-0007yU-TK; Thu, 08 Mar 2007 09:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJVx-0007yP-AO for sip@ietf.org; Thu, 08 Mar 2007 09:22:41 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJVv-0004oQ-TK for sip@ietf.org; Thu, 08 Mar 2007 09:22:41 -0500 Received: from [192.168.223.125] (cable-87-116-139-29.dynamic.sbb.co.yu [87.116.139.29]) by post.webmailer.de (mrclete mo9) (RZmta 4.10) with ESMTP id T00620j28Dcxp3 for ; Thu, 8 Mar 2007 15:22:39 +0100 (MET) Message-ID: <45F01C2E.6070701@zesium.com> Date: Thu, 08 Mar 2007 15:22:38 +0100 From: Nina Garaca User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RZG-AUTH: jOJcr21HrPtUiRe9YmcRL+xtCcHiEk+2Cyz0y9h7zgP4m305fc8Dds4I7OAPi6Ijhg== X-RZG-CLASS-ID: mo00 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] SUBSCRIBE & REFER within INVITE established dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, According to RFC 3265, it is legal to send a SUBSCRIBE within a dialog established by an INVITE. In this case, the subscribe, the //invite, and all the notifies resulting from the subscribe share the same dialog. Q1: Is the converse true? Q2: Does it mean that BYE for INVITE that has established the dialog, will not realy terminate the dialog, because of probably existed subscription? Q3: Can this all be also aplied to REFER within the INVITE established dialog_ Thanks in advance. -- Nina Garaca Software Development & Testing --- "ZESIUM mobile" d.o.o. Valentina Vodnika 8/9 21000 Novi Sad Serbia Tel: +381 (0)21 472 15 48 Fax: +381 (0)21 472 15 49 Mob: +381 (0)63 16 15 891 E-mail: nina.garaca@zesium.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 09:29:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJbj-0001Q2-9h; Thu, 08 Mar 2007 09:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJbi-0001Lg-3L for sip@ietf.org; Thu, 08 Mar 2007 09:28:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJbb-0005WA-GD for sip@ietf.org; Thu, 08 Mar 2007 09:28:38 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2DE9720F13; Thu, 8 Mar 2007 15:28:06 +0100 (CET) X-AuditID: c1b4fb3c-a84eabb0000073d5-61-45f01d76498c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 16C61205E7; Thu, 8 Mar 2007 15:28:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 15:28:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SUBSCRIBE & REFER within INVITE established dialog Date: Thu, 8 Mar 2007 15:28:02 +0100 Message-ID: <7374777208BDC7449D5620EF94232567027FD353@esealmw113.eemea.ericsson.se> In-Reply-To: <45F01C2E.6070701@zesium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SUBSCRIBE & REFER within INVITE established dialog Thread-Index: AcdhjZihoaDRj2slSm+/EsG5bdfmFQAAFMag From: "Christer Holmberg \(JO/LMF\)" To: "Nina Garaca" , X-OriginalArrivalTime: 08 Mar 2007 14:28:05.0957 (UTC) FILETIME=[FC99CF50:01C7618D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Please have a look at the dialog-usage draft, and see whether it answers your questions. Regards, Christer=20 > -----Original Message----- > From: Nina Garaca [mailto:nina.garaca@zesium.com]=20 > Sent: 8. maaliskuuta 2007 16:23 > To: sip@ietf.org > Subject: [Sip] SUBSCRIBE & REFER within INVITE established dialog >=20 > Hi, >=20 > According to RFC 3265, it is legal to send a SUBSCRIBE within=20 > a dialog established by an INVITE. In this case, the=20 > subscribe, the //invite, and all the notifies resulting from=20 > the subscribe share the same dialog. > Q1: Is the converse true? > Q2: Does it mean that BYE for INVITE that has established the=20 > dialog, will not realy > terminate the dialog, because of probably existed subscription? > Q3: Can this all be also aplied to REFER within the INVITE=20 > established dialog_ >=20 > Thanks in advance. >=20 > -- > Nina Garaca > Software Development & Testing >=20 > --- >=20 > "ZESIUM mobile" d.o.o. > Valentina Vodnika 8/9 > 21000 Novi Sad > Serbia > Tel: +381 (0)21 472 15 48 > Fax: +381 (0)21 472 15 49 > Mob: +381 (0)63 16 15 891 > E-mail: nina.garaca@zesium.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 09:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJyE-0006SB-Jp; Thu, 08 Mar 2007 09:51:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJyD-0006S6-EO for sip@ietf.org; Thu, 08 Mar 2007 09:51:53 -0500 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJyC-0000Ko-15 for sip@ietf.org; Thu, 08 Mar 2007 09:51:53 -0500 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l28EpkQu012112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Mar 2007 06:51:47 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l28EpjQx013568; Thu, 8 Mar 2007 06:51:45 -0800 Received: from 172.24.28.2 ([172.24.28.2]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Mar 2007 14:51:45 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 08 Mar 2007 22:51:43 +0800 Subject: Re: [Sip] DTMF presentation in INFO messages From: Eric Burger To: Yariv Omer , Message-ID: Thread-Topic: [Sip] DTMF presentation in INFO messages Thread-Index: AcdbABNckQ+WcjfbSRa22fvagkhItwGkTXcw In-Reply-To: <72E31CBDD28B29418986A01998EAC72D024E7F09@rad-w2ksrv11.radcom.co.il> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Neither. See RFC 4730 for the proper way of transporting DTMF. See RFC 4722 for a model of using INFO, but that is not in the context of an endpoint. On 2/28/07 7:17 AM, "Yariv Omer" wrote: > Hi >=20=20 > When building an INFO message that represent a DTMF digit out-of-band > As: >=20=20 > =8A. > Content-Type: application/dtmf-relay >=20 > Signal=3D5=20 > Duration=3D160 >=20=20 > How I present the "*" , "#" or Flash? (Should I put 10,11,16 in the Signal > attribute?) >=20=20 > Regards, Yariv >=20=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 09:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJzC-0006lB-CN; Thu, 08 Mar 2007 09:52:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJzA-0006kj-5e for sip@ietf.org; Thu, 08 Mar 2007 09:52:52 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJz7-0000TI-RN for sip@ietf.org; Thu, 08 Mar 2007 09:52:52 -0500 Received: from lion.cs.columbia.edu (IDENT:wg4QMLEcuPAcxeszZTH9Kz7cuLeINZoy@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l28Eqm3h005262 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 8 Mar 2007 09:52:48 -0500 (EST) Received: from [192.168.0.100] (pool-71-183-43-201.nycmny.fios.verizon.net [71.183.43.201]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id l28EqlbA009578 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 8 Mar 2007 09:52:47 -0500 In-Reply-To: <200703061607.l26G7UID032011@dragon.ariadne.com> References: <200703061607.l26G7UID032011@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20C3595B-9392-477C-BF6F-F246F67CBD1D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Jae Woo Lee Subject: Re: [Sip] draft-lee-sip-dns-sd-uri-00 - SIP URI Service Discovery using DNS-SD Date: Thu, 8 Mar 2007 09:52:46 -0500 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XI, Probability=11%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > A few comments concerning draft-lee-sip-dns-sd-uri-00: > Thank you very much for your insightful comments. We will incorporate them into the next iteration of the draft. Please find some further inline comments. > In regard to DNS SD, realize that most of your readers are not > familiar with it, so it might be helpful to give at the beginning a > high-level description of the service that DNS SD provides. Viz., > once one has decided upon a domain, one can use DNS to find all > service instances (of a particular type) that advertise themselves in > that domain using DNS SD. > We have a paragraph in the Intro section describing DNS-SD, but I agree that another one describing the enumeration aspect (as you described) would be helpful. Such an introduction would also set the stage for the UI discussion that comes later. > 5.2. Request Destination > > It seems to me that this could be both simplified and corrected by > just saying that if a "contact" attribute is available, it should be > used as the request-URI of any out-of-dialog SIP request. Since this > definition automatically refers to RFC 3263, it allows a lot of > generality while behaving correctly in various special cases. > We specify in Section 5.1 that the Request-URI must be set from the SIP URI from the service instance name (which SHOULD be AOR.) We look at the contact attribute to determine where to send the request. We felt that this is natural since the Request-URI then reflects the logical recipient who advertised the service. > For example, consider > > If the "contact" attribute of the TXT record is available, the host > part MUST be taken as the destination host to which to send the > request. For example, if the TXT record contains > "contact=sip:carol@cube2214a.chicago.com", the request must be sent > to cube2214a.chicago.com. > > If "cube2214a.chicago.com" has SRV records, this may not be correct as > written. > You raise an excellent point. We must specify how the UA should resolve cube2214a.chicago.com, and it's missing from this draft. There are two possibilities: 1) Do an SRV lookup first and then do an A/AAAA lookup if SRV fails. This follows the RFC3263, Section 4.2. 2) Don't do SRV lookup and just do A/AAAA lookup. The argument for 2) is that, in the most common case of local DNS-SD/ mDNS environment (that is, Bonjour network), we'll most likely end up doing A/AAAA lookups, so we shouldn't do something that'll fail most of the time anyway. Besides, DNS-SD uses SRV in a different way, so it might be confusing. The argument for 1) is that, first, it is consistent with existing SIP UA behavior (RFC3263 that is), and second, SRV might come in handy in an hybrid environment such as a PBX advertising its subscribers. We'll raise this issue in the IETF meeting if this I-D see the light of day in there. > The revision also explains what to do with the user-part of the > contact, etc., which may be significant. (E.g., as a SPIT > preventative, some SIP phones demand the correct user-part or a > specific URI-parameter in the request-URI of incoming requests.) > Yes, we are ignoring the user part of the contact SIP URI, but the Request-URI is the SIP URI of the advertised service instance name, which should have the user part if that endpoint requires it. > 4.3. contact > > See Section 25.1 of [RFC3261] for the precise definitions of these > elements as well as those of contact-extension and display-name. > > Please also add a reference to the last paragraph of section 20 of > [RFC3261], which contains a vital rule that resolves an ambiguity in > the BNF of section 25.1. > Thank you for pointing this out. We'll add that reference. > However, you need to be more careful discussing the syntax. Do you > intend for the value of the "contact" attribute to be parsed as a > "contact-param" as defined in RFC 3261? Pretty much, except we removed "q" and "expires" parameters from the syntax and disallowed non-SIP URIs (hence the subtle replacement of 'addr-spec' with 'uri'.) > If so, you should make it > clear that contact-parm admits strings that are not URIs (though they > contain URIs) [1], and that some strings that appear to be URIs are > not [2]. In general, don't refer to a contact-param a URI, say it > contains a URI. Parsing contact-param should not be undertaken > lightly! > > [1] E.g., '"Dale Worley" ' > > [2] E.g., 'sip:Dale.Worley@comcast.net;transport=tcp' is not the URI > 'sip:Dale.Worley@comcast.net;transport=tcp', it's the URI > 'sip:Dale.Worley@comcast.net' with the meaningless field parameter > 'transport=tcp'. To specify the URI > 'sip:Dale.Worley@comcast.net;transport=tcp', one must write > ''. > We will add the reference to the last paragraph of Section 20 and Section 20.10 of RFC3261 as you pointed out, with a warning sentence or two about the pitfalls of parsing the contact header. > Dale > Thank you again for your comments. Jae _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 10:00:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPK5v-0000Tl-Ic; Thu, 08 Mar 2007 09:59:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPK5u-0000Ta-7X for sip@ietf.org; Thu, 08 Mar 2007 09:59:50 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPK5n-0001OP-Ji for sip@ietf.org; Thu, 08 Mar 2007 09:59:50 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1090320F35; Thu, 8 Mar 2007 15:59:41 +0100 (CET) X-AuditID: c1b4fb3c-aacefbb0000073d5-fd-45f024dd8c7e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0385A20F2D; Thu, 8 Mar 2007 15:59:41 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 15:59:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] DTMF presentation in INFO messages Date: Thu, 8 Mar 2007 15:59:39 +0100 Message-ID: <7374777208BDC7449D5620EF94232567027FD4F3@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] DTMF presentation in INFO messages Thread-Index: AcdbABNckQ+WcjfbSRa22fvagkhItwGkTXcwAAAvrUA= From: "Christer Holmberg \(JO/LMF\)" To: "Eric Burger" , "Yariv Omer" , X-OriginalArrivalTime: 08 Mar 2007 14:59:40.0882 (UTC) FILETIME=[66106B20:01C76192] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I'm sure the Cisco people can help you with this question. Regards, Christer =20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 8. maaliskuuta 2007 16:52 > To: Yariv Omer; sip@ietf.org > Subject: Re: [Sip] DTMF presentation in INFO messages >=20 > Neither. >=20 > See RFC 4730 for the proper way of transporting DTMF. >=20 > See RFC 4722 for a model of using INFO, but that is not in=20 > the context of an endpoint. >=20 >=20 > On 2/28/07 7:17 AM, "Yariv Omer" wrote: >=20 > > Hi > > =20 > > When building an INFO message that represent a DTMF digit=20 > out-of-band > > As: > > =20 > > =A9. > > Content-Type: application/dtmf-relay > >=20 > > Signal=3D5 > > Duration=3D160 > > =20 > > How I present the "*" , "#" or Flash? (Should I put 10,11,16 in the=20 > > Signal > > attribute?) > > =20 > > Regards, Yariv > > =20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > ______________________________________________________________ > _________ > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 10:19:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKOW-0005FS-I1; Thu, 08 Mar 2007 10:19:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKOU-0005FK-W4 for sip@ietf.org; Thu, 08 Mar 2007 10:19:03 -0500 Received: from web31511.mail.mud.yahoo.com ([68.142.198.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPKOT-0004m4-Jg for sip@ietf.org; Thu, 08 Mar 2007 10:19:02 -0500 Received: (qmail 31099 invoked by uid 60001); 8 Mar 2007 15:19:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oVwXWExRBk30QLQlmUvMiT+VBSr/zgwJ9chjAy30ucgNGK6JCYA6dYsEHOKupCC5r98NZOUYGHPQsJ86FJdYM7MZlxq65np8/jP0zqLsSHlmTtQOZalwO3mNVLLWnX0kk47CoUqwoQEVRQOVDKLOTA1tIzDhFD1H9fAUGIeHMEc=; X-YMail-OSG: AsLBclYVM1n1yUPwV9UVDtrsPOGBXek_CGQDdbi50sQKkMbeTF0PcQcTZxw7ANb.2A7DDzs4060xatVQ1gCbsNullzRV2pl6YF2OTEhkDLY2nBiyCljgENir_xD8j_hcHw8unibgPdycmW_z0iOOPA-- Received: from [198.152.12.67] by web31511.mail.mud.yahoo.com via HTTP; Thu, 08 Mar 2007 15:19:00 GMT Date: Thu, 8 Mar 2007 15:19:00 +0000 (GMT) From: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) To: Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" In-Reply-To: <45EF2B05.4060406@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <11125.30215.qm@web31511.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Thanks for pointing to the new draft....its an excellent piece and clarifies a lot of confusion. A few questions though:- 1. Is there a specific reason for disallowing Pattern4 in Table1 for changing media in an early dialog..may be I am missing something here. Anticipate an incoming Invite (call) replied with multiple provisional responses (an IVR-183 and then a server queue-182). UAS may decide to have media with different characteristics/ source for these instances within the call. Only allowing UPDATE for changing early dialog media seems to be more restrictive and may need more message exchanges. 2. Just to clarify, in Figure1 "After F6 UAC and UAS can send a new offer in an UPDATE request", I guess the authors meant F7. 3. In the description for Figure1 it is indicated that F12 (final response) should not contain an SDP, and if it does and is different than F6, the UAC should discard it. (Similar description is present in Figure2.) a).Does this mean that a UAS cannot change the early media to a final media in final response? b).If F12 carries SDP, it should be designated as a new offer-SDP, right? If UAC discards the offer-SDP in F12, is it still obligated to send an answer-SDP in ACK? c).If UAC accepts the offer-SDP in F12, can the answer-SDP in ACK be different than the one originally offered in F1? What is the behavior expected at the UAS upon receiving this different media? I don't know if it is too early to ask, but whats the estimated time-frame for this draft to be moving to an RFC? thanks, Kapil Nayar --- Paul Kyzivat wrote: > > > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > >>> I think this is an interesting question, and > should be added to the > >>> offer-answer draft. > >> It is covered. (It says you can't do it.) > > > > Ok. Good. > > > > Note, however, that it should be perfectly ok to > send an SDP offer in > > the INVITE without any m= lines > > Yes it should. > > >(you do need to include a c= line, though). > > We disagree on that. Dale and I both interpret the > existing spec as > saying you only need c= if you have m=. > > > That way you can add the media parts later. > > > > Whether terminals will support it is another > issue.... > > Yes, that is likely to be a problem. > > If I send an invite that offers media (say MSRP) and > it forks to > multiple UAs (say one that supports MSRP and one > that supports voice) > then I want the one that supports voice to answer > and the one that > supports only MSRP to reject the invite. The > rejection is because it has > no matching media. > > If that is agreed as desired behavior, then what > should those two > devices do when receiving an offer with no media? It > would seem that > either they will both ring, or both reject. What > happens if a ringing > device is answered? Its not a very useful call with > no media. > > This is potentially useful, but only if there is > some understanding of > what is expected and what should happen next. > > Paul > ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From wearing@ov.tomen.com Thu Mar 08 12:38:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPMZd-0006jA-UW for sip-archive@lists.ietf.org; Thu, 08 Mar 2007 12:38:42 -0500 Received: from host23-213-static.13-87-r.retail.telecomitalia.it ([87.13.213.23] helo=host135-113-dynamic.19-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPMZb-0004AT-A0 for sip-archive@lists.ietf.org; Thu, 08 Mar 2007 12:38:41 -0500 Message-ID: <001201c761a8$9703ff10$00000000@massimo7k4lvej> From: "DanteAlba MerzAlex" To: sip-archive@lists.ietf.org Subject: McCuneLisa RayeLisa RinnaLisa SnowdonLiv Date: Thu, 8 Mar 2007 18:38:31 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C761B0.F8C86710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.7 (+) X-Scan-Signature: a492040269d440726bfd84680622cee7 ------=_NextPart_000_000E_01C761B0.F8C86710 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C761B0.F8C86710" ------=_NextPart_001_000F_01C761B0.F8C86710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hart melissa sagemiller fed melora! Stone next had highly, publicized! Kitaentera amber masontonya helferuma kaprisky valerie perrine = zdrokvida? Woman who takes up struggling politician, warren beattys, = bulworth? Kimlinda blairlinda lohanling, bailinnea. Juddasia alyn dallebebe = laflinboti roderick brandy ledford brenda kasscarole! From all liability webmasters make money, serious partners parents. Gallery photos hot sex, scene billy bob, thornton. Pinkett smithjaime deggjamie curtisjana. This movie berrys erotic, = plenty shots, bare butt rides. Came into, spotlight at years old when she. Be held, actionswe not. Birkinjane marchjanet jason love tillyjenny. Herself topless lawn = chairsize wearing, orange bikini, rises. Into spotlight, at years, old when she won. Cmelanie joan hart melissa = sagemiller fed melora. Category film gothika failed, receive nomination, however very, though? Buntonemma hemingemma, canadaseva greeneva. Accept foryour own actions thus releasing creators web. Bob thornton we see halles. Fed melora suvarimia maestromia drivermira ottomischa simsmonica. = Kimgeena davisgena halliwell gigi! Von, swaindona kroesdrew anayaelena = sommerelle foxemilie, ravinemily, watsonemma. Liulucy le taydemandy = arcurimarg bellomaria. Hunthelen bonham swankholly marie combsholly = tyloilary baileyines sastreione pascoivana. Alice dodd fe evansalice = wittalina curtisally oomsamanda. They have couchsize mbrunning, time? Kitaentera amber masontonya helferuma kaprisky valerie, perrine. Nice breasts pulls off! Harring fcd smithlea downlexa, doiglil. Michelle = youngselma, fennsheryl leesienna duezsophie! ------=_NextPart_001_000F_01C761B0.F8C86710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hart melissa sagemiller fed melora! = Stone next had=20 highly, publicized!
Kitaentera amber masontonya helferuma = kaprisky=20 valerie perrine zdrokvida? Woman who takes up struggling politician, = warren=20 beattys, bulworth?
Kimlinda blairlinda lohanling, = bailinnea. Juddasia=20 alyn dallebebe laflinboti roderick brandy ledford brenda = kasscarole!
From all liability webmasters make = money, serious=20 partners parents.
Gallery photos hot sex, scene billy = bob, thornton.
Pinkett smithjaime deggjamie = curtisjana. This movie=20 berrys erotic, plenty shots, bare butt rides.
Came into, spotlight at years old when = she. Be=20 held, actionswe not.
Birkinjane marchjanet jason love = tillyjenny.=20 Herself topless lawn chairsize wearing, orange bikini, = rises.
Into spotlight, at years, old when she = won.=20 Cmelanie joan hart melissa sagemiller fed melora.
Category film gothika failed, receive = nomination,=20 however very, though?
Buntonemma hemingemma, canadaseva = greeneva.
Accept foryour own actions thus = releasing creators web.
Bob thornton we see = halles.
Fed melora suvarimia maestromia = drivermira=20 ottomischa simsmonica. Kimgeena davisgena halliwell gigi! Von, swaindona = kroesdrew anayaelena sommerelle foxemilie, ravinemily, watsonemma. = Liulucy le=20 taydemandy arcurimarg bellomaria. Hunthelen bonham swankholly marie = combsholly=20 tyloilary baileyines sastreione pascoivana. Alice dodd fe evansalice = wittalina=20 curtisally oomsamanda. They have couchsize mbrunning, time?
Kitaentera amber masontonya helferuma = kaprisky=20 valerie, perrine.
Nice breasts pulls off! Harring fcd = smithlea=20 downlexa, doiglil. Michelle youngselma, fennsheryl leesienna=20 duezsophie!
------=_NextPart_001_000F_01C761B0.F8C86710-- ------=_NextPart_000_000E_01C761B0.F8C86710 Content-Type: image/gif; name="Le TaydeMandy.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c761a8$9703ff10$00000000@massimo7k4lvej> R0lGODlhfAEEAoebAAYADXcAAQx/AHyLAA4CiosAcQeJhMC3vcHewK/E8zonBWwWAIkfBqgeAMMa ANgtCwBDACE+AEFKBWM/AHJBA5Q9CLNEAN83AABaABdXAUdtAFRdAntTCqhZALRdCe5fAACJABd9 Bz2ADFJ/Cnp9Cp6CALqAAN6HAAaUACGaDE2YAmOSAIqkDpGfAcChANyTBwDGDCbAAEDMDWnHCIOx AJjNAMK2AOW7CwDfDi7lBj3YAFjXAI7lAJjeAMHkAOLbAA4GRxoOP0EMRWEATnYAM5oEQrMASdwA PAArQysfQTYoO1QWO4orPKAuObYnO+IfPAZMOy02NjxFOGlAQYg/PqRIP75BPOY9QABTPyRSRzds Q2hrNHNcBK5fSrZrPONRNwB8My2GNEh6Mll6PISCNJqANr2IOdqARwqhNCGRSDWjOWWiPYqZPaiu NMWsRuCWMwK/RS29QkrKR1m1OYTANJW3R72/QOHMOwDjSx7WQ0TlNF/aOY3nR6XVO8TYRO3iTgAA jCEAfUIOe2oIfnoCjaMAec0AdeYAdwQtfScnijgdi1gfhYsffpMdg8QlhuglfA49dho2fEFLe1VF f4tDdaVNeb1IeuA4ggBndhRadkVgeWpgeI1qfaVujLZZfdtecwF3jB+HfztyhWuCc3x+jqGNjL2L d9qGcgqTchqSh0Ctc1qYeHacjJyugr+Tf+qqcwK5eynDdzayil7McYa1jaHNeMG2et3HdQDYjS3f eEbkcVLmeYHRdpTcgsnSiODgeAcAzRkHzD0AzlkBxoUAt6oOx8kAuNwNuwATuR0rvzkcslUft40b tKEXy7knwtIVuQA4zRNLszg5ylo5unE6vJpCvLdAs9tIxwBUwSVVvkRhvGlcynhSw61iwrdYvuxX vQCOsxt6xDOCsVJ6uoCNzJuJtLpztt16zQCVsSypyj2TvGGRyH+Uu5OiwMqpuuSduQu3yyy3uzm8 yVLNvHS5yKa+s//866qirot8cf8AAAnxCv/2AAYA9f8C+Qn///H5/yH5BAD//9UALAAAAAB8AQQC Bwj/ADkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAOz5OeQMEJ+hgUrHpmYU+OTiQk/TijZ 4OTCAy9bRrz4b2PNjAuCFn2Y4miFpzvL/SwQseHIrTmLll3ZsWzbkjnXdr1Zd+zctR3jjqzbN+7f j1OrhuuaN8Hg0J9ntt16Ouvq0adjF66du3DY179b/++ufPnb6823D/+cnjjv8JWbw/8Ou7p68eS9 Zy9v3i3r+ruVJp193emHn2XjxWbgfcEZCJ52/PXH1n/5EThffQc6uKCF3h344H0aMihhX+g516GJ mdH23G3O+fbabSm6qGKM+9G224zcRTjijjz26OOPQAYp5JBEFvmSjg0hyZCSRgoWIZOoeaQclE3G 9aSUWC5ZZWfJsTgje14mZx9w7qmH4m9j2ojhloFdOJ6YIkIoInivFfjgfB2y6dmAHlJHWpzbxWdd ezSCKWOhBOq5Z353/tnnm33CmWeB+jWYqKIk8hldnYxSCmCCj54IaqiYApbecWhuCCCMHC7Y4oqT vf9q4qyl1mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimq+667Lbr7rvw5gpATfPGOxYA+M5bL0j7PqSvQ/3a21TAAXdUMEMHJ5Sw wEcVnO+++Q4UMScPS4yvxfpeTNDEFVPscccUa+wxwwMbBPHIKAv0r8oor8xyQSfH/LHELb9M8lIO 0/xwvRXH3PPJMOsstMsZc3wzUzmzTLDQSh90cdIzN010yjYfndTSTWcd9db9ukyz1v9ODbTVA0cM 9MQhP402xyKLrLLGMk+d9tdkg7Vw3TzejffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eacd+7556CHLvropI/bD0b9nD6R6hnprZHrhaeeOiesE3R67QbJjrtArO+u++60 bwQ7RhCD/Dbbw7MLfO4LLT9Q7wg577xEyVfUc0Ny3+w777MHr7rstufePfjgF1R7+bo/3z3G7H9t 9MgEt+0201Q7bXP16G4f/u3BH4T+8/0LoPn8F0D+KcRr9FsZzxCCwKAVb34ba9/R9Jc+/q2PgNCD HgHVN7sMAu9nJqtZ2KgGQoVB8GBjw9+5tpfBAi7PgN4D4AYLSEPuRfB+XRPhzHKIQ4WR0H73Ixvu /2BowfBhEIAaZB7vkCjDJdKNh2AL4g1TtrARvmxsNRMi+bjXQe9dkHblA+P3bKc/Lt4OfV9MW9GC NjcpbsxsEDzeA58IsziWDml3TIsK88jHPrJLH/ooSSBLske+DZITgTzkRQAJSIYo8iGPdEgk+RVC k8HNeAw75CQrosmFbPIjn+QIyE5It6plciCJFAgjUbnKVCKykQTppCtX+cpB0rKWqmykLWHJSE3y kiReayAWC2muWRbElYh8pUEUKUtbojKZqnwmM2MJzWR2kpqhfF0WoQbFoxmzlshEJjhjSctrWpOV rfSlNNcZzXFm83WXRJsbiVlMaIazmvdspz71Kf/LZy5TnffsZzTfqc1uznNvAj3nQP1ZzYbik50P Zeg5ExrQg1o0iw6c4gKvaEh/9jKXuiQnLPfZ0HKKFKQotecv2/nRQaaQjheVIxtb1jbGEdRunrvl Wujpx576dFtpdMj0YsJTITJRI+lTogDNCLyhwgRqM+VbEjMy1KkacYY3GSUKi5q/o4axgv0LoxPJ +L0OpvF84/tqUFMSzPqZcm8GHCINz2q+8R11qU3c312fuk0GAi6uZpwrWV8o2LEOkINEBONMkBdH rnZ1jC1cYhIJG1m8jrWyvXOqSdoKxL9htrA1ZN5nZzhaJ770oqfFaAShaFCpyjCpYEXsYDloWLr/ yha260utbmGqWjXOdI6P0yxOOydWtTj2p8hN7pZuKpbjerOVBxGncTHWWJ5h8pSOfMv1fNhZkkVy l84E71myV8ny3uy7x5zodB/oMHm61V7odac1mbsV9/7Qjd5c5kPDSd+sIBBrvT1vevs5TY3ydreo PbCCE4zfoblPis4NV0tBmspEjnTBGEVwhjGs4Q7XUX4prKlyrzZir0S4xChO8eJOrL3iSkR6e8Wj BKnLYnEJ9yJWRZrZSvleuPovrev7X1wvGFm1drGsN1ZJA+8buDIm1oOSjV5YBwjlw9rkv+21o1HF KMYuSja2MTxiWLcYZdnixL5V9KxerwrDy1o2/8xPvmuOafJf7vrts3iOMZtBm1jTcvjPDM7o2Ros VTSO0Yn/Q7RtxwzkNifVw4HWsEyP90QtKzfJdFbxi9fakxpr+tOg/pun4/XRvAD4wzMWMF861tgE ku27vNSlL/tLlTofMMCZXKlCnUnNezHZkql+9X5ZSuGyyFNv5BW2QMMr0ebierU8tlpF7RlRSG84 0oC+trZRqNqNcu3VtzQptce57Wxb+9zm/jBwabruUPNk1O5ebLznTW9MNVUq8IbX7zpy76h0zY7s zXe2MC1UrJbtadFutY/LbGjFctHMiXbKkrkd1bplVrSIprKc34wUYfq14lsWYGwPDeY4Q+XYdv9+ a8gnO+Uwu9zkJ4ffrae48NAC9uV87h+6sc1zbUMbqq21eF5HruhGP1zn6e75znvLalZLUOD1vgjU o65kqlv96oGb+rroK11jVzxhjNU6s2hN66s0/Y2dPTW8HinuiYZUvFyxdbS77d1eK1S9udRvfX/t 1mHWHZ2/ZPY+S11ft6mdunN/V4GxuVB+Ntu/TF8IFuFrd3Pms9pJL7fSM8/tyRt08vAt54WvGVLA b/70mk+959cG4krTHOstETvsRSL72dv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/ +dCPvvSnT/3qu7v2FsE+9uB1XeztOITDkxn/WyFysHyYPx8DOT/6BWJ+gqz/1hEOOrFAL/ntz5zQ myW/Qd7PCfTz3//sF4AI8xHyNyzi920JR2lRg3J0ZF3stYAnFE8P+EbxpIAHAYDp138CyH+WhHBt hDxB1HTehixOF0UJ+HN9l1E/5DPmBW0mGIL0gxAYGIDrN4NptzVU5GoH2GPCcoALdHgOOEIg5nQb tV04iElGSF4+830yKIAbWIPsx4E6JGIwGEUF2IOuhoP1IzY09XoKpEMvyFpgmINao3L9937/t38a uIYNaDFk+G07qH394YNztzRxQ3PcNIbZI4Z02IZlmIHuF4iCCIUGlkN8qIPQolVUqG7ws2Nr//R6 28RYVOReSThpiNdGISOImsiGG+iEiPeIHziEkWiGiZgTUzc86td+Z6iKgBiFhyOHDGRpwiOL1leL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0qiM+XZ49Wd/FAGLPJgt qRWLHph4MdVdCKiF4beNv3V/tKdNx9KNLVg97NiOPgeOIDeApGiOraOOxnJalMiIH7OPEAY3EPiN 4ieCHSiEFghHVjSJDniOH+hglxiKGfN0yWKQTAeQUsNjFMmCCJiReliImTiGHYlhHamRfriAJqiN i5GR3QeHkWdFdDhoLilCxnOHcsRZMgdgnv8nc1ZYXlx4kyW4jjtUjzuZkzG5kxwVkzvokTkJU3JH lFWohSN5lC1YLJLmgkH5VrvVhxumlVNYkvH4lS+VlFF5k/JogKVEie+zQ/bVbRbZiFR4NiDIiMHU eplIfxVoXqz3jUxpkUW4iOWCkixBTICpLoNZddk4jYiZmFNRmKtGfw95jYepgvnHk/oXmfhIjwbo mPg3lff4ErKHfYy5F1+IiVWzkJQWlzapQAi3lr4VkO3jiP1YgaaJhBbYmhDpgnnJhao5gWb5g2dp lampMzh5hDyokXGIdixplDlIccmJnC85NN6WbMDim36HiArWeUojlh5Zkx/5hj3ZnIaYh2L/GXBR SZ6aySvU+ZvWeVDY2YVLVpJb5Z1jOY5dCJ9biJGIuJT2iCvFQ3ccVYZh+XHL+YZP6XeHqJxKiIfr eZ35aZ/z54akaZuYyDYKCHbC2Zem9JO3eZoX2p+z+Zv+6JYQWpqi6FtzyZuIY43EUxSh2S5QJTws qpgyOqM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqREWqRGeqRImqRKuqRMSi08ZWnvWZm+8o6TKRFg EiMpQincGRGsaT9RmnJ+VVSu06LjxVvjZ6UYsiljAqYAU5Zm2qb1J6aYySb6GIECWaEi2ppxGaGt EikggpcS+HWRSJ13SoG12ZD/BpCmaaLu/6M2i0okHFmaWSic4Dep0pmmrsIpAsqVdoifCVmdUImC DRid8/lsQqKSDLiRTMioYPMz9oWpa5IjlxGgkgqcMpWQ5BiDnyiftNqc9dkkkUqZz1mgkUcZnXIp AcKQ9NmpQzmg26mUzzqsxImcRiJp0rqHIUmffZodazopvTqc5cl3IAmDBzqfNummeXOWdhqEt0qB cnOXfDorYeIorEKi7NqB7tqu1lWHbZmvJzqCuTlpFNqlu0KmwDSnlukRBrslBLuY3pd9IbGwTTqx FFuxFnuxGJuxGruxHNuxHvuxIBuyIjuyJFuyJnuyKJuyKruyLNuy1icfCtIbhvIis7EZNv8rH+0B s7CCs6DmJX5is1mqIPMKtCvyszWbKkbrbqySG4dBHKShJk17s5oBIz47b/Uas0B7tdRxJkVbs1pL tU5rtVM7tlg7G1zbtUX7tewRtPGmtlGbtDSyEDibs3P7s2BbtyrmtgdhI017tmybpWp7Kn8banqb tWTrt3BbHG+7tFSSR4V7tHrrt/WquHsbtmWrtGJSuEtrt1c7uUxbuVh6uYTrs5pLuld6tGlLtqGr tT17KngruOtxuWfiueuRs2Zbu4jrsrq7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veBfG77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AHMACPMAEXMAGfMAInMAKvMAM3MAO/MAQHMESPMEUXMEWfMEYnMEavMEc 3MGNExAAOw== ------=_NextPart_000_000E_01C761B0.F8C86710-- From sip-bounces@ietf.org Thu Mar 08 13:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNnB-0002x8-NK; Thu, 08 Mar 2007 13:56:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNnB-0002x3-2t for sip@ietf.org; Thu, 08 Mar 2007 13:56:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPNn8-0001rp-CK for sip@ietf.org; Thu, 08 Mar 2007 13:56:45 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2007 10:56:37 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="398822296:sNHT2022244296" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l28IuaKX010279; Thu, 8 Mar 2007 10:56:36 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l28Iu3Zx027845; Thu, 8 Mar 2007 18:56:36 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 13:56:34 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 13:56:33 -0500 Message-ID: <45F05C65.80107@cisco.com> Date: Thu, 08 Mar 2007 13:56:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <11125.30215.qm@web31511.mail.mud.yahoo.com> In-Reply-To: <11125.30215.qm@web31511.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2007 18:56:33.0838 (UTC) FILETIME=[7DA564E0:01C761B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5469; t=1173380196; x=1174244196; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20; bh=ssjb+LhiZEhZ4cw1akY2lG9GKAtm6Ld9rpU3j/4v01k=; b=MmDkNpP4UXCzHOByLU/+IrZRqaEEhYBNGEffTB2RXOM6SGnR/jXAb+FR9eCZkefiAxUhHn7P EsB/mESir8arnlcot6YZN3XUrzsvz0F/BvyD0lmb4/LvAqzSRWtadiBJ; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Kapil Nayar wrote: > Hi > > Thanks for pointing to the new draft....its an > excellent piece and clarifies a lot of confusion. A > few questions though:- > > 1. Is there a specific reason for disallowing Pattern4 > in Table1 for changing media in an early dialog..may > be I am missing something here. Its been a long time, and I don't recall all the reasoning that went into this. This was partly a matter of inferring original intent in all the pertinent RFCs, and extrapolating where things are unclear. We concluded that this was the only self consistent interpretation that works in all cases. (The assumption being that an interpretation that didn't work must not be the right one.) If you were to allow a second o/a exchange via reliable 1xx, then it would have the potential for a race with a concurrent UPDATE in the other direction. And that would result in a need to send an error response. But PRACK isn't prepared for carrying an error response. Forcing subsequent o/a to use UPDATE avoids this. > Anticipate an incoming > Invite (call) replied with multiple provisional > responses (an IVR-183 and then a server queue-182). > UAS may decide to have media with different > characteristics/ source for these instances within the > call. Only allowing UPDATE for changing early dialog > media seems to be more restrictive and may need more > message exchanges. It may take an extra message, but it is cleaner. It is not more restrictive in what can be done. > 2. Just to clarify, in Figure1 "After F6 UAC and UAS > can send a new offer in an UPDATE request", I guess > the authors meant F7. Debatable. I think the UAS can send an UPDATE after sending F6, without waiting to receive F7. (With the understanding that the UPDATE could fail if received before F6.) The UAC should probably wait until it sends F7. > 3. In the description for Figure1 it is indicated that > F12 (final response) should not contain an SDP, and if > it does and is different than F6, the UAC should > discard it. (Similar description is present in > Figure2.) > > a).Does this mean that a UAS cannot change the early > media to a final media in final response? It means that each offer has been answered, and that once an answer has been sent, it can't be changed without another offer/answer cycle. And that another offer/answer cycle may not be initiated in the 2xx if one has already been completed. This last is part of a principle that was discovered during the evolution of this work: At most one offer and one answer per transaction. At the time of F12, if the UAS wants to change the SDP, it can send an UPDATE before sending the 2xx for the INVITE. Or it can send the 2xx and send an UPDATE or reINVITE after the ACK. > b).If F12 carries SDP, it should be designated as a > new offer-SDP, right? If UAC discards the offer-SDP in > F12, is it still obligated to send an answer-SDP in > ACK? No. This is all as specified in 3261. Having sent an unreliable provisional with an answer in F2, if there is any SDP in the 2xx it must be identical to what was sent in F2. It is *not* another offer, and so it there must not be an answer to it in F13. > c).If UAC accepts the offer-SDP in F12, can the > answer-SDP in ACK be different than the one originally > offered in F1? What is the behavior expected at the > UAS upon receiving this different media? See above. > I don't know if it is too early to ask, but whats the > estimated time-frame for this draft to be moving to an > RFC? Pretty soon. I think there is hope for WGLC in April. Paul > thanks, > Kapil Nayar > > --- Paul Kyzivat wrote: > >> >> Christer Holmberg (JO/LMF) wrote: >>> Hi, >>> >>>>> I think this is an interesting question, and >> should be added to the >>>>> offer-answer draft. >>>> It is covered. (It says you can't do it.) >>> Ok. Good. >>> >>> Note, however, that it should be perfectly ok to >> send an SDP offer in >>> the INVITE without any m= lines >> Yes it should. >> >>> (you do need to include a c= line, though). >> We disagree on that. Dale and I both interpret the >> existing spec as >> saying you only need c= if you have m=. >> >>> That way you can add the media parts later. >>> >>> Whether terminals will support it is another >> issue.... >> >> Yes, that is likely to be a problem. >> >> If I send an invite that offers media (say MSRP) and >> it forks to >> multiple UAs (say one that supports MSRP and one >> that supports voice) >> then I want the one that supports voice to answer >> and the one that >> supports only MSRP to reject the invite. The >> rejection is because it has >> no matching media. >> >> If that is agreed as desired behavior, then what >> should those two >> devices do when receiving an offer with no media? It >> would seem that >> either they will both ring, or both reject. What >> happens if a ringing >> device is answered? Its not a very useful call with >> no media. >> >> This is potentially useful, but only if there is >> some understanding of >> what is expected and what should happen next. >> >> Paul >> > > > > > > ___________________________________________________________ > Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 15:47:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPVd-0004vK-GN; Thu, 08 Mar 2007 15:46:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPVb-0004sx-6K for sip@ietf.org; Thu, 08 Mar 2007 15:46:43 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPVV-0006yr-Qr for sip@ietf.org; Thu, 08 Mar 2007 15:46:43 -0500 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l28JqXVm020937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2007 13:52:34 -0600 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Keepalive mechanisms for TCP flows in outbound-08 Date: Thu, 8 Mar 2007 14:46:32 -0600 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 8, 2007, at 1:58 AM, wrote: > > Hi, > > Outbound-08 specifies the CRLF keepalive technique like this: > > 3.5.1. CRLF Keepalive Technique > > This approach can only be used with connection-oriented transports > such as TCP or SCTP. The client periodically sends a double-CRLF > (the "ping") then waits to receive a single CRLF (the "pong"). If > the server does not receive a "pong" within an appropriate > amount of > time, it considers the flow failed. > > Question 1: > > Is the single CRLF "pong" necessary or could the UA detect the > flow failure just by receiving a socket or ICMP error when the > connection is broken and not able to pass the double-CRLF "ping" > to the proxy ? Sure, if you don't mind not getting calls for 10 minutes. And if some moron hasn't blocked ICMP on your network (which unfortunately corpsec guidelines frequently recommend). It can take TCP a LONG time to know a flow has failed. This is a large part of why I liked the STUN model. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 15:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPXQ-0005ug-RW; Thu, 08 Mar 2007 15:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPXP-0005uT-PI for sip@ietf.org; Thu, 08 Mar 2007 15:48:35 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPXO-0007Hy-FV for sip@ietf.org; Thu, 08 Mar 2007 15:48:35 -0500 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l28JsJfB020955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2007 13:54:20 -0600 In-Reply-To: <3E4278088AD82C48B4663DDFE762CEF302A48F31@prga004a.ww300.siemens.net> References: <45EC89B7.5070501@cisco.com> <45EE7189.4000201@nokia.com> <3E4278088AD82C48B4663DDFE762CEF302A48F31@prga004a.ww300.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0683539F-437C-43E1-B820-BD329BD273C8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" Date: Thu, 8 Mar 2007 14:48:18 -0600 To: "Dostal, Pavel" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: fluffy@cisco.com, sip@ietf.org, OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG, "Drage, Keith \(Keith\)" , OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, Antti Laurila X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 8, 2007, at 3:17 AM, Dostal, Pavel wrote: > OMA defines a group document in a similar way as the RLS services > document is defined in draft-ietf-simple-xcap-list-usage. The group is > identified by URI that must be unique along all groups inside an XCAP > root and there is a global document representing all groups stored in > the users tree. > As the enabler server may need to get access to the group based on its > URI, the enabler must access the global document. In case the enabler > needs to know about the changes in the group document, for example to > remove a participant from a conference when the participant is removed > from the group document, there is a need to subscribe for changes of > such global document. And as such document may be really huge and only > few groups have the service (conference) active in some time, > subscription to only part of the global document is needed. This strikes me as a design issue. If the "global document" were a collection and each "group" a document, we wouldn't have this problem. Of course, I seem to recall saying this in OMA meetings and getting lots of funny looks from the room. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 08 16:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPjB-0002oI-5D; Thu, 08 Mar 2007 16:00:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZq-0007w6-4A; Thu, 08 Mar 2007 15:51:06 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZn-00026J-Ft; Thu, 08 Mar 2007 15:51:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B07DA2AD08; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007Gp-Dy; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-12.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-12.txt Pages : 37 Date : 2007-3-8 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-12.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: <2007-3-8120556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8120556.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Mar 08 16:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPj8-0002nw-QB; Thu, 08 Mar 2007 16:00:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZp-0007vy-T7; Thu, 08 Mar 2007 15:51:05 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZn-00026D-5n; Thu, 08 Mar 2007 15:51:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6BBFB2AD03; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007GI-4q; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-ice-option-tag-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-ice-option-tag-01.txt Pages : 8 Date : 2007-3-8 This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-ice-option-tag-01.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-ice-option-tag-01.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: <2007-3-8114803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-ice-option-tag-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-ice-option-tag-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8114803.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Mar 08 17:14:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPkS-0005QL-9n; Thu, 08 Mar 2007 16:02:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZq-0007wn-Rq; Thu, 08 Mar 2007 15:51:06 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZn-00026H-DI; Thu, 08 Mar 2007 15:51:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 924AD2AD05; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007GX-9U; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hitchhikers-guide-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : A Hitchhiker's Guide to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-hitchhikers-guide-02.txt Pages : 31 Date : 2007-3-8 The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hitchhikers-guide-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-hitchhikers-guide-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: <2007-3-8115251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hitchhikers-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8115251.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Mar 09 04:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb2t-0003MF-9m; Fri, 09 Mar 2007 04:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQDs-00057Y-GW for sip@ietf.org; Thu, 08 Mar 2007 16:32:28 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPop-0002PT-PT for sip@ietf.org; Thu, 08 Mar 2007 16:06:54 -0500 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l28KCIlk021266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2007 14:12:19 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) To: SIP IETF Message-Id: From: Dean Willis Date: Thu, 8 Mar 2007 15:06:17 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: Cullen Jennings Subject: [Sip] Yet another revised SIP agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0662783514==" Errors-To: sip-bounces@ietf.org --===============0662783514== Content-Type: multipart/alternative; boundary=Apple-Mail-1--340234519 --Apple-Mail-1--340234519 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I had the wrong version of outbound (should be -08) linked, and Richard Barnes's draft on early media has moved to the SIPPING agenda. MHTML follows: Draft Agenda, SIP at IETF 68 Session 1: Tuesday March 20, 2007 1740-1840 Grand Ballroom Discussion Lead Topic Reading List Est. Time Chairs Agenda bash, status, announcements This document 5 Jonathan Rosenberg ICE Option Tag draft-ietf-sip-ice-option-tag-01 15 Jonathan Rosenberg GRUU changes draft-ietf-sip-gruu-12 20 Robert Sparks Process for Revising 3261 Mechanism for Publication Prioritization of Issues Which current drafts are bugfixes? 20 Session 2: Wednesday, March 21, 2007 1300-1500 Congress II Discussion Lead Topic Reading List Est. Time Francois Audet SIPS: Guidelines draft-ietf-sip-sips-02 30 Cullen Jennings Outbound draft-ietf-sip-outbound-08 45 If time permits ... Marc Petit-Huguenin Fragmentation draft-petithuguenin-sip-outbound-fragmentation-02 15 Jae Woo Lee Henning Schulzrinne SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-00 15 Mayumi Munakata Clarification of Privacy draft-munakata-sip-privacy-clarified-00 15 Thomas Froment Record route management draft-froment-sip-record-route-fix-00 10 --Apple-Mail-1--340234519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I had the wrong version of = outbound (should be -08) linked, and Richard Barnes's draft on early = media has moved to the SIPPING agenda.


MHTML = follows:

Draft Agenda, = SIP at IETF 68


Session 1: = Tuesday March 20, 2007 1740-1840 Grand = Ballroom

Discussion Lead
Topic
Reading = List
Est. = Time
Chairs
Agenda bash, status, announcements
This document
5
Jonathan = Rosenberg
ICE Option Tag
15
Jonathan = Rosenberg
GRUU changes
20
Robert Sparks
Process for Revising = 3261
Mechanism for = Publication=A0
Prioritization of = Issues=A0
Which current = drafts are bugfixes?

=A0

20

Session 2: Wednesday, March 21, 2007 1300-1500 Congress = II

<= TD valign=3D"middle" style=3D"width: 65.0px; margin: 0.0px 1.0px 0.0px = 1.0px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 4.0px = 0.0px 4.0px">
10
Discussion Lead
Topic
Reading = List
Est. = Time
Francois Audet
SIPS: Guidelines
30
Cullen Jennings
Outbound
45
If time permits = ...
Marc Petit-Huguenin
Fragmentation
15
Jae Woo Lee
Henning Schulzrinne
SIP URI Service Discovery using = DNS-SD
15
Mayumi Munakata
Clarification of = Privacy
15
Thomas Froment
Record route = management

= --Apple-Mail-1--340234519-- --===============0662783514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0662783514==-- From sip-bounces@ietf.org Fri Mar 09 04:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbFx-0004mW-G0; Fri, 09 Mar 2007 04:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQD2-000500-3z for sip@ietf.org; Thu, 08 Mar 2007 16:31:36 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPQ5Q-0006nC-QY for sip@ietf.org; Thu, 08 Mar 2007 16:24:14 -0500 Received: from [172.17.2.61] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l28LNbCj023460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2007 15:23:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45F07EDE.2040001@nostrum.com> Date: Thu, 08 Mar 2007 15:23:42 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Cullen Jennings , Jon Peterson , Jason Fischl , SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Dean Willis Subject: [Sip] draft-ietf-sip-certs-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean asked me to review draft-ietf-sip-certs-03 specifically to evaluate its use of RFC 3265. Based on my reading, its use of 3265 is correct, with one minor exception (which relates to terminology, not protocol behavior). The document describes two event packages (certificate and credential). Both packages are described exclusively in the context of a credential server, which fields SUBSCRIBE and PUBLISH requests, and sends NOTIFY requests. In particular, normal user endpoints appear to be disallowed from receiving the SUBSCRIBE requests or responding to the NOTIFY requests. This credential server that is described for both event packages is the poster-boy description of a "State Agent" as described in section 4.4.11 of RFC 3265. However, sections 6.12 and 7.14 of draft-ietf-sip-certs-03 both contain language which prohibits the use of state agents. This prohibition is nonsensical in the context of the proposed architectures. Both event packages, in fact, appear to require the use of state agents, and (by my reading) cannot be made to work without them. To avoid confusion regarding the term "State Agent," draft-ietf-sip-certs-03 should be revised to clarify that the credential server *is* a State Agent, and that State Agents are mandatory for the event packages described in the document. As an unrelated nit that I noticed in reviewing draft-ietf-sip-certs-03: this document uses "header" in many places where "header field" would be correct. (RFC 3265 is guilty of this same transgression in many places, which probably influenced this erroneous use in draft-ietf-sip-certs-03). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 04:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbFa-0004Mj-Vw; Fri, 09 Mar 2007 04:18:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPROK-0004h0-7K for sip@ietf.org; Thu, 08 Mar 2007 17:47:20 -0500 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPROG-0005ME-KP for sip@ietf.org; Thu, 08 Mar 2007 17:47:20 -0500 Received: (qmail 4724 invoked by uid 0); 8 Mar 2007 22:46:46 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Mar 2007 22:46:46 -0000 Message-ID: <002801c761d3$ab26a9e0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-gruu-12.txt Date: Thu, 8 Mar 2007 23:46:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, 4 comments: 1. Section 5.1: recommend to somehow explicitly add that for a contact which has expires=0, it should be avoided to construct a public GRUU or any new temporary GRUUs 2. Section 5.2: the text about Contact:* and Expires:0 is better placed in section 5.1 3. Section 6.2 second paragraph: could add explicitly that the GRUU needs to be still valid 4. Section 9 (Example call flow) remark under last message: what if the GRUU-enabled registrar does not support outbound? More on point 4: the text in outbound-08 regarding "most recent registration first" is in section 3.2: "If the instance-id and reg-id are the same as a previous registration for the same AOR, the registrar replaces the old Contact URI and flow information." This means that the example will not work correctly unless the registrar supports this part of outbound behavior (with a difference that it won't necessarily need to deal with 'reg-id') Perhaps this hints at a missing requirement for the authorative proxy: namely that it MUST target Contacts with the same instance-id in most-recent-first order, and MUST NOT try a second one if a first one gives a final response (ref section 7 of outbound-08) nits: - in section 4.4: The only reason not to use a *public* GRUU would be privacy considerations - section 5.3: yet still meet -> add s - in section 10.3: invalidate temporary a GRUU (switch "temporary" and "a") Regards, Jeroen Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol Working >> Group of the IETF. >> >> Title : Obtaining and Using Globally Routable User Agent (UA) URIs >> (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. >> Rosenberg >> Filename : draft-ietf-sip-gruu-12.txt >> Pages : 37 >> Date : 2007-3-8 >> >> Several applications of the Session Initiation Protocol (SIP) require >> a user agent (UA) to construct and distribute a URI that can be >> used by anyone on the Internet to route a call to that specific UA >> instance. A URI that routes to a specific UA instance is called a >> Globally Routable UA URI (GRUU). This document describes an >> extension to SIP for obtaining a GRUU from a registrar and for >> communicating a GRUU to a peer within a dialog. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-sip-gruu-12.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-sip-gruu-12.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 04:26:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbMa-0001WL-0l; Fri, 09 Mar 2007 04:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPWKS-0004Pw-7S for sip@ietf.org; Thu, 08 Mar 2007 23:03:40 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPWKP-00077E-Ut for sip@ietf.org; Thu, 08 Mar 2007 23:03:40 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070309040324m13007ge9ee>; Fri, 9 Mar 2007 04:03:34 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2943NtB015980 for ; Thu, 8 Mar 2007 23:03:23 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2943NUR015976; Thu, 8 Mar 2007 23:03:23 -0500 Date: Thu, 8 Mar 2007 23:03:23 -0500 Message-Id: <200703090403.l2943NUR015976@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20C3595B-9392-477C-BF6F-F246F67CBD1D@cs.columbia.edu> (jae@cs.columbia.edu) Subject: Re: [Sip] draft-lee-sip-dns-sd-uri-00 - SIP URI Service Discovery using DNS-SD References: <200703061607.l26G7UID032011@dragon.ariadne.com> <20C3595B-9392-477C-BF6F-F246F67CBD1D@cs.columbia.edu> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jae Woo Lee > 5.2. Request Destination > > It seems to me that this could be both simplified and corrected by > just saying that if a "contact" attribute is available, it should be > used as the request-URI of any out-of-dialog SIP request. Since this > definition automatically refers to RFC 3263, it allows a lot of > generality while behaving correctly in various special cases. > We specify in Section 5.1 that the Request-URI must be set from the SIP URI from the service instance name (which SHOULD be AOR.) We look at the contact attribute to determine where to send the request. We felt that this is natural since the Request-URI then reflects the logical recipient who advertised the service. I'd suggest that you change this so that the SIP URI from the service instance name is the To value, and the URI part of the contact becomes the request-URI. This gives DNS SD the same redirection power as a proxy/registrar. It also allows you to not have to specify how the contact value is to be interpreted, because you inherit all the rules of RFC 3263 automatically. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 04:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbOT-0004S5-6b; Fri, 09 Mar 2007 04:28:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPYcJ-0007tq-A9 for sip@ietf.org; Fri, 09 Mar 2007 01:30:15 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPYcG-00005E-R0 for sip@ietf.org; Fri, 09 Mar 2007 01:30:15 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l296U0kI030416; Fri, 9 Mar 2007 08:30:05 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 08:30:04 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 08:30:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Keepalive mechanisms for TCP flows in outbound-08 Date: Fri, 9 Mar 2007 08:30:04 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F036F8BC2@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Keepalive mechanisms for TCP flows in outbound-08 thread-index: AcdhwubG50pxXUJcRsuOaMpSwvuj1wATKS1g References: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 09 Mar 2007 06:30:04.0746 (UTC) FILETIME=[5FAE12A0:01C76214] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070309083010-75419BB0-4F8078F3/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >> Question 1: >> >> Is the single CRLF "pong" necessary or could the UA detect the >> flow failure just by receiving a socket or ICMP error when the >> connection is broken and not able to pass the double-CRLF "ping" >> to the proxy ? > >Sure, if you don't mind not getting calls for 10 minutes. And if some =20 >moron hasn't blocked ICMP on your network (which unfortunately =20 >corpsec guidelines frequently recommend). To overcome this problem, doesn't Outbound strongly promote the UA registering over multiple flows ?=20 This requires the UA to detect when a flow fails. Since such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to use multiple flows to the proxy or registrar. Are you suggesting that this mechanism in the Outbound only has limited or even no value ? >It can take TCP a LONG time to know a flow has failed. This is a =20 >large part of why I liked the STUN model. How does the addition of CRLF keepalive without CRLF "pong" make the situation worse compared using TCP keepalive, which has been considered acceptable for Outbound over several=20 successive draft revisions and is still there without any=20 "pong" other than TCP ACK ? And as you say, it can take TCP a LONG time to know a flow has failed, but not necessarily. The device which rebooted might indicate the broken connection by sending TCP RST, which immediately tells the sender about the flow failure. Even the STUN over TCP model will not guarantee an immediate detection of a failed flow as Outbound suggests that the time=20 between successive keepalives over TCP should be between 95 and=20 120 seconds on top of which the STUN transaction adds 8 seconds=20 to wait for the response. So even with STUN or CRLF "ping-pong" you could not getting calls for two minutes if the UA is relying on one single flow only or using two flows towards two different proxies over a single NAT which reboots. I am still questioning whether the requirement to add CRLF "pong" and 'keep-crlf' URI tags are really worth the extra complexity. Personally I am not at all convinced about it. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 04:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbOz-0005FX-Gb; Fri, 09 Mar 2007 04:28:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPZRT-00040e-0l for sip@ietf.org; Fri, 09 Mar 2007 02:23:07 -0500 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPZRG-0003Nr-4w for sip@ietf.org; Fri, 09 Mar 2007 02:23:06 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zrx.siemens.at with ESMTP id l297LGrP028469; Fri, 9 Mar 2007 08:21:18 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l297MNs3020355; Fri, 9 Mar 2007 08:22:24 +0100 Received: from prga004a.ww300.siemens.net ([163.242.71.105]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 08:22:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" Date: Fri, 9 Mar 2007 08:22:20 +0100 Message-ID: <3E4278088AD82C48B4663DDFE762CEF302A49467@prga004a.ww300.siemens.net> In-Reply-To: <0683539F-437C-43E1-B820-BD329BD273C8@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event" Thread-Index: Acdhwzpp9EcUtOeuQHSESDIciVSa4wAV71aw References: <45EC89B7.5070501@cisco.com> <45EE7189.4000201@nokia.com> <3E4278088AD82C48B4663DDFE762CEF302A48F31@prga004a.ww300.siemens.net> <0683539F-437C-43E1-B820-BD329BD273C8@softarmor.com> From: "Dostal, Pavel" To: "Dean Willis" X-OriginalArrivalTime: 09 Mar 2007 07:22:23.0464 (UTC) FILETIME=[AE806E80:01C7621B] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070309082116-25812BB0-01585B71/0-0/0-15 X-purgate-size: 966/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: fluffy@cisco.com, sip@ietf.org, OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG, "Drage, Keith \(Keith\)" , OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG, Antti Laurila X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 8, 2007, at 9:48 PM, Willis, Dean wrote: >This strikes me as a design issue. If the "global document" were a =20 >collection and each "group" a document, we wouldn't have this =20 >problem. Of course, I seem to recall saying this in OMA meetings and =20 >getting lots of funny looks from the room. I'm sorry but I'm not sure if I understand your comment.=20 In my understanding of usage of RLS (as defined in draft-ietf-xcap-list-usage-05), a SIP request sent to the service URI initiates a download of the list to the SIP service from the global document, because the XUI is not known for the download from users tree. If the SIP service needs from any reason to be informed about the changes of the list, it needs to subscribe to the changes of the global document, but only changes in a small part may be useful for the SIP service. In this case subscription only to the part of the document sounds like useful optimization. Pavel=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 05:51:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcfm-0002Fi-Gc; Fri, 09 Mar 2007 05:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcfk-0002D3-39 for sip@ietf.org; Fri, 09 Mar 2007 05:50:04 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPcfi-0002tX-Q6 for sip@ietf.org; Fri, 09 Mar 2007 05:50:04 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l29Anvu5013433 for ; Fri, 9 Mar 2007 04:49:58 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 04:49:57 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 11:49:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 Mar 2007 11:49:56 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F113@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progression of draft-audet-sip-sips-02 Thread-Index: AcdiOKzrAi/adh1+QTCsM5w6T6Ie5g== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Mar 2007 10:49:57.0031 (UTC) FILETIME=[AD67F370:01C76238] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] Progression of draft-audet-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2117441340==" Errors-To: sip-bounces@ietf.org --===============2117441340== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpUaGUgYXV0aG9yIGhhcyBhcHBhcmVudGx5IGNsb3NlZCBhbGwgb3Bl biB0ZXh0IGluIHRoaXMgY2FuZGlkYXRlIElORk9STUFUSU9OQUwgUkZDDQoNCldlIHdpbGwgYmUg aGF2aW5nIGEgZGlzY3Vzc2lvbiBpbiBQcmFndWUgYXMgdG8gd2hpY2ggaXNzdWVzIGFuZCByZWNv bW1lbmRhdGlvbnMgZnJvbSBBbm5leCBBIHRoYXQgd2Ugd2lzaCB0byBhZGRyZXNzIGFzIGZ1cnRo ZXIgY2hhcnRlciB3b3JrLg0KDQpBcGFydCBmcm9tIHRoaXMgZGlzY3Vzc2lvbiAoYW5kIHRoZXJl Zm9yZSBwb3NzaWJsZSByZXZpc2lvbiBvZiBhbm5leCBBKSwgaXMgdGhlIHRleHQgaW4gdGhlIHJl c3Qgb2YgdGhlIGRvY3VtZW50IGNvbXBsZXRlLCBpLmUuIGl0IGNvdmVycyBhbGwgaXNzdWVzLCBh bmQgdGhlcmVmb3JlOg0KDQpJcyB0aGUgZG9jdW1lbnQgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsPw0KDQooSWYgdGhlIGFuc3dlciBpcyBhZmZpcm1hdGl2ZSwgdGhlbiBteSBleHBl Y3RhdGlvbiBpcyB0aGF0IHdlIGhhdmUgYSByZXZpc2lvbiBpbW1lZGlhdGVseSBhZnRlciBQcmFn dWUsIHRvIGRlYWwgd2l0aCBpc3N1ZXMgcmFpc2VkIG9uIGxpc3QsIGFuZCB0aGUgYW5uZXggQSBk aXNjdXNzaW9uLCBhbmQgdGhlbiBXR0xDKS4NCg0KUmVnYXJkcw0KDQpLZWl0aA0K --===============2117441340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2117441340==-- From sip-bounces@ietf.org Fri Mar 09 05:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcoE-0005nl-JM; Fri, 09 Mar 2007 05:58:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyu3-0004A8-0b for sip@ietf.org; Wed, 07 Mar 2007 11:22:11 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOytW-0007sF-UG for sip@ietf.org; Wed, 07 Mar 2007 11:22:10 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JEJ00GHYJVBQS@firewall.mci.com> for sip@ietf.org; Wed, 07 Mar 2007 16:16:23 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JEJ00IO4JVBES@dgismtp06.mcilink.com> for sip@ietf.org; Wed, 07 Mar 2007 16:16:23 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([153.39.68.168]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JEJ00I65JVBQ2@dgismtp06.mcilink.com> for sip@ietf.org; Wed, 07 Mar 2007 16:16:23 +0000 (GMT) Received: from ASHEVS005.mcilink.com ([153.39.69.148]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 07 Mar 2007 16:16:23 +0000 Date: Wed, 07 Mar 2007 16:16:21 +0000 From: "Iliff, Tina" To: sip@ietf.org Message-id: <623C984B2206AC4CAE7CED15174F019D05AC9A40@ASHEVS005.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: Diversion header draft/RFC status? Thread-index: Acdg0/G07s0Dkd//R5iQny96G6ezbw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Mar 2007 16:16:23.0207 (UTC) FILETIME=[F2D9BB70:01C760D3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Fri, 09 Mar 2007 05:58:47 -0500 Subject: [Sip] Diversion header draft/RFC status? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0500414998==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0500414998== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C760D3.F2AC12DA" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C760D3.F2AC12DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-levy-sip-diversion-08 expired back in 2005. Has History-Info replaced Diversion? Or is there a new draft or RFC? Thanks, Tina Iliff ------_=_NextPart_001_01C760D3.F2AC12DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Diversion header draft/RFC status?

draft-levy-sip-diversion-08 expired back in 2005.  Has History-Info replaced = Diversion?  Or is there a new draft or RFC?

Thanks,


Tina Iliff

------_=_NextPart_001_01C760D3.F2AC12DA-- --===============0500414998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0500414998==-- From sip-bounces@ietf.org Fri Mar 09 05:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcoD-0005nA-SA; Fri, 09 Mar 2007 05:58:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOkJZ-0000kP-1C for sip@ietf.org; Tue, 06 Mar 2007 19:47:33 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOkJW-000184-LX for sip@ietf.org; Tue, 06 Mar 2007 19:47:32 -0500 Received: by nf-out-0910.google.com with SMTP id l36so2846384nfa for ; Tue, 06 Mar 2007 16:47:30 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=nuiB0E2vH8sYRb/1AizCCt6rg5UDDgyCkrl3PbMVxV094bVz94S9DApp741xChjuNeiG8cyPnqF6spSxTcR3LqeesDszLAToZmH6uOa6C4l7BY1v+gT6Vrt1Q9UaeZX3FWFpzy62qdFclvoekQetm3/iyM04U4UMP8Cb8XH1kc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=QS6391kwqMUeB1phlYgaHyaW0hz4PXuQUChpl2hw5MrXujtQ1w03qOoQN4pT4Biyh9eKHnXrLI11b4tdgFwh/iVm9mGqAeoF5bcv76iLKeTBpODIq6SLzPsmGmkEEss4jBGNTO7b2Ifrl3OYfXUVRHWAW+q9tPvtpmUflYS0s/k= Received: by 10.78.172.20 with SMTP id u20mr896482hue.1173228449778; Tue, 06 Mar 2007 16:47:29 -0800 (PST) Received: by 10.78.16.6 with HTTP; Tue, 6 Mar 2007 16:47:29 -0800 (PST) Message-ID: <7bfdc29a0703061647l193f1f22oc45bf6fde6f8d9cd@mail.gmail.com> Date: Wed, 7 Mar 2007 06:47:29 +0600 From: "Imran M Yousuf" To: sip@ietf.org In-Reply-To: <7bfdc29a0703052038i7f3ab2dp4a446592d3a5a733@mail.gmail.com> MIME-Version: 1.0 References: <7bfdc29a0703052038i7f3ab2dp4a446592d3a5a733@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Fri, 09 Mar 2007 05:58:47 -0500 Subject: [Sip] Fwd: About SIP Presence X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: imran@smart-it-engineering.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2058720726==" Errors-To: sip-bounces@ietf.org --===============2058720726== Content-Type: multipart/alternative; boundary="----=_Part_129018_1979975.1173228449750" ------=_Part_129018_1979975.1173228449750 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Friends, I have a query regarding SIP Presence flow. I will illustrate my question with an example. imran@smartitengineering.com REQUEST to SUBSCRIBE to imyousuf@smartitengineering.com EVENT: presence PROXY - Synchronize with NOTIFY to - imran@smartitengineering.com Now my question is how does imyousuf@smartitengineering.com update his information to the PROXY? As far as my understanding goes "imyousuf" will PUBLISH his status to the PROXY; now if the UA of "imyousuf" does not ALLOW PUBLISH, can the PROXY REQUEST to SUBSCRIBE to imyousuf@smartitengineering.com EVENT: presence? Thanks in advance, Imran M Yousuf Entrepreneur & Lead Developer Smart IT Engineering Dhaka, Bangladesh Email: imran@smartitengineering.com Mobile: +880-1711402557 ------=_Part_129018_1979975.1173228449750 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Friends,

I have a query regarding SIP Presence flow. I will illustrate my question with an example.

imran@smartitengineering.com REQUEST to SUBSCRIBE to imyousuf@smartitengineering.com EVENT: presence
PROXY - Synchronize with NOTIFY to - imran@smartitengineering.com
Now my question is how does imyousuf@smartitengineering.com update his information to the PROXY?
As far as my understanding goes "imyousuf" will PUBLISH his status to the PROXY; now if the UA of "imyousuf" does not ALLOW PUBLISH, can the PROXY REQUEST to SUBSCRIBE to imyousuf@smartitengineering.com EVENT: presence?

Thanks in advance,

Imran M Yousuf
Entrepreneur & Lead Developer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557


------=_Part_129018_1979975.1173228449750-- --===============2058720726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2058720726==-- From sip-bounces@ietf.org Fri Mar 09 07:33:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPeGp-0007Ym-Gm; Fri, 09 Mar 2007 07:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPeGo-0007Ye-0J for sip@ietf.org; Fri, 09 Mar 2007 07:32:26 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPeGm-0003yP-PX for sip@ietf.org; Fri, 09 Mar 2007 07:32:25 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l29CWC304398 for ; Fri, 9 Mar 2007 12:32:12 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Progression of draft-audet-sip-sips-02 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 Mar 2007 06:32:11 -0600 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180E1F113@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progression of draft-audet-sip-sips-02 Thread-Index: AcdiOKzrAi/adh1+QTCsM5w6T6Ie5gADf4cg From: "Mary Barnes" To: "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm assuming you're referring to draft-ietf-sip-sips-02, rather than the individual doc? I think the WG document is ready for WGLC. Mary -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Friday, March 09, 2007 4:50 AM To: sip@ietf.org Subject: [Sip] Progression of draft-audet-sip-sips-02 (As WG chair) The author has apparently closed all open text in this candidate INFORMATIONAL RFC We will be having a discussion in Prague as to which issues and recommendations from Annex A that we wish to address as further charter work. Apart from this discussion (and therefore possible revision of annex A), is the text in the rest of the document complete, i.e. it covers all issues, and therefore: Is the document ready for working group last call? (If the answer is affirmative, then my expectation is that we have a revision immediately after Prague, to deal with issues raised on list, and the annex A discussion, and then WGLC). Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 07:43:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPeQe-0001rh-T8; Fri, 09 Mar 2007 07:42:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPeQe-0001qB-2y for sip@ietf.org; Fri, 09 Mar 2007 07:42:36 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPeQc-0006EY-Kw for sip@ietf.org; Fri, 09 Mar 2007 07:42:35 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l29CgLf1006040 for ; Fri, 9 Mar 2007 06:42:30 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 06:42:24 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:42:23 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Progression of draft-ietf-sip-sips-02 Date: Fri, 9 Mar 2007 13:42:22 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F207@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180E1F113@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progression of draft-ietf-sip-sips-02 Thread-Index: AcdiOKzrAi/adh1+QTCsM5w6T6Ie5gAD3GaA From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Mar 2007 12:42:23.0656 (UTC) FILETIME=[62B53A80:01C76248] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946909323==" Errors-To: sip-bounces@ietf.org --===============0946909323== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdGlvbiwgaW4gdGhlIG9yaWdpbmFsIG1haWwgSSB3YXMgaW50ZW5kaW5nIHRvIHJlZmVy IHRvIA0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNp cC1zaXBzLTAyLnR4dA0KDQpUaGFua3MgdG8gTWFyeSBmb3IgcG9pbnRpbmcgb3V0IG1yIGVycm9y Lg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogRHJhZ2UsIEtlaXRoIChLZWl0aCkgW21haWx0bzpkcmFnZUBhbGNhdGVsLWx1Y2VudC5j b21dIA0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDA5LCAyMDA3IDEwOjUwIEFNDQo+IFRvOiBzaXBA aWV0Zi5vcmcNCj4gU3ViamVjdDogW1NpcF0gUHJvZ3Jlc3Npb24gb2YgZHJhZnQtYXVkZXQtc2lw LXNpcHMtMDINCj4gDQo+IChBcyBXRyBjaGFpcikNCj4gDQo+IFRoZSBhdXRob3IgaGFzIGFwcGFy ZW50bHkgY2xvc2VkIGFsbCBvcGVuIHRleHQgaW4gdGhpcyANCj4gY2FuZGlkYXRlIElORk9STUFU SU9OQUwgUkZDDQo+IA0KPiBXZSB3aWxsIGJlIGhhdmluZyBhIGRpc2N1c3Npb24gaW4gUHJhZ3Vl IGFzIHRvIHdoaWNoIGlzc3VlcyANCj4gYW5kIHJlY29tbWVuZGF0aW9ucyBmcm9tIEFubmV4IEEg dGhhdCB3ZSB3aXNoIHRvIGFkZHJlc3MgYXMgDQo+IGZ1cnRoZXIgY2hhcnRlciB3b3JrLg0KPiAN Cj4gQXBhcnQgZnJvbSB0aGlzIGRpc2N1c3Npb24gKGFuZCB0aGVyZWZvcmUgcG9zc2libGUgcmV2 aXNpb24gDQo+IG9mIGFubmV4IEEpLCBpcyB0aGUgdGV4dCBpbiB0aGUgcmVzdCBvZiB0aGUgZG9j dW1lbnQgDQo+IGNvbXBsZXRlLCBpLmUuIGl0IGNvdmVycyBhbGwgaXNzdWVzLCBhbmQgdGhlcmVm b3JlOg0KPiANCj4gSXMgdGhlIGRvY3VtZW50IHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbD8NCj4gDQo+IChJZiB0aGUgYW5zd2VyIGlzIGFmZmlybWF0aXZlLCB0aGVuIG15IGV4cGVj dGF0aW9uIGlzIHRoYXQgd2UgDQo+IGhhdmUgYSByZXZpc2lvbiBpbW1lZGlhdGVseSBhZnRlciBQ cmFndWUsIHRvIGRlYWwgd2l0aCBpc3N1ZXMgDQo+IHJhaXNlZCBvbiBsaXN0LCBhbmQgdGhlIGFu bmV4IEEgZGlzY3Vzc2lvbiwgYW5kIHRoZW4gV0dMQykuDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBL ZWl0aA0KPiANCg== --===============0946909323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0946909323==-- From sip-bounces@ietf.org Fri Mar 09 09:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgM8-00070g-Jn; Fri, 09 Mar 2007 09:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgM7-00070b-3e for sip@ietf.org; Fri, 09 Mar 2007 09:46:03 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgM1-0005tT-0h for sip@ietf.org; Fri, 09 Mar 2007 09:46:03 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l29Eji6Z010841 for ; Fri, 9 Mar 2007 08:45:56 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 08:45:56 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 15:45:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 Mar 2007 15:45:54 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F2E6@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making sense of the SIP author drafts Thread-Index: AcdiWaOo/0i6T+HBSCWrZ3+RaCYiUA== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Mar 2007 14:45:54.0719 (UTC) FILETIME=[A40BB2F0:01C76259] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Sip] Making sense of the SIP author drafts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0764408425==" Errors-To: sip-bounces@ietf.org --===============0764408425== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KGFzIFdHIGNoYWlyKQ0KDQpJIGhhdmUgYmVlbiBhdHRlbXB0aW5nIHRvIG1ha2Ugc2Vuc2Ugb2Yg dGhlIGxhcmdlIG51bWJlciBvZiBhdXRob3IgZHJhZnRzIG91dCB0aGVyZSB3aGljaCBpbiBzb21l IG1hbm5lciBpbXBhY3QgU0lQLiBJIGhhdmUgdGhyZWUgY2F0ZWdvcmllczoNCg0KLQlCdWdmaXhl cyAoZG9jdW1lbnRzIHdoaWNoIG1heSBmYWxsIGludG8gdGhlIGNyaXRlcmlhIGlkZW50aWZpZWQg aW4gZHJhZnQtZHJhZ2Utc2lwLWVzc2VudGlhbC1jb3JyZWN0aW9uLTAxKQ0KLQlTSVAgZXh0ZW5z aW9ucyAod2hpY2ggbmVlZCB0byBiZSBTSVAgY2hhcnRlciBpdGVtcyBkdWUgdG8gUkZDIDM0Mjcp DQotCVNlY3VyaXR5IChhbGwgU0lQIHNlY3VyaXR5IGlzc3VlcyBhcmUgbm9ybWFsbHkgZGVhbHQg d2l0aCBpbiB0aGUgU0lQIFdHLCBldmVuIGlmIElORk9STUFUSU9OQUwpDQoNClBsdXMgb25lIHdo ZXJlIEkgZG9uJ3Qga25vdyB3aGVyZSB0byBwdXQgdGhlIGRvY3VtZW50Lg0KDQpUaGUgbGlzdHMg Zm9sbG93LCBidXQgdGhlIGluZm9ybWF0aW9uIEkgbmVlZCAoZnJvbSB0aGUgYXV0aG9ycyBpZiBu b29uZSBlbHNlIGlzKQ0KDQotCWRvZXMgdGhlIGRvY3VtZW50IGJlbG9uZyBvciBub3QgYmVsb25n IGluIHRoZSBTSVAgZ3JvdXAgYXMgYSByZXN1bHQgb2YgdGhpcyBhbmFseXNpcz8NCi0JaGF2ZSBJ IGNhdGVnb3Jpc2VkIHRoaXMgY29ycmVjdGx5Pw0KLQloYXZlIEkgbWlzc2VkIGFueSBkcmFmdHMg dGhhdCBzaG91bGQgYmUgaGVyZT8NCi0JZm9yIHRoZSBTSVAgZXh0ZW5zaW9ucyBpcyB0aGVyZSBh IGRvY3VtZW50IG91dCB0aGVyZSB3aGljaCBsaXN0cyB0aGUgcmVxdWlyZW1lbnRzLCBhbmQgaWYg c28sIHdoaWNoIGRvY3VtZW50IGlzIGl0PyBCeSB0aGlzIEkgbWVhbiBhIHNvbWUgdGV4dCwgdG90 YWxseSBpbmRlcGVuZGVudCBvZiB0aGUgcHJvcG9zZWQgc29sdXRpb24gd2hpY2g6DQoNCglpZGVu dGlmaWVzIHRoZSBuZWVkIGZvciBhIG1lY2hhbmlzbSAoQSBtZWNoYW5pc20gaXMgbmVlZGVkIHN1 Y2ggdGhhdCAuLi4pDQoJcHJvdmlkZXMgcmVxdWlyZW1lbnRzIChUaGUgbWVjaGFuaXNtIE1VU1Qv U0hPVUxEL01BWSBzdXBwb3J0IC4uLikNCg0KTm90ZSB0aGF0IGlmIHN1Y2ggdGV4dCBkb2VzIG5v dCBleGlzdCwgSSBzdHJvbmdseSBzdWdnZXN0IHRoYXQgYXV0aG9ycyBvZiBTSVAgZXh0ZW5zaW9u cyB3aXRoIFJGQyAzNDI3IGltcGFjdCB0aGluayBhYm91dCBwcm92aWRpbmcgc3VjaCB0ZXh0IGlm IHRoZXkgd2FudCB0aGVpciBkb2N1bWVudCB0byBwcm9ncmVzcywgb3IgZWxzZSBwcm92aWRlIGEg cmF0aW9uYWwgZXhwbGFuYXRpb24gb2Ygd2h5IGl0IGlzIG5vdCBuZWVkZWQuIFN1Y2ggdGV4dCBt YXkgd2VsbCBiZWxvbmcgd2l0aCB0aGUgU0lQUElORyBncm91cCBmb3IgcHJpb3IgZGlzY3Vzc2lv bi4NCg0KTm9uZSBvZiB0aGUgYWJvdmUgaW1wbGllcyBhbnkgY29tbWl0bWVudCBvZiB0aGUgU0lQ IFdHIG9yIElFVEYgdG8gZnVydGhlciB0aGUgd29yayBvbiBzdWNoIGRyYWZ0cywgYnV0IEkgc3Vz cGVjdCBpZiBpdCBpcyBub3QgY29tcGxldGUgb24gbXkgbGlzdCwgd2l0aCB0aGUgaW5mb3JtYXRp b24gYXMgcmVxdWVzdGVkIGFib3ZlLCB0aGVuIG5vdGhpbmcgaXMgZ29pbmcgdG8gaGFwcGVuIHdp dGggaXQuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpBdXRob3IgZHJhZnRzIC0gYnVnZml4ZXMNCg0KZHJhZnQtZnJvbWVudC1zaXAtcmVjb3JkLXJv dXRlLWZpeC0wMCAodXBkYXRlcyBSRkMgMzI2MT8sIG9yIGlzIGl0IGp1c3QgYSBCQ1A/KQ0KZHJh ZnQtZ3VyYmFuaS1zaXAtbGFyZ2UtdWRwLXJlc3BvbnNlLTAwICh1cGRhdGVzIFJGQyAzMjYxKQ0K ZHJhZnQtbXVuYWthdGEtc2lwLXByaXZhY3ktY2xhcmlmaWVkLTAwICh1cGRhdGVzIFJGQyAzMzIz PywgZGVmaW5lcyBuZXcgcHJpdmFjeSB2YWx1ZXMpDQpkcmFmdC1oYXNlYmUtc2lwcGluZy1yYWNl LWV4YW1wbGVzLTAyIChoYXMgUkZDIDIxMTkgbGFuZ3VhZ2UgYWdhaW5zdCBSRkMgMzI2MSBiZWhh dmlvdXIpIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQXV0aG9yIGRyYWZ0cyAtIGV4 dGVuc2lvbnMNCg0KZHJhZnQtc2luaGEtc2lwLWJsb2NrLTAxIChkZWZpbmVzIG5ldyByZXNwb25z ZSBjb2RlKQ0KZHJhZnQtYm91bHRvbi1zaXAtY29udHJvbC1mcmFtZXdvcmstMDUgKGRlZmluZXMg bmV3IG9wdGlvbiB0YWcgYW5kIG5ldyBTSVAgaGVhZGVyIGZpZWxkKQ0KZHJhZnQtam9obnMtc2lw LW91dGJvdW5kLW1pZGRpYWxvZy1kcmFmdC0wMiAoZXh0ZW5kcyBleGlzdGluZyBvdXRib3VuZCB3 b3JrKQ0KZHJhZnQtbGVlLXNpcC1kbnMtc2QtdXJpLTAwDQpkcmFmdC1tYWh5LXNpcC1yZW1vdGUt Y2MtMDUgKGRlZmluZXMgbmV3IG9wdGlvbiB0YWcgYW5kIG5ldyBVUkkgcGFyYW1ldGVyKQ0KZHJh ZnQtcGV0aXRodWd1ZW5pbi1zaXAtZnJhZ21lbnRhdGlvbi1yZXNwb25zZXMtMDIgKGRlZmluZXMg bmV3IGhlYWRlciBmaWVsZCwgbmV3IHJlc3BvbnNlIGNvZGUsIGFuZCBuZXcgaGVhZGVyIGZpZWxk IHBhcmFtZXRlcnMpDQpkcmFmdC1wZXRpdGh1Z3VlbmluLXNpcC1vdXRib3VuZC1mcmFnbWVudGF0 aW9uLTAyIChleHRlbmRzIFNUVU4g4oCTIGRvZXMgdGhpcyBiZWxvbmcgd2l0aCBCRUhBVkUgV0c/ KQ0KZHJhZnQtcGV0cmllLXNpcC1ldmVudC1wYXJhbS1lcnItMDAgKGRlZmluZXMgbmV3IHJlc3Bv bnNlIGNvZGUgYW5kIG5ldyBoZWFkZXIgZmllbGQg4oCTIG1heSBiZSBwYXJ0IG9mIGNvbmZpZyBm cmFtZXdvcmsgY2hhcnRlcmVkIHdvcmspDQpkcmFmdC1wb2xrLXNpcC1ycGgtbmV3LW5hbWVzcGFj ZXMtMDAgKGRlZmluZXMgbmV3IHJlc291cmNlIHByaW9yaXR5IG5hbWVzcGFjZXMpDQpkcmFmdC1y YmhhdGlhLWFueWNhc3Qtc2lwLXByb3h5LWRpc2NvdmVyeS0wMA0KZHJhZnQtcm9zZW5iZXJnLXNp cC1vdXRib3VuZC1kaXNjb3ZlcnktbWlkLWRpYWxvZyAoZGVmaW5lcyBuZXcgaGVhZGVyIGZpZWxk LCBuZXcgb3B0aW9uIHRhZywgbmV3IFVSSSBwYXJhbWV0ZXIpDQpkcmFmdC1yb3NlbmJlcmctc2lw LXJvdXRlLWNvbnN0cnVjdC0wMiAoZGVmaW5lcyBuZXcgb3B0aW9uIHRhZyBhbmQgbmV3IGhlYWRl ciBmaWVsZCBwYXJhbWV0ZXIpDQpkcmFmdC11cnBhbGFpbmVuLXNpcC14Y2FwLWRpZmYtZXZlbnQt MDEgKGRlZmluZXMgbmV3IGV2ZW50IHBhY2thZ2UsIG1heSBpbnRlcnJlbGF0ZSB3aXRoIGNvbmZp ZyBmcmFtZXdvcmsgd29yaykNCmRyYWZ0LWhld2V0dC1zaXBwaW5nLWNhbC0wMCAoZGVmaW5lcyBu ZXcgaGVhZGVyIGZpZWxkLCBuZXcgb3B0aW9uIHRhZyBhbmQgbmV3IHJlc3BvbnNlIGNvZGUpDQpk cmFmdC1oaWx0LXNpcHBpbmctb3ZlcmxvYWQtMDEgKGRlZmluZXMgbmV3IGhlYWRlciBmaWVsZCDi gJMgcmVxdWlyZW1lbnRzIGluIGRyYWZ0LWlldGYtc2lwcGluZy1vdmVybG9hZC1yZXFzLTAwKQ0K ZHJhZnQtamVubmluZ3Mtc2lwcGluZy1wYXktMDUgKGRlZmluZXMgbmV3IGhlYWRlciBmaWVsZCwg bmV3IG9wdGlvbiB0YWdzLCBuZXcgcmVzcG9uc2UgY29kZXMpDQpkcmFmdC1qdW5nLXNpcHBpbmct YXV0aGVudGljYXRpb24tc3BpdC0wMCAoZGVmaW5lcyBuZXcgcmVzcG9uc2UgY29kZSkNCmRyYWZ0 LXJhamVzaC1zaXBwaW5nLTMwMy0wMSAoZGVmaW5lcyBuZXcgcmVzcG9uc2UgY29kZSkNCmRyYWZ0 LXJhamVzaC1zaXBwaW5nLTYwNS0wMSAoZGVmaW5lcyBuZXcgcmVzcG9uc2UgY29kZSkNCmRyYWZ0 LXJvYWNoLXNpcHBpbmctY2FsbGNvbXAtYmZjcC0wMCAoZGVmaW5lcyBuZXcgb3B0aW9uIHRhZyAg LSBob3d2ZXIgYWxzbyBkZWZpbmVzIEJGQ1AgZXh0ZW5zaW9ucyB3aGljaCBuZWVkIHRvIGdvIHRv IFhDT04gV0cpDQpkcmFmdC1zY2h1YmVydC1zaXBwaW5nLWhlYWRlci1pbnRlZ3JpdHktcmVxcy0w MCAoZGVmaW5lcyBuZXcgb3B0aW9uIHRhZyDigJMgaG93ZXZlciBhbHNvIGRlZmluZXMgU0RQIGV4 dGVuc2lvbnMgd2hpY2ggbmVlZCB0byBnbyB0byBNTVVTSUMgV0cpDQpkcmFmdC1zdHVja2VyLXNp cHBpbmctZWFybHktbWVkaWEtaW5kaXJlY3Rpb24tMDAgKGRlZmluZXMgbmV3IG9wdGlvbiB0YWcp DQpkcmFmdC12YWtpbC1zaXBwaW5nLW5vdGlmeS1wYXVzZS0wMCAoZGVmaW5lcyBuZXcgaGVhZGVy IGZpZWxkIHBhcmFtdGVyIOKAkyBleHRlbmRzIFJGQyAzMjY1KQ0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpBdXRob3IgZHJhZnRzIC0gc2VjdXJpdHkNCg0KZHJhZnQtZG90c29uLXNpcC1jZXJ0 aWZpY2F0ZS1hdXRoLTAyIChyZXF1aXJlbWVudHMgZG9jdW1lbnQpDQpkcmFmdC1kb3Rzb24tc2lw LWNlcnRpZmljYXRlLWF1dGgtc29sLTAwIChzb2x1dGlvbiBmb3IgYWJvdmUpDQpkcmFmdC1mcmll cy1zaXAtaWRlbnRpdHktdXNhZ2UtYmNwLTAxIChwcm9wb3NlZCBCQ1AgZm9yIG91ciBpZGVudGl0 eSBSRkNzKQ0KZHJhZnQtZ3VyYmFuaS1zaXAtZG9tYWluLWNlcnRzLTA0DQpkcmFmdC1qZW5uaW5n cy1zaXAtZHRscy0wMyAoY3VycmVudGx5IGJlaW5nIGFkZHJlc3NlZCBpbiBSQUkgV0cg4oCTIG1v ZGlmaWVzIFVSSSBwYXJhbWV0ZXIpDQpkcmFmdC1ncmVjby1zaXBwaW5nLXJvYW1pbmctMDANCmRy YWZ0LXNjaHViZXJ0LXNpcHBpbmctaGVhZGVyLWludGVncml0eS1yZXFzLTAwDQpkcmFmdC10c2No b2ZlbmlnLXNpcHBpbmctc3BpdC1wb2xpY3ktMDANCmRyYWZ0LXdpbmctc2lwcGluZy1zcnRwLWtl eS0wMCAgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBdXRob3IgZHJhZnRzIC0gbm90IHN1 cmUNCg0KZHJhZnQtYmFiaWFyei1wY24tc2lwLWNhcC0wMA0KZHJhZnQtYmFybmVzLXNpcC1lbS1w cy1yZXEtc29sLTAwIChyZXF1aXJlbWVudHMgZHJhZnQgcHJvYmFibHkgYmVzdCBkZWFsdCB3aXRo IGJ5IFNJUFBJTkcgV0cpDQpkcmFmdC1kb25kZXRpLW9tYS1zaXAtc2RwLWF0dHJzLTAwIChiZWxp ZXZlIHRoaXMgaXMgYSBNTVVTSUMgaXNzdWUpDQpkcmFmdC1zaW5ucmVpY2gtc2lwLXRvb2xzLTAx IChpcyB0aGlzIHBhcnQgb2YgdGhlIGhpdGNoaGlrZXLigJlzIGd1aWRlIHdvcmspDQpkcmFmdC13 b3JsZXktc2lwLWRpYWxvZy0wMyAoaW4gc2NvcGUgb2YgU0lQUElORz8pDQpkcmFmdC13b3JsZXkt c2lwLWdydXUtaW1wbGVtZW50LTAyIChpbiBzY29wZSBvZiBTSVBQSU5HIG9yIGluY29ycG9yYXRl IGluIGRyYWZ0LWlldGYtc2lwLWdydXU/IOKAkyBhbnl0aGluZyBsZWZ0PykNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoJDQo= --===============0764408425== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0764408425==-- From sip-bounces@ietf.org Fri Mar 09 10:09:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPghr-0001Fd-PU; Fri, 09 Mar 2007 10:08:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPghq-0001FS-BI for sip@ietf.org; Fri, 09 Mar 2007 10:08:30 -0500 Received: from web31505.mail.mud.yahoo.com ([68.142.198.134]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPghk-0001j0-BT for sip@ietf.org; Fri, 09 Mar 2007 10:08:30 -0500 Received: (qmail 5439 invoked by uid 60001); 9 Mar 2007 15:08:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=AwvtIjwZzfMu5dHqznSQAFCCblefdjQof5WTOhPntHsO6vvsECUGTrJs/r4T8ob7NPccCmzcPn5JzsY4TZFAlIuJ2++K1cgdGqNyQkPVm/ZKZB5C1z3gxOegydhK2N7bLJujh/u5n0HGnJMWgIpgZPUFQJRW+t3kPrr/vlEhVqc=; X-YMail-OSG: zAvCsJUVM1k3quRRuVYMbR0E9UzfW3JyI_kLPZZF Received: from [198.152.13.67] by web31505.mail.mud.yahoo.com via HTTP; Fri, 09 Mar 2007 15:08:23 GMT Date: Fri, 9 Mar 2007 15:08:23 +0000 (GMT) From: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) To: Paul Kyzivat In-Reply-To: <45F05C65.80107@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <759646.5268.qm@web31505.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Paul for the clarifications. Replies inline. Kapil --- Paul Kyzivat wrote: > > > Kapil Nayar wrote: > > Hi > > > > Thanks for pointing to the new draft....its an > > excellent piece and clarifies a lot of confusion. > A > > few questions though:- > > > > 1. Is there a specific reason for disallowing > Pattern4 > > in Table1 for changing media in an early > dialog..may > > be I am missing something here. > > Its been a long time, and I don't recall all the > reasoning that went > into this. This was partly a matter of inferring > original intent in all > the pertinent RFCs, and extrapolating where things > are unclear. We > concluded that this was the only self consistent > interpretation that > works in all cases. (The assumption being that an > interpretation that > didn't work must not be the right one.) > > If you were to allow a second o/a exchange via > reliable 1xx, then it > would have the potential for a race with a > concurrent UPDATE in the > other direction. And that would result in a need to > send an error > response. But PRACK isn't prepared for carrying an > error response. > Forcing subsequent o/a to use UPDATE avoids this. KN>> Perfect. So UPDATE (with SDP) support is sort of mandatory for implementations which want to enable changing early-media. > > > Anticipate an incoming > > Invite (call) replied with multiple provisional > > responses (an IVR-183 and then a server > queue-182). > > UAS may decide to have media with different > > characteristics/ source for these instances within > the > > call. Only allowing UPDATE for changing early > dialog > > media seems to be more restrictive and may need > more > > message exchanges. > > It may take an extra message, but it is cleaner. It > is not more > restrictive in what can be done. > > > 2. Just to clarify, in Figure1 "After F6 UAC and > UAS > > can send a new offer in an UPDATE request", I > guess > > the authors meant F7. > > Debatable. I think the UAS can send an UPDATE after > sending F6, without > waiting to receive F7. (With the understanding that > the UPDATE could > fail if received before F6.) > > The UAC should probably wait until it sends F7. KN>> I would agree with mandating UAC to wait until it sends F7. > > > 3. In the description for Figure1 it is indicated > that > > F12 (final response) should not contain an SDP, > and if > > it does and is different than F6, the UAC should > > discard it. (Similar description is present in > > Figure2.) > > > > a).Does this mean that a UAS cannot change the > early > > media to a final media in final response? > > It means that each offer has been answered, and that > once an answer has > been sent, it can't be changed without another > offer/answer cycle. And > that another offer/answer cycle may not be initiated > in the 2xx if one > has already been completed. > > This last is part of a principle that was discovered > during the > evolution of this work: At most one offer and one > answer per transaction. > > At the time of F12, if the UAS wants to change the > SDP, it can send an > UPDATE before sending the 2xx for the INVITE. Or it > can send the 2xx and > send an UPDATE or reINVITE after the ACK. > > > b).If F12 carries SDP, it should be designated as > a > > new offer-SDP, right? If UAC discards the > offer-SDP in > > F12, is it still obligated to send an answer-SDP > in > > ACK? > > No. This is all as specified in 3261. Having sent an > unreliable > provisional with an answer in F2, if there is any > SDP in the 2xx it must > be identical to what was sent in F2. It is *not* > another offer, and so > it there must not be an answer to it in F13. > > > c).If UAC accepts the offer-SDP in F12, can the > > answer-SDP in ACK be different than the one > originally > > offered in F1? What is the behavior expected at > the > > UAS upon receiving this different media? > > See above. KN>> Actually, there is some confusion here. In Figure1 and Figure2 call flows there is a successful completion of the o/a through reliable 1xx. As per RFC 3261..."Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE." However, if you read the description in line with the figures it seems we have relaxed the MUST NOT to SHOULD NOT. Figure1 - UAS should not include an SDP in the responses F9 and F12. Figure2 - UAS should not include an SDP in the responses F6 and F9. And, it sort of opens the discussion to possible scenarios where another o/a can be initiated. Is this intentional? > and if > > > I don't know if it is too early to ask, but whats > the > > estimated time-frame for this draft to be moving > to an > > RFC? > > Pretty soon. I think there is hope for WGLC in > April. > > Paul > > > thanks, > > Kapil Nayar > > > > --- Paul Kyzivat wrote: > > > >> > >> Christer Holmberg (JO/LMF) wrote: > >>> Hi, > >>> > >>>>> I think this is an interesting question, and > >> should be added to the > >>>>> offer-answer draft. > >>>> It is covered. (It says you can't do it.) > >>> Ok. Good. > >>> > >>> Note, however, that it should be perfectly ok to > >> send an SDP offer in > >>> the INVITE without any m= lines > >> Yes it should. > >> > >>> (you do need to include a c= line, though). > >> We disagree on that. Dale and I both interpret > the > >> existing spec as > >> saying you only need c= if you have m=. > >> > >>> That way you can add the media parts later. > >>> > >>> Whether terminals will support it is another > >> issue.... > >> > >> Yes, that is likely to be a problem. > >> > >> If I send an invite that offers media (say MSRP) > and > >> it forks to > >> multiple UAs (say one that supports MSRP and one > >> that supports voice) > >> then I want the one that supports voice to answer > >> and the one that > >> supports only MSRP to reject the invite. The > >> rejection is because it has > >> no matching media. > >> > >> If that is agreed as desired behavior, then what > >> should those two > >> devices do when receiving an offer with no media? > It > >> would seem that > >> either they will both ring, or both reject. What > >> happens if a ringing > >> device is answered? Its not a very useful call > with > >> no media. > >> > >> This is potentially useful, but only if there is > >> some understanding of > >> what is expected and what should happen next. > >> > >> Paul > >> > > > > > > > > > > > > > ___________________________________________________________ > > > Now you can scan emails quickly with a reading > pane. Get the new Yahoo! Mail. > http://uk.docs.yahoo.com/nowyoucan.html > > > ___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 11:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPhi1-0000iz-T7; Fri, 09 Mar 2007 11:12:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPhi0-0000bL-Gc for sip@ietf.org; Fri, 09 Mar 2007 11:12:44 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPhhw-0006Ww-P0 for sip@ietf.org; Fri, 09 Mar 2007 11:12:44 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2007 08:12:39 -0800 X-IronPort-AV: i="4.14,268,1170662400"; d="scan'208"; a="469615561:sNHT53943712" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l29GCdat032253; Fri, 9 Mar 2007 11:12:39 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l29GCQZT011900; Fri, 9 Mar 2007 16:12:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 11:12:32 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 11:12:31 -0500 Message-ID: <45F1876F.5020405@cisco.com> Date: Fri, 09 Mar 2007 11:12:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <759646.5268.qm@web31505.mail.mud.yahoo.com> In-Reply-To: <759646.5268.qm@web31505.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2007 16:12:31.0623 (UTC) FILETIME=[BDA45170:01C76265] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4639; t=1173456759; x=1174320759; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20Kapil=20Nayar=20; bh=epHcHLNY2ljJRcL6rXXW8KAcEEsSsIrbNMXEHaOs4cE=; b=UPKarLIa9XhRcCihkQjcT8uuvGXul++2JFAjmRES8dKaNNy4OpDwLaa2sR/3roUq5j7LcIHi LrwOqT8JciHsjvIt7J1+IhVE8Y8oe1v/wD7Jdp7c5PnyHAsLW7vubJmn; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE BELOW AND COMMENT *** (References are to figures in draft-ietf-sipping-sip-offeranswer-00.) Comments inline. Paul Kapil Nayar wrote: > Thanks Paul for the clarifications. > Replies inline. >> If you were to allow a second o/a exchange via >> reliable 1xx, then it >> would have the potential for a race with a >> concurrent UPDATE in the >> other direction. And that would result in a need to >> send an error >> response. But PRACK isn't prepared for carrying an >> error response. >> Forcing subsequent o/a to use UPDATE avoids this. > > KN>> Perfect. So UPDATE (with SDP) support is sort of > mandatory for implementations which want to enable > changing early-media. Yeah. It would be quite unwise to support 100rel and not UPDATE. >>> 2. Just to clarify, in Figure1 "After F6 UAC and >> UAS >>> can send a new offer in an UPDATE request", I >> guess >>> the authors meant F7. >> Debatable. I think the UAS can send an UPDATE after >> sending F6, without >> waiting to receive F7. (With the understanding that >> the UPDATE could >> fail if received before F6.) >> >> The UAC should probably wait until it sends F7. > KN>> I would agree with mandating UAC to wait until it > sends F7. I don't feel too strongly about this. I think it would probably be wise to wait until after F7, but if somebody wants to jump the gun and is prepared for the potential error if F7 was lost then I guess that is their business. >>> 3. In the description for Figure1 it is indicated >> that >>> F12 (final response) should not contain an SDP, >> and if >>> it does and is different than F6, the UAC should >>> discard it. (Similar description is present in >>> Figure2.) >>> >>> a).Does this mean that a UAS cannot change the >> early >>> media to a final media in final response? >> It means that each offer has been answered, and that >> once an answer has >> been sent, it can't be changed without another >> offer/answer cycle. And >> that another offer/answer cycle may not be initiated >> in the 2xx if one >> has already been completed. >> >> This last is part of a principle that was discovered >> during the >> evolution of this work: At most one offer and one >> answer per transaction. >> >> At the time of F12, if the UAS wants to change the >> SDP, it can send an >> UPDATE before sending the 2xx for the INVITE. Or it >> can send the 2xx and >> send an UPDATE or reINVITE after the ACK. >> >>> b).If F12 carries SDP, it should be designated as >> a >>> new offer-SDP, right? If UAC discards the >> offer-SDP in >>> F12, is it still obligated to send an answer-SDP >> in >>> ACK? >> No. This is all as specified in 3261. Having sent an >> unreliable >> provisional with an answer in F2, if there is any >> SDP in the 2xx it must >> be identical to what was sent in F2. It is *not* >> another offer, and so >> it there must not be an answer to it in F13. >> >>> c).If UAC accepts the offer-SDP in F12, can the >>> answer-SDP in ACK be different than the one >> originally >>> offered in F1? What is the behavior expected at >> the >>> UAS upon receiving this different media? >> See above. > KN>> Actually, there is some confusion here. In > Figure1 and Figure2 call flows there is a successful > completion of the o/a through reliable 1xx. As per RFC > 3261..."Once the UAS has sent or received an answer to > the initial offer, it MUST NOT generate subsequent > offers in any responses to the initial INVITE." > However, if you read the description in line with the > figures it seems we have relaxed the MUST NOT to > SHOULD NOT. > Figure1 - UAS should not include an SDP in the > responses F9 and F12. Figure2 - UAS should not include > an SDP in the responses F6 and F9. It has been a long time, and I no longer remember the rationale that led to the SHOULD here. Note that in these figures the SDP in the 2xx is not to be considered an offer. It is just a piece of redundant data. Personally I would be happy to say that the UAS MUST NOT include SDP in the 2xx in these examples. But I would also like to say (this is a best practice) that the UAC SHOULD/MUST ignore any SDP that arrives in the 2xx in these cases. This happens a lot in the wild, so one ought not break in these cases. But I would like to hear from Takuya (who is the primary author) and others on this. > And, it sort of opens the discussion to possible > scenarios where another o/a can be initiated. Is this > intentional? Definitely not. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 13:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjne-0004lA-Ba; Fri, 09 Mar 2007 13:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjnc-0004l2-Df for sip@ietf.org; Fri, 09 Mar 2007 13:26:40 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPjnb-0007nw-13 for sip@ietf.org; Fri, 09 Mar 2007 13:26:40 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 503AA3A0210B; Fri, 9 Mar 2007 10:26:32 -0800 (PST) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id D6C063A0210A; Fri, 9 Mar 2007 10:26:30 -0800 (PST) Message-ID: <45F1A6D6.50609@acm.org> Date: Fri, 09 Mar 2007 10:26:30 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Making sense of the SIP author drafts References: <5D1A7985295922448D5550C94DE29180E1F2E6@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180E1F2E6@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. Drage, Keith (Keith) wrote: > (as WG chair) >=20 > I have been attempting to make sense of the large number of author draf= ts out there which in some manner impact SIP. I have three categories: >=20 > - Bugfixes (documents which may fall into the criteria identified in dr= aft-drage-sip-essential-correction-01) > - SIP extensions (which need to be SIP charter items due to RFC 3427) > - Security (all SIP security issues are normally dealt with in the SIP = WG, even if INFORMATIONAL) >=20 > Plus one where I don't know where to put the document. >=20 > The lists follow, but the information I need (from the authors if noone= else is) >=20 > - does the document belong or not belong in the SIP group as a result o= f this analysis? > - have I categorised this correctly? > - have I missed any drafts that should be here? > - for the SIP extensions is there a document out there which lists the = requirements, and if so, which document is it? By this I mean a some text= , totally independent of the proposed solution which: >=20 > identifies the need for a mechanism (A mechanism is needed such that .= ..) > provides requirements (The mechanism MUST/SHOULD/MAY support ...) >=20 > Note that if such text does not exist, I strongly suggest that authors = of SIP extensions with RFC 3427 impact think about providing such text if= they want their document to progress, or else provide a rational explana= tion of why it is not needed. Such text may well belong with the SIPPING = group for prior discussion. >=20 > None of the above implies any commitment of the SIP WG or IETF to furth= er the work on such drafts, but I suspect if it is not complete on my lis= t, with the information as requested above, then nothing is going to happ= en with it. >=20 > Regards >=20 > Keith >=20 >=20 > -----------------------------------------------------------------------= --------- > Author drafts - extensions >=20 [snip] > draft-petithuguenin-sip-fragmentation-responses-02 (defines new header = field, new response code, and new header field parameters) This document defines a SIP extension that fixes a bug in SIP (i.e. SIP response fragmented in some cases), so it can also be in the bugfixes category. If you agree, then I'll update the I-D to follow the requirements in draft-drage-sip-essential-correction. There is AFAIK no existing requirements document. I will work on this, with the authors of draft-gurbani-sip-large-udp-response-00 if they are interested. > draft-petithuguenin-sip-outbound-fragmentation-02 (extends STUN =E2=80=93= does this belong with BEHAVE WG?) You are right that this document describes a STUN extension, so it should perhaps be in the BEHAVE WG. But it also describes an extension to Outbound. So should I split the document in two, one for the STUN usages (in the BEHAVE WG), and another one for the usage of the STUN Usages in Outbound? Anyway, I believe that the Outbound extension part of this document belong to the SIP WG. There is no existing requirements document, but I think that it could be the same document than the one that need to be written for draft-petithuguenin-sip-fragmentation-responses-02 (see above= ). --=20 Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 14:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPkUi-0005OF-V6; Fri, 09 Mar 2007 14:11:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPkUi-0005OA-1Z for sip@ietf.org; Fri, 09 Mar 2007 14:11:12 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPkUg-0007ot-J0 for sip@ietf.org; Fri, 09 Mar 2007 14:11:12 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l29JB9Qm000175 for ; Fri, 9 Mar 2007 13:11:10 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:11:09 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 20:11:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Making sense of the SIP author drafts Date: Fri, 9 Mar 2007 20:11:07 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F418@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180E1F2E6@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Making sense of the SIP author drafts Thread-Index: AcdiWaOo/0i6T+HBSCWrZ3+RaCYiUAAIql+A From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Mar 2007 19:11:07.0866 (UTC) FILETIME=[B1053BA0:01C7627E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1673489554==" Errors-To: sip-bounces@ietf.org --===============1673489554== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpKdXN0IHRvIHNoZWQgYSBiaXQgbW9yZSBsaWdodCBvbiB0aGlzIGFu ZCB3aGF0IHRoZSBkaWZmZXJlbnQgY2F0ZWdvcmlzYXRpb25zIG1lYW4uIEFuZCBJIHJlcGVhdCB0 aGF0IHdoYXRldmVyIHdvcmssIHdlIHN0aWxsIG5lZWQgdG8gYnVpbGQgd29ya2luZyBjb25jZW5z dXMgdGhhdCB3ZSB3YW50IHRvIGRvIHRoZSB3b3JrLiBJZiB5b3UgZG8gbm90IHVuZGVyc3RhbmQg dGhpcyBwcm9jZXNzLCB0aGVyZSBpcyBlZHVjYXRpb24gbWF0ZXJpYWwgaW4gSUVURiBsaW5rZWQg ZnJvbSB0aGUgSUVURiBob21lIHBhZ2UgdG8gcHJvdmlkZSBndWlkYW5jZS4NCg0KMSkJYnVnZml4 ZXMuIFRoaXMgaXMgd2hlcmUgd2UgYWdyZWUgdGhlIHVuZGVybHlpbmcgc3BlY2lmaWNhdGlvbiAo UkZDIDMyNjEgb3Igd2hhdGV2ZXIpIGlzIGJyb2tlbiwgYW5kIHRoZXJlZm9yZSBuZWVkcyBmaXhp bmcuIElmIHdlIGFncmVlIHRoaXMsIHRoZW4gaXQgZm9sbG93cyBwcm9jZWR1cmUgaW4gZHJhZnQt ZHJhZ2Utc2lwLWVzc2VudGlhbC1jb3JyZWN0aW9ucyBhbmQgRE9FUyBOT1QgbmVlZCBhIHJlcXVp cmVtZW50cyBkb2N1bWVudC4gT25jZSB3ZSBoYXZlIGFncmVlZCB3ZSBoYXZlIHNvbWV0aGluZyB0 aGF0IG5lZWRzIGZpeGluZywgdGhlIHdvcmtpbmcgZ3JvdXAgaWRlbnRpZmllcyBhIHNvbHV0aW9u IGluIGEgV0cgZHJhZnQuIFJvYmVydHMgU3BhcmtzIGlzIGxlYWRpbmcgdGhpcyB3b3JrLCBidXQg eW91IG1heSBlbmQgdXAgZHJhZnRpbmcgdGhlIFdHIGludGVybmV0LWRyYWZ0IGRvY3VtZW50aW5n IHRoZSBmaXguIEluIGdlbmVyYWwsIEkgYW0gYXNzdW1pbmcgdGhhdCBpZiB3ZSBoYXZlIHdvcmtp bmcgY29uc2Vuc3VzIHRoYXQgdGhlIGJhc2Ugc3BlYyBpcyBicm9rZW4sIHdlIGhhdmUgY29uc2Vu c3VzIHRvIGZpeCBpdC4gRnVydGhlciwgaWYgaXQgaXMgYnJva2VuLCB3ZSBkbyB3YW50IHRvIGZp eCBpdCBxdWlja2x5Lg0KDQoyKQlleHRlbnNpb25zLiBUaGVzZSBhcmUgZW5oYW5jZW1lbnRzIHRv IFNJUCB3aGVyZSBpbiBwYXJ0aWN1bGFyLCBSRkMgMzQyNyBzYXlzIFNJUCBXRyBoYXMgdG8gZG8g dGhlIHdvcmsuIEluIGdlbmVyYWwgZm9yIHRoZXNlLCB3ZSB3b3VsZCBleHBlY3QgcmVxdWlyZW1l bnRzIHRvIGNvbWUgZnJvbSBzb21lIG90aGVyIGdyb3VwIG9uIHRoZXNlLCBhbmQgaXQgaXMgdGhp cyBncm91cCB0aGF0IEkgYW0gZW1waGFzaXNpbmcgdGhhdCB3ZSBuZWVkIHRvIGlkZW50aWZ5IHRo ZSByZXF1aXJlbWVudHMgaW5wdXQgaWYgaXQgZXhpc3RzLCBhbmQgcHJvZHVjZSBpdCBpbiB0aGUg YXBwcm9wcmlhdGUgV0cgaWYgaXQgZG9lcyBub3QuDQoNCjMpCXNlY3VyaXR5LiBXZSBoYXZlIGEg cGhpbG9zb3BoeSBvZiBsb29raW5nIGF0IGFsbCB0aGUgU0lQIHNlY3VyaXR5IGlzc3VlcyAocmVx dWlyZW1lbnRzIGFuZCBzb2x1dGlvbnMpIHdpdGhpbiBTSVAgaW4gb3JkZXIgdG8gcmVsaWV2ZSB0 aGUgbG9hZCBvbiB0aGUgU0lQUElORyBncm91cC4gVGhpcyBncm91cCB0aGVyZWZvcmUgd2UgY29u dHJvbCBvdXIgb3duIGRlc3RpbnksIGFuZCBjYW4gYmUgYSBsaXR0bGUgbW9yZSBmbGV4aWJsZSBp biBwb2xpY2luZyBob3cgd29yayBnZXRzIHN0YXJ0ZWQuDQoNClRoZXJlIGlzIG9idmlvdXNseSBh IGdyZXkgYXJlYSBiZXR3ZWVuIDEpIGFuZCAyKSBhYm92ZSwgYW5kIGl0IG1heSBtZWFuIHRoYXQg c29tZSBleGlzdGluZyBkcmFmdHMgbWF5IGhhdmUgdG8gYmUgc3BsaXQgdG8gc2VwYXJhdGUgdGhl IGJ1Z2ZpeCBmcm9tIHRoZSBleHRlbnNpb24uDQoNCg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRHJhZ2UsIEtlaXRoIChLZWl0aCkg W21haWx0bzpkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb21dIA0KPiBTZW50OiBGcmlkYXksIE1hcmNo IDA5LCAyMDA3IDI6NDYgUE0NCj4gVG86IHNpcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbU2lwXSBN YWtpbmcgc2Vuc2Ugb2YgdGhlIFNJUCBhdXRob3IgZHJhZnRzDQo+IA0KPiAoYXMgV0cgY2hhaXIp DQo+IA0KPiBJIGhhdmUgYmVlbiBhdHRlbXB0aW5nIHRvIG1ha2Ugc2Vuc2Ugb2YgdGhlIGxhcmdl IG51bWJlciBvZiANCj4gYXV0aG9yIGRyYWZ0cyBvdXQgdGhlcmUgd2hpY2ggaW4gc29tZSBtYW5u ZXIgaW1wYWN0IFNJUC4gSSANCj4gaGF2ZSB0aHJlZSBjYXRlZ29yaWVzOg0KPiANCj4gLQlCdWdm aXhlcyAoZG9jdW1lbnRzIHdoaWNoIG1heSBmYWxsIGludG8gdGhlIGNyaXRlcmlhIA0KPiBpZGVu dGlmaWVkIGluIGRyYWZ0LWRyYWdlLXNpcC1lc3NlbnRpYWwtY29ycmVjdGlvbi0wMSkNCj4gLQlT SVAgZXh0ZW5zaW9ucyAod2hpY2ggbmVlZCB0byBiZSBTSVAgY2hhcnRlciBpdGVtcyBkdWUgDQo+ IHRvIFJGQyAzNDI3KQ0KPiAtCVNlY3VyaXR5IChhbGwgU0lQIHNlY3VyaXR5IGlzc3VlcyBhcmUg bm9ybWFsbHkgZGVhbHQgDQo+IHdpdGggaW4gdGhlIFNJUCBXRywgZXZlbiBpZiBJTkZPUk1BVElP TkFMKQ0KPiANCj4gUGx1cyBvbmUgd2hlcmUgSSBkb24ndCBrbm93IHdoZXJlIHRvIHB1dCB0aGUg ZG9jdW1lbnQuDQo+IA0KPiBUaGUgbGlzdHMgZm9sbG93LCBidXQgdGhlIGluZm9ybWF0aW9uIEkg bmVlZCAoZnJvbSB0aGUgDQo+IGF1dGhvcnMgaWYgbm9vbmUgZWxzZSBpcykNCj4gDQo+IC0JZG9l cyB0aGUgZG9jdW1lbnQgYmVsb25nIG9yIG5vdCBiZWxvbmcgaW4gdGhlIFNJUCBncm91cCANCj4g YXMgYSByZXN1bHQgb2YgdGhpcyBhbmFseXNpcz8NCj4gLQloYXZlIEkgY2F0ZWdvcmlzZWQgdGhp cyBjb3JyZWN0bHk/DQo+IC0JaGF2ZSBJIG1pc3NlZCBhbnkgZHJhZnRzIHRoYXQgc2hvdWxkIGJl IGhlcmU/DQo+IC0JZm9yIHRoZSBTSVAgZXh0ZW5zaW9ucyBpcyB0aGVyZSBhIGRvY3VtZW50IG91 dCB0aGVyZSANCj4gd2hpY2ggbGlzdHMgdGhlIHJlcXVpcmVtZW50cywgYW5kIGlmIHNvLCB3aGlj aCBkb2N1bWVudCBpcyANCj4gaXQ/IEJ5IHRoaXMgSSBtZWFuIGEgc29tZSB0ZXh0LCB0b3RhbGx5 IGluZGVwZW5kZW50IG9mIHRoZSANCj4gcHJvcG9zZWQgc29sdXRpb24gd2hpY2g6DQo+IA0KPiAJ aWRlbnRpZmllcyB0aGUgbmVlZCBmb3IgYSBtZWNoYW5pc20gKEEgbWVjaGFuaXNtIGlzIA0KPiBu ZWVkZWQgc3VjaCB0aGF0IC4uLikNCj4gCXByb3ZpZGVzIHJlcXVpcmVtZW50cyAoVGhlIG1lY2hh bmlzbSBNVVNUL1NIT1VMRC9NQVkgDQo+IHN1cHBvcnQgLi4uKQ0KPiANCj4gTm90ZSB0aGF0IGlm IHN1Y2ggdGV4dCBkb2VzIG5vdCBleGlzdCwgSSBzdHJvbmdseSBzdWdnZXN0IA0KPiB0aGF0IGF1 dGhvcnMgb2YgU0lQIGV4dGVuc2lvbnMgd2l0aCBSRkMgMzQyNyBpbXBhY3QgdGhpbmsgDQo+IGFi b3V0IHByb3ZpZGluZyBzdWNoIHRleHQgaWYgdGhleSB3YW50IHRoZWlyIGRvY3VtZW50IHRvIA0K PiBwcm9ncmVzcywgb3IgZWxzZSBwcm92aWRlIGEgcmF0aW9uYWwgZXhwbGFuYXRpb24gb2Ygd2h5 IGl0IGlzIA0KPiBub3QgbmVlZGVkLiBTdWNoIHRleHQgbWF5IHdlbGwgYmVsb25nIHdpdGggdGhl IFNJUFBJTkcgZ3JvdXAgDQo+IGZvciBwcmlvciBkaXNjdXNzaW9uLg0KPiANCj4gTm9uZSBvZiB0 aGUgYWJvdmUgaW1wbGllcyBhbnkgY29tbWl0bWVudCBvZiB0aGUgU0lQIFdHIG9yIA0KPiBJRVRG IHRvIGZ1cnRoZXIgdGhlIHdvcmsgb24gc3VjaCBkcmFmdHMsIGJ1dCBJIHN1c3BlY3QgaWYgaXQg DQo+IGlzIG5vdCBjb21wbGV0ZSBvbiBteSBsaXN0LCB3aXRoIHRoZSBpbmZvcm1hdGlvbiBhcyBy ZXF1ZXN0ZWQgDQo+IGFib3ZlLCB0aGVuIG5vdGhpbmcgaXMgZ29pbmcgdG8gaGFwcGVuIHdpdGgg aXQuDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBLZWl0aA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0t LS0tLS0tLS0tLS0tLQ0KPiANCj4gQXV0aG9yIGRyYWZ0cyAtIGJ1Z2ZpeGVzDQo+IA0KPiBkcmFm dC1mcm9tZW50LXNpcC1yZWNvcmQtcm91dGUtZml4LTAwICh1cGRhdGVzIFJGQyAzMjYxPywgb3Ig DQo+IGlzIGl0IGp1c3QgYSBCQ1A/KSBkcmFmdC1ndXJiYW5pLXNpcC1sYXJnZS11ZHAtcmVzcG9u c2UtMDAgDQo+ICh1cGRhdGVzIFJGQyAzMjYxKSBkcmFmdC1tdW5ha2F0YS1zaXAtcHJpdmFjeS1j bGFyaWZpZWQtMDAgDQo+ICh1cGRhdGVzIFJGQyAzMzIzPywgZGVmaW5lcyBuZXcgcHJpdmFjeSB2 YWx1ZXMpDQo+IGRyYWZ0LWhhc2ViZS1zaXBwaW5nLXJhY2UtZXhhbXBsZXMtMDIgKGhhcyBSRkMg MjExOSBsYW5ndWFnZSANCj4gYWdhaW5zdCBSRkMgMzI2MSBiZWhhdmlvdXIpIA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQXV0aG9yIGRyYWZ0cyAtIGV4dGVuc2lv bnMNCj4gDQo+IGRyYWZ0LXNpbmhhLXNpcC1ibG9jay0wMSAoZGVmaW5lcyBuZXcgcmVzcG9uc2Ug Y29kZSkNCj4gZHJhZnQtYm91bHRvbi1zaXAtY29udHJvbC1mcmFtZXdvcmstMDUgKGRlZmluZXMg bmV3IG9wdGlvbiANCj4gdGFnIGFuZCBuZXcgU0lQIGhlYWRlciBmaWVsZCkNCj4gZHJhZnQtam9o bnMtc2lwLW91dGJvdW5kLW1pZGRpYWxvZy1kcmFmdC0wMiAoZXh0ZW5kcyBleGlzdGluZyANCj4g b3V0Ym91bmQgd29yaykgZHJhZnQtbGVlLXNpcC1kbnMtc2QtdXJpLTAwDQo+IGRyYWZ0LW1haHkt c2lwLXJlbW90ZS1jYy0wNSAoZGVmaW5lcyBuZXcgb3B0aW9uIHRhZyBhbmQgbmV3IA0KPiBVUkkg cGFyYW1ldGVyKQ0KPiBkcmFmdC1wZXRpdGh1Z3VlbmluLXNpcC1mcmFnbWVudGF0aW9uLXJlc3Bv bnNlcy0wMiAoZGVmaW5lcyANCj4gbmV3IGhlYWRlciBmaWVsZCwgbmV3IHJlc3BvbnNlIGNvZGUs IGFuZCBuZXcgaGVhZGVyIGZpZWxkIHBhcmFtZXRlcnMpDQo+IGRyYWZ0LXBldGl0aHVndWVuaW4t c2lwLW91dGJvdW5kLWZyYWdtZW50YXRpb24tMDIgKGV4dGVuZHMgDQo+IFNUVU4g4oCTIGRvZXMg dGhpcyBiZWxvbmcgd2l0aCBCRUhBVkUgV0c/KSANCj4gZHJhZnQtcGV0cmllLXNpcC1ldmVudC1w YXJhbS1lcnItMDAgKGRlZmluZXMgbmV3IHJlc3BvbnNlIA0KPiBjb2RlIGFuZCBuZXcgaGVhZGVy IGZpZWxkIOKAkyBtYXkgYmUgcGFydCBvZiBjb25maWcgZnJhbWV3b3JrIA0KPiBjaGFydGVyZWQg d29yaykgZHJhZnQtcG9say1zaXAtcnBoLW5ldy1uYW1lc3BhY2VzLTAwIChkZWZpbmVzIA0KPiBu ZXcgcmVzb3VyY2UgcHJpb3JpdHkgbmFtZXNwYWNlcykgDQo+IGRyYWZ0LXJiaGF0aWEtYW55Y2Fz dC1zaXAtcHJveHktZGlzY292ZXJ5LTAwDQo+IGRyYWZ0LXJvc2VuYmVyZy1zaXAtb3V0Ym91bmQt ZGlzY292ZXJ5LW1pZC1kaWFsb2cgKGRlZmluZXMgDQo+IG5ldyBoZWFkZXIgZmllbGQsIG5ldyBv cHRpb24gdGFnLCBuZXcgVVJJIHBhcmFtZXRlcikNCj4gZHJhZnQtcm9zZW5iZXJnLXNpcC1yb3V0 ZS1jb25zdHJ1Y3QtMDIgKGRlZmluZXMgbmV3IG9wdGlvbiANCj4gdGFnIGFuZCBuZXcgaGVhZGVy IGZpZWxkIHBhcmFtZXRlcikNCj4gZHJhZnQtdXJwYWxhaW5lbi1zaXAteGNhcC1kaWZmLWV2ZW50 LTAxIChkZWZpbmVzIG5ldyBldmVudCANCj4gcGFja2FnZSwgbWF5IGludGVycmVsYXRlIHdpdGgg Y29uZmlnIGZyYW1ld29yayB3b3JrKSANCj4gZHJhZnQtaGV3ZXR0LXNpcHBpbmctY2FsLTAwIChk ZWZpbmVzIG5ldyBoZWFkZXIgZmllbGQsIG5ldyANCj4gb3B0aW9uIHRhZyBhbmQgbmV3IHJlc3Bv bnNlIGNvZGUpDQo+IGRyYWZ0LWhpbHQtc2lwcGluZy1vdmVybG9hZC0wMSAoZGVmaW5lcyBuZXcg aGVhZGVyIGZpZWxkIOKAkyANCj4gcmVxdWlyZW1lbnRzIGluIGRyYWZ0LWlldGYtc2lwcGluZy1v dmVybG9hZC1yZXFzLTAwKQ0KPiBkcmFmdC1qZW5uaW5ncy1zaXBwaW5nLXBheS0wNSAoZGVmaW5l cyBuZXcgaGVhZGVyIGZpZWxkLCBuZXcgDQo+IG9wdGlvbiB0YWdzLCBuZXcgcmVzcG9uc2UgY29k ZXMpIA0KPiBkcmFmdC1qdW5nLXNpcHBpbmctYXV0aGVudGljYXRpb24tc3BpdC0wMCAoZGVmaW5l cyBuZXcgcmVzcG9uc2UgY29kZSkNCj4gZHJhZnQtcmFqZXNoLXNpcHBpbmctMzAzLTAxIChkZWZp bmVzIG5ldyByZXNwb25zZSBjb2RlKQ0KPiBkcmFmdC1yYWplc2gtc2lwcGluZy02MDUtMDEgKGRl ZmluZXMgbmV3IHJlc3BvbnNlIGNvZGUpIA0KPiBkcmFmdC1yb2FjaC1zaXBwaW5nLWNhbGxjb21w LWJmY3AtMDAgKGRlZmluZXMgbmV3IG9wdGlvbiB0YWcgIA0KPiAtIGhvd3ZlciBhbHNvIGRlZmlu ZXMgQkZDUCBleHRlbnNpb25zIHdoaWNoIG5lZWQgdG8gZ28gdG8gDQo+IFhDT04gV0cpIGRyYWZ0 LXNjaHViZXJ0LXNpcHBpbmctaGVhZGVyLWludGVncml0eS1yZXFzLTAwIA0KPiAoZGVmaW5lcyBu ZXcgb3B0aW9uIHRhZyDigJMgaG93ZXZlciBhbHNvIGRlZmluZXMgU0RQIGV4dGVuc2lvbnMgDQo+ IHdoaWNoIG5lZWQgdG8gZ28gdG8gTU1VU0lDIFdHKSANCj4gZHJhZnQtc3R1Y2tlci1zaXBwaW5n LWVhcmx5LW1lZGlhLWluZGlyZWN0aW9uLTAwIChkZWZpbmVzIG5ldyANCj4gb3B0aW9uIHRhZykg ZHJhZnQtdmFraWwtc2lwcGluZy1ub3RpZnktcGF1c2UtMDAgKGRlZmluZXMgbmV3IA0KPiBoZWFk ZXIgZmllbGQgcGFyYW10ZXIg4oCTIGV4dGVuZHMgUkZDIDMyNjUpDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAt LS0tLS0tLS0tLS0tLS0NCj4gDQo+IEF1dGhvciBkcmFmdHMgLSBzZWN1cml0eQ0KPiANCj4gZHJh ZnQtZG90c29uLXNpcC1jZXJ0aWZpY2F0ZS1hdXRoLTAyIChyZXF1aXJlbWVudHMgZG9jdW1lbnQp IA0KPiBkcmFmdC1kb3Rzb24tc2lwLWNlcnRpZmljYXRlLWF1dGgtc29sLTAwIChzb2x1dGlvbiBm b3IgYWJvdmUpDQo+IGRyYWZ0LWZyaWVzLXNpcC1pZGVudGl0eS11c2FnZS1iY3AtMDEgKHByb3Bv c2VkIEJDUCBmb3Igb3VyIA0KPiBpZGVudGl0eSBSRkNzKQ0KPiBkcmFmdC1ndXJiYW5pLXNpcC1k b21haW4tY2VydHMtMDQNCj4gZHJhZnQtamVubmluZ3Mtc2lwLWR0bHMtMDMgKGN1cnJlbnRseSBi ZWluZyBhZGRyZXNzZWQgaW4gUkFJIA0KPiBXRyDigJMgbW9kaWZpZXMgVVJJIHBhcmFtZXRlcikg ZHJhZnQtZ3JlY28tc2lwcGluZy1yb2FtaW5nLTAwIA0KPiBkcmFmdC1zY2h1YmVydC1zaXBwaW5n LWhlYWRlci1pbnRlZ3JpdHktcmVxcy0wMA0KPiBkcmFmdC10c2Nob2ZlbmlnLXNpcHBpbmctc3Bp dC1wb2xpY3ktMDANCj4gZHJhZnQtd2luZy1zaXBwaW5nLXNydHAta2V5LTAwICANCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEF1dGhvciBkcmFmdHMgLSBub3Qgc3VyZQ0K PiANCj4gZHJhZnQtYmFiaWFyei1wY24tc2lwLWNhcC0wMA0KPiBkcmFmdC1iYXJuZXMtc2lwLWVt LXBzLXJlcS1zb2wtMDAgKHJlcXVpcmVtZW50cyBkcmFmdCANCj4gcHJvYmFibHkgYmVzdCBkZWFs dCB3aXRoIGJ5IFNJUFBJTkcgV0cpIA0KPiBkcmFmdC1kb25kZXRpLW9tYS1zaXAtc2RwLWF0dHJz LTAwIChiZWxpZXZlIHRoaXMgaXMgYSBNTVVTSUMgaXNzdWUpDQo+IGRyYWZ0LXNpbm5yZWljaC1z aXAtdG9vbHMtMDEgKGlzIHRoaXMgcGFydCBvZiB0aGUgDQo+IGhpdGNoaGlrZXLigJlzIGd1aWRl IHdvcmspDQo+IGRyYWZ0LXdvcmxleS1zaXAtZGlhbG9nLTAzIChpbiBzY29wZSBvZiBTSVBQSU5H PykNCj4gZHJhZnQtd29ybGV5LXNpcC1ncnV1LWltcGxlbWVudC0wMiAoaW4gc2NvcGUgb2YgU0lQ UElORyBvciANCj4gaW5jb3Jwb3JhdGUgaW4gZHJhZnQtaWV0Zi1zaXAtZ3J1dT8g4oCTIGFueXRo aW5nIGxlZnQ/KQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAJDQo+IA0K --===============1673489554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1673489554==-- From sip-bounces@ietf.org Fri Mar 09 14:25:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPki8-00027q-TP; Fri, 09 Mar 2007 14:25:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPki7-00027h-Ku for sip@ietf.org; Fri, 09 Mar 2007 14:25:03 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPkhn-0002Gf-EQ for sip@ietf.org; Fri, 09 Mar 2007 14:25:03 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l29JOQ0Y014267; Fri, 9 Mar 2007 13:24:41 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:24:28 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 20:24:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Making sense of the SIP author drafts Date: Fri, 9 Mar 2007 20:24:26 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F41C@DEEXC1U01.de.lucent.com> In-Reply-To: <45F1A6D6.50609@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Making sense of the SIP author drafts Thread-Index: AcdieHuxCTb+4QIYQv6GAea6Nfo3OwAB5CIw From: "Drage, Keith \(Keith\)" To: "Marc Petit-Huguenin" , "Robert Sparks" X-OriginalArrivalTime: 09 Mar 2007 19:24:26.0866 (UTC) FILETIME=[8D42F520:01C76280] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0973551947==" Errors-To: sip-bounces@ietf.org --===============0973551947== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBoYXZlIGNsYXJpZmllZCBpbiBhIHNlcGFyYXRlIG1haWwsIGJ1Z2ZpeGVzIGRvbid0IG5l ZWQgcmVxdWlyZW1lbnRzLCBidXQgdGhleSB3aWxsIG5lZWQgdG8gZm9sbG93IHRoZSBwcm9jZWR1 cmVzIG9mDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRyYWdl LXNpcC1lc3NlbnRpYWwtY29ycmVjdGlvbi0wMS50eHQNCg0KT3IgdGhlIGN1cnJlbnQgdmVyc2lv biBvZiB0aGF0Lg0KDQpXZSBoYXZlIGFza2VkIFJvYmVydCB0byBsZWFkIHRoZSBidWdmaXhlcyBw cm9ncmFtbWUuIA0KDQpJIHdvdWxkIHdlbGNvbWUgaGlzIHRha2UgKGFuZCBpbmRlZWQgdGhhdCBv ZiBhbnlvbmUgZWxzZSkgYXMgdG8gd2hldGhlciB0aGlzIGlzIGEgUkZDIDMyNjEgYnVnIHRoYXQg bmVlZHMgZml4aW5nLCBvciBzb21ldGhpbmcgZWxzZS4NCg0KS2VpdGgNCg0KIA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmMgUGV0aXQtSHVndWVuaW4gW21haWx0 bzpwZXRpdGh1Z0BhY20ub3JnXSANCj4gU2VudDogRnJpZGF5LCBNYXJjaCAwOSwgMjAwNyA2OjI3 IFBNDQo+IFRvOiBEcmFnZSwgS2VpdGggKEtlaXRoKQ0KPiBDYzogc2lwQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbU2lwXSBNYWtpbmcgc2Vuc2Ugb2YgdGhlIFNJUCBhdXRob3IgZHJhZnRzDQo+ IA0KPiBJbmxpbmUuDQo+IA0KPiBEcmFnZSwgS2VpdGggKEtlaXRoKSB3cm90ZToNCj4gPiAoYXMg V0cgY2hhaXIpDQo+ID4gDQo+ID4gSSBoYXZlIGJlZW4gYXR0ZW1wdGluZyB0byBtYWtlIHNlbnNl IG9mIHRoZSBsYXJnZSBudW1iZXIgb2YgDQo+IGF1dGhvciBkcmFmdHMgb3V0IHRoZXJlIHdoaWNo IGluIHNvbWUgbWFubmVyIGltcGFjdCBTSVAuIEkgDQo+IGhhdmUgdGhyZWUgY2F0ZWdvcmllczoN Cj4gPiANCj4gPiAtCUJ1Z2ZpeGVzIChkb2N1bWVudHMgd2hpY2ggbWF5IGZhbGwgaW50byB0aGUg Y3JpdGVyaWEgDQo+IGlkZW50aWZpZWQgaW4gZHJhZnQtZHJhZ2Utc2lwLWVzc2VudGlhbC1jb3Jy ZWN0aW9uLTAxKQ0KPiA+IC0JU0lQIGV4dGVuc2lvbnMgKHdoaWNoIG5lZWQgdG8gYmUgU0lQIGNo YXJ0ZXIgaXRlbXMgZHVlIA0KPiB0byBSRkMgMzQyNykNCj4gPiAtCVNlY3VyaXR5IChhbGwgU0lQ IHNlY3VyaXR5IGlzc3VlcyBhcmUgbm9ybWFsbHkgZGVhbHQgDQo+IHdpdGggaW4gdGhlIFNJUCBX RywgZXZlbiBpZiBJTkZPUk1BVElPTkFMKQ0KPiA+IA0KPiA+IFBsdXMgb25lIHdoZXJlIEkgZG9u J3Qga25vdyB3aGVyZSB0byBwdXQgdGhlIGRvY3VtZW50Lg0KPiA+IA0KPiA+IFRoZSBsaXN0cyBm b2xsb3csIGJ1dCB0aGUgaW5mb3JtYXRpb24gSSBuZWVkIChmcm9tIHRoZSBhdXRob3JzIGlmIA0K PiA+IG5vb25lIGVsc2UgaXMpDQo+ID4gDQo+ID4gLQlkb2VzIHRoZSBkb2N1bWVudCBiZWxvbmcg b3Igbm90IGJlbG9uZyBpbiB0aGUgU0lQIGdyb3VwIA0KPiBhcyBhIHJlc3VsdCBvZiB0aGlzIGFu YWx5c2lzPw0KPiA+IC0JaGF2ZSBJIGNhdGVnb3Jpc2VkIHRoaXMgY29ycmVjdGx5Pw0KPiA+IC0J aGF2ZSBJIG1pc3NlZCBhbnkgZHJhZnRzIHRoYXQgc2hvdWxkIGJlIGhlcmU/DQo+ID4gLQlmb3Ig dGhlIFNJUCBleHRlbnNpb25zIGlzIHRoZXJlIGEgZG9jdW1lbnQgb3V0IHRoZXJlIA0KPiB3aGlj aCBsaXN0cyB0aGUgcmVxdWlyZW1lbnRzLCBhbmQgaWYgc28sIHdoaWNoIGRvY3VtZW50IGlzIA0K PiBpdD8gQnkgdGhpcyBJIG1lYW4gYSBzb21lIHRleHQsIHRvdGFsbHkgaW5kZXBlbmRlbnQgb2Yg dGhlIA0KPiBwcm9wb3NlZCBzb2x1dGlvbiB3aGljaDoNCj4gPiANCj4gPiAJaWRlbnRpZmllcyB0 aGUgbmVlZCBmb3IgYSBtZWNoYW5pc20gKEEgbWVjaGFuaXNtIGlzIA0KPiBuZWVkZWQgc3VjaCB0 aGF0IC4uLikNCj4gPiAJcHJvdmlkZXMgcmVxdWlyZW1lbnRzIChUaGUgbWVjaGFuaXNtIE1VU1Qv U0hPVUxEL01BWSANCj4gc3VwcG9ydCAuLi4pDQo+ID4gDQo+ID4gTm90ZSB0aGF0IGlmIHN1Y2gg dGV4dCBkb2VzIG5vdCBleGlzdCwgSSBzdHJvbmdseSBzdWdnZXN0IA0KPiB0aGF0IGF1dGhvcnMg b2YgU0lQIGV4dGVuc2lvbnMgd2l0aCBSRkMgMzQyNyBpbXBhY3QgdGhpbmsgDQo+IGFib3V0IHBy b3ZpZGluZyBzdWNoIHRleHQgaWYgdGhleSB3YW50IHRoZWlyIGRvY3VtZW50IHRvIA0KPiBwcm9n cmVzcywgb3IgZWxzZSBwcm92aWRlIGEgcmF0aW9uYWwgZXhwbGFuYXRpb24gb2Ygd2h5IGl0IGlz IA0KPiBub3QgbmVlZGVkLiBTdWNoIHRleHQgbWF5IHdlbGwgYmVsb25nIHdpdGggdGhlIFNJUFBJ TkcgZ3JvdXAgDQo+IGZvciBwcmlvciBkaXNjdXNzaW9uLg0KPiA+IA0KPiA+IE5vbmUgb2YgdGhl IGFib3ZlIGltcGxpZXMgYW55IGNvbW1pdG1lbnQgb2YgdGhlIFNJUCBXRyBvciANCj4gSUVURiB0 byBmdXJ0aGVyIHRoZSB3b3JrIG9uIHN1Y2ggZHJhZnRzLCBidXQgSSBzdXNwZWN0IGlmIGl0IA0K PiBpcyBub3QgY29tcGxldGUgb24gbXkgbGlzdCwgd2l0aCB0aGUgaW5mb3JtYXRpb24gYXMgcmVx dWVzdGVkIA0KPiBhYm92ZSwgdGhlbiBub3RoaW5nIGlzIGdvaW5nIHRvIGhhcHBlbiB3aXRoIGl0 Lg0KPiA+IA0KPiA+IFJlZ2FyZHMNCj4gPiANCj4gPiBLZWl0aA0KPiA+IA0KPiA+IA0KPiA+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0tLS0tLS0tLQ0KPiA+IEF1dGhvciBkcmFmdHMgLSBleHRl bnNpb25zDQo+ID4gDQo+IA0KPiBbc25pcF0NCj4gDQo+ID4gZHJhZnQtcGV0aXRodWd1ZW5pbi1z aXAtZnJhZ21lbnRhdGlvbi1yZXNwb25zZXMtMDIgKGRlZmluZXMgDQo+IG5ldyBoZWFkZXIgDQo+ ID4gZmllbGQsIG5ldyByZXNwb25zZSBjb2RlLCBhbmQgbmV3IGhlYWRlciBmaWVsZCBwYXJhbWV0 ZXJzKQ0KPiANCj4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgU0lQIGV4dGVuc2lvbiB0aGF0IGZp eGVzIGEgYnVnIGluIFNJUCANCj4gKGkuZS4gU0lQIHJlc3BvbnNlIGZyYWdtZW50ZWQgaW4gc29t ZSBjYXNlcyksIHNvIGl0IGNhbiBhbHNvIA0KPiBiZSBpbiB0aGUgYnVnZml4ZXMgY2F0ZWdvcnku ICBJZiB5b3UgYWdyZWUsIHRoZW4gSSdsbCB1cGRhdGUgDQo+IHRoZSBJLUQgdG8gZm9sbG93IHRo ZSByZXF1aXJlbWVudHMgaW4gDQo+IGRyYWZ0LWRyYWdlLXNpcC1lc3NlbnRpYWwtY29ycmVjdGlv bi4NCj4gDQo+IFRoZXJlIGlzIEFGQUlLIG5vIGV4aXN0aW5nIHJlcXVpcmVtZW50cyBkb2N1bWVu dC4gIEkgd2lsbCANCj4gd29yayBvbiB0aGlzLCB3aXRoIHRoZSBhdXRob3JzIG9mIA0KPiBkcmFm dC1ndXJiYW5pLXNpcC1sYXJnZS11ZHAtcmVzcG9uc2UtMDAgaWYgdGhleSBhcmUgaW50ZXJlc3Rl ZC4NCj4gDQo+ID4gZHJhZnQtcGV0aXRodWd1ZW5pbi1zaXAtb3V0Ym91bmQtZnJhZ21lbnRhdGlv bi0wMiAoZXh0ZW5kcyANCj4gU1RVTiDigJMgZG9lcyANCj4gPiB0aGlzIGJlbG9uZyB3aXRoIEJF SEFWRSBXRz8pDQo+IA0KPiBZb3UgYXJlIHJpZ2h0IHRoYXQgdGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBTVFVOIGV4dGVuc2lvbiwgDQo+IHNvIGl0IHNob3VsZCBwZXJoYXBzIGJlIGluIHRoZSBC RUhBVkUgV0cuICBCdXQgaXQgYWxzbyANCj4gZGVzY3JpYmVzIGFuIGV4dGVuc2lvbiB0byBPdXRi b3VuZC4gIFNvIHNob3VsZCBJIHNwbGl0IHRoZSANCj4gZG9jdW1lbnQgaW4gdHdvLCBvbmUgZm9y IHRoZSBTVFVOIHVzYWdlcyAoaW4gdGhlIEJFSEFWRSBXRyksIA0KPiBhbmQgYW5vdGhlciBvbmUg Zm9yIHRoZSB1c2FnZSBvZiB0aGUgU1RVTiBVc2FnZXMgaW4gT3V0Ym91bmQ/DQo+IA0KPiBBbnl3 YXksIEkgYmVsaWV2ZSB0aGF0IHRoZSBPdXRib3VuZCBleHRlbnNpb24gcGFydCBvZiB0aGlzIA0K PiBkb2N1bWVudCBiZWxvbmcgdG8gdGhlIFNJUCBXRy4gIFRoZXJlIGlzIG5vIGV4aXN0aW5nIA0K PiByZXF1aXJlbWVudHMgZG9jdW1lbnQsIGJ1dCBJIHRoaW5rIHRoYXQgaXQgY291bGQgYmUgdGhl IHNhbWUgDQo+IGRvY3VtZW50IHRoYW4gdGhlIG9uZSB0aGF0IG5lZWQgdG8gYmUgd3JpdHRlbiBm b3IgDQo+IGRyYWZ0LXBldGl0aHVndWVuaW4tc2lwLWZyYWdtZW50YXRpb24tcmVzcG9uc2VzLTAy IChzZWUgYWJvdmUpLg0KPiANCj4gLS0gDQo+IE1hcmMgUGV0aXQtSHVndWVuaW4gICAgICAgICAg IFsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBdDQo+IEhvbWU6IG1hcmNAcGV0aXQt aHVndWVuaW4ub3JnIFtSRkMxODU1LWNvbXBsaWFudCBzcGFjZSBmb3IgcmVudCBdDQo+IFdvcms6 IG1hcmNAOHg4LmNvbSAgICAgICAgICAgIFsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBdDQo+IA0K --===============0973551947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0973551947==-- From sip-bounces@ietf.org Fri Mar 09 14:31:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPknO-0005aY-Qu; Fri, 09 Mar 2007 14:30:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPknM-0005aF-UR for sip@ietf.org; Fri, 09 Mar 2007 14:30:28 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPknK-0003WC-EU for sip@ietf.org; Fri, 09 Mar 2007 14:30:28 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l29JUIqd020637; Fri, 9 Mar 2007 13:30:24 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:30:22 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 20:30:08 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Making sense of the SIP author drafts Date: Fri, 9 Mar 2007 20:30:08 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F41E@DEEXC1U01.de.lucent.com> In-Reply-To: <45F1A6D6.50609@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Making sense of the SIP author drafts Thread-Index: AcdieHuxCTb+4QIYQv6GAea6Nfo3OwACFYuA From: "Drage, Keith \(Keith\)" To: "Marc Petit-Huguenin" X-OriginalArrivalTime: 09 Mar 2007 19:30:08.0966 (UTC) FILETIME=[592B4660:01C76281] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0402722102==" Errors-To: sip-bounces@ietf.org --===============0402722102== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBtaXNzZWQgdGhlIDJuZCBwYXJ0IG9mIHlvdXIgbWFpbCByZWxhdGluZyB0byANCg0KZHJhZnQt cGV0aXRodWd1ZW5pbi1zaXAtb3V0Ym91bmQtZnJhZ21lbnRhdGlvbi0wMiANCg0KSSB3b3VsZCBy ZWNvbW1lbmQgdGhhdCB3ZSB0cnkgYW5kIGlkZW50aWZ5IHNvbWUga2V5IHJlcXVpcmVtZW50cyBm b3IgdGhpcyBwcm9ibGVtLCBhbmQgZGVjaWRlIGluIFByYWd1ZSB3aGljaCBXRyBwcm9ncmVzc2Vz IHRob3NlIHJlcXVpcmVtZW50cyAtIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMgbGlrZWx5IHRvIGJl IHNvbWUgY29uY2Vuc3VzIG9uIHRoZSBwcm9ibGVtIChpdCBtYXkgd2VsbCBiZSBTSVBQSU5HKS4g SSBiZWxpZXZlIHlvdSBoYXZlIGFuICJJZiB0aW1lIHBlcm1pdHMuLi4iIHNsb3QgaW4gdGhlIFNJ UCBXRyBmb3IgdGhpcyBkcmFmdC4NCg0KT25jZSB0aGUgcmVxdWlyZW1lbnRzIGV4aXN0LCB0aGV5 IGNhbiBiZSBkZWxpdmVyZWQgdG8gU0lQIGFuZCBCRUhBVkUgZm9yIGVhY2ggdG8gd29yayBvbiB0 aGVpciBwYXJ0IG9mIHRoZSBwcm9ibGVtLg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyYyBQZXRpdC1IdWd1ZW5pbiBbbWFpbHRv OnBldGl0aHVnQGFjbS5vcmddIA0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDA5LCAyMDA3IDY6Mjcg UE0NCj4gVG86IERyYWdlLCBLZWl0aCAoS2VpdGgpDQo+IENjOiBzaXBAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtTaXBdIE1ha2luZyBzZW5zZSBvZiB0aGUgU0lQIGF1dGhvciBkcmFmdHMNCj4g DQo+IElubGluZS4NCj4gDQo+IERyYWdlLCBLZWl0aCAoS2VpdGgpIHdyb3RlOg0KPiA+IChhcyBX RyBjaGFpcikNCj4gPiANCj4gPiBJIGhhdmUgYmVlbiBhdHRlbXB0aW5nIHRvIG1ha2Ugc2Vuc2Ug b2YgdGhlIGxhcmdlIG51bWJlciBvZiANCj4gYXV0aG9yIGRyYWZ0cyBvdXQgdGhlcmUgd2hpY2gg aW4gc29tZSBtYW5uZXIgaW1wYWN0IFNJUC4gSSANCj4gaGF2ZSB0aHJlZSBjYXRlZ29yaWVzOg0K PiA+IA0KPiA+IC0JQnVnZml4ZXMgKGRvY3VtZW50cyB3aGljaCBtYXkgZmFsbCBpbnRvIHRoZSBj cml0ZXJpYSANCj4gaWRlbnRpZmllZCBpbiBkcmFmdC1kcmFnZS1zaXAtZXNzZW50aWFsLWNvcnJl Y3Rpb24tMDEpDQo+ID4gLQlTSVAgZXh0ZW5zaW9ucyAod2hpY2ggbmVlZCB0byBiZSBTSVAgY2hh cnRlciBpdGVtcyBkdWUgDQo+IHRvIFJGQyAzNDI3KQ0KPiA+IC0JU2VjdXJpdHkgKGFsbCBTSVAg c2VjdXJpdHkgaXNzdWVzIGFyZSBub3JtYWxseSBkZWFsdCANCj4gd2l0aCBpbiB0aGUgU0lQIFdH LCBldmVuIGlmIElORk9STUFUSU9OQUwpDQo+ID4gDQo+ID4gUGx1cyBvbmUgd2hlcmUgSSBkb24n dCBrbm93IHdoZXJlIHRvIHB1dCB0aGUgZG9jdW1lbnQuDQo+ID4gDQo+ID4gVGhlIGxpc3RzIGZv bGxvdywgYnV0IHRoZSBpbmZvcm1hdGlvbiBJIG5lZWQgKGZyb20gdGhlIGF1dGhvcnMgaWYgDQo+ ID4gbm9vbmUgZWxzZSBpcykNCj4gPiANCj4gPiAtCWRvZXMgdGhlIGRvY3VtZW50IGJlbG9uZyBv ciBub3QgYmVsb25nIGluIHRoZSBTSVAgZ3JvdXAgDQo+IGFzIGEgcmVzdWx0IG9mIHRoaXMgYW5h bHlzaXM/DQo+ID4gLQloYXZlIEkgY2F0ZWdvcmlzZWQgdGhpcyBjb3JyZWN0bHk/DQo+ID4gLQlo YXZlIEkgbWlzc2VkIGFueSBkcmFmdHMgdGhhdCBzaG91bGQgYmUgaGVyZT8NCj4gPiAtCWZvciB0 aGUgU0lQIGV4dGVuc2lvbnMgaXMgdGhlcmUgYSBkb2N1bWVudCBvdXQgdGhlcmUgDQo+IHdoaWNo IGxpc3RzIHRoZSByZXF1aXJlbWVudHMsIGFuZCBpZiBzbywgd2hpY2ggZG9jdW1lbnQgaXMgDQo+ IGl0PyBCeSB0aGlzIEkgbWVhbiBhIHNvbWUgdGV4dCwgdG90YWxseSBpbmRlcGVuZGVudCBvZiB0 aGUgDQo+IHByb3Bvc2VkIHNvbHV0aW9uIHdoaWNoOg0KPiA+IA0KPiA+IAlpZGVudGlmaWVzIHRo ZSBuZWVkIGZvciBhIG1lY2hhbmlzbSAoQSBtZWNoYW5pc20gaXMgDQo+IG5lZWRlZCBzdWNoIHRo YXQgLi4uKQ0KPiA+IAlwcm92aWRlcyByZXF1aXJlbWVudHMgKFRoZSBtZWNoYW5pc20gTVVTVC9T SE9VTEQvTUFZIA0KPiBzdXBwb3J0IC4uLikNCj4gPiANCj4gPiBOb3RlIHRoYXQgaWYgc3VjaCB0 ZXh0IGRvZXMgbm90IGV4aXN0LCBJIHN0cm9uZ2x5IHN1Z2dlc3QgDQo+IHRoYXQgYXV0aG9ycyBv ZiBTSVAgZXh0ZW5zaW9ucyB3aXRoIFJGQyAzNDI3IGltcGFjdCB0aGluayANCj4gYWJvdXQgcHJv dmlkaW5nIHN1Y2ggdGV4dCBpZiB0aGV5IHdhbnQgdGhlaXIgZG9jdW1lbnQgdG8gDQo+IHByb2dy ZXNzLCBvciBlbHNlIHByb3ZpZGUgYSByYXRpb25hbCBleHBsYW5hdGlvbiBvZiB3aHkgaXQgaXMg DQo+IG5vdCBuZWVkZWQuIFN1Y2ggdGV4dCBtYXkgd2VsbCBiZWxvbmcgd2l0aCB0aGUgU0lQUElO RyBncm91cCANCj4gZm9yIHByaW9yIGRpc2N1c3Npb24uDQo+ID4gDQo+ID4gTm9uZSBvZiB0aGUg YWJvdmUgaW1wbGllcyBhbnkgY29tbWl0bWVudCBvZiB0aGUgU0lQIFdHIG9yIA0KPiBJRVRGIHRv IGZ1cnRoZXIgdGhlIHdvcmsgb24gc3VjaCBkcmFmdHMsIGJ1dCBJIHN1c3BlY3QgaWYgaXQgDQo+ IGlzIG5vdCBjb21wbGV0ZSBvbiBteSBsaXN0LCB3aXRoIHRoZSBpbmZvcm1hdGlvbiBhcyByZXF1 ZXN0ZWQgDQo+IGFib3ZlLCB0aGVuIG5vdGhpbmcgaXMgZ29pbmcgdG8gaGFwcGVuIHdpdGggaXQu DQo+ID4gDQo+ID4gUmVnYXJkcw0KPiA+IA0KPiA+IEtlaXRoDQo+ID4gDQo+ID4gDQo+ID4gDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiAtLS0tLS0tLS0tDQo+ID4gQXV0aG9yIGRyYWZ0cyAtIGV4dGVu c2lvbnMNCj4gPiANCj4gDQo+IFtzbmlwXQ0KPiANCj4gPiBkcmFmdC1wZXRpdGh1Z3VlbmluLXNp cC1mcmFnbWVudGF0aW9uLXJlc3BvbnNlcy0wMiAoZGVmaW5lcyANCj4gbmV3IGhlYWRlciANCj4g PiBmaWVsZCwgbmV3IHJlc3BvbnNlIGNvZGUsIGFuZCBuZXcgaGVhZGVyIGZpZWxkIHBhcmFtZXRl cnMpDQo+IA0KPiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBTSVAgZXh0ZW5zaW9uIHRoYXQgZml4 ZXMgYSBidWcgaW4gU0lQIA0KPiAoaS5lLiBTSVAgcmVzcG9uc2UgZnJhZ21lbnRlZCBpbiBzb21l IGNhc2VzKSwgc28gaXQgY2FuIGFsc28gDQo+IGJlIGluIHRoZSBidWdmaXhlcyBjYXRlZ29yeS4g IElmIHlvdSBhZ3JlZSwgdGhlbiBJJ2xsIHVwZGF0ZSANCj4gdGhlIEktRCB0byBmb2xsb3cgdGhl IHJlcXVpcmVtZW50cyBpbiANCj4gZHJhZnQtZHJhZ2Utc2lwLWVzc2VudGlhbC1jb3JyZWN0aW9u Lg0KPiANCj4gVGhlcmUgaXMgQUZBSUsgbm8gZXhpc3RpbmcgcmVxdWlyZW1lbnRzIGRvY3VtZW50 LiAgSSB3aWxsIA0KPiB3b3JrIG9uIHRoaXMsIHdpdGggdGhlIGF1dGhvcnMgb2YgDQo+IGRyYWZ0 LWd1cmJhbmktc2lwLWxhcmdlLXVkcC1yZXNwb25zZS0wMCBpZiB0aGV5IGFyZSBpbnRlcmVzdGVk Lg0KPiANCj4gPiBkcmFmdC1wZXRpdGh1Z3VlbmluLXNpcC1vdXRib3VuZC1mcmFnbWVudGF0aW9u LTAyIChleHRlbmRzIA0KPiBTVFVOIOKAkyBkb2VzIA0KPiA+IHRoaXMgYmVsb25nIHdpdGggQkVI QVZFIFdHPykNCj4gDQo+IFlvdSBhcmUgcmlnaHQgdGhhdCB0aGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhIFNUVU4gZXh0ZW5zaW9uLCANCj4gc28gaXQgc2hvdWxkIHBlcmhhcHMgYmUgaW4gdGhlIEJF SEFWRSBXRy4gIEJ1dCBpdCBhbHNvIA0KPiBkZXNjcmliZXMgYW4gZXh0ZW5zaW9uIHRvIE91dGJv dW5kLiAgU28gc2hvdWxkIEkgc3BsaXQgdGhlIA0KPiBkb2N1bWVudCBpbiB0d28sIG9uZSBmb3Ig dGhlIFNUVU4gdXNhZ2VzIChpbiB0aGUgQkVIQVZFIFdHKSwgDQo+IGFuZCBhbm90aGVyIG9uZSBm b3IgdGhlIHVzYWdlIG9mIHRoZSBTVFVOIFVzYWdlcyBpbiBPdXRib3VuZD8NCj4gDQo+IEFueXdh eSwgSSBiZWxpZXZlIHRoYXQgdGhlIE91dGJvdW5kIGV4dGVuc2lvbiBwYXJ0IG9mIHRoaXMgDQo+ IGRvY3VtZW50IGJlbG9uZyB0byB0aGUgU0lQIFdHLiAgVGhlcmUgaXMgbm8gZXhpc3RpbmcgDQo+ IHJlcXVpcmVtZW50cyBkb2N1bWVudCwgYnV0IEkgdGhpbmsgdGhhdCBpdCBjb3VsZCBiZSB0aGUg c2FtZSANCj4gZG9jdW1lbnQgdGhhbiB0aGUgb25lIHRoYXQgbmVlZCB0byBiZSB3cml0dGVuIGZv ciANCj4gZHJhZnQtcGV0aXRodWd1ZW5pbi1zaXAtZnJhZ21lbnRhdGlvbi1yZXNwb25zZXMtMDIg KHNlZSBhYm92ZSkuDQo+IA0KPiAtLSANCj4gTWFyYyBQZXRpdC1IdWd1ZW5pbiAgICAgICAgICAg WyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF0NCj4gSG9tZTogbWFyY0BwZXRpdC1o dWd1ZW5pbi5vcmcgW1JGQzE4NTUtY29tcGxpYW50IHNwYWNlIGZvciByZW50IF0NCj4gV29yazog bWFyY0A4eDguY29tICAgICAgICAgICAgWyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IF0NCj4gDQo= --===============0402722102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0402722102==-- From sip-bounces@ietf.org Fri Mar 09 14:41:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPkxP-0006OH-6c; Fri, 09 Mar 2007 14:40:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPkxO-0006OC-5g for sip@ietf.org; Fri, 09 Mar 2007 14:40:50 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPkx8-0005Vq-8C for sip@ietf.org; Fri, 09 Mar 2007 14:40:50 -0500 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l29JeQU9087995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2007 13:40:26 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE29180E1F41C@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180E1F41C@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <982C8E8B-3183-4F33-AA4C-4DFBA760F9BC@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Sip] Making sense of the SIP author drafts Date: Fri, 9 Mar 2007 13:40:22 -0600 To: "Drage, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org, Marc Petit-Huguenin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My initial impression: Marc's draft looks (on a fast skim) to just use the extension =20 mechanisms to address a problem, not normatively replace text in =20 3261, so from that perspective, if/when consensus around it settled, =20 it would be published directly and not go into the essential-=20 correction process (with the caveat that I have only given it a fast =20 skim). That said, its a bit early to try to classify such things for any =20 purpose other than setting rough expectations. Things can (and probably will) change as drafts go through the consensus process. RjS On Mar 9, 2007, at 1:24 PM, Drage, Keith ((Keith)) wrote: > As I have clarified in a separate mail, bugfixes don't need =20 > requirements, but they will need to follow the procedures of > > http://www.ietf.org/internet-drafts/draft-drage-sip-essential-=20 > correction-01.txt > > Or the current version of that. > > We have asked Robert to lead the bugfixes programme. > > I would welcome his take (and indeed that of anyone else) as to =20 > whether this is a RFC 3261 bug that needs fixing, or something else. > > Keith > > > >> -----Original Message----- >> From: Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: Friday, March 09, 2007 6:27 PM >> To: Drage, Keith (Keith) >> Cc: sip@ietf.org >> Subject: Re: [Sip] Making sense of the SIP author drafts >> >> Inline. >> >> Drage, Keith (Keith) wrote: >>> (as WG chair) >>> >>> I have been attempting to make sense of the large number of >> author drafts out there which in some manner impact SIP. I >> have three categories: >>> >>> - Bugfixes (documents which may fall into the criteria >> identified in draft-drage-sip-essential-correction-01) >>> - SIP extensions (which need to be SIP charter items due >> to RFC 3427) >>> - Security (all SIP security issues are normally dealt >> with in the SIP WG, even if INFORMATIONAL) >>> >>> Plus one where I don't know where to put the document. >>> >>> The lists follow, but the information I need (from the authors if >>> noone else is) >>> >>> - does the document belong or not belong in the SIP group >> as a result of this analysis? >>> - have I categorised this correctly? >>> - have I missed any drafts that should be here? >>> - for the SIP extensions is there a document out there >> which lists the requirements, and if so, which document is >> it? By this I mean a some text, totally independent of the >> proposed solution which: >>> >>> identifies the need for a mechanism (A mechanism is >> needed such that ...) >>> provides requirements (The mechanism MUST/SHOULD/MAY >> support ...) >>> >>> Note that if such text does not exist, I strongly suggest >> that authors of SIP extensions with RFC 3427 impact think >> about providing such text if they want their document to >> progress, or else provide a rational explanation of why it is >> not needed. Such text may well belong with the SIPPING group >> for prior discussion. >>> >>> None of the above implies any commitment of the SIP WG or >> IETF to further the work on such drafts, but I suspect if it >> is not complete on my list, with the information as requested >> above, then nothing is going to happen with it. >>> >>> Regards >>> >>> Keith >>> >>> >>> >> ---------------------------------------------------------------------=20= >> - >>> ---------- >>> Author drafts - extensions >>> >> >> [snip] >> >>> draft-petithuguenin-sip-fragmentation-responses-02 (defines >> new header >>> field, new response code, and new header field parameters) >> >> This document defines a SIP extension that fixes a bug in SIP >> (i.e. SIP response fragmented in some cases), so it can also >> be in the bugfixes category. If you agree, then I'll update >> the I-D to follow the requirements in >> draft-drage-sip-essential-correction. >> >> There is AFAIK no existing requirements document. I will >> work on this, with the authors of >> draft-gurbani-sip-large-udp-response-00 if they are interested. >> >>> draft-petithuguenin-sip-outbound-fragmentation-02 (extends >> STUN =96 does >>> this belong with BEHAVE WG?) >> >> You are right that this document describes a STUN extension, >> so it should perhaps be in the BEHAVE WG. But it also >> describes an extension to Outbound. So should I split the >> document in two, one for the STUN usages (in the BEHAVE WG), >> and another one for the usage of the STUN Usages in Outbound? >> >> Anyway, I believe that the Outbound extension part of this >> document belong to the SIP WG. There is no existing >> requirements document, but I think that it could be the same >> document than the one that need to be written for >> draft-petithuguenin-sip-fragmentation-responses-02 (see above). >> >> --=20 >> Marc Petit-Huguenin [ ] >> Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] >> Work: marc@8x8.com [ ] >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 14:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl0f-0003BN-C4; Fri, 09 Mar 2007 14:44:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl0d-0003B1-FY for sip@ietf.org; Fri, 09 Mar 2007 14:44:11 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPl0b-00066u-Vd for sip@ietf.org; Fri, 09 Mar 2007 14:44:11 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l29Ji2b08330; Fri, 9 Mar 2007 19:44:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt Date: Fri, 9 Mar 2007 13:43:54 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F8915BF@zrc2hxm0.corp.nortel.com> In-Reply-To: <00d001c7617c$f1ee8c50$3f91460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt Thread-Index: AcdbarbTgoznNYBZRcqJyrGfl3IayQAFK0jgAX2jUhAAQuU48A== References: <1ECE0EB50388174790F9694F77522CCF0F62DDEA@zrc2hxm0.corp.nortel.com> <00d001c7617c$f1ee8c50$3f91460a@china.huawei.com> From: "Francois Audet" To: "Lavis Zhou" X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thank you for your comments Lavis. I will incorporate most of them into = version -03. It will result on good clarfications. On the following 2 items: Item 2:=20 Yes, I guess one of the item that we will discuss in Prague (as per = Appendix A), is the idea of deprecating the last hop exception.=20 Item 5: I don't understand your question. And for the part about the conflict: there is no conflict. The case = you are refering to in line 680 is the case where a request is sent over TLS using = SIP Request-URI. It just recommends putting a SIP Contact instead of SIPS because of = complications that=20 would arise. > -----Original Message----- > From: Lavis Zhou [mailto:lavis@huawei.com]=20 > Sent: Thursday, March 08, 2007 04:26 > To: Audet, Francois (SC100:3055) > Cc: 'SIP' > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt >=20 > Hi, > Some doubts or comments about this draft: > 1. Section 3, Line 237, for the statement "In either case,=20 > the Request-URI would be > a SIPS URI." > It's better to mention Request-URI in which hop is a SIPS=20 > URI, so it may be better to state as "In either case, the=20 > Request-URI between Proxy B and UA b would be > a SIPS URI." > 2. Section 4, Line 348 > "except for cases where the "last-hop exception" > rule is in effect (in which case the Request-URI would be=20 > replaced by > a SIP URI)." > This statement is conflicted with the statement referred by=20 > bullet 1 which emphasises that Request-URI should be SIPS. Is=20 > it better to state that SIPS cannot be downgraded to SIP even=20 > TLS will not be used in last-hop exception to make it consistent? > 3. Section 4.1, Line 430 > " then the dialog is "tentatively" secure." > It's better to change the word "dialog" to "transaction or=20 > dialog" as there may be a MESSAGE transaction which will not=20 > establish a dialog. > 4. Section 5, Line 573 > " If all the Contacts are SIPS, a SIPS AOR MUST also be used by the > UAC. If at least one of the Contacts is SIP or is neither SIP nor > SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also=20 > be used by > the UAC." > And line 599 > " A registrar MUST only accept a binding to a SIPS Contact if all the > appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the > AOR (i.e., To header), the From header, the Contacts and=20 > all the Path > headers." > From the second part, it can be inferred that a SIPS contact=20 > can only be registered by a SIPS AOR and SIPS contact and SIP=20 > contact cannot be registered in one REGISTER message. But the=20 > first part is not mention this meaning clearly. Is it better=20 > to append this implication? > 5. Section 6 Line 644, > " As mandated by [RFC3261]/8.1.1.8, in a request, if the=20 > Request-URI or > top Route header field value contains a SIPS URI, the=20 > Contact header > field MUST contain a SIPS URI as well." > Why top Route header filed value has to be checked? If the=20 > resource UAC want to accessed which identified by Req-URI is=20 > a SIP URI, so it will be non-secure, the secure link in one=20 > hop will help? And in this case, it will mandatory one of the=20 > proxy in-between to RR as there is a conversion between SIPS=20 > and SIP. Is any usage for this? > And the statement is conflict with the following statement=20 > (line 680) " It is therefore > RECOMMENDED that in this case, the Contact be a SIP URI" > So it's better to remove the top Route header check. > 6. Section 6, Line 686 > " When a target refresh occurs within a dialog (e.g., re-INVITE, > UPDATE), unless there is a need to change it, the UAC=20 > SHOULD include > a Contact header with a SIPS URI if the original request=20 > used a SIPS > Request-URI." > As my understanding, the response of a target refresh request=20 > also can carry a different Contact to update the target, so=20 > the statement may be should be rewritten. > 7. some Type errors > a. "The USC registers either a SIPS or a SIP AOR.", USC=20 > should be UAC b. "Since upgrading from SIP to SIPS is allowed=20 > it other circumstances", "it" should be "in". > c. "If the Request-UIR on the receiving", UIR should be URI. > d. "MAY or MAY NOTt use TLS", NOTt should be NOT. > e. nothwistanding should be notwithstanding. >=20 > Rgds, > Lavis >=20 > ************************************************************** > ************** > *********** > = =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA > = =D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0= =CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF= =BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2 > = =B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4= =FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7= =BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1= =BE > =D3=CA=BC=FE=A3=A1 > ************************************************************** > ************** > ********** > =20 > ************************************************************** > ************** > *********** > This e-mail and its attachments contain confidential=20 > information from HUAWEI, which is intended only for the=20 > person or entity whose address is listed above. Any use of=20 > the information contained herein in any way (including, but=20 > not limited to, total or partial disclosure, reproduction, or=20 > dissemination) by persons other than the intended=20 > recipient(s) is prohibited. If you receive this e-mail in=20 > error, please notify the sender by phone or email immediately=20 > and delete it! > ************************************************************** > ************** > *********** >=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, March 01, 2007 6:00 AM > To: Jonathan Rosenberg > Cc: SIP > Subject: [Sip] draft-ietf-sip-sips Open Issues: Delivering=20 > requests toregistered contact >=20 > I'm changing the Subject field because Jonathan is pointing=20 > out another important issue. >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Wednesday, February 28, 2007 11:00 > > To: Audet, Francois (SC100:3055) > > Cc: Robert Sparks; SIP > > Subject: Re: [Sip] draft-ietf-sip-sips Open Issues: GRUU > > > > Another related point, with current registrar behavior of replacing=20 > > the R-URI with the registered contact, if I send a REGISTER request=20 > > with a sips Contact and sips URI, and then someone sends me=20 > a call to=20 > > the sip version of my AOR, the r-uri will be translated to the sips=20 > > contact I had registered. So how does a sips-only client=20 > reject this?=20 > > I'm referring to paragraph 4 in section 5. Not a GRUU=20 > question per se,=20 > > but related. >=20 > Actually, I the problem you are refering to affects not only=20 > REGISTER, but any requests that has a Contact (like an=20 > INVITE, if you expect mid-dialog requests). >=20 > That problem is something that I noticed was a big problem in=20 > earlier versions of this draft (i.e., draft-ietf-sip-sips-00,=20 > and the individual drafts draft-audet-sip-sips-guidelines). > Basically, it was broken >=20 > I had done a change in this version of the draft (i.e., > draft-ietf-sip-sips-01) to address this. Look at the second=20 > paragraph of section 4. (The call flows have been adjusted=20 > for this too). >=20 > Basically, it says that the proxy must keep the same scheme=20 > (sip or sips) that was in the incoming request before=20 > delivering it (i.e., sip -> sip, and sips -> sips). > If we don't do that, we'll have the problem you are=20 > describing, but we'll also have a bigger problem with=20 > mid-dialog requests. >=20 > To me this is consistent with the idea that schemes are=20 > equivalent from a routing perspective. >=20 > So yes, the proxy replaces the contact with the registered=20 > contact, but it keeps the originial scheme of the request=20 > that it is forwarding. >=20 > > I'll note that this issue is solved with UA loose route. >=20 > Yes it would. But I think proxies should nevertheless keep=20 > the same scheme (sip or sips) when forwarding a request to=20 > the client. Otherwise, it makes SIPS dependent on loose=20 > routes. I do not think that it would be warranted to make=20 > that a dependency. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 14:51:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl77-0004oa-E1; Fri, 09 Mar 2007 14:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl75-0004mm-95 for sip@ietf.org; Fri, 09 Mar 2007 14:50:51 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPl6F-00079E-Tk for sip@ietf.org; Fri, 09 Mar 2007 14:50:01 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l29JntIe015780; Fri, 9 Mar 2007 13:49:55 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:49:55 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 20:49:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Diversion header draft/RFC status? Date: Fri, 9 Mar 2007 20:49:52 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F425@DEEXC1U01.de.lucent.com> In-Reply-To: <623C984B2206AC4CAE7CED15174F019D05AC9A40@ASHEVS005.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Diversion header draft/RFC status? Thread-Index: Acdg0/G07s0Dkd//R5iQny96G6ezbwBr9vxA From: "Drage, Keith \(Keith\)" To: "Iliff, Tina" , X-OriginalArrivalTime: 09 Mar 2007 19:49:53.0184 (UTC) FILETIME=[1B049A00:01C76284] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 4244 (An Extension to the Session Initiation Protocol for Request History Information)=20 and=20 RFC 4458 (Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR))=20 Are the SIP RFCs that provide the diversion functionality (over and above RFC 3261). Regards Keith ________________________________ From: Iliff, Tina [mailto:tina.iliff@verizonbusiness.com]=20 Sent: Wednesday, March 07, 2007 4:16 PM To: sip@ietf.org Subject: [Sip] Diversion header draft/RFC status? =09 =09 draft-levy-sip-diversion-08 expired back in 2005. Has History-Info replaced Diversion? Or is there a new draft or RFC? Thanks,=20 Tina Iliff=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 15:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPm8f-00055h-QK; Fri, 09 Mar 2007 15:56:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPm8c-00054M-VO for sip@ietf.org; Fri, 09 Mar 2007 15:56:30 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPm8O-0008Mh-D3 for sip@ietf.org; Fri, 09 Mar 2007 15:56:30 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l29K2BMB027319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Mar 2007 14:02:11 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Fri, 9 Mar 2007 14:56:11 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't normally discuss patent-related issues here, but this one has me worried. According to C/NET (http://news.com.com/2100-1036_3-6162747.html) "The broader dispute rests on allegations by Verizon that features central to the success of Vonage's offerings infringe on five of its patents. They relate to various aspects of commercial voice over Internet Protocol, or VoIP, service, including methods of connecting Internet calls to the public-switched telephone network, enabling features like call forwarding and voice mail, and allowing Internet phone usage via Wi-Fi hot spots." If I'm reading this right (along with what I've managed to winkle out of the reporting coverage) it looks like the courts have proclaimed that Verizon has exclusive rights to processing phone numbers in a proxy, making conditional forwarding decisions based on presence, making calls from WiFi attached devices, and so on. This is amazingly huge, and very clearly has implications (if not overturned) on our work. Like, "We might as well all go home" sorts of implications. You might take a look at patents 6,104,711 and 6,282,574 by Eric Voit, and 6,359,880 by James Curry and Robert Farris, as I believe the courts considered these in the Verizon vs Vonage case. 6,104,711's abstract: An enhanced name translation server, for use on a packet data network such as the Internet, executes a conditional analysis in response to at least some queries or requests for name translations. For example, the server may return a different destination address at different times or in response to translation requests from different terminals. The server also can query a primary destination terminal device, and condition the response to the calling terminal on the status of the primary terminal. For example, if the primary terminal is `live` the server forwards the address of that terminal to the calling terminal device to set up communications. Otherwise, the server returns alternate destination address information. The server also supports a wide variety of different types of translations, including domain name to address, domain name to telephone number, and telephone number to address. The enhanced translations offer called customers numerous options for controlling communications directed toward them, and the customers may elect to apply these options both to their data communications services and their voice communications services through the packet data network. 6,282,574's abstract: An enhanced name translation server, for use on a packet data network such as the Internet, executes a conditional analysis in response to at least some queries or requests for name translations. For example, the server may return a different destination address at different times or in response to translation requests from different terminals. The server also can query a primary destination terminal device, and condition the response to the calling terminal on the status of the primary terminal. For example, if the primary terminal is `live` the server forwards the address of that terminal to the calling terminal device to set up communications. Otherwise, the server returns alternate destination address information. The server also supports a wide variety of different types of translations, including domain name to address, domain name to telephone number, and telephone number to address. The enhanced translations offer called customers numerous options for controlling communications directed toward them, and the customers may elect to apply these options both to their data communications services and their voice communications services through the packet data network. 6,359,880's abstract: A localized wireless gateway system provides wireless telephone communication, and for at least interexchange communication, provides voice telephone access to a public packet data network, such as the Internet. The wireless gateway system includes base station transceivers and a packet service gateway coupling the transceivers to the public packet data network. The packet service gateway compresses and decompresses voice frequency communication signals, and it sends and receives the compressed signals in packet form via the network. The packet service gateway also provides for signaling through the network to establish two-way voice communication sessions. In the preferred implementation, the localized wireless gateway system includes at least one radio port control unit coupled to the base station transceivers for controlling calls through the transceivers. The localized wireless gateway system also includes a telephone switch, such as a digital PBX, selectively providing telephone communication channels between the radio port control unit (s) and the packet service gateway. An access manager controls registration and validation of roaming wireless telephones to utilize the wireless gateway system. The access manager also transmits location information for registered wireless telephones to a home location register database via the network. The communications of the access manager to the home location register database permit telephone authentication as well as maintenance of accurate location information in the home location register identifying the current gateway through which a caller can reach the roaming user's wireless telephone. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 16:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmZK-0005xq-6V; Fri, 09 Mar 2007 16:24:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmZI-0005uo-E7 for sip@ietf.org; Fri, 09 Mar 2007 16:24:04 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPmZG-0007Os-Rc for sip@ietf.org; Fri, 09 Mar 2007 16:24:04 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2007 13:24:02 -0800 X-IronPort-AV: i="4.14,268,1170662400"; d="scan'208"; a="119673761:sNHT48220560" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l29LO2m3028646; Fri, 9 Mar 2007 13:24:02 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l29LNXeJ004711; Fri, 9 Mar 2007 21:24:00 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:23:58 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.122.177]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 13:23:57 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Mar 2007 15:23:56 -0600 To: Dean Willis , SIP IETF From: "James M. Polk" Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations In-Reply-To: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Mar 2007 21:23:57.0772 (UTC) FILETIME=[3F7460C0:01C76291] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4916; t=1173475442; x=1174339442; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20News=20flash=3A=20Verizon=20appears=20to=20ha ve=20exclusive=20rights=0A=20=20to=20IP=20telephony=20and=20SIP=20proxy=20 operations |Sender:=20; bh=11TH076CHlPmE4x38803l3poa1vTHM7Gji+xVmhMGOM=; b=XDOPgzXuvJ+4A1Rl3tvYGLO7uJn2F7yNaP0XvhgjCUbyFzDJYeypSSx+jQU6kOZoSQHt4pm1 txB5nZlopU9L0pLKR+ncnS+fqifCzFDsF8q+/V/rVqi7XY0OyalCWvpoKzjrOSaa7xW5jfA3Vn GneO32UURrnilIW5VDVuKRcvg=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 02:56 PM 3/9/2007, Dean Willis wrote: >You might take a look at patents 6,104,711 and 6,282,574 by Eric >Voit, both of these appear to be more tuned towards an H.323 type of architecture, looking like the addresses returned in H.225 Set-up message(s) >and 6,359,880 by James Curry and Robert Farris, this one seems to hurt more, as I read the abstract, this appears to cover all hot-spots for Telephony over IP communications - including residential 802.11, if used for voice communications. but I could be reading this completely incorrectly >as I believe >the courts considered these in the Verizon vs Vonage case. > > >6,104,711's abstract: > >An enhanced name translation server, for use on a packet data network >such as the Internet, executes a conditional analysis in response to >at least some queries or requests for name translations. For example, >the server may return a different destination address at different >times or in response to translation requests from different >terminals. The server also can query a primary destination terminal >device, and condition the response to the calling terminal on the >status of the primary terminal. For example, if the primary terminal >is `live` the server forwards the address of that terminal to the >calling terminal device to set up communications. Otherwise, the >server returns alternate destination address information. The server >also supports a wide variety of different types of translations, >including domain name to address, domain name to telephone number, >and telephone number to address. The enhanced translations offer >called customers numerous options for controlling communications >directed toward them, and the customers may elect to apply these >options both to their data communications services and their voice >communications services through the packet data network. > > >6,282,574's abstract: > >An enhanced name translation server, for use on a packet data network >such as the Internet, executes a conditional analysis in response to >at least some queries or requests for name translations. For example, >the server may return a different destination address at different >times or in response to translation requests from different >terminals. The server also can query a primary destination terminal >device, and condition the response to the calling terminal on the >status of the primary terminal. For example, if the primary terminal >is `live` the server forwards the address of that terminal to the >calling terminal device to set up communications. Otherwise, the >server returns alternate destination address information. The server >also supports a wide variety of different types of translations, >including domain name to address, domain name to telephone number, >and telephone number to address. The enhanced translations offer >called customers numerous options for controlling communications >directed toward them, and the customers may elect to apply these >options both to their data communications services and their voice >communications services through the packet data network. > > >6,359,880's abstract: > >A localized wireless gateway system provides wireless telephone >communication, and for at least interexchange communication, provides >voice telephone access to a public packet data network, such as the >Internet. The wireless gateway system includes base station >transceivers and a packet service gateway coupling the transceivers >to the public packet data network. The packet service gateway >compresses and decompresses voice frequency communication signals, >and it sends and receives the compressed signals in packet form via >the network. The packet service gateway also provides for signaling >through the network to establish two-way voice communication >sessions. In the preferred implementation, the localized wireless >gateway system includes at least one radio port control unit coupled >to the base station transceivers for controlling calls through the >transceivers. The localized wireless gateway system also includes a >telephone switch, such as a digital PBX, selectively providing >telephone communication channels between the radio port control unit >(s) and the packet service gateway. An access manager controls >registration and validation of roaming wireless telephones to utilize >the wireless gateway system. The access manager also transmits >location information for registered wireless telephones to a home >location register database via the network. The communications of the >access manager to the home location register database permit >telephone authentication as well as maintenance of accurate location >information in the home location register identifying the current >gateway through which a caller can reach the roaming user's wireless >telephone. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 16:27:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmcW-0001QL-75; Fri, 09 Mar 2007 16:27:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmcU-0001K1-PR for sip@ietf.org; Fri, 09 Mar 2007 16:27:22 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPmcQ-0008Lt-La for sip@ietf.org; Fri, 09 Mar 2007 16:27:22 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1425719ugd for ; Fri, 09 Mar 2007 13:27:17 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=e3OliOqHRQSe/d/hHkAMjTHjn1y9jnBDYWOa5xrJo0tEbrmw0NiApkFz3bm4JhIqoKCDvEnAZ8783RjQSlPEFWDMschtal4lPbKINV47psQEYO1KQ6P3SPisnmQMfKc5pefoLWbTY16U/IXhkT4rcfhdUW472isfESlsFlhbjhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ex5nbDuptkAcNssI8s7x+PbIdZEvJDRaCe+toZ9FarzNgyNZQ9GyDn+qS/XYqzXf/xMOGk9aHD5Vikiq1MeOrIuXwY6ExytUBKBFX0kSwZtsAUoJ8Z/0zIakDPU1Gc+QJ1S6Ly4K1FkmMPrDKGlyGCGFrEQjiYtzQimc+ikOSX0= Received: by 10.114.127.1 with SMTP id z1mr785795wac.1173475635498; Fri, 09 Mar 2007 13:27:15 -0800 (PST) Received: by 10.114.120.10 with HTTP; Fri, 9 Mar 2007 13:27:15 -0800 (PST) Message-ID: <894e079b0703091327r4d41cbd7j36a03f33fb5d459c@mail.gmail.com> Date: Fri, 9 Mar 2007 16:27:15 -0500 From: "Medhavi Bhatia" To: "James M. Polk" Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations In-Reply-To: MIME-Version: 1.0 References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> X-Google-Sender-Auth: 906fc9437eb0daa6 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0291333576==" Errors-To: sip-bounces@ietf.org --===============0291333576== Content-Type: multipart/alternative; boundary="----=_Part_4410_31711590.1173475635448" ------=_Part_4410_31711590.1173475635448 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that one was done in year 2000. Wasn't most of this stuff figured out by then? On 3/9/07, James M. Polk wrote: > > At 02:56 PM 3/9/2007, Dean Willis wrote: > >You might take a look at patents 6,104,711 and 6,282,574 by Eric > >Voit, > > both of these appear to be more tuned towards an H.323 type of > architecture, looking like the addresses returned in H.225 Set-up > message(s) > > >and 6,359,880 by James Curry and Robert Farris, > > this one seems to hurt more, as I read the abstract, this appears to > cover all hot-spots for Telephony over IP communications - including > residential 802.11, if used for voice communications. > > but I could be reading this completely incorrectly > > >as I believe > >the courts considered these in the Verizon vs Vonage case. > > > > > >6,104,711's abstract: > > > >An enhanced name translation server, for use on a packet data network > >such as the Internet, executes a conditional analysis in response to > >at least some queries or requests for name translations. For example, > >the server may return a different destination address at different > >times or in response to translation requests from different > >terminals. The server also can query a primary destination terminal > >device, and condition the response to the calling terminal on the > >status of the primary terminal. For example, if the primary terminal > >is `live` the server forwards the address of that terminal to the > >calling terminal device to set up communications. Otherwise, the > >server returns alternate destination address information. The server > >also supports a wide variety of different types of translations, > >including domain name to address, domain name to telephone number, > >and telephone number to address. The enhanced translations offer > >called customers numerous options for controlling communications > >directed toward them, and the customers may elect to apply these > >options both to their data communications services and their voice > >communications services through the packet data network. > > > > > >6,282,574's abstract: > > > >An enhanced name translation server, for use on a packet data network > >such as the Internet, executes a conditional analysis in response to > >at least some queries or requests for name translations. For example, > >the server may return a different destination address at different > >times or in response to translation requests from different > >terminals. The server also can query a primary destination terminal > >device, and condition the response to the calling terminal on the > >status of the primary terminal. For example, if the primary terminal > >is `live` the server forwards the address of that terminal to the > >calling terminal device to set up communications. Otherwise, the > >server returns alternate destination address information. The server > >also supports a wide variety of different types of translations, > >including domain name to address, domain name to telephone number, > >and telephone number to address. The enhanced translations offer > >called customers numerous options for controlling communications > >directed toward them, and the customers may elect to apply these > >options both to their data communications services and their voice > >communications services through the packet data network. > > > > > >6,359,880's abstract: > > > >A localized wireless gateway system provides wireless telephone > >communication, and for at least interexchange communication, provides > >voice telephone access to a public packet data network, such as the > >Internet. The wireless gateway system includes base station > >transceivers and a packet service gateway coupling the transceivers > >to the public packet data network. The packet service gateway > >compresses and decompresses voice frequency communication signals, > >and it sends and receives the compressed signals in packet form via > >the network. The packet service gateway also provides for signaling > >through the network to establish two-way voice communication > >sessions. In the preferred implementation, the localized wireless > >gateway system includes at least one radio port control unit coupled > >to the base station transceivers for controlling calls through the > >transceivers. The localized wireless gateway system also includes a > >telephone switch, such as a digital PBX, selectively providing > >telephone communication channels between the radio port control unit > >(s) and the packet service gateway. An access manager controls > >registration and validation of roaming wireless telephones to utilize > >the wireless gateway system. The access manager also transmits > >location information for registered wireless telephones to a home > >location register database via the network. The communications of the > >access manager to the home location register database permit > >telephone authentication as well as maintenance of accurate location > >information in the home location register identifying the current > >gateway through which a caller can reach the roaming user's wireless > >telephone. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_4410_31711590.1173475635448 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that one was done in year 2000. Wasn't most of this stuff figured out by then?

On 3/9/07, James M. Polk < jmpolk@cisco.com> wrote:
At 02:56 PM 3/9/2007, Dean Willis wrote:
>You might take a look at patents 6,104,711  and 6,282,574 by Eric
>Voit,

both of these appear to be more tuned towards an H.323 type of
architecture, looking like the addresses returned in H.225 Set-up message(s)

>and 6,359,880 by James Curry and Robert Farris,

this one seems to hurt more, as I read the abstract, this appears to
cover all hot-spots for Telephony over IP communications - including
residential 802.11, if used for voice communications.

but I could be reading this completely incorrectly

>as I believe
>the courts considered these in the Verizon vs Vonage case.
>
>
>6,104,711's abstract:
>
>An enhanced name translation server, for use on a packet data network
>such as the Internet, executes a conditional analysis in response to
>at least some queries or requests for name translations. For example,
>the server may return a different destination address at different
>times or in response to translation requests from different
>terminals. The server also can query a primary destination terminal
>device, and condition the response to the calling terminal on the
>status of the primary terminal. For example, if the primary terminal
>is `live` the server forwards the address of that terminal to the
>calling terminal device to set up communications. Otherwise, the
>server returns alternate destination address information. The server
>also supports a wide variety of different types of translations,
>including domain name to address, domain name to telephone number,
>and telephone number to address. The enhanced translations offer
>called customers numerous options for controlling communications
>directed toward them, and the customers may elect to apply these
>options both to their data communications services and their voice
>communications services through the packet data network.
>
>
>6,282,574's abstract:
>
>An enhanced name translation server, for use on a packet data network
>such as the Internet, executes a conditional analysis in response to
>at least some queries or requests for name translations. For example,
>the server may return a different destination address at different
>times or in response to translation requests from different
>terminals. The server also can query a primary destination terminal
>device, and condition the response to the calling terminal on the
>status of the primary terminal. For example, if the primary terminal
>is `live` the server forwards the address of that terminal to the
>calling terminal device to set up communications. Otherwise, the
>server returns alternate destination address information. The server
>also supports a wide variety of different types of translations,
>including domain name to address, domain name to telephone number,
>and telephone number to address. The enhanced translations offer
>called customers numerous options for controlling communications
>directed toward them, and the customers may elect to apply these
>options both to their data communications services and their voice
>communications services through the packet data network.
>
>
>6,359,880's abstract:
>
>A localized wireless gateway system provides wireless telephone
>communication, and for at least interexchange communication, provides
>voice telephone access to a public packet data network, such as the
>Internet. The wireless gateway system includes base station
>transceivers and a packet service gateway coupling the transceivers
>to the public packet data network. The packet service gateway
>compresses and decompresses voice frequency communication signals,
>and it sends and receives the compressed signals in packet form via
>the network. The packet service gateway also provides for signaling
>through the network to establish two-way voice communication
>sessions. In the preferred implementation, the localized wireless
>gateway system includes at least one radio port control unit coupled
>to the base station transceivers for controlling calls through the
>transceivers. The localized wireless gateway system also includes a
>telephone switch, such as a digital PBX, selectively providing
>telephone communication channels between the radio port control unit
>(s) and the packet service gateway. An access manager controls
>registration and validation of roaming wireless telephones to utilize
>the wireless gateway system. The access manager also transmits
>location information for registered wireless telephones to a home
>location register database via the network. The communications of the
>access manager to the home location register database permit
>telephone authentication as well as maintenance of accurate location
>information in the home location register identifying the current
>gateway through which a caller can reach the roaming user's wireless
>telephone.

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

------=_Part_4410_31711590.1173475635448-- --===============0291333576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0291333576==-- From sip-bounces@ietf.org Fri Mar 09 16:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmgL-0000Pn-2H; Fri, 09 Mar 2007 16:31:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmgJ-0000Pe-7G for sip@ietf.org; Fri, 09 Mar 2007 16:31:19 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPmgG-0000hr-Ob for sip@ietf.org; Fri, 09 Mar 2007 16:31:19 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id E4A9F3A0210C; Fri, 9 Mar 2007 13:31:13 -0800 (PST) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 1AA6F3A0210B; Fri, 9 Mar 2007 13:31:12 -0800 (PST) Message-ID: <45F1D21F.3040702@acm.org> Date: Fri, 09 Mar 2007 13:31:11 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Making sense of the SIP author drafts References: <5D1A7985295922448D5550C94DE29180E1F41E@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180E1F41E@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) wrote: > I missed the 2nd part of your mail relating to >=20 > draft-petithuguenin-sip-outbound-fragmentation-02 >=20 > I would recommend that we try and identify some key requirements for > this problem, and decide in Prague which WG progresses those > requirements - assuming that there is likely to be some concensus on > the problem (it may well be SIPPING). I believe you have an "If time > permits..." slot in the SIP WG for this draft. Yes, I will add the question of where this work should progress on my slides for the presentation (in case "[...] time permits.") >=20 > Once the requirements exist, they can be delivered to SIP and BEHAVE > for each to work on their part of the problem. >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- From: Marc Petit-Huguenin >> [mailto:petithug@acm.org] Sent: Friday, March 09, 2007 6:27 PM To: >> Drage, Keith (Keith) Cc: sip@ietf.org Subject: Re: [Sip] Making >> sense of the SIP author drafts >>=20 >> Inline. >>=20 >> Drage, Keith (Keith) wrote: >>> (as WG chair) >>>=20 >>> I have been attempting to make sense of the large number of >> author drafts out there which in some manner impact SIP. I have >> three categories: >>> - Bugfixes (documents which may fall into the criteria >> identified in draft-drage-sip-essential-correction-01) >>> - SIP extensions (which need to be SIP charter items due >> to RFC 3427) >>> - Security (all SIP security issues are normally dealt >> with in the SIP WG, even if INFORMATIONAL) >>> Plus one where I don't know where to put the document. >>>=20 >>> The lists follow, but the information I need (from the authors if >>> noone else is) >>>=20 >>> - does the document belong or not belong in the SIP group >> as a result of this analysis? >>> - have I categorised this correctly? - have I missed any drafts >>> that should be here? - for the SIP extensions is there a document >>> out there >> which lists the requirements, and if so, which document is it? By >> this I mean a some text, totally independent of the proposed >> solution which: >>> identifies the need for a mechanism (A mechanism is >> needed such that ...) >>> provides requirements (The mechanism MUST/SHOULD/MAY >> support ...) >>> Note that if such text does not exist, I strongly suggest >> that authors of SIP extensions with RFC 3427 impact think about >> providing such text if they want their document to progress, or >> else provide a rational explanation of why it is not needed. Such >> text may well belong with the SIPPING group for prior discussion. >>> None of the above implies any commitment of the SIP WG or >> IETF to further the work on such drafts, but I suspect if it is not >> complete on my list, with the information as requested above, then >> nothing is going to happen with it. >>> Regards >>>=20 >>> Keith >>>=20 >>>=20 >>>=20 >> ---------------------------------------------------------------------- >>=20 >>> ---------- Author drafts - extensions >>>=20 >> [snip] >>=20 >>> draft-petithuguenin-sip-fragmentation-responses-02 (defines >> new header >>> field, new response code, and new header field parameters) >> This document defines a SIP extension that fixes a bug in SIP (i.e. >> SIP response fragmented in some cases), so it can also be in the >> bugfixes category. If you agree, then I'll update the I-D to >> follow the requirements in draft-drage-sip-essential-correction. >>=20 >> There is AFAIK no existing requirements document. I will work on >> this, with the authors of draft-gurbani-sip-large-udp-response-00 >> if they are interested. >>=20 >>> draft-petithuguenin-sip-outbound-fragmentation-02 (extends >> STUN =E2=80=93 does >>> this belong with BEHAVE WG?) >> You are right that this document describes a STUN extension, so it >> should perhaps be in the BEHAVE WG. But it also describes an >> extension to Outbound. So should I split the document in two, one >> for the STUN usages (in the BEHAVE WG), and another one for the >> usage of the STUN Usages in Outbound? >>=20 >> Anyway, I believe that the Outbound extension part of this document >> belong to the SIP WG. There is no existing requirements document, >> but I think that it could be the same document than the one that >> need to be written for=20 >> draft-petithuguenin-sip-fragmentation-responses-02 (see above). >>=20 >> -- Marc Petit-Huguenin [ >> ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] >> Work: marc@8x8.com [ ] >>=20 --=20 Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 17:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnEq-0007Zs-TX; Fri, 09 Mar 2007 17:07:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnEn-0007Ie-32 for sip@ietf.org; Fri, 09 Mar 2007 17:06:57 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPnEl-0007uO-GE for sip@ietf.org; Fri, 09 Mar 2007 17:06:57 -0500 Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l29M6qtU077157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2007 16:06:52 -0600 (CST) (envelope-from bcampen@estacado.net) In-Reply-To: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> From: Byron Campen Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations Date: Fri, 9 Mar 2007 16:06:48 -0600 To: Dean Willis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2130347210==" Errors-To: sip-bounces@ietf.org --===============2130347210== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--250199435; protocol="application/pkcs7-signature" --Apple-Mail-3--250199435 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 6,104,711 and 6,282,574 seem to be a specifying a "smart" DNS server to me, and not a SIP proxy. (Although it might be possible to convince a jury that a redirect-server fell into this category). It also seems that these are directly related to enum. 6,359,880 seems to be nastier, in that it appears to be a patent on the concept of registration over pretty much any medium (although they specify TCP/ IP, but nothing about UDP. I hope this doesn't mean that avoiding this patent will require using UDP exclusively...) I am not sure how they got around the fact that 2543 predates this patent's submission. I'll probably try tracking down the court transcripts at some point. Best regards, Byron Campen > > I don't normally discuss patent-related issues here, but this one > has me worried. > > > According to C/NET (http://news.com.com/2100-1036_3-6162747.html) > > "The broader dispute rests on allegations by Verizon that features > central to the success of Vonage's offerings infringe on five of > its patents. They relate to various aspects of commercial voice > over Internet Protocol, or VoIP, service, including methods of > connecting Internet calls to the public-switched telephone network, > enabling features like call forwarding and voice mail, and allowing > Internet phone usage via Wi-Fi hot spots." > > If I'm reading this right (along with what I've managed to winkle > out of the reporting coverage) it looks like the courts have > proclaimed that Verizon has exclusive rights to processing phone > numbers in a proxy, making conditional forwarding decisions based > on presence, making calls from WiFi attached devices, and so on. > This is amazingly huge, and very clearly has implications (if not > overturned) on our work. Like, "We might as well all go home" sorts > of implications. > > You might take a look at patents 6,104,711 and 6,282,574 by Eric > Voit, and 6,359,880 by James Curry and Robert Farris, as I believe > the courts considered these in the Verizon vs Vonage case. > > > 6,104,711's abstract: > > An enhanced name translation server, for use on a packet data > network such as the Internet, executes a conditional analysis in > response to at least some queries or requests for name > translations. For example, the server may return a different > destination address at different times or in response to > translation requests from different terminals. The server also can > query a primary destination terminal device, and condition the > response to the calling terminal on the status of the primary > terminal. For example, if the primary terminal is `live` the server > forwards the address of that terminal to the calling terminal > device to set up communications. Otherwise, the server returns > alternate destination address information. The server also supports > a wide variety of different types of translations, including domain > name to address, domain name to telephone number, and telephone > number to address. The enhanced translations offer called customers > numerous options for controlling communications directed toward > them, and the customers may elect to apply these options both to > their data communications services and their voice communications > services through the packet data network. > > > 6,282,574's abstract: > > An enhanced name translation server, for use on a packet data > network such as the Internet, executes a conditional analysis in > response to at least some queries or requests for name > translations. For example, the server may return a different > destination address at different times or in response to > translation requests from different terminals. The server also can > query a primary destination terminal device, and condition the > response to the calling terminal on the status of the primary > terminal. For example, if the primary terminal is `live` the server > forwards the address of that terminal to the calling terminal > device to set up communications. Otherwise, the server returns > alternate destination address information. The server also supports > a wide variety of different types of translations, including domain > name to address, domain name to telephone number, and telephone > number to address. The enhanced translations offer called customers > numerous options for controlling communications directed toward > them, and the customers may elect to apply these options both to > their data communications services and their voice communications > services through the packet data network. > > > 6,359,880's abstract: > > A localized wireless gateway system provides wireless telephone > communication, and for at least interexchange communication, > provides voice telephone access to a public packet data network, > such as the Internet. The wireless gateway system includes base > station transceivers and a packet service gateway coupling the > transceivers to the public packet data network. The packet service > gateway compresses and decompresses voice frequency communication > signals, and it sends and receives the compressed signals in packet > form via the network. The packet service gateway also provides for > signaling through the network to establish two-way voice > communication sessions. In the preferred implementation, the > localized wireless gateway system includes at least one radio port > control unit coupled to the base station transceivers for > controlling calls through the transceivers. The localized wireless > gateway system also includes a telephone switch, such as a digital > PBX, selectively providing telephone communication channels between > the radio port control unit(s) and the packet service gateway. An > access manager controls registration and validation of roaming > wireless telephones to utilize the wireless gateway system. The > access manager also transmits location information for registered > wireless telephones to a home location register database via the > network. The communications of the access manager to the home > location register database permit telephone authentication as well > as maintenance of accurate location information in the home > location register identifying the current gateway through which a > caller can reach the roaming user's wireless telephone. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-3--250199435 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMzA5 MjIwNjQ5WjAjBgkqhkiG9w0BCQQxFgQU5VnJkePEhBzN8xuPe/iTMPglLxowgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAFcHWctg wHNvZGnvYX+09myaDgMCED1tMQts10PnYYUMgN5UBbmg3r8w5VkoD4WD/qiWBwD+kLXpgULNq05p 94YU7+fkoLW5Ob0z2wxWRFTTxa+lFO2E7ZcERRsA+ABqVf8g6WnOGG7gpc8cyiLY4V8037mpqnU4 xk8lUplzRq/Q0UkNzdrXGjNwXT71TeN2r8Qq0upVkktqWrZ6Vk9K9AG/zk6B34vn6sspGcdgusuo Ifup/9Amg0kVF4wzn4NGi30fDytv+RR1aynGtNlWaIo0+2wqiIaSfBVTUfAoB/IMkJ478Fg4FpDY OJhblR4cl8v01fVhBziXBLRX/bzQXEQAAAAAAAA= --Apple-Mail-3--250199435-- --===============2130347210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2130347210==-- From sip-bounces@ietf.org Fri Mar 09 17:13:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnLI-0005SH-VF; Fri, 09 Mar 2007 17:13:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnLG-0005Rm-Gn for sip@ietf.org; Fri, 09 Mar 2007 17:13:38 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPnL8-0000lL-0N for sip@ietf.org; Fri, 09 Mar 2007 17:13:38 -0500 Received: (qmail invoked by alias); 09 Mar 2007 22:13:28 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 09 Mar 2007 23:13:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+C8F1zh5mCKK31nkzk/E3NvurXPIq8p3OYk93OzY 6joCn44DCgpq72 Message-ID: <45F1DC03.9030609@gmx.net> Date: Sat, 10 Mar 2007 00:13:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT , GEOPRIV , sip@ietf.org, es-coordination@cs.columbia.edu, iab@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Sip] SDO Emergency Services Workshop 2007 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, we would like to inform you about the progress of the preparation of the 2nd SDO Emergency Services Workshop hosted by the U.S. Department of Transportation (DOT). The workshop will be held April 10, 11 & 12, 2007, from 8:30 am 6:00 pm., in the Jefferson Building of the Library of Congress, located at 101 Independence Avenue SE in Washington, D.C. Please find updated information at this webpage: http://www.emergency-services-coordination.info/2007/ Best regards, Jenny Hansen Marc Linsner Stephen McCann Christian Militeau Atle Monrad Henning Schulzrinne Hannes Tschofenig Harry Worstell _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 17:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnrR-0003jd-9N; Fri, 09 Mar 2007 17:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnrQ-0003jY-Kp for sip@ietf.org; Fri, 09 Mar 2007 17:46:52 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPnrP-0002AV-3B for sip@ietf.org; Fri, 09 Mar 2007 17:46:52 -0500 Received: from [64.101.172.235] ([64.101.172.235]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l29LqYQM028127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2007 15:52:36 -0600 In-Reply-To: <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations Date: Fri, 9 Mar 2007 16:46:33 -0600 To: Byron Campen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You guys are missing it. This is not a "this patent could be interpreted too broadly" warning, but a "This patent WAS interpreted in such a way that Vonage was ordered to pay close to $60M in damages -- you might be next" warning. The courts appear (though I haven't gotten the detailed transcript yet) to be asserting that any VoIP routing decision based on logic applied to stuff like phone numbers and device status, SPECIFICALLY WHEN EMBODIED IN A SIP PROXY, belongs to Verizon. Sure, there's tons of prior art. Maybe it'll show up in court. But in the meantime, I suspect that anybody doing SIP commercially in the US is in danger of having to spend lots of money on lawyers. Many of us will probably be contacted by lawyers Real Soon Now to start having various time- sucking meetings. We need to look VERY closely at this court decision, and consider our response. I don't know if there is anything we can do within the scope of our work to avoid this furball, but we need to do that analysis. -- Dean On Mar 9, 2007, at 4:06 PM, Byron Campen wrote: > 6,104,711 and 6,282,574 seem to be a specifying a "smart" DNS > server to me, and not a SIP proxy. (Although it might be possible > to convince a jury that a redirect-server fell into this category). > It also seems that these are directly related to enum. 6,359,880 > seems to be nastier, in that it appears to be a patent on the > concept of registration over pretty much any medium (although they > specify TCP/IP, but nothing about UDP. I hope this doesn't mean > that avoiding this patent will require using UDP exclusively...) I > am not sure how they got around the fact that 2543 predates this > patent's submission. I'll probably try tracking down the court > transcripts at some point. > > Best regards, > Byron Campen > > >> >> I don't normally discuss patent-related issues here, but this one >> has me worried. >> >> >> According to C/NET (http://news.com.com/2100-1036_3-6162747.html) >> >> "The broader dispute rests on allegations by Verizon that features >> central to the success of Vonage's offerings infringe on five of >> its patents. They relate to various aspects of commercial voice >> over Internet Protocol, or VoIP, service, including methods of >> connecting Internet calls to the public-switched telephone >> network, enabling features like call forwarding and voice mail, >> and allowing Internet phone usage via Wi-Fi hot spots." >> >> If I'm reading this right (along with what I've managed to winkle >> out of the reporting coverage) it looks like the courts have >> proclaimed that Verizon has exclusive rights to processing phone >> numbers in a proxy, making conditional forwarding decisions based >> on presence, making calls from WiFi attached devices, and so on. >> This is amazingly huge, and very clearly has implications (if not >> overturned) on our work. Like, "We might as well all go home" >> sorts of implications. >> >> You might take a look at patents 6,104,711 and 6,282,574 by Eric >> Voit, and 6,359,880 by James Curry and Robert Farris, as I believe >> the courts considered these in the Verizon vs Vonage case. >> >> >> 6,104,711's abstract: >> >> An enhanced name translation server, for use on a packet data >> network such as the Internet, executes a conditional analysis in >> response to at least some queries or requests for name >> translations. For example, the server may return a different >> destination address at different times or in response to >> translation requests from different terminals. The server also can >> query a primary destination terminal device, and condition the >> response to the calling terminal on the status of the primary >> terminal. For example, if the primary terminal is `live` the >> server forwards the address of that terminal to the calling >> terminal device to set up communications. Otherwise, the server >> returns alternate destination address information. The server also >> supports a wide variety of different types of translations, >> including domain name to address, domain name to telephone number, >> and telephone number to address. The enhanced translations offer >> called customers numerous options for controlling communications >> directed toward them, and the customers may elect to apply these >> options both to their data communications services and their voice >> communications services through the packet data network. >> >> >> 6,282,574's abstract: >> >> An enhanced name translation server, for use on a packet data >> network such as the Internet, executes a conditional analysis in >> response to at least some queries or requests for name >> translations. For example, the server may return a different >> destination address at different times or in response to >> translation requests from different terminals. The server also can >> query a primary destination terminal device, and condition the >> response to the calling terminal on the status of the primary >> terminal. For example, if the primary terminal is `live` the >> server forwards the address of that terminal to the calling >> terminal device to set up communications. Otherwise, the server >> returns alternate destination address information. The server also >> supports a wide variety of different types of translations, >> including domain name to address, domain name to telephone number, >> and telephone number to address. The enhanced translations offer >> called customers numerous options for controlling communications >> directed toward them, and the customers may elect to apply these >> options both to their data communications services and their voice >> communications services through the packet data network. >> >> >> 6,359,880's abstract: >> >> A localized wireless gateway system provides wireless telephone >> communication, and for at least interexchange communication, >> provides voice telephone access to a public packet data network, >> such as the Internet. The wireless gateway system includes base >> station transceivers and a packet service gateway coupling the >> transceivers to the public packet data network. The packet service >> gateway compresses and decompresses voice frequency communication >> signals, and it sends and receives the compressed signals in >> packet form via the network. The packet service gateway also >> provides for signaling through the network to establish two-way >> voice communication sessions. In the preferred implementation, the >> localized wireless gateway system includes at least one radio port >> control unit coupled to the base station transceivers for >> controlling calls through the transceivers. The localized wireless >> gateway system also includes a telephone switch, such as a digital >> PBX, selectively providing telephone communication channels >> between the radio port control unit(s) and the packet service >> gateway. An access manager controls registration and validation of >> roaming wireless telephones to utilize the wireless gateway >> system. The access manager also transmits location information for >> registered wireless telephones to a home location register >> database via the network. The communications of the access manager >> to the home location register database permit telephone >> authentication as well as maintenance of accurate location >> information in the home location register identifying the current >> gateway through which a caller can reach the roaming user's >> wireless telephone. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 09 17:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPo0H-0002iL-0U; Fri, 09 Mar 2007 17:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPo0F-0002iB-3q for sip@ietf.org; Fri, 09 Mar 2007 17:55:59 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPo0E-00038O-Er for sip@ietf.org; Fri, 09 Mar 2007 17:55:59 -0500 Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l29MtvjP082232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2007 16:55:58 -0600 (CST) (envelope-from bcampen@estacado.net) In-Reply-To: References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8FF54145-10A3-46B3-98BF-919D5BB651C4@estacado.net> From: Byron Campen Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations Date: Fri, 9 Mar 2007 16:55:53 -0600 To: Dean Willis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0513887201==" Errors-To: sip-bounces@ietf.org --===============0513887201== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--247254101; protocol="application/pkcs7-signature" --Apple-Mail-4--247254101 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Oh, I agree with you. I was just wondering how this case could have gone so far off the rails. Was _anyone_ in the IETF contacted about this case? If not, why not? It seems like the IETF would have been the obvious place to go for incontrovertible evidence of prior art. I have been unable to find a transcript, but if anyone does, please make it known. I am itching to read it. Best regards, Byron Campen > > You guys are missing it. This is not a "this patent could be > interpreted too broadly" warning, but a "This patent WAS > interpreted in such a way that Vonage was ordered to pay close to > $60M in damages -- you might be next" warning. > > The courts appear (though I haven't gotten the detailed transcript > yet) to be asserting that any VoIP routing decision based on logic > applied to stuff like phone numbers and device status, SPECIFICALLY > WHEN EMBODIED IN A SIP PROXY, belongs to Verizon. Sure, there's > tons of prior art. Maybe it'll show up in court. But in the > meantime, I suspect that anybody doing SIP commercially in the US > is in danger of having to spend lots of money on lawyers. Many of > us will probably be contacted by lawyers Real Soon Now to start > having various time-sucking meetings. > > We need to look VERY closely at this court decision, and consider > our response. I don't know if there is anything we can do within > the scope of our work to avoid this furball, but we need to do that > analysis. > > -- > Dean > > > On Mar 9, 2007, at 4:06 PM, Byron Campen wrote: > >> 6,104,711 and 6,282,574 seem to be a specifying a "smart" DNS >> server to me, and not a SIP proxy. (Although it might be possible >> to convince a jury that a redirect-server fell into this >> category). It also seems that these are directly related to enum. >> 6,359,880 seems to be nastier, in that it appears to be a patent >> on the concept of registration over pretty much any medium >> (although they specify TCP/IP, but nothing about UDP. I hope this >> doesn't mean that avoiding this patent will require using UDP >> exclusively...) I am not sure how they got around the fact that >> 2543 predates this patent's submission. I'll probably try tracking >> down the court transcripts at some point. >> >> Best regards, >> Byron Campen >> >> >>> >>> I don't normally discuss patent-related issues here, but this one >>> has me worried. >>> >>> >>> According to C/NET (http://news.com.com/2100-1036_3-6162747.html) >>> >>> "The broader dispute rests on allegations by Verizon that >>> features central to the success of Vonage's offerings infringe on >>> five of its patents. They relate to various aspects of commercial >>> voice over Internet Protocol, or VoIP, service, including methods >>> of connecting Internet calls to the public-switched telephone >>> network, enabling features like call forwarding and voice mail, >>> and allowing Internet phone usage via Wi-Fi hot spots." >>> >>> If I'm reading this right (along with what I've managed to winkle >>> out of the reporting coverage) it looks like the courts have >>> proclaimed that Verizon has exclusive rights to processing phone >>> numbers in a proxy, making conditional forwarding decisions based >>> on presence, making calls from WiFi attached devices, and so on. >>> This is amazingly huge, and very clearly has implications (if not >>> overturned) on our work. Like, "We might as well all go home" >>> sorts of implications. >>> >>> You might take a look at patents 6,104,711 and 6,282,574 by Eric >>> Voit, and 6,359,880 by James Curry and Robert Farris, as I >>> believe the courts considered these in the Verizon vs Vonage case. >>> >>> >>> 6,104,711's abstract: >>> >>> An enhanced name translation server, for use on a packet data >>> network such as the Internet, executes a conditional analysis in >>> response to at least some queries or requests for name >>> translations. For example, the server may return a different >>> destination address at different times or in response to >>> translation requests from different terminals. The server also >>> can query a primary destination terminal device, and condition >>> the response to the calling terminal on the status of the primary >>> terminal. For example, if the primary terminal is `live` the >>> server forwards the address of that terminal to the calling >>> terminal device to set up communications. Otherwise, the server >>> returns alternate destination address information. The server >>> also supports a wide variety of different types of translations, >>> including domain name to address, domain name to telephone >>> number, and telephone number to address. The enhanced >>> translations offer called customers numerous options for >>> controlling communications directed toward them, and the >>> customers may elect to apply these options both to their data >>> communications services and their voice communications services >>> through the packet data network. >>> >>> >>> 6,282,574's abstract: >>> >>> An enhanced name translation server, for use on a packet data >>> network such as the Internet, executes a conditional analysis in >>> response to at least some queries or requests for name >>> translations. For example, the server may return a different >>> destination address at different times or in response to >>> translation requests from different terminals. The server also >>> can query a primary destination terminal device, and condition >>> the response to the calling terminal on the status of the primary >>> terminal. For example, if the primary terminal is `live` the >>> server forwards the address of that terminal to the calling >>> terminal device to set up communications. Otherwise, the server >>> returns alternate destination address information. The server >>> also supports a wide variety of different types of translations, >>> including domain name to address, domain name to telephone >>> number, and telephone number to address. The enhanced >>> translations offer called customers numerous options for >>> controlling communications directed toward them, and the >>> customers may elect to apply these options both to their data >>> communications services and their voice communications services >>> through the packet data network. >>> >>> >>> 6,359,880's abstract: >>> >>> A localized wireless gateway system provides wireless telephone >>> communication, and for at least interexchange communication, >>> provides voice telephone access to a public packet data network, >>> such as the Internet. The wireless gateway system includes base >>> station transceivers and a packet service gateway coupling the >>> transceivers to the public packet data network. The packet >>> service gateway compresses and decompresses voice frequency >>> communication signals, and it sends and receives the compressed >>> signals in packet form via the network. The packet service >>> gateway also provides for signaling through the network to >>> establish two-way voice communication sessions. In the preferred >>> implementation, the localized wireless gateway system includes at >>> least one radio port control unit coupled to the base station >>> transceivers for controlling calls through the transceivers. The >>> localized wireless gateway system also includes a telephone >>> switch, such as a digital PBX, selectively providing telephone >>> communication channels between the radio port control unit(s) and >>> the packet service gateway. An access manager controls >>> registration and validation of roaming wireless telephones to >>> utilize the wireless gateway system. The access manager also >>> transmits location information for registered wireless telephones >>> to a home location register database via the network. The >>> communications of the access manager to the home location >>> register database permit telephone authentication as well as >>> maintenance of accurate location information in the home location >>> register identifying the current gateway through which a caller >>> can reach the roaming user's wireless telephone. >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > --Apple-Mail-4--247254101 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMzA5 MjI1NTU0WjAjBgkqhkiG9w0BCQQxFgQUWnE7RF4xX7JUUcjb6RFrVizWzmYwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAFa+r/ns n5WwQUv4WOEhV2XDI0KxjIiY7vpLCeNwa35GUmKb5TQJehI7WBhr9b8orGoXAuMcEyXrbCb+k88s po8a0f+VYC4sU1iftmuYknbMcX6669n4JfReWOA6tarkZgVjLRm+ipvZUmrzPPNhyr64nUR2fPgF 4odw0wIUo+xSSEmsyW61wFtEm+6gpGPHmym40c4iC6cnGLI3EYNuHqqgqHpEgk4iruB993fVyZWw mfHxsbb3vSXmQZ1uF0MLXwOlry0ziNnjR4yTdZkrBqMIkrDhiOihkFCW+qS9rTqKY+M310+g+j0f M2KLBwXMdsME0nZirma7zBCVajwlDsAAAAAAAAA= --Apple-Mail-4--247254101-- --===============0513887201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0513887201==-- From Permalink@pacosport.com Fri Mar 09 17:58:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPo2F-0003qH-RK for sip-archive@lists.ietf.org; Fri, 09 Mar 2007 17:58:03 -0500 Received: from host75-111-static.105-80-b.business.telecomitalia.it ([80.105.111.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPo2D-0003MR-8Y for sip-archive@lists.ietf.org; Fri, 09 Mar 2007 17:58:03 -0500 Message-ID: <000801c7629e$5fcaf5c0$00000000@CL04> From: "Privacy Policy" To: sip-archive@lists.ietf.org Subject: Ricky Martin Beverly Hills Date: Fri, 9 Mar 2007 23:57:55 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C762A6.C18AA2D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 ------=_NextPart_000_0004_01C762A6.C18AA2D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C762A6.C18AA2D0" ------=_NextPart_001_0005_01C762A6.C18AA2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jello opposite bill cosby! Federline, company sparks bidding. Children act so never find real job, putting. Guilty medianow gods, sake destroyed chances hes, able prove. Recordsbut blossoming month previously cast jamie curtis fantasy. Pix = xonline adoor heads, court mischa redeems almost struts! Action um kindview lohanout townview loves posts. Underaged daughter booze even. Pad recorded someone sounds, awful = screaming effect? Atb audi audrey tautou. Who stop something had problem. Heather mills lots beckham. Lohan clan sans appeared live on ryan seacrests radio. Tickets imdbpro = imdb resume register. Run mid dancing etc. Umm swore wen helping inso linsays, allowed. Linday, gang nicer rough = bitchdamn filming idiots prissy. York, barack obama brings. Began sixty spots, gap pizza hut. Upif frienemies, trixay, wannabe naive utoo losersthe hire speak. Lifeview petrified row boat stream. Thong cameras flashing believes. = Matt sayle maybach melinda, clarke mena, suvari mercedes. ------=_NextPart_001_0005_01C762A6.C18AA2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""=20
Jello opposite bill cosby!
Federline, company sparks = bidding.
Children act so never find real job, = putting.
Guilty medianow gods, sake destroyed = chances hes,=20 able prove.
Recordsbut blossoming month previously = cast jamie=20 curtis fantasy. Pix xonline adoor heads, court mischa redeems almost = struts!
Action um kindview lohanout townview = loves posts.
Underaged daughter booze even. Pad = recorded someone=20 sounds, awful screaming effect?
Atb audi audrey tautou.
Who stop something had problem. Heather = mills lots beckham.
Lohan clan sans appeared live on ryan = seacrests=20 radio. Tickets imdbpro imdb resume register.
Run mid dancing etc.
Umm swore wen helping inso linsays, = allowed.=20 Linday, gang nicer rough bitchdamn filming idiots prissy. York, barack = obama brings.
Began sixty spots, gap pizza = hut.
Upif frienemies, trixay, wannabe naive = utoo=20 losersthe hire speak.
Lifeview petrified row boat stream. = Thong cameras=20 flashing believes. Matt sayle maybach melinda, clarke mena, suvari=20 mercedes.
------=_NextPart_001_0005_01C762A6.C18AA2D0-- ------=_NextPart_000_0004_01C762A6.C18AA2D0 Content-Type: image/gif; name="passaro.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c7629e$5fc63ad0$00000000@CL04> R0lGODlhKAG8AYebAAAAC4oMDgCCAHV/AAAOiYAAjgZxe8K3xcXiw5zE7TsfAFghDY4iB5MTAMkp CNsfCgBIACxHBEBMAlZHAHQyAKVFA8UyCNg9AANsAyxeADpVAF5bA3FRAJFTCsNaAOVlAAB4ACSM ADWNAFSOAI5/AKpzA7p2AOeAAQCjABuSAjadAFWeCoKXAJGkArytANigAACyBRW2CkC8DGzOAHe9 AK3KAMq2ANLMAADoACPoAEnWAWPnBXTXCqXuC7bhBdnrAAAAOSgATTUAPG4LQogAMqMAPMMATuQA SQAZQBIkQTktNWYcOHgrSaQoTccZNtETMQBAThU2STY/SF9MO3w0QZE7RsFGPuY2OQpVOhVSMkZk PFpaS4hZAKFZQLxXOtZkSQaGSCiIN02NQ2eMRYGCRKSJOMiDPeB8OgCTNhmrPECfNF+qQ4ySN6Wa PbeZTdejSQDLOBG4Sz+1RmDKO4LFNZK4TrfNMufCSgDjMR/gSjjmPW7XOnLhQanbSM7UMeHaNwUA cisAhzQAd1sAiIQLdKgAfrEAd+YAegAdfxsrhk0fiF0XdnccepYkeL8mitIpcwA5gydDfDNMiGY+ i409h5RGjLkyg+o1fABmiChkfUlidmNjiYhfjpRWgbVdctVfdAB2gBaHeE5zfGOMgoWBg6uOh7+E ieeDhgCecyqUjUmacWurjIejhayqgcajhNyhfQe1dy27jTzIhGLNjXS0fJnMhbPMeunCiQDpdyDb dDPcel3jcYTkcqTahsLidN3pegYCvyAGwz4AyFcGyoMBvqgAt7YEwdkJygAatSIazkIgxmEWwIkm wJEdusIZveUsugA+tBU9uD45w15MyYs7uKc0yc03s+Q9vwdYwBtosUhdwVRYuXdospNqy7xXtt1Y xAyFuR9/yzl+x2h7yIh9tp14u7h/wdJ4wgituCOiv06hzGScwoSmxZahvbWXwtSXugC9uiC/szO/ v2W+sYC5x6THuPT4956mm4Z2dvkACA7/Bf//CAgI8f8A/wD4/////yH5BACAvJkALAAAAAAoAbwB Bwj/ADkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUv2Jj+HZxHyS1u2bUK2nOCeZHtW7tu4Bu2iHag371q3SOH2HSl3cMG+hhUmvgu4qGCBa9PShfz3 cOW6lOn+jYxXcmWCkTHH3byZ7+jPnFNnzly4sePQrSdPNg15dO3aj3Hjvc0bc+7dnU3/Fh28t2vH oFnrPv2ZOXHYwIH7Dp1cN2raxbNL3z578fGcj7vv/0Z8GDtv7tGrZy9tXLb659vTf/8ZHvvs6O7b v1+/v77+5f/xNx9ytFF3HmeWSQYaapf5tlqC0ynIl2q3IciehQUOqOGGHHbo4YcghijiiBt6F5GJ EKFIIlQqqrhXR965uCJ9KXokI0MxzvhUYQxKKBiCp5U3HnMTKuiZXRgGqaR8OgbWn3Dp5Ydfhejh JuGU1u3HZJNGDccdklAeGBx80GkGpHOdmXkZl0x56V5rANbnIIDGHQSnbWCyqZSbYfJ5XnxSwicm nYLquZSBQCYZ33jN1dndmkX6ZWSP5hlq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNsspADVB62xMAFQLrbQgYfvQtQ5p O+1G3nrbkbgMkZuQud9WJK612Fo7kLucsPtutfNeSy9B8Mob7776xnvvvumCa1C7ABcsELcHF4xw wgUR7DC/7yrMcMAZrRsxu9LK67DGBDd88ccL25svxRpZnHC4H598EL0mQ6xyyAZPTPJFKKtss8s4 a7twxDdzC3PHM4Prbsfw+sty0fn+++/B9z4Ms9E8B+0SulJvRXXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPf/bWw/GPUD+ESDV1zS1bIKLjgnhRMEeOMGKQ65 QIVPLvnkjAtMUrv9Mp004pliHvlCog9UOUKlly4R6DQP3dDToVpO+eKZD66445HTfvvtBTXOu+Sm 017v8DyPDHC4Si+dcswrT8y6obLj/njmB/1uOvXY91499tMrtPPyCGeM0Pcec648vsSLGj3w0wu/ /emnbx/84vBjzvHAEvsc8/3nnk8u0M/Tk+zgxz3Rda9215Mf9xY4O/Q5T2f5gxgEH3iu/TXPeaSC 3AHbh7v3XS9+o6PcBxMowqhNsGcYdKDB0KU/hgFNYhnc3ezoVzv3MY53N7Sd46I3w8f9zoZGE5nH /6CWQnwN7XyeM58JG4ZEv3kkgE5cCRSjSMUqOkUf+ihJFg+3qy1yIotevAgWsciQMD7EjA5BY7bw N7Cmde5TXlRjReK4EDl+xI4c6Zf/oiYzOA4EjAIZ4x8FCcgvkpEgdCykIA25xUUyMpBkbOQhxxjH SW5uhcx74RTZpMiCFPKLhjRIGBPZyD+CMpCmHCUiTwlKOq4SjyWDYctOKKpOMvKTn7wlIhfpylYO kpCVTKUwUalLWJbMjUUr4iY5eUpcstKZxIxmNBNpSlEG05nURKUxY0lLZZ4qm77UZjVZSc5nDtOc 4/QlOLHpzXbCsHwqFJ8LUeVKSkIykrs8pDTJyf/LfN7zn820JDHtuUUALtGdSRyiwpSGq22CZZm2 cuRxIGrFilq0J0B0iOqotSsCagR4IcxeDzG3UZi0TKGoAmFGNqrSDirwJnr8H0WhN8Iczo+DNnXp /GaYU53+UHg4bMnOyNfHU3VPgwsEogZ1V1ORklB6TTWpLMfHqqP2MKk7zCgCRdjSp7LvgyU9yeeQ OFOa6tCjW2Xg6NBqQBJuMHgyGSpVq9rUt4KwrWxFnVvVSj2DutOv70TfCbuZ0gSC9Ks3zWrlmApX 7SX2sMIDrGQPGtggKlSJHZ1PWROn1bZs9qKgDW1EHCqWz46KoAfJpWvMR9aMvdGPZdSQxrw311D/ oVGSpcStW2DHxt7aVpSeVOdqF+q/ZDLPU7e9JyDBSFqr7TGefPxtcKkZTMB8r2aVle45l7tK6P6V spP9rnjf+UKQFS+FpiURaovZSn2C973jDS954TvfPsYUgAwVreb0OzX++ve/nkrvqEBakdRFlSk6 K65xjVqSri5ltvZ9FUl1h0PrHdV9Hq2wDG3XWan+D6Wr4qFdwcpVveoQqlzlYbT2t64Fm4rDPpRh imWcVu2dGLE1JrBNFszCEKN4r0gtsQfTOuISOpUm162gj4VMZKwyOaRFbnIJ5Utl+n74afI87ot/ amQYd5mnjqUeZGmY2PqaucpFTKjnTNhEroUV/6ZyC2pQBAzgOtt5t72yJ4mwy0TMnrZJ+iIr+Eh1 20lGspLNrUqSaVteUPVTnM0M7lgWvTI/m4qdkdYlWZJ5Nd4S2pylDGc5w+Jp/DW6lqAeKDrRfGYr uzq+lBUsH7NcauQ68tGh1jOrd/3qVsPaiMnDr6Xv3C1io4TOxk42gEkqFWR/6nIdYXZUEmwu1jr7 Q2+OiLSfAuFMfpjBQuYyUMdN4RM7hajfVuGLG4ticzM5yk0hX7V9WyqVIvbGNIZ3vJfWY3Wv+8vh freTa3zu49HW3/Xea8CbnNfB8frXvo64rE9K2IQbOYdWFfNPvdzXXj884vJVM8YeeGplK9nkIv+5 NspXznKkqHxTzVVtWfis5bG+HDCJHvWkk2bEC1oQuZ4UqDrxqVuuULqogb05zrsrau5CErhW+3l0 06x0t4xSz53spaad281qI027o876OLWuFU93euowZ3ovoblqj7sd4h+XdYSjW3JNYd299cylrt8O cr7H3bJrDvxCEc7yqifb8C1PvOIXz/jGO/7xkI+85CdP+cpb/vKYz7zmN8/5znv+86APvehHT/rS GwrxhsMJ6r3y2te5ztTFvplYIUKufNg+HwO5Pe4FYnuC7J7R4yJ81JF+8IWcPdbHpr1Bfs8J3DPf +byPfrk+UvHh5yzpbByZa2n5MCJaNnwKVjP/4Ou1fcEvv/m+R7/6md9GlgX+cxgMdNNKa7zrTx1l LQRx+OB5spPK3f7xtzwIAX25t37qV1v5h0ko1H3EV3aDhjNFtX36E2yBZnDfJ4Bv1G28tTGvN4DS J329t37sF0H5FYALKHwOiEIQmEkkOC/+tn8MCDuDFUEyw4DEF4IHmIPRt3vsF4NydYKyt3qq94DH hX/mNWu99TNEOIMxCF02WIDpB4VQyIOXhUlMOGhCyBP3VXIQNltChHBEM1YrZFwaKH4ilzxRmIY6 SIU6eIFIg0zkJ0tZ9h1Z+Dqz1xC6F4K6VxDPN4KtUof9o3QuZnqEWIiGeIiImIiKuIiM2IiO//iI kBiJkjiJlFiJlniJmJiJmriJnNiJngg2N0dz02eH6iJVe4Z87Xd0SYh2LzhfokhVAVR3WhZ8qdcV gOVzDehzsmhBt8iK9EaKsxiM+0UzX+FXZNhn4pOBB6V9x9OB3Sd/LeZ+4KdErqNJcOhd9ZeA97Vm weaLVzGBaUZETkN3EhR/yXheLaSENQgytKaAAGhmNHh9ytOE8oRlD1WOQTRv4xhh6YiF6OgyP9M5 +5iP7niO3sWLJriC8bh//FKBxYiPiKOE5QWOCzlV/fiES2R22Ch1E2mB8riKzyh7ufiN9MV/+MiC 3tSEKUmELZiQ8IhQKymSFVmP2cV6szaP2f/YkIJWg/PnQl+HXvCHjBD4hq5Vk9eIUkQpb8XTk/VY goBmi6VoLID4EhA1lZ94lQBmlSzhlKkYexRhMYiXbrEYlbHklVnBlVU4irTYXymRhVopRRZ4jEtJ jdf4gwApjU1UgeX3ftKok+W3l8rofeMXlDaTlC24l+N3lganSf9nlxtThXJFNY8Zj2MIhB+5jmJJ mUyTkBLZjrs4bS+DhP74XlfWfwIIkuRnL6J5mawJQc/FmmzmjC1JkJ8JFefImKMZk/zHOQrphGjn fhmZmxvogsEpkx15gscpjKC5mbjpkY55mrGmjZAZnQU5kyzJfblJmv5oULXJbcRJhpzWjf7/8n4I KI6byWI9yZfUeDFv2IztyJ7YhZj8Bmxx6Ib0aYaz8ooY8ZYTwZ+b4n9lORT+iZUEWqAGeqAImqAK uqAM2qAO+qAQGqESOqEUWqEWeqEYmqEauqErMlNt1psRMaAph4omsUw/YiYTUilJNEWD2DxEZXzT V1YRqRS9eIcnch9kQiW1pXwjSaIwCqMyqpZHYYwKhmXzB5hBSZR2Yh9VQhy4KIatGIa3CZzoaX7m SW0GaZhSKo4fqhMU2ZwauUcq+Y51IiCQUp4qyI/kmH9gGozSaZrWGYTe2BNfKpAP2G0X2DMcs2A4 uigVohfcuZoq6IVWOJ1d+ZyBapmDVxRf/1qe9FicZEo1fXofy2EXieqOlkmRIomRA1mRmYqp40kU IfeoaaqOnqolAqKjlgqp8cmZJxmB0NmpY2qqdjmnXnqT0SiBCYWlcih4fEopD2IfgHqfrReeyJSO p1Z/wKaNymqYgMdzLdpsRiekXxkSIpoU0ToVoNOlP0p9HPqt4Bqu4jqu5Fqu5nqu6Jqu6rqu7Nqu 7vqu8Bqv8jqv9Fqv9vp50GEbknKiDWIZfvGvsEEdAQsh+Ro2DKKv/5qilIGwZ6KwC4Kw/hqsjUI2 jVIXiKEZ5dEgFwuwG+uwEys2HwuxDyuyKdqwI/uwIdscB3s2KduxLWuyJ1uyHbuwNGs2Lb6rFp6B syFbJAFrsT3LsPxasF5zs3aSs0ULsw4rszrbsDv7NUSbsDeLtCRLGjhbs1ZLsTMbsUSLtBNLtUWb tE3rtLExsxULtHrRtRZbtRJ7I1KTKGn7tWsLsSaLtiRrtRbCtlWTrz9LJDxrtJESswvbs14bKYKL t/d6uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7LLKgEBADs= ------=_NextPart_000_0004_01C762A6.C18AA2D0-- From sip-bounces@ietf.org Fri Mar 09 18:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPowa-0001ti-Sh; Fri, 09 Mar 2007 18:56:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPowX-0001tM-Nh for sip@ietf.org; Fri, 09 Mar 2007 18:56:14 -0500 Received: from cir-el.real.com ([207.188.23.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPowT-0007qF-Cv for sip@ietf.org; Fri, 09 Mar 2007 18:56:13 -0500 Received: from SEAL25947 ([::ffff:70.57.75.168]) (AUTH: LOGIN csteck, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cir-el.real.com with esmtp; Fri, 09 Mar 2007 15:20:12 -0800 id 00209908.45F1EBAC.00000B23 From: "Chris Steck" To: "'Byron Campen'" , "'Dean Willis'" References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com><069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <8FF54145-10A3-46B3-98BF-919D5BB651C4@estacado.net> Subject: RE: [Sip] News flash: Verizon appears to have exclusive rights to IPtelephony and SIP proxy operations Date: Fri, 9 Mar 2007 15:20:13 -0800 Message-ID: <011301c762a1$7e2a5a30$6601010a@corp.real.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8FF54145-10A3-46B3-98BF-919D5BB651C4@estacado.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdinlJkxiNW3oQ+RAOFe+IczwfJtQAAha0w X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'SIP IETF' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org fwiw, it's a really really bad idea to be discussing patents on a reflector, and could have the exact opposite affect you all are hoping for by potentially increasing the liability of anyone who has been deemed to have "read" them because the info was pushed to them, and then "wittingly" continues to infringe. May I suggest that this be taken off the reflector. The people who fight these things for a living definitely know how to get prior art. -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 dtulbbzoza@ipcs-inc.com Fri Mar 09 19:50:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpmv-0004B3-7j; Fri, 09 Mar 2007 19:50:21 -0500 Received: from [218.9.163.101] (helo=ipcs-inc.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HPpmn-00056o-F4; Fri, 09 Mar 2007 19:50:21 -0500 Message-ID: <760210FB.A5051AFA@ipcs-inc.com> Date: Fri, 09 Mar 2007 16:47:03 -0800 From: "Jake Richardson" X-Accept-Language: en-us MIME-Version: 1.0 To: "James" Cc: "Harold Ruiz" , "Rosella" , "Isidra" , "Marquitta" , "Odis" , "Marianela" , "Collin" , "Neil Payne" , "Pricilla" , "Dallas Ramirez" , "Adele" Subject: Are You Ready Content-Type: multipart/related; boundary="------------101271766712060273182135" X-Spam-Score: 1.6 (+) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 --------------101271766712060273182135 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit



stung "No," replied Dants. desire "I announce know nothing. cushion Some of you  "What is suggest lie spoil it soap you want?" said the inspector.     "You are knelt drain danger bred not convinced yet?"crack wax "I, monsieur," replied the abb with an peel control air of sur  
"Ah, ha," sped step said practise the shipowner, "I tree am not in the lea   The prisoner copy suspend heard the cry, guide which weave sounded like the strike "Wait for me moon stale here, all of you!" shone cried M. Morrel; "     
strange shoot slope "She is not bite my mistress," replied the young sailor     
The abb boy wire taken smiled. "Well," said apple he, "but you had anocow "You plate knowledge do not understand," bewildered continued the inspector;"I saw hope at least, that grind less you station may be mistaken."spring "Oh, injure cook that is different," cried osseous the abb; "and we s   
put "Sometimes one clock and gone dark the same thing," said Morrel, w  sun ursine slung "That's right!" arm exclaimed a multitude of voices, "  This second departure was misspell followed rich risen by sawed a long and f    
preserve "Not present wove with loss us, sir," replied Dants.  "I did!"curve shrill "There, room now," whispered stormy the governor, "it is justpled clung "Shall you somatic book see the king again?""Monsieur," continued the wobble engine light rarely prisoner, "I am the Abb     
sanguineous "Well, well, wrote iron my fax dear Edmond," continued the owner,  Meanwhile Fernand vessel made rose his insurance tired appearance, poured out  shoe split "He is the cause sharp equally of all this misery--I am quite su       
attention grown "No, sir; I have journey all genteel my pay to take--nearly three      "Perhaps."   
"Now, could cheese any one have wriggle store had any save interest in prevemeasure polish "Why from bet statement the French government?"spoon drawer pig top "Would you pass in his eyes for a prophet?""Because word file I hook was arrested at church Piombino, and I presume 
"You are a request escape growth embarrass careful fellow, Edmond."     awoke onto "I don't whine mass think so," answered the other; he's too s     "You don't rich mention back those thought who went aided and abetted the 
seek "I sawed part cannot believe such was punch the case. I was general"Ah," said bathe the reason inspector, "you hour have view not the latest"Prophets of evil machine awoken are not in pleasant favor at physical the court, fpay "My information dates wide need from the day on morning which I was        
"Say I wreck under have shop a sound poor father, sir.""Surely," answered eye Danglars, "one shiver been cannot hammer be held r  slope bulb "You can, fit indeed, when the quit arrow lights point down      "Yes, yes, I know how good power a son ovine wet you surprise are, so now h  
"Now we fetch are act getting on. stroke homely And what was this man's napack sew "Monsieur," returned the change print inspector, "providence haload "True, but prove some day stay money they do them justice; and supp"It is the ovine only found desire bit means of rendering Italy strong, h   "Then sister forego caught I seldom have your leave, sir?" Meantime amuse paint the subject of the stretch apologise arrest was being canva "What think you, sock Danglars," said help kettle comb one of the party,          
"Yes, tiny if felt you have weather nothing more country to say to me.""Very copper rubbery structure possibly; distinct only I am not come to discuss poli        
--------------101271766712060273182135 Content-Type: image/gif; name="bpyilqoerlyy.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhlAGSAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlAGSAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6739GAIACv2+/4vP4sEAz6BAUGB3uFhoeIiW0B dAAHgQUIfggIjUMHAwYChIqdnp+gngMEA0MJBagCAAKaRI+RfgmbobS1trdhB3SnpUICCKgDugGc QqcFpb+SuMzNzs9ICQSbBgZDv8GjqkMBwAUJQoHb0OTl5od9BwawrI3dqAaBvULvwQADCZyY4+f9 /v9iMFGSgwqBrEavCkwjVeQYqgTEhBw4RaAYwIsYM0IJAKnAJkgI5gEAyUgOoQNzOnq8ZpBVPo0w Y8oEwBEVrAE2lwlZF4mO/rZ7FWs+5KbqWMWZSJOeExpJmk0CjY5JwqZKHE1I4IjgLDhLqdevt5gq 7NiLp6QECKCOFOQIEj8BNpFJ4we2rt1DTCVBsnZvwJ9h3DIJOGWwGLaHr+jeXcw4TQB8f+l1TPnN ia4EsogwtfZLZOPPoMMI6Jh2m1ACNOdUQdlRbZ/QsGN3Ge2Nq2SFlqoc7rnxtRoFwIMrOBK8nPDi RZDHFE5FOQDneCaWEqsTpeIpQnUuQZnALyWIaY5Dfw7803Am4ssTGQ8w/XkoztnXeVdK4FOLWgKs 45tEl32PkBx1BnLM2SJfcuqR956CMCl3YBIP5lFPVtnltsU+SBygCwEh/h02QD2ejeFggkLEV+B6 J6II3YjvuTdEekuwqGKKCqZYHIkwjgcjgiYueOCKOO74YpDnucgjiV8kJAgd6qSCxmMETLMOVFIF YJSFYfSo4ow92igkgyUm6F6R4imhZZhCjjlkl2quWaabMq4JIZJsnnhmjcfBGSEWu00TTiVlpLMV MqtAdFgfNl33xZ1gNkqgmI+2CKmklJJJaRNxomnpnJUeWWOjxE0qZ5ijhrogmjOiquqqBd7oKJJe DIrKNL6BMQw2wuzlCJN7JZQVGYyyeCqoPG6p6p2Zmmkkq3S+SSyYkRqx44OiIqEjkaUiW+2Yw8Za m5OiBULKAGmhxBVm/kJsRSU8ZghrrKbVmmpssnHuCS+smbb5bLSgtkmtpMqeCuSlq75KMLeBSpOW MF7o8seg0wlTTzyAHooNfyLGW7CbBfN7rMb1wmqtyNmq1yq2xUI76aYdr/yvwM0S3G+8Hq/hnxes kJKWfrMCBgBPBqC1Ta/ylOFuyQevrCmzlsqcLKcBIy11yjXnq/S96GlscKlbM821GHJ0lYXDo8BD LqKwGOTLrGH7xBWHWC66bMt56klk3XjaSTON0pLs9b1Pq8wy4HfTiDenh/89s9OF+40zJYNgMREB aFHO9h/1cAioUNORMuEf7X65ceJ4morvjT6CHOHLXDMXOL8DDxd7/rd8I0773qkzDrO9U/iBJVyA ToGSMI+ERPmhEpkVzzY8VQTXQpTHLVtotXv1fHd9RPWSFKP1rF8sCfEHMSObwAXLfiVNr76zd8la 0PHSH6GLKXFV5Nf8WwWfuS4hvRPS/eoL4Kc+w5O45ERRRhiNnxxBLptowgDu8MY8pOIHhShQbALM IGjUEaVv2YYJCRHQKmqzwJ3M6ho2URjxNMjC2BBDF7HgEG+K4LMhQOwaBqjNr1bxQWxMJX4tDOIG /cAwiTBiFJQrRkKCh72O/Oo0dNBPZoRIRSHSRmf28AVa2FWoqxQEISBBYBXHGMACoi14QTOLKiai Cs5JxnNFGE0r/shIR8bkbBuHgQgw1AIAzJyGEAmIHDYEFBEjrCMkqyDAHOvISJgwIhxsMwbbipYu TZBlhFlhRYiKwBEITiQnm2ykKMtBrqPccITns6AvKCfDmygEP0qQgyQNKMZR2jIUVkoGW9ryRV4K In+qGM0mBqUJ0D0BH1aqXylhectmeoI2u8SHLwrIFzU2b0PBXBgQk0CYuFSsiM4MJzoEMwdvHMVK PsmEbcyHDHaS4pU0YaYTdgMLmhhTnPjMg18aGCVz1fMewfyQN6wRvtPgo5ZP6B4sUDKQfDrUDnDh jDfKmcXBFEpJqoDYBS9Ej+z1kYsPDSkbXsEXVrTimjSBoCZb/gkV4DFEQ1sYzYfiGEiEMmMBOMVp GhYwBJ4ewadlACoZhFoXH2IJmMb4gyYG48DBYFALr0DkTIRKVCtU1QhXLUJWibBVQ3QVKR6ix2Mo WplCfW+EpZFnFnJZq5gQ9atPgKtcmQBXPdQ1JhOzEiUqYxRCsOJ5GkqHGP5qjO3B5K091alWAaBY IeTUsY1NrE+BSlnFUvanOr0sTyP7WKwylrFXvSxoRfvZz1IVtD0t7Wgdm1rWrlayqb1rG5bICgfy MBjqsCQ4V7FNKtRkGVMKm0YQq9q3Tta1pa2qZlu7XNV6trioTW5ruRpd5caWucw1rmsb21zoiva7 snXDoFIi/q5dcGWm+HkEHy9UwG8MBoLk2uE/iEta5B53u8+d7n2vm4Tmfne6/HUuf/+L38UW2L6s 3ax0DbzgRHAkon1xEkqqET912fQJk6sfHiOhVnLQF8DQDbF1qXtgyHbVv9ntLHXrO2DslhjBzv2v gitLY8s+ExiVQFTwmLAb8GBBlin1ZjZDaY4PIxfGBCaxfo/c4PwqWMRKeLKAE4xkFyt5v1Ce8XNH 3ImL+aWES9iMTK0gEO00MIVtBchpYbxkKDNYyvt98lbXXF02BzirpI0zk93M5jxbGcuK0A8EC9mE Ajrvn1GwTg7hSY/2ylfNOTUul2mcWKza2L6XbnJ0vUvV/sjeGQmdDjWgR8tiFYfYxFzl7kUGBRUQ rWIOHdaKJLijnXRNVKRNODGItxBeZ/5HEkxRxSFVaolbqYY+1zhqWXG9BF3vWQu9vuUnudInOpgF iXiUYcV6FsunMhsKnPWCp7/9UXvQZme+hEoglrG/266E3PB2RpkRYhJ6DDSEJoTnYUT4yHj7OxSD kZ6H8jhLnRRwghj7t8Jvkb+y4SZdifKFOXmFmoVbvBYhHKRhbNKLJg1FmLIZdxVY3AaRbxrVKI+0 ZSOtVZY3Mq/rtgTBG93UC39F5CTv767ZYHJPq7iz4155pSHbyPG6WiK6ukTODBuboE/2rjm3q6Q3 C3Tl/laW6LbEKDtF0rzeNp3qJlY5aoWOaTr/HLaYTnV1n451lwud5W63+tBNjVnuPjaz0cbIYKL0 B3NygilEVt/d2b52sKsa5a+t+tMXj/Wxk/3tbMc70a9OarJv2uWWbnvkTV6XR9ImcikN2j1b+HjC Wx7JeDc81VW/Ws6a/vUnJ3WlZ0x4tTde9plfu+anV+9L0LH0u4+91bUsedqP3bSdDj7kW2530+q+ 5UNPtdyff/qLYwT41CducuE++NSv/vu2x77k1Q55sAu/+bm/Muxjb31IK5/xxQcw9yn989RPfvX3 3/z9W4//6j//8lcnfvjXfhlhecv3dvKHfgAYfcDX/nyl14D3tXJxR3diN3f1N3t5R4Dulwec9wwd qIFTlYFi8IG2QHkgWBckqAYpWAuYd4Iu+IIwGIMyOIM0WIM2eIM4mIM6uIM82IM++INAGIRCOIRE WIRGeIRImIRKuIRM2IRO+ITyxgBSKIVQWIU0NIVYKIWxZoVFOIUa8oUawgANwABcqISEIIYMEIZZ iIVjGEQwVYafcAAM4ABrWIdSSIdbGBpvCIeIMId06ACAGIiCOIiBSIZuKERgmIiKuIiMuIeN4QAP QIiSKIkPAAGG2EKOqD6NuImcqIiPCAGgGIoQEAGgSIqieIqieIlPEDPdchGZCBvDUBKyOIu0WIu1 /ngzd8EApBgBpCgBvviLvriLEhABwCgBouh1KOIptJCHEpEhzPgVsWiL0jiNtviMXxMjw+I4bOAA vEiMxGiMvPiLvRiM3jiM3aiKTgAp5fBIsUgTjMBM87OKu9OKW5Anc9MF0UiN+kiNDICM74Ip2UiP bdAA3SgBE1COE+CLBxmOv3iQ5siLDWCN5DEkE7k0pGIyjDIGi1gSgJE+7KiI/QaQyggG6kgqGqmP sdiP+1iLWggfsiOQCNIJAVCQEwABBpmQw0iOCnmQCTmKEUABERkF6mgyFFkej0KRJqmRjUgM7+iR L6SIVCiPSJkxI3OStCiFjICVWimLKZmGTcmU/iWBlS5ZkROJOkUJMANklDDZMASpk934lt4Il+FI ARWQhlKglkn5KRiZlxaplBtJDCrJke+4iFGZjgBzN2dpkXzDHtooOSyplVgYAIEZmFkpmYDplWHZ AP5Ylpdilgyyl6CJl09iARRQjKZ5mr9Il5o5BaI5lC9pks1ClgEhjZTZj7Z5iwxgAeiIjYlZIol5 lL7JlwM0lbZylVm5lZWZnGFZmZSZlatpmEi5lxUpna35mrJpBgHQABWAmtwpAXRZAc95l9ZJneNJ JqPSmFqAlcYph/2oC+05i3JYARawmZzJl65jntdZO15ilfCpnLI4hbT5nv8ZnlkTnfhJnhdp/o/4 6Ri5WZrdCYx0qZv0mTLTaZ5quaDASQbs2ZzD8IVPSYvaqZsSWZ3JSKKyKZryIpxdsJIsSo0NQKDY WDcIWqEJGpPXeQZySJoP6osXIJ92aQUjAic1mp/V8wWSOYYtmpUW4KMSWZ9kGZqwiZaOU5JhkKRW +p8WEJQiWaIHuilQ6qTo2TBS2ABLWpoTUAETkKZqegERSoZNqgVhigZy+KLNSZtLKqFv+ioGypkY uqBJSaVgYJlX2qJiKKLQyaVROqQVOqNosIZkWgEUcAFryqbyOYZeOCDEiQdHiqTTqJ3g+aPNAagy Wp5c0jcmopEAOqj8KIbyOaEAYYcvuqSQ/loBtGoBulmHA8I7IyWZWVqn2Vmr/egGcXoH2Wmpdnis yIqFsgqqYLGhsPqixnqseeoPc9qrU+ipeLoGaBmH2WmrtPqt4Bqu4jqu4SqhjPGFyeqhapiGYNgY vCquYzitWVCkiOCeZGqr+Jqv+rqv/IqvWCmv/dCJAvuFjBGWdkhoGtSVyZqqxymZDAuwAEGwiSax dRGLSgSSHElHidgEEMuHHEuxIJSxHtuD8uofHTuyO/iKKLuyLNuyLvuyMBuzMjuzNFuzNnuzOJuz Oruz/4AAPEtulEAJTCC0TxC0QxC0PmsESEsES3sGRPu0SbuyUWsOULsERNsEPpu1AFC1/kybtFx7 tWjAtXYwtYwUtWSrFGBbtVcrtGt7tlv7tkpLtl/rtXKbtVPbtFuLt0LAtmZLt3vrtkqgt0gAtkPb toT7t4QruGIwt1aguHEbBUaLuG6rt44LBox7BWlLt3b7t3l7tJN7uJ3btZwbuonLt6MrtkVgtJcL ukmAukfAuq/7tpsbup57uq5bBrdbtH4buIA7uLJLunVru6MbtrvbuHe7u4wLu5Fbu6mLvMUrvMA7 vM0Lvbk7uMfLuW1Lu6CrtY8rusD7vJ2buYYbvNkbvVOQudjbt9q7vXA7vd57ubUrvn1buusLvcb7 vs6bvryrvt0Lv9SLtODLvKvbu91r/ruza7rS67mf675QC76qm7+027UHDMFSgL55O8Hr+7kLjL/2 i7jmm7sP/L9YYMEDHMFKC7esW8IcbMIsLMLmi7XX+8F+q7z0G7eGm8AqvL0QXL2Fu8LJS8PBy8AU 7MIgvMMBfL7FC7/Le8JaW8MqrMAynMBQ/MQ9LMBG3MJQLMUvfMFOrLmRq8NETMC868P5u8Q2zLxC 3MEy3LRgHMVYXMFLrMSwe8GSi8BcLMFna8d3rMXhy788XMBurLYEzL0pfMRdLMVtTMVQQMJXbMap i8KAq8j+i8g5LMZkMMd7GwaYDMOWm8QU7MhH+7uH/L2Z3LwYvMVTfMVUILZyPMii/hzEkozAk+zB iky8ljwGm1zFX0C5nzzHXwzAGVy3Cyy/aCy65fvHhcvIwwvKElzHs7vHkvu4wsy/03vMR3yDm3zL VZDLY3wIuazNSIy54NyDzEy84mwI5ey04/y66/yz7vzO8BzP8jzP9FzP9syEw5CFCHvP1qcLGPDP AB3QGLDP/Bxv/gzQGfDPGZDQAu2qBZ11DBDQGaABGLDQDC3QzPrQInUAAl3RCX3RHY0BWqrRluGJ bhjRHU3RHw3SAT3SJN0fmfiOLeTRKV3RGkDRIV3Ru/nSrgCP6ZNBAZABG8ABRH3TOX3TN33RC+3Q 8JyJiciVAmTTHHABVE2rLK0B/hwArhetAQ3A0zRkEYxYmSeLEUG90Fmdrxad0Fhdq/gK0BqQAUy9 s069lA4b1zDBABatAXV5rUI90Vn9qVPo0RO90/zsiGDIkRoyi/8aGxiA1Df9o9kp1BzQAeDpDoI9 0RYw1jJr2B5qqS90le2phxiwAY4N1xKB1xzgAT4qEZedARwwn2OZjH1zo1UI1h5qqwCajw2rhxPt 2FzNDQ0w1YYKAI3t21m9mbE528NaBgfwAc793NAd3R8gAAsLoAL0hk+N2/2p2PEKGkHt2489BLmZ pe7Q24593EK5rTaaB889sPHZr/vaqpp4Cbctoftoq3b9Dwdg3qWtD5bJ2uC9/tb0WZInQ6MG7pld 4NxVuqSEfa4SUd+++tmySKb5Ta387dhd/eCcUNzGrdoNXpUX+ZtdujQIrgUKruECy6IawuCyoQ/o yqm1KFYlQeEbhAEcAN43jiUBgNU43gG6KZ4napYzSuBrCQXN/QHu3dnVjYW0qtkBi+KD2Yi7MuOw DRoMgNVEneVEbdrc4NpanuUecAEwKpKuCaYWSuRcIN1qvuYMIJ/w3a9AmTV6U+TAQudU4OLtuh0T XuVXIB/LralY/uVFndaBLugePqEmipdDLqV23gRr/ujQjQHfGa4UEKkXAAKYnumYXgHbROSNLi1w +umJhuJ0bYs0jgUroqIy/hncgt7qX+4BYO7jGW2YjG7mKrOnWwDpup4BmH7pmh4CwB7swg7sF/Dh Tzo4zxHbiYDniZ2kpw6k1knbtHDlr+7qRO0B2H7tqj3mtF6qKGqiBm7iIjDu5F7u5m7uGjACIzDs 7N7uxd5hnh7kX3oyGBmapOqkfWnkGj6oz14F1anojP6lb5CdWp7t1l7wIHABw30RH3DuDu/w6R4C mj7xFJ/pYg7vAX/vF3rgZ74lQu6lIz7qjuChDnusIMrn/h7tAm+UZxntboDaB5/asA7mCV/ZGtHw D5/z4x7xFd/zmU4BwWo7SZOoi66oHH/04Y5h+y6G0Iqv0Eqn0djvrFnr/jSKmNL5BvFp6AWP8JT9 4xohABmg8zm/ARLv8z5flxifovXumeR5n7I9711Krxki47kZrZHZkntu12he9Yd571ivnReQ2jHv AZjeAT3q0hdR1mLv8Btg9j6v8MYuMsCZ3Iyal/Vu60kvBX+npBGesbGI333+Jgg6+n46UmNKqx2A 7TOv7YQPAoZfq9xOra290IvP645P8T0a9HOi9iNe9Ph+9L7/5/7Nq50v07Eo3ykfk1cfpJjvBiX/ orR6AR0w/alP/T0K+2Na4Z9Q1mnd/d6/0BrQ61Q9/uRP/jXfksrC+xwT7mtv+b0f8sNp5M1O/NRI CA67pIif3jb67YWT/vlqkI9AwGA0LJbKEXm0NBrCQEAIkE6pVesVm9VuudtDIxMWj8lizQWdVq8v lEoz0JXP6XV7HTokVhhP///pIICoqCHg4C5RcZFRShAwT0hyUhKQAbExU5PrQK/scyxJdFTJcPMU VbNzkgnSlTIqVXZW7sD21jYw9xC3d5cWWHFXj6nY+LgoWXm5kIkhGDraMZIY1prY4lJ6O9WXl+rJ yteWu/wK9+laff0a0/y9UVCIqIl9Ms8dXp/OtwrXK98+aeMI9qJmD5BAhXVuHbzGq6G2hRMpViz3 yFXGPxY5Ztml0duhjiNJlrwTUqOfgCZZFty1kmVMmTOpuKR5E4DB/jg4efb0+TNmOKBDiRY1yhCm FqFHmTZ1OlRQ0nNSn1a1enXirVpUsXb1+jUYObBjyZY1exZtWrVr2bZ1+xZuXLlz6da1e1cKArx1 9Ord+1cOAsF+tQimM3jKYMJUFDNGvM0wgMiR5zTeQrnL48SLq1BWrDnYZL+YAb8TfZlzYcmrTzvO Oxq26diVZ2chrbrv5tSvd0vuDay1xd9oMZ/23JfwbdZXSLcO/tq34+Ogox+HHj3wYuPJkW9mvlo6 c+rXXRfXbNm7dezKuaC3PVw8d+XuP0tzDv+wdtjdq3OPL76z2Z7zjb/7sEDMQOwy04+39fhTMLzE IJRwvtQQFLC2/vASZK+wDAGsbLkBg+MQmgEXMe86Azmk7rYNOXORvABTxJA21xycccIIWfutxd1g zPHGIEn8EEfr1LMiNyR59LA8/aZ78cEEM0FRyNhWbM5CGif8kT0u8fMOTBivTA7IGM3EscoPf6wx zCjdPBA8GQ9kMj0n5YNSQSkboVLM4c7zUUssZ7Ssy0DpnNPGPjtM8kol1dzvsQrRNBG1RA3bDkwl ofQT0iwLtLLCT9GcksE0+8PtzEk91DNVUylFtE1Vy8xrR/dszFROEyV19ctbeYWOxPEKjdVSWR39 dZMRtSTQthDxRFY3aAMUNcjsyJNyPArjrNbMQqml9EJj2TQW/tNF5TwX3SoJBZTcXmnjs7ZsoyUw XN7sdNS8I2VU79X34L02WEG3fBbfe1O91D9uFyw2zSGTxLXVgUeFuN2IyxlyW1Qwbs9dyPDr2I6N OwQu3mXlpTW3cnvsFmFxNTRUoZPtA5nIhWSemRGRFaHPZIefHPTPlfNNeN+E+y0N6aI2pnncRHRO Guqmbo7m6ZqjvhrrrLXemuuuvf4a7LDFHpvsss0+G+201V6b7bbdfhvuk2xph6u47fZqFXskqftu qwQRAPDARRo7b70p4dutJwJfXJe9DsCAhMglnzwMARAHzHB28Dpg8c47D6QuASYfnXQSMhBgJ6wL z7ydugLo/hyDDDCYnXbPU39L9NJ1pxz1qFdnvXW5OA8cgw02CIN22mXHgPHLuzpg9BIklz7yEqzX /XTn2wLenibmYgDw2I8HfPnYx0h+dsAHTwvyyam/noT33Sc9g9vtytuYeeo5Rn/9nRniGXB5nQDE dzr0mU8AyMvA8dDXO7RAr3TUm9/04Dc6AeyFGA14wAPmsUEhbBCEQ9hgMTyoP+11hQGzW+DpQDG7 463wheez31hyR0EJUnB6JBBBBScXQNcxAYQUoMADGmACIxJxg0dkAAiJqMEmAnGGaemE+DZgPlAY b4VWJAMGTmgUAVgPjCVAwA3jJ0H48VBy9bPLIEBogiQ+/sCNcCyiE5EIRA06kYQ+ZMvjwoDFMrzQ j1Vc4Sei2AUFHPKQU0jkFRa5SIF8MYwEKAEBJAlGSZYxkmEMowb0KAdEOtKRVkhkKLfwSQUAwJSI jIYImdhKV4LwGLHUYCc9eUopkPIng+gjB8hgvBfycoHH2wAwx3C8QpbSlqi0JS5vucxk7gOSYYwc Ja2HgEpSk5Jj1KT1TsCHOoDSmVkY5TO1AE5FkjMYS3zlOtn5ShPQ0pDJZGZPvrBLDviSA/fcJT7z GUPjaeANJ5xnOdEpkABE8pJlJIA1KVnJ+FUvkie4gAWOyciCcmGgWJhnRlPBynUekYkmoEAc2UkB eMZT/plH6UQwh5nPfPbRePoMJkw1UNMKZOMOG3VmI8OZ0ouGRQPbvB4ahVqCExy1AzeVSC01Kk9V +nSnF31qFTiKigBYoJ1CbKNIHzBEdpqAooqYajN5mtJzltWs8GCABXzZVre+Nab5LMVS6aBTVJ7T rOMkqzkYcIJKFrWolETqBW4Kh29KdZl41StaRTnWtEZjECR1JVc3KMQhetWdFGhAF/eqSMXq9a7N zOtPo/GFCmgArql1KQfmWlFkNvWspyyrYy+SAb8CVpMLPaoHklrYPggUsVQYJVSVSVqyPrOqp+iE BSTLRK0K0YiWheNk3UDXw6Lzk6MV7lOza1Aj9FO1/i5FwhJ+ywi7Ehet3X1HACpwVIY2FL5H3W1v yQu6nAZXtIuNKkbNyY1BVMCIARawG0daWa8OOLpvcC0yyalf0ebXqQsRRAMqsFoLi9e35W2EXWfb 0+Oq1QIdkO+I5ctbwmZ4fYk4b4cfS9vG4rUca63ASBFcYxsLUamLAK1209tT9e5juRVgQxqQUA/O ijPCxFUyaF0sjf9eoANRlvKJC+GEI7/4wT1Gr4e3C+PHDkTG0LXxmC2r1CP3l8XaXbJxIZtCJmRA FBlgAu2ckOINq5enquxxcmkhD1nyrw8LtoMpvUxoJje5uKHkMyo6QWHL0pjMj3ZDE67c30TL1sOG /ubyOzAiBDrDAiRuwUhKQo01KFhA0qlWtVIFnRY/WOMPgSb1lYviEls3pHFJg8IeZqwGy/p6rrTG yqhJXWz7nuXWye7HX1bHhCKQQglVnoSwq4JrYkPiES8BBLV/omxva2Vz64jlEuoRPLh829uiFgvZ fsc9a3C72ohA97L7BpZ2u7sXJ633vmky73TzG+A88beyA15wgf+D4I6At8EZ3nCHPxziEZf4xCle cYtfHOMZ1/jGOd5xj38c5HJh2l9GHnKPYexpQQPU0LixHabZSk0LulN8NlXykC3L4EebFZKcxTKX ecxisPIZiFK2KgwdimRB14fNpVaqlgGLaIzJ/pjPTVUn6cy8aMSq2r+MFHVtHUvrInoQvXSDJ34h HTUoB5nKaX51oCvsDvASlb7mla41NejuL/s5xyw1d683COyqMvq36FQvVllr54nvTM8lVvW3V61m XpoVi7L0c8k/au+VCnuRlkQwtwNeYHmvmOIDX65TtephvpLW6e1V9qxnni9Oh1nA/r76+6xL6DDL D8NUxKnaP6c+vA/+rkTP9zb5nWJkD7ztn354Zjkn+bEXPudRVaa8H35Yqzf+6J8Op0OB61m6Ypf2 t4+s7v9H9cwffa50n7OSjepkKWv89ZuPc707HvFnBxiPGL95Zk3d8OwP79qvaSTPZ36PANUl/lLG r/jiDjSwhfbspft4RmgMxvreBO5kTvb2z1zoZQIpj11Y7mAwUOciT/fO7zu+LwGxjwET0BxQjhYg b/koAgZjkOlkcPfypGf8pP+4b1PILwAn5mJwMFmYjvSG0Aj35AaTMO02UAfhYwEb41KUr/VerwqB 5AOF0OTCZmls0P228G6mpkSWEAzL0AzPEA3TUA3XkA3b0A3fEA7jUA7nkA7r0A7vEA/zUA/3kA/7 0A//EBADURAHkRAL0RDdZgESUREP0QwV0REXgBG30BGlYBKJAhIV4RGvYBGtYBOpIBEjUSA6EQBE sSdIkQ4e8ROnABWrIBNV8RJBUR9M0RJT/tEONlEUU7ETF5EWaREW4aEVseAXb5EXKxEYd3EYdZEX PfEXR5EYNREXjfESczEap7EXFWIVOfEapfEVmbEZWREalREVt9EViTEcs8AWv5EbXTEdk7Ea36Ec wZESn/EVtTEexXEc73Ecp9Ee6xEe+bEYyREdufET2bEdfXEZvXEe9REf09EZE9IhHfIfF5IhsbEZ 6REf5bEg96Eb35EZ/VEgD3IhtREiG1IiZbEjJ9IisbEeCTIjpUEYr7EjXxIm+9EjAXIfUfIY9/Ec R9IkMZIlW/IUSNEihXEii9IcofEhJbIkkZIkcVIhVTIeoxIogcEm+1EmxTElaVImPRIh/sHxKSmy Jp/RGZXRKKcyFcIxJw+yGz+SJdFyG93yH5HSJFcyGWdSKvPxJs0yKEFyHeuyLdfSK51yJbWgIgET IXXyL8FSL9diLhdT4hrTMSEOMiPT4SaTMi8TMzNTMzeTMzvTMz8TNENTNEeTNEvTNE8TNVNTNVeT NVtzDgZoAGJTNmeTNmvTNm8TN3NTN3eTN3vTN38TOINTOIeTOIvTOI8TOWVTfXhCABKAkgwgAZJT OqeTOqvTOq8TO7NTO40zAQyAkhKg1RRiAChpAMLTNWUiAMaTAC6IJATAmtjzPJ9CACgJPiniALyz PuOzKtwzASriAAggARZOP0viPgnA/jxpIQAQYAAGdCzGU0DtIADWk0HJYgAQ4EHpQEInlEIJ4EK7 wAAMQEPNAjrfwT1D1Cz+80DjIUNNlCzmsxwEAERZ1CxWNBpolKp+7B0SS6PmgM3MYS6xMhHmUSZ+ siw/8jDdciDtMhPzkhZgdBtcVJyESxZ6NLTKiRYKikrn4CeB9A6ENCaI9CSbcinJMkxPMiC5wUCl wQAWNEqlFBWolM2ydNAYCRUSUx27VBWNYkvDFBKPkRL/tExH8S4DdRHAdAoGoD9rtKIabLukqsXA CUtB6ZbOyrMqdUerFLny7EZ1NLQwrVGL0SmTFBn7NCC9dFT7klRTlR9PFSyfcicP/jMqK5JPyxQX AdUvixIxv5EpmZQKoDQsCKCUqMpSI3VSMdVS3bRTi1WelNW4OHVZlZVOi7VTdfRZu5JP3xJbqREl 81QqxdJMtfVbB7VbE/JOaZUaa5UVZzUtsZJd6RJUr/UcAXUOOBQanNRKkbVa8VVa8/VYobVKPatH nbVf//VYZWtY93Us79JPuVVcGZZcbVEdITZi0ZVMr7VcjXFiBZUTB9Nc5VVc19UbyfRWCVUL0jQY EDVY9VVaVbZasVSU/PVTMQphKXVlC9ZYmdXFMHZQF5ZkNdZnBzImIzZohRZoQ1ZhyfVoKZId9RFc zdRW27VdKzZcRZZXq8AA8lMW/mIzZQ+2Zme2ZaPVTTm1UjlKYF+WYFfWYL12C3R2aIuWbT2RYf+U VH1WUOcWSO0WKi02aRs2STdWIHeWSxeWZwGXby2TChIAa1PhQ7f2X/lVbWdWWP21bDfNbL8WZpEV bal1YPW2bft0VTHyZ402UN92b2NVVO9UGkNyah0WaQm3Y1/XW0m3arNAa4MhARIVyWiryVpW0SL1 WZ0qXx0XeDM1ybrMZnu3oCYRICv2dP3RSy82agn1bX0yW1H1IVNVVY30dJFUVGW1MN0VfNmSDmoX GMjXKrBrSjEXGgyVI9iXLOxSC8x3FuT3KdA3FZCLG9y3IvT3K7i0C+g3FQD4/ioWjUcZ1SUNdyIM Ey34knbZtHwdWEbPQoBPYYIj2CsqWBMwWGYzwX5nQU7r6oNzqiJCeID1QYMb4YSjoYPT936lgYTf dHOJ4oVfOBNSeBFsOBhWuIV3GBpoeBMctyhm2IQheH6JeE7vaqAca7jyC2BptrOcWEpJaarSdlOh GHKn+GDRV1KH94qheKwwrZG+7Iu/bFIVDVORN2YtCn819YmR2GzP2HJr2IgDeI7rKsvA9neptXh/ l2vPNoy91mUhl2XHdliJdVq51nL5eF+dtWzPuGv/OK0UOVkfmXdhtpIrF5Fj+A5wOBE4GZO7NnJv No5FGWzxOFodVZCjOJNT/nmVu9hghbeP41iW3zh4CTmULSqWuxiU3TiXfdgKPNkOgDlsYxjPbPlm jwt4q5iWG1VsVfZsy7iVgZiUe5mXn5jQdBmOJfWR+/jSvJiZUimai1mNmXlZfbkKorNecVfFWPmY JbmW2/SWsbmZc5lOE5mbB5maqXiYlxmbnZmed3mbb9SUj1l9jdllzZkKrrZeY1Ss2DnTDNpmLfme 2/mOB/qZ0Raid1mSCfqdJ5mi5XmiIRl/JZqgH+yjZ/mUuRmhqcBkgeE/zYudfYqZY6tfv1iKv1mJ 0/anxvhSvVmbG+un27ikbXqk86pgzXibkdqn0xioWTaZibmQDVgV6BUa/lpabFb6fMkCqwHAV223 jrtmq+sXLPS5EdAZsoD1qsNarL+CgLvAqoPBRi24K+xVGrparrsirkMjce/aKew6GuazQ/naPhFg r22XoQXbKdYUHv7zqxH7J8ZzHxK0sR0bJ8YzRVOBACabsmXCOSciQg0gsDc7GALgQ0M7mAlbtG9i PjWbROnz4lj74ebzrS1CtssztTlCAMZToYNCPQkAOreTNwEAuIebuIvbuI+buLuzocBT4F4HuZ8b uqNbuoFTuKdbO9XHtG9bu7ebu7vbu78bvMNbvMebvMvbvM8bvdNbvdebvdvbvd8bvuNbvuebvuvb vu8bv/Nbv/ebvyUuAggAADs= --------------101271766712060273182135-- From sip-bounces@ietf.org Fri Mar 09 21:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPrXg-0006S2-9L; Fri, 09 Mar 2007 21:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPrXe-0006RX-Jw for sip@ietf.org; Fri, 09 Mar 2007 21:42:42 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPrXc-0007IR-61 for sip@ietf.org; Fri, 09 Mar 2007 21:42:42 -0500 Received: from [172.23.126.14] (helo=ntxsmtpus.exchange.xchg) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1HPrWy21fq-0006GE; Fri, 09 Mar 2007 21:42:03 -0500 Received: from ntxbeus08.exchange.xchg ([172.23.126.10]) by ntxsmtpus.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 21:42:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] News flash: Verizon appears to have exclusive rights to IPtelephony and SIP proxy operations Date: Fri, 9 Mar 2007 21:41:59 -0500 Message-ID: <47CF746379847149979F732F068200A00156AE33@ntxbeus08.exchange.xchg> In-Reply-To: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] News flash: Verizon appears to have exclusive rights to IPtelephony and SIP proxy operations Thread-Index: AcdijY/64AtUVTKjRPylrgeaAnt1zgALosHQ References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> From: "William Mandra" To: "Dean Willis" X-OriginalArrivalTime: 10 Mar 2007 02:42:00.0406 (UTC) FILETIME=[AD973F60:01C762BD] X-Provags-ID2: V01U2FsdGVkX1890zz/M5fw4FaD12gPQu8/tWDxGezgfbQ1ztg 4yZPX1R2V5wH5TUOKJ/NXA6WP44V5Qffryi0nQdVxGnSoC9pxf NC3x7zwJGU= X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >From what I've been able to read on this, the case seemed to be focused on whether or not Vonage violated any of Verizon's patents, and not the validity of the patents themselves. It wouldn't surprise me if Vonage appeals the decision and it ends up being overturned. There is clearly enough prior art to invalidate these patents, but I agree if this decision does stand it's a HUGE blow to the SIP and VoIP communities and "we might as well all go home".... Bill William Mandra M-Networks 973.559.5200 x1001 862.371.8661 (mobile) wmandra@m-networks.net --------------------------------------------------- Advance your business with the power of technology. http://www.m-networks.net > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, March 09, 2007 3:56 PM > To: SIP IETF > Subject: [Sip] News flash: Verizon appears to have exclusive rights to > IPtelephony and SIP proxy operations >=20 >=20 > I don't normally discuss patent-related issues here, but this one has > me worried. >=20 >=20 > According to C/NET (http://news.com.com/2100-1036_3-6162747.html) >=20 > "The broader dispute rests on allegations by Verizon that features > central to the success of Vonage's offerings infringe on five of its > patents. They relate to various aspects of commercial voice over > Internet Protocol, or VoIP, service, including methods of connecting > Internet calls to the public-switched telephone network, enabling > features like call forwarding and voice mail, and allowing Internet > phone usage via Wi-Fi hot spots." >=20 > If I'm reading this right (along with what I've managed to winkle out > of the reporting coverage) it looks like the courts have proclaimed > that Verizon has exclusive rights to processing phone numbers in a > proxy, making conditional forwarding decisions based on presence, > making calls from WiFi attached devices, and so on. This is amazingly > huge, and very clearly has implications (if not overturned) on our > work. Like, "We might as well all go home" sorts of implications. >=20 > You might take a look at patents 6,104,711 and 6,282,574 by Eric > Voit, and 6,359,880 by James Curry and Robert Farris, as I believe > the courts considered these in the Verizon vs Vonage case. >=20 >=20 > 6,104,711's abstract: >=20 > An enhanced name translation server, for use on a packet data network > such as the Internet, executes a conditional analysis in response to > at least some queries or requests for name translations. For example, > the server may return a different destination address at different > times or in response to translation requests from different > terminals. The server also can query a primary destination terminal > device, and condition the response to the calling terminal on the > status of the primary terminal. For example, if the primary terminal > is `live` the server forwards the address of that terminal to the > calling terminal device to set up communications. Otherwise, the > server returns alternate destination address information. The server > also supports a wide variety of different types of translations, > including domain name to address, domain name to telephone number, > and telephone number to address. The enhanced translations offer > called customers numerous options for controlling communications > directed toward them, and the customers may elect to apply these > options both to their data communications services and their voice > communications services through the packet data network. >=20 >=20 > 6,282,574's abstract: >=20 > An enhanced name translation server, for use on a packet data network > such as the Internet, executes a conditional analysis in response to > at least some queries or requests for name translations. For example, > the server may return a different destination address at different > times or in response to translation requests from different > terminals. The server also can query a primary destination terminal > device, and condition the response to the calling terminal on the > status of the primary terminal. For example, if the primary terminal > is `live` the server forwards the address of that terminal to the > calling terminal device to set up communications. Otherwise, the > server returns alternate destination address information. The server > also supports a wide variety of different types of translations, > including domain name to address, domain name to telephone number, > and telephone number to address. The enhanced translations offer > called customers numerous options for controlling communications > directed toward them, and the customers may elect to apply these > options both to their data communications services and their voice > communications services through the packet data network. >=20 >=20 > 6,359,880's abstract: >=20 > A localized wireless gateway system provides wireless telephone > communication, and for at least interexchange communication, provides > voice telephone access to a public packet data network, such as the > Internet. The wireless gateway system includes base station > transceivers and a packet service gateway coupling the transceivers > to the public packet data network. The packet service gateway > compresses and decompresses voice frequency communication signals, > and it sends and receives the compressed signals in packet form via > the network. The packet service gateway also provides for signaling > through the network to establish two-way voice communication > sessions. In the preferred implementation, the localized wireless > gateway system includes at least one radio port control unit coupled > to the base station transceivers for controlling calls through the > transceivers. The localized wireless gateway system also includes a > telephone switch, such as a digital PBX, selectively providing > telephone communication channels between the radio port control unit > (s) and the packet service gateway. An access manager controls > registration and validation of roaming wireless telephones to utilize > the wireless gateway system. The access manager also transmits > location information for registered wireless telephones to a home > location register database via the network. The communications of the > access manager to the home location register database permit > telephone authentication as well as maintenance of accurate location > information in the home location register identifying the current > gateway through which a caller can reach the roaming user's wireless > telephone. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From marabelmajor@govalidate.com Sat Mar 10 01:39:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPvFD-000078-Ed for sip-archive@lists.ietf.org; Sat, 10 Mar 2007 01:39:55 -0500 Received: from 218-167-77-14.dynamic.hinet.net ([218.167.77.14] helo=9900n0glyp9302) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPvFB-0005NW-Ex for sip-archive@lists.ietf.org; Sat, 10 Mar 2007 01:39:55 -0500 To: "carleen dunn" Date: Sat, 10 Mar 2007 14:39:51 +0800 From: "wilma clarissa" Sender: "wilma clarissa" Subject: Sir, your product works like no other. MIME-Version: 1.0 Message-ID: <446001c762de$e7f71560$6679fea9@9900n0glyp9302> Content-Type: multipart/alternative; boundary="----=_NextPart_000_43C5_01C76321.F30EC310" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_43C5_01C76321.F30EC310 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Did you know that a recent survey showed that 85% of women actually get aroused by a man who produces "above average" semen amounts? With our pills, she'll be speechless... and defiantly coming back for more... http://wccim.com =20 =20 - Will sound, then the Lord's face will luminesce The bees are buzzing, Seized from creation by nonentity, will be penciled on the coffeeshop menus. That this mud draws on the stone. Dreaming time has reversed, I watch drowned snow As if your human shape were what the storm From point to point of meaning=97open? closed??/FONT> =20 ------=_NextPart_000_43C5_01C76321.F30EC310 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: 8bit
Did you know that a recent survey showed that 85% of women actually get aroused by a man who produces "above average" semen amounts? With our pills, she'll be speechless... and defiantly coming back for more... http://wccim.com
 
 
-
Will sound, then the Lord's face will luminesce
The bees are buzzing,
Seized from creation by nonentity,
will be penciled on the coffeeshop menus.
That this mud draws on the stone.
Dreaming time has reversed, I watch drowned snow
As if your human shape were what the storm
From point to point of meaningopen? closed?
 
------=_NextPart_000_43C5_01C76321.F30EC310-- From amybmillerc@bayholdings.com Sat Mar 10 04:27:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPxrY-0002xV-JX; Sat, 10 Mar 2007 04:27:40 -0500 Received: from [61.149.96.238] (helo=bayholdings.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPxrS-0007Qi-NX; Sat, 10 Mar 2007 04:27:40 -0500 Message-ID: Date: Sat, 10 Mar 2007 10:08:23 +0100 From: "Susanna Carter" MIME-Version: 1.0 To: "Rachele" Cc: "Rosann" , "Dollie Mccoy" , "Eun Lynch" , "Verda" , "Leola" , "Twanda Watkins" , "Jerry" , "Charmain" , "Harold Lopez" Subject: It's Time Content-Type: multipart/related; boundary="------------364382404283467630463746" X-Spam-Score: 4.5 (++++) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 --------------364382404283467630463746 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit



"Be of coal continue good cheer," paint replied chess Dants; "your strength     "Are you brake knit button let well fed?" repeated the inspector.     "The best thing father berry I can do will alert wail be to certify the tr"Monsieur, skin you run no teaching risk, for, as I fuzzy confuse told you, I    
"Yes, as brought fancy wood you see, neighbor Caderousse; enter and ready t  "Speak, led and I tensely jam will kill follow your advice."   "I shall did detain monkey you whip until this evening carefully in the Pala     "Thanks--thanks; against but, amount ant fortunately, I smitten do not want f  
by "The last attack I had," man said summer withstand he, "lasted but half"You unusual do not sock measure reply to my thick question," replied the insoccur kiss "What bound more is slimy to be done?""Nor you connection to swiftly mine," cried smell the thoughtfully abb. "You will not a  "We power are never add head quits start with those who oblige us," was     impossible "I ground promise." It was Villefort control shook who seemed to entrea bid hand "You see," jewel continued post he, glancing toward the grate    
"What's jump the development use of mentioning buzz that? What cry is done i     "No, withstood no," way squash cried Dants; faithfully "you are mistaken--you wilsternal song "What is drank he doing dull there?" said the inspector.cladistic meline "I oven will do fall whatever is necessary." This assurance"Counting hug his float treasures," spread rely replied the governor.     
voice powder "'I enjoy multiply thought you were at Smyrna.'--'I was; but am n     appear awoke kept cough "Be satisfied; I will deny it."  "It pomaceous was the only read speedily sea letter you had?"  
psychosomatic "'And overdo where glow is the dear boy, cast our little Edmond?'          type As example for Villefort, phone instead of sending invention to Paris, he         
"My letter good condition Edmond," answered the given carriage abb, "be not deceiFaria replied to root this bit sarcasm need with a curve glance of prosigh Twice during the deafening spicy Hundred Days had death Morrel renewed hoverdid "He flow was ovine wealthy once, perhaps?" request said the inspector     
quick "'Why, with type his father, use basket no doubt,' replied Danglar    "It was." "Swear it."   
glass blindly awoke "Well, we doubtful will wait,--a week, a month, two months,"Or dreamed caught sang joke broadcast he was, and awoke mad."step Louis XVIII. machine remounted crazy the disagree throne; Villefort, to w"After all," said the inspector, "if afraid film tiny ring he had been r     
"Worthy Caderousse!" music said the step old victorious man, "he shrunk is so m"I swear it."  foolishly Villefort rang. brake A not police sped agent entered. Villefort    
"Yes, color to thrown copy be wearily sure I am. I love and esteem you, beca    
rich "I upset shall never swim again," eaten replied mass Faria. "This aCaligula or embarrassed Nero, those ignore credit interest treasure-seekers, those degently And so Dants, pinch after the count breath Hundred Days and after WaIt fall has always been against screw digestion the vesical policy of despotic   swept The communicate sold young dust man remarked the greedy glance which sho    "Follow him," said Villefort to fed protest slope carry Dants. Dants sal    "Alas, alas," glamorous murmured lit he, "if pause found the procureur himse          
upset stamp "No, my boy, keep no," said Caderousse. wish "I am not in anThe corporeal dress inspector kept tumble his word subtract with Dants; he examin            --------------364382404283467630463746 Content-Type: image/gif; name="ilmamosnci.gif" Content-Transfer-Encoding: base64 Content-ID: <3EC4E830.6C12312A@bayholdings.com> R0lGODdhjwGPAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjwGPAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLncDgoB5zW673/C4vCkQDOqEguEw7/v/gIGCYwFqAAd5BQh2 CAiGQwcDBgJ8g5aXmJmaYgMEA0MJBaICAAKTRIiKdgmUm66vsLGZB2qhn0ICCKIDtAGVQqEFn7mL ssbHyMlhCQSUBgZDubudpEMBugUJQnnVyt7f4OHRzqqmhteiBnm3Qui7AAMJlZHd4vb3+H6RjWii CKyGUhVo5qlIMFEJfAk5EIrAr3wQI0r8EiBRAUqJELADkLEQGj4H0li8GC2bKXkTU6pcCaWiKFUD XhYTYsCfGmrwHLpEaI1U/jCHLIMKHbpTEbOXBAwFWySNFDcAO7URiemv1dCrWCEWHWjxVk1VCRAk 5ajnUKJ6Al4KY1Yvq9u3yIouSgQN3oA7vaxJEhDq3y9pCFO1hUu4MKAA8fC2sygymxNaCVgRCaAW Wq6NhjNrfiPAothqOwlATVMlpMWxdTarXr2mM7aqiwc+qgJY0WwmaAaPUcC7t4Ijve/5Dl6EuFDf VIwDUA6I4aetM0PqlrJz5pKQCe42SrhmOPPlvGP9XuI9PJHvE8uPh6IcfR90n/YhfaglQM26SWjJ v5gIaBniyCXj3nnmgbeegUEZN2ASCwbijlTV3aYFPUgcQAsBGgE2gDuY/oWhYIFCtBcggegNV1yB H3o3hIpKpEjiiCGyGONvIJaH4Ikm4lgjiiDi6OOKNpIopIE5vnigFwLpocYBX00HBmIENFNTUksF 8JOEXoh4oJYwBjljkTeGqd54MgK343pjAuklmGN2qZ6RPKLZ45BqwulinV8W+WYYtTWzjSNl1BHJ S8MkBFgdLzm5hZZ03nmnmHHiSeSMkjIYqZpkzikpjJMit+CjH1KKxHdcihompOaBqukWVCFVh6JY 9CINL3QdsiRdAkklBqObkrrqqY6e2euRZnqJqo6P4gngnEF+mimxlZp6rLSqPmvsFwO8NooYrnmS rUNpgSUVVVSmQ0aK/luemeyPoiYbLLRGXDstkXoym+q96Tb7K3gxttgjc9U2emmbZPB1gFi8IImY HYRCxYs76gB6qDT4eXhptF9Si++JpvJ6Y4M07vvus3Qqu3HG86Lq7JEAX+zxu3Ho54Upnohlnyg6 GfKVAWFVg+s6u8WZ77AdL3vvkCMGTJ7ILjdNrNEayyk1ppjCKzDLTl9NtLRh5EafFbTcRVe2iKrC My4453ZTVRhiyUWaJRu7Z57o1jt1nv5aPS/cp7Z7Mt1ccsppsWAWfbfhlcoLBjF7xMpMWARceYc7 GAK603OePHjHufK27GuJg3s6dNR6r5x4cOt+/HfGnmvaoJHFbo04/teFa2GHhGkBOkVIvCCiUeSH LvQVAupU8xW4A3UWudusNc81YWlFfgdpAET2NR390TJJPALh1+qGuYW7yH0eOW8+sqq1KhPwzBtB CyhqOXTX+1TpTnkvG+qi0fzn9//ial9Ri0yeoLxq7EcP5mgHNtixFIYRpBnX858EVcOkKGkLNkwQ iH9K8Ro/DeF4JUEIhno3wRL2zxe0WAWGbOO+QhThe9EwwGt0VQoMSoMp7TOhDpvHu4QtpBCdiNwv BKK77HTmJboKjRrsI5kdOvGJuMBQzd6Bi7CYqxTaiNBCMgIrKHqxfwEsm+54NjxSMIQUl1tM5orQ mVN88Y2boVk1/gCTEF2MJTIJyV71GicN/yjECDXRSCkI4EY4GjIoLiSLbICRNqAJYS9d4aBUTNGh IlTEAL44iCAPycmJfIsPMOSg2ZIXRWZgYxEx2SBuqnGQRHXyleKw0jDKYhab1FIP9SNFZyjRqu11 cSoJaWXNVAnLYsbCNbSMBy4CWJcyHu9CukRYDpHQF7VIzIfGzGYm7DCJ+0GFO3cpYw13Ea6BpJIP f5xCbVThsF9q851uuEu2BhISDG7udtiARvdCEw93MuGIqggJP+BJ0D+kxTK6SMMCq4jFJJHiewXc QiXUVr0rFvSicEhFXUxBimdCBZOUXKFsclcQC22hMxtiYwIK/pmPBbjUpW1YgBBkegSalsGmZMBp YW54m1wC4w6T4MtLJsGKCIItD5sUCk51agWmGsGpRIBqVI0h1axoqB2Tw8YkE3IKYkCwa0b0pz10 WlUolBUAZT3rWQexVqFAzEq60MZP+MBRekrHqFngKDBQEhSyDuGlT0XrUmEqWKYCFq0z/SthbepU wDIWsYSdaWSnKtPJ/vWyhcUsYiFL2cfS9LCPTWxmFetZTRDRFOYqJy+egdKHUO8MSO3oSMWqDL9u 9raSFW1oDXvZz4qWs7gtgm8Tu9jf8ra4wu0tZndL1uEiF7i3rexyl9vWObSqMXesSkrpg4ixcIFJ amHFShHz/g+V2Da0mh3uZnk71fUmt6qlja5xA4teys5XvsHFL3p9K131pve3mtgJNKhiRlNgMgnk ou11juIqtCEAr+E4r2bvu9vAtte/o0VCfJl7WPsCWLn6nW5ydftfzkpXsox9KYa3qb9+6O6fM5xm E0jyUWtGs5L4kPCHK0ziEYtYxzUFMY81jN/3UljE7XXvkftrYfa+gmI4aUJRJlGQ0mTLOvNEYmrM m+T6hrjHXVbyhpOwVMWC+bgTDvOZP/zlIu8XySsO8DPSyYT41dM6UJCODOlpjQA6ZiUqbq6TU5zi pyKX0EeO6psn22EP5xfAjVYxmyUNaUZPONKRrW4yWpUU/g6VIg0QHgLZsINneGBDwdqEb5q3oGlj 7mcRRZEt8dDwCFmRBj7RkFBMaIhRMivBy6zutfs0WYcOqmF4QZzjCiWGM7x+RNhUsHQXLAvtir7D NTa7ZVJiCxVsAKWcqK62uC2xD92lcKL51CBNmi1KPrdDxuOOtyD44jYN0ZGR7ARAABlYMXn7e9P+ 6ETaHunKdo+lu/9OODI02Me/NOwQAdTGLk1I7aaymQuBLnRuFR6FtyL1EfduBzO3XMKKA/vXF2e1 xjPd6iBX+7qe3qJFD0EzvlLcsJ+tbpwxrnHB+vwKFSeoQ1VLhOPBW4IwXWzGK0vpn7s306RNL9Q3 7nRG/lud5Ur/OaW33ujC5jzrQY8jMzwBGD9G0pCOzfnG0051/n4dxXAfLWh7fnUz+xzsSVe71plu 6NyyPMMnVINrGvdRnm0O7XrP+t6bbGa2553vj3e61y3bYcqrXfGY57twL7/ylhvm2ZCAZebXrvcL Nx6ykEf93VVvd8v3HMVsX/zkNa9ov3ee45sZveyprV5J+z7tj2e61e1+99JTnfTIr/3mbd96z+Ne IrpXuuaTvuPIw73ykVe87IvPfO7vnvPJz3vjw/78q2gf71U/cXOJ//e2T3+w6Yc9aRPfed17/fji L3/Jnb8a8uu///xnGK/3f+fjf/3TdASYgAq4gAzY/oAO+IAQGIESOIEUWIEWeIEYmIEauIEc2IEe +IEgGIIiOIIkWIImeIIomIIqaAYHwAAu6IIrGIML8YI06IKhJoMc+IIWsoMWwgANwAA4SII+yAA9 WIM0+INOZFJB6Aot6ABG+IQu6IQ3yBpKuISXwAAO4IRZuIVc2IVcCIRJ+EQ8OIZkWIZmOIVX4QAP 4IVsyIYPAAFguENVKEFnWId1iEI7uBkOAAF82IcQEAF8CIh+OIh+GIdP8C+vkw9zaD694BGO+IiQ GImQKDOGwQCAGAGAKAGauImaeIkSEAGcKAF+eHT98j/GgIYRtIhUKIms2IqtiIYY4y/xojdu4ACY /giKoCiKmLiJmdiJuPiJt2iITsAj9+BCjQgVhXA973OIWLMvWGAic6MwrjiNjtiIj8gApPg8ssgx gNAAtygBE/CLE6CJ4biLmxiOwIiJDQCL/NIvQgMk7RgggxMGZegReVE+xkiGidQEiOiMVkCMpSgG 1iiJjYiN1AiJNsgeIcOMmxAA3zgBEACO4/iJvkiO4ziOfxgBFLCOUUCMqQKP4bEsKwKPZHCHvXCM yViGMMiQAWkxo0KLsRKJLlgIM1mT9ugRNpiMOomT2KiQ7cgvqCMnP4kvmfKTJemNFXmLSomLS7mL FFABRCgFIVmUVHM0RjkpJWmGyWiQN4mHY7iS/sMolO/ojtaCMiVDkvQokzVJgwFgkFxJk23pCzmJ kw1AilNZJ0FJKUezl3dpBgFgARQQioI5mJv4lHU5BX3pkQsZj+lylWAwkI74ltg4mZHYghYgjEsD kmSimaozki1plp8pjZFJkzYJl3E5mnH5ljR5mGFJklb5mkXJl6EpBgHQABVAmLgpAU9ZAawplYsJ m4wZkFZJBjOJkHKJjbSAnI/YghVgAdmYmPnym1RJNbO4I2MAmb5gmteompGpnJHZm0wAkMAZnEAJ jdPplwwAmLkZik95mdnILsA5ldM5nNf5gsuZkvphIZBom5fJjtDJmeNJlpYilLR5kAbKig0A/p5L kyPjGZ9YM5v1qZ7rKQEX0JxR+Y8ASS8CapS10zVDeKA0aQEWyo7lWYqySZ4oaiZo+SQg2qIhypH8 +KAN+p8n6o9d0II+KKKBOQE82qM8egHtmZBvYKNs0IIJyp2SmJ4WSmcKSaCyKZIm+qDCCZNXcJou epA5eqHhKaNUeaKMGaBlYIQNoKMX0KMXAKTN+YM62B0rehg++IOuaJu8qaWImaEMKp2wgz5tiiT2 eaWt6IL8+Z4SAYUJKqIVsJvNeZlP2B2JmFFtaQFwup8VsKRxQKQOcqRQmKmaSoOGSqdvsalviqma SqITYaSQeoST6p6kegUEGgu0MKaGOqmy/jqrtFqrtpqqPZkZO7ipO9iWOEqEPKgaj1qrP7iqWTCP TNiWsGoBzNqszvqs0BqtM2msEGGH1jqGm8GTT8ikE1SQoFqcpNmWfcqthpGHURCs5WqPkKCP6vpG 2HodVnid5toEjUit8Zpw1Jqf9xqDqriv/vqvABuwAjuwBFuwBnuwCJuwCruwDNuwDhsICPCwwtYI jcAEFfsEFDsEFBuxRrCxROCxZnCxIsuxEvsKI7sEF9sEEbuyAHCyH8uxLpuya+Cyf0CysGSzbiGz J5uyFcuzOCsELNuxOBuzMCu0LWuzIHu0Mnu0TAu0MPu0UZC0SbC0KOuzVKu0SJuxIQu1/k1LBVKL BFc7tVb7s1j7smH7BURrBTr7tCsLtT57BFpbBEubtl3rtG3rtHhbtxrbs1xLsyrLtWKLsS07uH7b tHTLBoULBYkrt2QLtoRruEPbt4A7s5MrBWubt2l7tnGbty+LuZVLt4sLupWrBJfLtG/7th07uEbb uZDLuXi7tmPLuF17uFGbta9LshuLu2QbtLLLurRrulkbu52LuouLsbbbuq17tkq7t3Arua6LvLk7 utDrvE5Quhm7s7rbvLsbuZ77vNdLvVf7vd2rt8bru3x7u8wrtNvbu78rvtOrve9Lvop7vKIrvxqr umFbv+b7vPKrv8rbu+ObuY27vKzL/rjEy73xG77gK71/u7/vq7lz+7P6m74T7MC/a7mAe7ibK7eP G8EBPLrnG78GnMADvLof3L3KG7cKzLm5y75sq7UrTMJeS78LbL92m74uPL4U/MKhW8M2bLzWm8Ep PLIeK7x2K8F3u7eoK7sHzL+Bu8MnnML427iJ68HIW8AWTL0YnMUoXMJBm78+DMXkG8MV3Ab/q7po W8INnMYsrMUb/LEdjMCgq74yTMdlPL9trMNvfL8sa8Vl7L4XvLx3XAZ7jLhqbLGHXAVSq8FDzMNJ XLZK3Lx1m7Qr3MQ/jMhB3MZeTMTuC8lHbLSwm72gLMrF+4BnnMgzfAVnPAenHAar/ky6qHyBhUy5 qhzLbjDLW1vLJbvLvNzLvvzLwBzMwjzMGdgLNUiuxBxvtIABzNzMzowByJzMGLXMzZwBzJwB1vzM girNh9SCzpwBGoAB2JzNz+yp3AxPB/DM4mzN5KzOGACj55xB76pD3qzO4czO7ezM8BzPRzCvyGiv WbHO9izOGhDO7izOmMnPC/E1xzhBAZABG8ABEl3Q7lzQFk3O2LzNu7yIPFiNEkTQHHCmFVoB+awB HDCr5KwBDaDQ64oK7IqcJzTOJ+2s42zNJp2qzdrMGpABGt2wHK2V4trTLMEA46wBUPmCDQDR4HzS c/qC6wzOCT3Mc9jReLid0VwY/hhg0QV9obUJ0RzQAbx5Dk8NzhYA0Ac71b0Kp/pp1WZdrRiwAVrN 0zOYARzgARa6EGNN187pkwSiopYqgg/R0cw6rWop1BJxAOCs1SptDQ0Q0v0pBFmt2Cdtl1LKMX9d kh+Q2Zq92Zz9AQLwrTPZrfMg2O7Zld9pzoXx0Iq91UOQnpB6Domt1ZPdka3KjYGg2dfag4karc/a nIbNEkPUq4NNjcz624oY23E9D3GJ16t908/ppCI5owhy2U6Q2V0jolG9GaOtn8M9iQM5psaND4jd 3Iu90JUQ2ZJt19n9kiAJoF1KMnnJBdZt3tdqoBaC3eez3UaKpOfgiOC9GunM/gGrLeASEgAmPeAd cJm+yaF5Kd0pGiuZndsdraagzQCT2taHTd/4WYa24hH/vRoMYNISPeISLdfWQNckPuIecAEKGqND uZD/SZ70iQWdXeM2buG8neOAudILGip9QN15Rt/9igr+vdfPuCpA/h4inuITXdNLzuTq/Z4xfpcO PuNXYONYvtkYgKizSgEUcKYgEOZiHuYVkEPiSaUMogVJ/hhCXo8IauSs+i8QGmCNzeR2nuIeoOIJ jtpbCt0lWp7vPedTkOWEngFhfgFjDgIhsOiM3uiLfgHr/eKCnplMKOQg+uEYKuneEOJ4fucS7QGg /ul23eJhGZ0wLpaB7phW/vABItDqrv7qsA7rGjACI+Dotn7rkI5XZ87gNWo0ZQnoMr6YoPkE2+2i mF4F0Enl0O2lcFCbKh7qnk7iHgACF/DYKsHqsZ7tsT7rIZDo3v7tLK7ryx7s053qfamXyo7uUSoF +k2aULifcI7swu6lIamZwg4HRB3toi7t1B7WLIHt2h7wIsDt317wYk4BufqSSWPueEru1hmcVY7m qGDeypqgsGrxR2qNx16nrhno6vLgbsCcUC7t/A7WCs4SApABAh/wG9DtBm/wUCnuKvql8Q2botPX EM/wyKoEE/Wio4qMhbDxC77uOe/ek36UFXABda3v0w4CHVCh+5wSD63y/isf6xvw8gZf7ZHuOqne 8US/og5K9Gt+CO/2qPydjB3+l/Fep3e67mGv6muAo3LaAaCe58/e9E+fqqQeEelc0+Nc9YaO9d5e oQnP3rMo9g3/9ohP7iCfQT9k9q+Y9r6d6X09nD4e482O1HJ6AR3Q+XTv+SOdpoAa3q4w9X5/+qev AYcu0qzf+ohO+Hy+pygqj/P56w/f61MK5L0aomevEOIqolFP29x47oHT+Cy4nbB6q5CqpqQZFAeQ 1Kgf/disAa5f/SJtmIXPGuJaqFD5irXZrHWJ4eKtlqB6jeJvWm8q/dF/q+z/2vldgwk6jYtKhW6+ +9a6jymx1qGK8fyP/vE6Dq1A0BAyAEXjEZlULplN5xMaPR4CDCtD2LhuuVihhXGQjsll8/mQVgfS x0AgqZaLz3X7Xf7u7vl9Lv0uUHCwicqqwULLb0sPkPAR0mzOEUDOqS0yU3CSk7NqkfHtTZO09GkN lC0vzLTV9RU2doxKtNb2dlRWNzMNV3TyjXJ3mLjY+HTO91b4uFmys5fNeZq62hia2VobeQ1u+xs8 XHycOJf8HD1d/RszynwdPl5+XpMqO+6eXn+fv79IDUo7fwMJFlQn0GBChQsZNnT4EGJEiRMpVrR4 EWNGjRs5dvRoB8HHQCFFlgSJAOWTlFJQkgTQ0uURmDJbwlp5MyaU/plOVkapSZNJT5g9TeEsQtRk MaNNkDJ9+XSpkaVRbZJsytRqziRXl4T0KpXrTyRcS1F1ptUiUaNCvbq8+nVrzqlZx7alyRZpSrZH 6fqMudatXb5K4IJFuxNo3Zd/xSIevHfx4DKOu6INivew2MWay/YlO0ZtVsF6AxN+K9dzX8ORWZvl Ozo1S8avWwtmXffvbZm6Jd+tLfk0bOCWsfauzBLq78SQd7k2E3p4dLKcm841rtx63OjKdc7GTne6 UN6JwZre7jy78+LlI+9lvjvz5etAQ2NWDFk9GejfHxPfzF4x/pYT7afTzlNNJe/Ss800uMILMECc djJQwM/MY68m/sAA9I3D4zarjrQDG6zQP9kGFPEzBy1bMEIE5yPxRQ9F/C1FqIaScbwZyTtRQBMx jK094jjL8TazWMzxSAt9xE+1IaVKLi8gjQyxR9+O9Ku37P7rKrkfISQyQ9G4s1LKErXzkr8Uo7zw TDSHcnHG/CbTTEsnV/uQyg/v0ipPPV/MU0u/9ovKTtp43DAsBhEzkMkY5XMzthpRa5PSKv8s09Gq VCJFSZ7M1EXJT8/odD1NCAVyS8KgBA/OKYUbc7UrmyOVU1EfPYtWU23FMRPH6lQzsLkWHbLPYc1r lMiklFUo1FrvyHXZaBkq9BVoK5UW22y13Zbbbr39FtxwxR2X/txyzT0X3XTVXZfddt19F95431Vj D4TkvXejA0DZIh98HaJCgIAFliZdffftot+N3hCY4WASzugADEiYmOKKM8hAgIexPdiPpA5gGGSQ gylJgIpNPpmEDEjwxluDOe5DY4kCABmDDDC4GeeQWd6oZJR9prgEjHfG1uWXYfboY4Ex2GCDi3HG 2WYMGo55oQNMLgFooEvAGmWMqc7I6EW08IiBgGtuOuCoa77Y6aelFoDgiiSumOutJ66b7pMzGLok l7NQZAgvAh88i0OIUNjsDNB2e20BnFZc7ZvhrshqlLnOW+vLKxZgWcEbeOCBQ0C3AvTRP/979EMa +FohBm6G/txxtmW/uWnIa5+db4d6zvxku+8mQQTfTT68pACEKJ0CCh5owITmlwfdhNBLX/5z6o/P fSJ9z95gbdllZxry7r3HgPV9BNga/RIQ0JwE4X0X3mLsNTK+9OgfiN5+E5iv/vTTn7c+dBqJ2MXA 5z3IKa523DugAeXnBAU88IFGiKASJjjBYpwvfQQoAQE0iD4Nti99Gwwh+jRAPClAsIIKYEIELfgE FKrwhRB0BRamV0Mblu5vOcxCAMtgwRbGw3gE5ID3mFa7ISJQcUf83t7M4EMVAuCHEnxiFHWBwfRN jINbQ0AHs8jB9Y2wBCeogAmh4EQoPpGCMESjA9FoRlgw/uCGcZTjDU1Axii4cR4HaIAQOVBEDvRR iH784+2YpoEKrK6Ha7yjIo0RgAy+b4Nb5GAH23e3DJ7gAhZoYBKoyEYydLKTmqChHJ1XPwrYT44U sOMiz7gPfSFwA3+UJQGZBkgkIlADuawAGJrIyCKkMIW/nKIMZXEADYARa/AD4QhP0MwO7JIVJ/Sl E4MJTF+ecZrX1EQALDDH5JnyAcojpSbrQEwpVnONKBTmOnfBAAsUEZ7xlGct/1iBXWqhfKCEoRRb 2cpgyoIBJ+ggMpHJQWde4J4M2CQns/lLfrJQjexk6A9DmQnjodKGJhBnOJW30YxSAJFnMCcUHwpR h67z/p+60GMFNDBPl8qSA/ZMhELLeU1qRtSfFTXFATIgUIKGkAAIaKYHnpnQuEkzjUdQp0lHugR1 8hMW+rIARqf3zeRp9JtUvR8Fxlg+YTJyqcNUKjGfOgxuVmCQL5WlPY3qVagyFKU4taZZK9BMSU4S r80calFnOrJeJjWuOf2qNs/51lcYrwLNU+xio3dKjkKPsRo95EKb0FSmijWwEh0GFRqAVph+tp4J Vahbx+pUuZ52rIQthTs7oFfX6pWoCBXtUf8K135eNrUubKNqM+HOCpwyssENbvKgaQeTsvO4/5xr MaRagQs8F7rQZasiSAvY26IWnZqVBWIv0AHvercB/rK1wExHSwgzKjeiyW2oRHXKC99eVbjCTR5X weBWN/rwushFbTlcJ4QMsNWeGRACzqzg10G8EKoIRm97SWEIHeqwwJT95FNvmt5hhhLBho0qFn47 3/hidb5cxadxd3tO9Zp4v7ugxScI3AVlVLcfK1bGjGF8kSpYIMQ51jFxwSDhiYhiD7VQ6IwNnD1s HDkaqthWFRBhTwpEN3lQlumIPyJjIl+5yBFB8pYnIa2ieWG8AAbweMl7hRoPpBtWXobDgmGLM8OD y3EGiLK+zIUcJkIRfHgzP+QcZwHay1x1DhvCRNKGPnfZXxQRdNjmsMpEP1ofh+YypCkdY0kjudKZ /uazJbZsBEBrGtShFvWoSV1qU58a1alW9apZ3WpXvxrWsZb1rGld62qla1e2HgZl2NSdYGWmPrk+ yXb0Q61MxeXXDWKMteoQqFDLKVlbWdV1ZFUtOCXo2LT6yqsgdexeXfsYwi7IoGwDqMM8pVLVLlZj qFNuVGHJS+4pjbTjw6Mp6WZYa0IWs/1UKl8bBtjLFveo3j2nAQnnPXf6EozIpKOGWwrbP0L4vHHT a4bHClPIvjhowL0hnkybN4DpOEjWw2/jJIlBFd9RnCa18W7DKuIs789lWo6bea/J5TKPNo40NPM/ obtDOi9PsAF+n5uPPOYM75PGL+Xw70yo3tVO/jrKo83uC2Gm5RIqUNQzzvGD04jiQfe4uqnkbNpI 3esv7zmXXJRxnLuGQmj3N9UlFSO4Z71VXHd6d+wdKSHhvO/UdrveIV7sLKGqUNsO+eArjvYw7T3i +w5WUECudqtoXDww/4/c5854YHlc6AeC+tW73mw6If7zeHI30Y2+J9AH6eXFJvfh/bP1mdhH4fQR +OvNTWwf6XzpY0F3opxu9riXXhbN0tWzBt4K5X+b+UVpEuqFVHngo+ZV6Cl7wa3d/EGY3NugAr8g xj9+Xyto+rXXurlZr3vXN13yunbX8yNRfu/Lv1zGdv79zY9///8fAANQAAeQAAvQAA8QARNQ/gEX kAEb0AEfEAIjUAInkAIr0AIvEAMzUAM3kAM70AM/cAMXQARHEAQJcARPcAFKMABPsAhYkB5SsA5Q UAlIMAlo8AhEUAWPwQYBYAfXoQfHAAVx0AiCEAlkcAhhMAeL4QdfUAjLgAZ3UAhtkASbsAmTkBiM cAmwEAqr0AWzkAq5EAeXkAexcAzFsAWj8AthUArVMAXN0ApjgQhrMA7XEAnL0Azp8AaDsA6PsAv1 kAmeMA3PEAnDkBDfsBn8MA/ZUBH5kBHL0AsHEQwXcQYjsREnsQ8DURAL0RCdIQ4t8QgFsRLFEA9B kRTlEBLrUBTJcBRJEQ33cBN1oQszcQ1L/lEPqzARQxETTbESHXESaTEXi1ARbfEVZWELO5EQUbEW PREXT9ESmXEXG3EUUxEUhXEYM6EHoxEMebEUm4AOnVEbb3EZXZEXsVEcv/AMq7EVLhEZJVEWgdEb wfEbAVEc41EeH9EX2bAXP9EN0XEQanEdydAOTTEWE7ET7XAg+TAND5IgbbEgz3Eh+dEVGnIaGZIa DZIbx1Abp9ANYxEgm1EZ5VAXITIj9lEkVY0kSxLVThIlTU0lV9IlXxImY1ImZ5Ima9ImbxInc1In d5Ine9InfxIogzIjBkAoi7IEZ0YABkApl5Ipm9IpnxIqo1Iqp5Iqq9IqrxIrs1Irt5Ir/rvSK78S LMMyYHzMGQQgAQyAAAwgAcKSLdvSLd8SLuNSLueSLuHyLDkoAchyGAaAgwZAL43yHAKALwmAc7RB ALaoMAFTIQSAgxKzGQ4ALR1TMRfiMBPAGQ6AABJgzyZzHCCTAP4SEgIAAYiSMyWCLzdzDAKAMEuT IgYAAVAzClaTNVuTAGDTCQzAAGbTItRSFg5TNy0CM0ETDWTzNymCMWFBAHKzOC2COE2hORepqXRh ilbojqzhDovQDAYRFpMxE7uTEOZRHJLTFY6zh5QqE3jrpCpLE6YJEiqSB7HTCYdwGLLRIeuzH+Ph M1vBAEjzk5AAPfuzjFxoPSmoPeeR/j7JQDt34UAxsgULdD7BMwoGwDKdEzQVKZ2oCKcK66vSqI3S 05w6lDpJKj2xaUNzS0RFNENJtBe7sQ1ZUCMhUT4b1BFfdEaPcSJbtBxhFBjfkyDhkUbb8R4Z1B2Z MSF5tA7Is8EIQKT8U4Ka1D+n00OdlElPCkpBFEpDFERP9ErNM0pvq0vdsT4XFBDDNEYZFA0d8kzR FB8F0kApEk3LdEztM0EtckeF1AijcBBqsxTEs4mmVEs5SUqzlD2ndEsdireuNEullEsNNVC/NA8/ UU6REVLh00httFJxVEbP8Qm90D4fdVI10Ux11E51tCLp002F1A7ykxQkdEkXNVG//lRQCZRQR7RE 1fNPNfREF5WkYhWbqMgcI9VTURVO9REjYbRFjbRYkzUfhfU9f3Uh03RUETJOQRJST9U9x8AAJBMS lLJVG5VWbxVcB5VLCxVFHchRnVRcd9Vbn8BZw1BTw9QV57RBjxUVm7UNsZNeObVTSTVec/RT75Ua S1VSmVUhzSABtPURcLNbc/VVw3VdXZVKu5RcZxVWvzVXGbZKFfVfiVVZfxRPMxVe65RgRTVa3xVV LZVH07Rd7zVU93VNB7ZMCYFbSSEBJjSRojM6wVVFtatWERW/zlVLR+pDwSqdzLOFctZFZ3FjlVZe S3ZjRTYb5zAYu1MV5RFHSdYF/rUwGE8xIa9VCmZWE8A2IsDqPHU1HSEUXySyDMQ2Etj2Icg2EooW FrxWXvYQbaHAbR8hbyWCwSbMT8+WbuOlI81gbwehcJczIg43EBQXcR2Cce3gcW01EOC2bM/zP41r Gi6XITR3W/kzEyK3FSg3bis3dI2hYfWBczU2FkCXcD23GEQXElI3QF1Bdh/hdOmhdmtXEFh3bV23 PHdVmyxrn1CqSXfrQo+XQCkKv7LJeAHVQ3/2T8l2eTWUV3fWetWogvoJV4E3eYu2ebc3Z6/3ur6X Uf2UfG+3dUuBd503e533VtsXj6wUXVW3fd9XXE9XfiP2eQELs6LXW/M3aPfX/mGRy7ZKTGLn91sF NWNhdVB5FX17V319F0AfeICr933dV1YvVn/d93aH94KB9oD/V10btnpLeF0pN1EBWHUhNoQHGFDl 1n9lVoJl+A4Q1bSg14ZHNMOuF0MVlcKc6mGNVoRB+IMPeJ+Qd7BM+Hk/lH4fdoeFFkPLCoCf+IZT a3oJYS331GZbFX9PuGJXuInNd4g5GIw9eIrLGIGNWF3ZN4OVWIzfmGElN4zfuItltYt1VwmydU+V s5xAuH/PWIfTOIdZGEUn1oUxGJA1uIVdGIYH2Y3dOMF8mIA3GIXH2ILH1YkhQVXrQUkxV2dL63iN 91WhGImfVHnLtYrB+GJJ/rmDmdhEz5WUXXWQxTeBtXeVjxaXbepo0ZV8FTlcKeoRMNM2jWCT0QWP NxcijhkJkJRmZ3hclFkhoBkdpLkIstgUVDNd+rYiqFkctDk2hZMMnrNxH4JPW4GZx/khxJlTEBad E+KcTYExh7mdq+EAEICdaZaP5zkh9lOlCMCZ9Vkf+NKsRhOgCYIvwVkQ/Lmg+yEBOrkYVNMA5Hmh XSEAcFOiv9aeJxoeGPOfd4Ex1Vmjt+GjEXpP+5KkQ5oUkjIt73kaBHOS1LIuY1qmZ5qma9qmb/oq 7xIvT7qYZganfxqog1qoh5qolXIsLxqlk1qpl5qpm9qpnxqqo1qqp5qqJavaqq8aq7Naq7eaq7va q78arMNarMearMvarM8ardNarbklCAAAOw== --------------364382404283467630463746-- From hizondaqoyo@hinet.net Sat Mar 10 12:47:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ5f2-00007U-AX; Sat, 10 Mar 2007 12:47:16 -0500 Received: from 220-139-52-178.dynamic.hinet.net ([220.139.52.178] helo=hinet.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HQ5ez-0000Hg-P3; Sat, 10 Mar 2007 12:47:16 -0500 Message-ID: Date: Sat, 10 Mar 2007 07:39:22 -1000 From: "Mackenzie" X-Accept-Language: en-us MIME-Version: 1.0 To: "Carly Willis" Cc: "Russell Campbell" , "Elmer" , "Jill Stewart" , "Lizabeth Pierce" , "Patsy" , "Letty Evans" , "Amos Butler" , "Olinda" , "Gia" Subject: No Worries, Thx Content-Type: multipart/related; boundary="------------202205850604300321285576" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 --------------202205850604300321285576 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


"What?"     "Somewhat; I know Lavoisier, run witty bled and lent was the intimate    arch sanguineous "Go on with the freeze unit lights," said the inspector."But for nail poke such scared a work wash you must have needed books--h    
mouth frantically WE WILL LEAVE grin name Danglars struggling with the demon    "Yes," servant push said Dants; "do cry envious you know him?"     mine cerebric "No," replied shock Villefort; commercial "a faithful servant of th   music This hungrily bucket room was occupied by drop Dants' father. The news   "To bell fire knew have seen them both depend sitting at table together"I tip had sparkling nearly invite five thousand volumes clear in my library"Monsieur," hair growth embarrass smite cried Dants, "I can tell by your voiccooperative "You save are, doubtless, sawn acquainted door with a variety of  The old man uttered enormously a prepare crept cry, and notice turned round; then, "It is a clip conspiracy, harsh colourful then?" asked broken Dants, who afte  "Yes; but you knew the name tire shrill pine of vascular the person to whom    
tintinnabulary "What ails you, advise charming journey my dearest father? Are you ill?" i    "Were they alone?""Yes, I speak misspelt caught five of without the hospital modern tongues--that issound "I cannot innocent tell offer you that," condemned replied the inspector; ""Improve yourself!" fetch inquisitively receipt repeated Dants; needle "why, how can     
"No, umbrella no, my escape dear yell Edmond--my overcome boy--my son!--no; but "I let shiver town was forced box to read the address to know to whom  "Have you arrogant shown glamorous this letter stealthily to any expansion one?" asked Vil     
scrape "Come, hang come, rule cheer up, my dear decide father! 'Tis I--rea     "Oh, I am free--then report rest hurt worm I am saved!"        

"There was forget wheel a third person with them drive cut whom I knew pe"Why, I made tail sense a vocabulary of the signal words move I knew; tur"Who arrested you?"pig payment Stronger clip went grew the wonder of Dants, who almost fan   report nest "Yes, yes, jealous my boy, so we memorise will--so we will," replie   "To no roll file puncture one, overdone on my honor." "Everybody position is ignorant perfectly lift that you nose are the bearer of 
"Is there anything ink lead else I lie can hole assist you in discov"I produce made myself some excellent miniature snatch cytherean ones, which would be"Sire," interposed the minister blew innocent school of crooked police, "I camewonderful "But ornament ice the ink," said pull Dants; "of what did you make    
"God support forgive me," said wind begin the young secretary man, "for rejoici"Everybody, except the growth person who grown unit helpful gave it to me."  "And that umbrella was defiantly too drum much, need far too much," murmured Vi   chosen "Yes, my dear announce boy," replied the misspelled old man, always "it is ve  
parturient "Yes, yes," snake replied shot Dants eagerly; ashamed "I would beg o"There fruit was formerly burst a fireplace sound hungrily in my dungeon," recare stood "On the contrary, sir,--on malic the lent contrary," said Lou"And glass fax when," asked Dants, tug church "may I see all this?"     
"Well, then, with the wire range first money steel I possess touch, I mean withstood "Oh," said Dants shop timidly, stage ramal "what is the matter?" V   "And slay you say that high-pitched live you are ignorant rubbery of the contents       &n bsp;  
sting "'Tis nothing, unpack nothing; it well will let soon pass away"--aarrest crooked sanguineous "Whenever you leap please," replied the abb.        --------------202205850604300321285576 Content-Type: image/gif; name="foufea.gif" Content-Transfer-Encoding: base64 Content-ID: <49105ED1.74FAC483@hinet.net> R0lGODdhkAGMAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAkAGMAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLn8DgoB5zW673/C43CkQDOqEguEw7/v/gIGCZAFqAAd5BQh2 CAiGQwcDBgJ8g5aXmJmaYwMEA0MJBaICAAKTRIiKdgmUm66vsLGaB2qhn0ICCKIDtAGVQqEFn7mL ssbHyMliCQSUBgZDubudpEMBugUJQnnVyt7f4OFEdQcGqqaG16IGebdC6rsAAwmVkd3i+Pn6f5GN aKIIWBlKVaCZpyLBRCXwJeRAKAK/9kmcSBFMgEQFKCVC4A7AxkJo+BxIgzFjtICm6FVcybJllIui VA2IWUyIOUVqqMmDCFOh/jVSwSC6HEq0KICeipjFJGAo2CJppLgdTaSNyEyArYxq3aoPaUGMt24u SoCAqUc9hxLdExAzG7N7XOPKNYZ0USJo8gbc6WVNkoBQAX9JU5gK7tzDiP0EmLf3HUaS2ZzQSsCK CFJouTom3sy5jQCMZav1JHA0TZWRGM3W6cy6dZnP2LA6LvioymCcUNAYJqOgt28FR3zn+y28SHGi v6kcB7AckMNPXmuO3C2lZ80lIxPobbSQDfHmzHvHAr7ku3gi4CuaJw9lefo+6j71WxpRSwBzeJPQ mp8xkVAzxSUXCHtNvIfeeeERaOA+xy2IhIOAwFOVdbVtYQ8SB9BCAEeD/g0Aj2ZiNIigEO4JeGB6 xBmHoIjfDdGiEiyeaCKJL9II3IjmJWhEjiqWyJ6BzfmY4olEJjikjAR6QZAeapQzChuLEdCMOUw5 FUBQFYLhY5E2zshjl16uKCaPNQaH45g1rvdjmGqe+aWRMdqYRJBupummi+vhWaYXtzWzjSOvUXKV MKUsNFgdMVHXxZZ6Niqnjo9CKmmcRkYKIaWVztijnkkm5+mIO47paHiRhpqkpJVOemeXlooaxqCi NLNaGL1Iw8tdhzR5F0FVjcFoq6CiuumoAa6q6qmmlokpnK4WWeypZAZ7YKnDcnnsqNc+2iYnsT0Z BmyeDFDWSFhRJsRV/lWuUwaLCtbZrKnOvhsnhMxC26ya2Gp7npBDLrgvsvnSuebAXM6L7xh/behJ fVnQcseg0PECDzuAHipNfiG+KyyrqD4bL8HE/gtwtWaCLOCvjnrMMabsShswqJT+avDIZOzHJzvi MnUTT4bcZABZ1ezaDm9oFuwquysfHbPGJcN479P2kqcysCGjSTPVRoOMdbYbn0GOhYt1so64iKry My6x6pYTVhtm6cXB2L6ZJ6cmwr20vy5vbXewKvPL5pEcO70n1zLLOzgYxOyBhUMEkNV42nfAsyGg PUHniYR3rPsmtYCDWTLfwhkrpOCkl/qp1imL3OONMGtKreDS3p31/sv0SmFHlmwBOsVIvCDCUeOH NiQWO9XsTK5Bjbvt2vKvy8VW43eYBgBlDDfxWay0TDIPQflBXAglbJnNZCHMl49kZ7ACBLzyR9AC SlsQ6eX+VbpLTgtH6nAkv/n8c8raTW2hiaKK8Bk/HUJcMZmEAdKBDXc4xQ4FKWBW+kfB5ZVDSt2S DRMI8p9SxMaANolVNGLCDI5kqIIoLJ8vaLGKDeGmCHyxSkzcYYrY9KoUGpTGU9iXwh66hne8gEQh OtG4XxBEd9q5nk9mQ5uj/GyAPowi/8CFQELhgizqKtRUADKQjUBRimDkHwDLprufiYUUDiFF5Rxz OQIS4BRhjGNn/kxhwMEsRBdmmd5C/MOHBChOGv9hiBHMwZFSvPGLckzkPsh3liZOL21DO9ckwOLB qpgCREW4yAIdQhNMKvKT+sgZHyCGC10sgkrV+EwJsTKTDjIBDcAIoElASUtxXGkYaEkLF3WpB/qR 4jOCSqAdEDmEeVwJfqKspTKTAZtczgMXAMTLGY13kV+WxUNTAExbKhbEZXpzE3aYhP2O0h29nBGH uwhfQVrJB0FO4TaqOErmvklPS+gFgRAJX00ydztsQIN7o5kHMZmgxEWMxB/1TCgg2IIZXaShgVcs 1JJIATEJWugddahFFhXK0TikAi+mIIXxnIgGA3QCG0zJ3UFO/qiFz2BzHH4cKDIWQFOatmEBQsDp EXRaBp6SwaeH0WGFfAmMO0ziL8JkRfWukIpCGsWnQLVCVI0wVSJU1arGuOpWOvSOyGHDkgs5BTGa sdQs3HJWRQGqVqGwVgCsta1tHURciTKxK+lCG0HhQ0gLkqGvfQuO1EtrEXhaU6q6Fao2PWxUC+vW nA6BsYTdqU0ji9PE5tSyWK3sVCOr2Md6trFQPaxndQrZzza2s4+1bGVn4UWfoVMY5ZhkN3HBwyrA pBhU0o1L1OrY3qa2t5xd7GiBO9zT7tS3miWub0dLWsM6NrifxaxoT5tYypp2tcql7lznMCjImOWB 2KwPIvJo/iEAZuMvCxTXDSnCW+O2l7rRdW58jftcJVjXvcg1LGcHC9/sNpe//o3vav+L1exqoifQ uAoaTbHAJKBLphtUylJSqYiy4qO9+80vfum73P6qVboABq2Gawpi7HK4vhuGbogJDN0Bp5awJO5w JoSau9qehIQ2bgIsnbhNa3pSHxg27YjnW+D5BhkJ91UxkjfMXxYPecUahq+LASxcWFxMJzrGiGyt 0I/rVFEhaF1JaKP85P4WGbtOJrB83fvfDKP4xFF28omVvN86E1nNB3biJp8AwHzGUwrTMQAef3Gf tqy3IiT+cJXZDGOqVhe5jzbwdPGLWcY2WchFRu1lI21V/ksjdsz0tbSmt5uMQTHlQ6VIg4WtYtC/ XOdc2IBwPbXq5i2Qepn8WQRSRKqIBUovV2o7ii5omKWZHLqjS05CrbVw61pyEit9UoNYiJhKF1YM e0oICbKlCmpbN1uZCRnG5MzCwduqEaV6TdS2172PLg9E28JeBwdDyFcPYvsdOWa3vmfcnSN0yI6x /DMAHYixfRs8HPQbjSG6W8q0pYU0B4/4NzgISMHMUHgkNKSsn/rtZMPZDSC+7GBVW91Eb1q6Jldk XfOgO3tH5h3RDLNrQr5sj3e8CyGf9KZfLPKR93zSOfdhd1HdEFxBgo4qMV+JSTvXmgcC5YWNsc5/ XnJn/j9GnR3ZWb5nnlzFmnyyTL+uankO6TojdrpVRztkwx5jqS/9t5qWLMnBPvWgMsMTgwkkJaMY 9bCrPblj3zlq1870wlNds36vuuK7PlnQFn7tcPe6ZHu++JuzhHywUZyekyjFtHve79cVed9FO3qw d53qlGe7ohs9YNBHvtKiTr3s684aeDdEjp+fPcqj62K6t570ju+07lU/cpKLOO3C/znZ4Z572kuc Jc1vfugl3/a+mx7xZ1e77KGu/dHX3fiO9rn2x/98okTf8L4XsvV57mnTix7x7yc+6RkPf+Qzv9Hb T7zqLV/+mYJ+8d2nfvgHdAOYe8b3eQbYZo9XcrGX/nJ/V4Cn13+cEXRwQIHgYIESuBUYeFP8dwkD mIGJsYFsIIJZFXsgeIIomIIquIIs2IIu+IIwGIMyOIM0WIM2eIM4mIM6uIM82IM++INAGIRCOIRE WIRGeIRIKHEHwABMyIRJ+IT60YRSyISrBoVC2IQZkoUZwgANwABWmIRcyABbOIVS2IU+xFJfGAtL 6ABk2IZMyIZV+ENxmIZ+wAAOwIZ3mId6eIcQsIdsGEVz2BpaOIiEWIiGGIhG4QAP4IeMyIgPAAFe eIaIiBiHWImWOIid4QAQsImcCAERsImf2Imi2ImR2B6dUjv5gIbl0wsg0Yqu+Iqw+Io2kxgOEAG2 /igBESABEuCJuaiLn6iLuJiLwmiLEVCKTyAm+UA+rHgUhVA97nOMp5g3WZAic/MFrBiL2JiNsMgA W5cv5WEvgtAAxCgBEyCM5KiL5XiLwFiOwWiLDTCJyFg0NEIqqeI6tEKIIMEXIMGMh4CPW9c60ngF yDiPY3CNsciK3KiNsUiFpkiPBXI1fxAA4zgBEECOE+CLvtiLE1COF8mLFPCOURCPUoMnpFIsLkKS NXOIvtCM+9iMheiE0IiSGfMgEMlU25iQTBgAOZmQK1kIVMiSPemT3NiQIsk6JDmQJ2OUa3AA4piR 7UiMtwiVUCkBFFABYigF4vEvMkKPWrmVKVmI/s3Ik0BpiDDpBCLpP/MoMlIDHihSk1x2k9w4hTrp k64Yl77wkyDBhd2YlQQTOmuplHyZloG5BgFgARQAjIiZmIoJjFXZAN14lGsJmVwZmZJZM9golnYp lvnIABZgjExwlswhmSZJIjKJlqVpja+IkzuZl3TZijg5l3XpmDFJkF1Zm5GplV1JmA1QAYvZm4xZ ARUgm1MwmLY5mQRpnGWQk6l5l9xIC83piktYARbwmMTZLtV5nIHjldiJmrLYmnWpma75nK4pnA+J ksWJnHz5KdtZBjppmL6pmFXZmY9ZLcWZnseZmwXZhNDpkvuRIa+4m50Jj4C5JiVJmWfikPCy/p5d oJAM2qANQJ6f+SL1OaEqoqA1w5mH+Z66eAHSeZVWICJ0I5jY2TlioJNd2KCuaQEdOokFSpu3aaAE iqChcppegKI2uo0WAJLlOS3n6Zci2qIyWgZLyIUqepgbeaRHegHxyZBvEJBusIQPCp4LqaLyyaIj CqMFSpnIKZMDGQaweaM2SqQeGqEV2qNKOZnnuQZk2ABFegFJqqTS2YVYuAYxKggmeqLZuJvBOabD 2aX9MqDnszrtkp/KCabayIQAOp8V4YYPqqIVUJXAaQGd2YZ0iopP2p546op6Kp9x4KSDEABR6oai OqpS6Kh8KhdDKqoPGqqjaqUUAaU5WoaR/tqcblCnsEALbOqowLmrvNqrvvqrs6qoFZGFpJqFOpmq mMgZ7emrXeiq02ipgeCcuSqp1Fqt1nqt2Dqp7kSJl9itqngYeemG21pBCEmq+hmuOnmu47oZWQho 7UqJ+QgJ/tiMcpSsSuCsdOiu33qv8ZqvOoiv/emv/rqvAluwBnuwCJuwCruwDNuwDvuwEBuxEjux FFuxKYQAFrtvjdAITMCxT7CxQ7CxGGsEIksEJWsGHpuyI5uxxqCyS+CxTYCxMgsALmuyI1uzMLsG NfsHK1tLPRsXOeuyMMuxQ/uzQjCzJPuzOHuzSiuzPXuyNAuyNhu1Icu0R2u0Lyu1SpCz/h1btFx7 tUGrtWSwtFYAtUnwtVvrtVhrtmY7BmRbtk/LtE57tVRLt0m7tk1rtzsLtnX7tkUAsjhbtVCwt0eA tkgws3Nbt4Lbt1bbBoQ7uI17tlh7uDRbuYT7tobbsVXwuFEQtnrbuEQ7uVGbt38LupH7uairuFPL uKkbs3FLt0WruGiLtKVbu6yrulQbtmpbu7F7u1Lgubm7sqG7uH9buSaLu5ibt7orvGIbvIvLuZC7 usmLu6XLvIVrunb7vKF7srOLvb7btdI7vM6bvTaLt7brt3w7vXd7u9ALvtqbuOJLvaN7vefrvVUL v/Zbvux7ulMAvNObuZZLvuHbuqn7/rXdW8D8m7YDvL/yy7erW73Wi7zey7nqC8AKrL0I3MDz+8AY /L0M7MEZDMK/G7l+27zHi7ikq773+8Hdi78EnLULTLYArLUHLLttu7Tca74sLLow3MERHL/XG8H1 +8I4LLU1rMJw678kPMMqW7K7e79GC8RQe8C9275JG8PYO8PGa7iPy7XoK8AhbMUXHMZWq8UJTMZD TL1HPME8PLZtbLxfYMHu6wU7W8KZi7gSHMbri8QrzMfRa8Ota8IhG8BezMYCDLiGvMeJ7AaCzAZy 3MNxLLZ2zMNGLLKJO7pxa77LS7xTW8Vn/LGSbL+N7MCWfMlsa8JSTMOa/MOfHINy/vzGmwvLY3wJ rxwGjzzLQzjKKCvLkosJulwGt9zLLDvMxFzMxnzMyJzMyrzMENsLcomvzFxPtIAB1FzN1owB6xrN +zbN1ZwB1JwB3nzNwqrNtLSE1pwBGoAB4BzO13yq5NxRB3DN6uzN7CzPGKCj7/wEhAiIDGDP6UzP 9WzN+JzP96qK9JpC8yzP/6wB6WzP6uyZBG0E+7qMFRQAGbABHJDRDO3QDM3Q7AzO41zM36qFrQjN RaHOGsABF7DSwBnQKc2r7KwBDRDREh0RYDmXJu0SFg3OHCCd1LrO3vzSPi2p1awBGRDSFjvShiiU SO0SDLDOGmCVTdgAF43OPb2n/k04z+gM0eSsiiS9QgaZkzldERjQ0QztoaB60RzQAcGZDlqNzhYw 1g/r1cZ6ov75ndlMiRiwAWZ91A3x1BzgAR3aEG+dARwwnQ05LTPqqUVo08YqqWJ9k039quhs1jJt DQ2g0gEqBGVt2T29l6doJkEqBwfwAaZ92qid2h8gAOaqnxTEUoNYmPKZj6nZrK1h0ZZ91kPAmTma DpVt1p8dkraq2IFw2t4andl6rdI52S1hRI8929ooqczdbr/d1/Uwl4Sd2y9NnTGalOj5omfKBabt pSrK1Z1RD88tpXcNEmw63fpwANVt1jPdECzV2Z4t2OY9JwS634CKpjrC2E8w/t707a0omiHlvYoD DqVSmg6t2N6CiAEckNsRniUBkNIS3gGdiZXhrZ5m6qJcUNofcNx13dpSCJxyPRHofdeVCGyF4OCt wQApndEyntF+bQ2GPeMy7gEXAKFmeaaBeZ3fbaFUoNpEXuQMMNTJfa0fGaF145a+4uS7k+AEiwoN jthY8B4AbqcxjuMaDdRbzuX4PZ9A/uNYGuRbUORojtoYAKm9SgEUsNIgEOdyHucVUFtICeU7ogVZ DmhSftOx6OICCTNCfmCZzeWGjuMekOMY7s4P2d1GiZsdfuZpnuYZEOcXMOcgEAKavumcrukXkN/3 qaUa/gopvt4OauUf6uN4/n4JMI7oh57RHhDrsC7YPA6N1knmlZmmWfABItDrvv7rwA7sGjACI9Dp xn7sn25hd46g3q2WSQPp/T2Y2anPA26ogF4F1YnrLgrp8FHos/7qiA4CF7DZLMHrwX7uwT7sIYDp 7N7uO67sjh7trCPvPyonPqo6ui4ZCS6U4qqpqI7tql7vWQmZ4Q0HgA3ugZ3oOS7ube0S5o7uEC8C 6t7uFC/nFDCU+t3kHg6kHX6gxhnpe34I1c6Fqyqpqxql13jtfWqeWFonW+pRRw7mM67wsA4CbJ3h LiEAGRDxEL8B617xFW+V8C7aaOqj362eLP+jtmmPBY1vmNqqzNji/77y/hvP7SKKn3DAlBVwAYGN 8B4Q5x3AoQO9EjvN8+e+AUBf8eMO6qOd75FemhRq5lRQCXkJ3bAoEiAh3YH+px4e9yHfBUOqpx0Q 6zSf8F9v8xwap+69CfEM1Ots9pWe9uzOoRiv30Tv92Uu7UEO8qt+3e254PTKisud6mWqpSDK8au+ oFOtpxfQAa4/+K+f+HGKqIt/YI5/+7iPzpa+0rzf+73P8Exq+TPqkN5N/H8p6pgf6n9vrD5p97J4 FEyoomMv3BUKpB2D9H8PNuGZq8Cao3IqlEPBlLk//ujs++bv+41Z+a6Rro1qldmIq9TqmCf+3nBJ qnU5/5kApVRN/rcP/qz+39tAABAOiUXjEZlULplNJ/HAkEobjcAVm71OuU/vFxwWCw9lc/lqTp/Z 6MAYHh+7GVX7HV+17Pl9v8WOQW6QsPDoIIArkItxys6C4cBwkjKsLaCM6MqoLbPyM+5ss5G01JRL ElR19TCxDvCU0TWVtfazrehsydO2F6kTmM01dkrL95hSjRhTNBL5GTpaGg5Ry/p6c1rbshr7EnM7 XHz8+Bs7i5ZcnSnYLX0dPl5ern3ePkn47X6fv9//30s2gAMJFjQIilcTgQcZNnT48Be4JgkhVrR4 sZ+Zie8wdvT4cRtFkCNJljR5EmVKlStZtnT5EmZMmTNp1rR5ExkC/pxjdO70+QVB0J5KgnoROkTo UCJJlx61VRQAVKhPmC6Z2sQpUqVFpia9qkpqz68/n4W1upVoVLVmmwphO5YVWydykcCtu1YrWrdw 7YIVq3ca4JVXzXbVafjI4cRb3/7lelhp1ahZ907WWtny3MiOESM2oripXsmXH2fea/hrUc90qVKu K3jx0NF5N7sG1ZgQ4b+QK3t+LJqx48ypVQtnfXq4cdilSR8tLBt4ZNNLp2MOnRwz3+LZhRvt/poq XtZy+8b9Dkc3d/V9XY/FXf39cezzyzNXT5/3a9nV2/ZnHh+4++QjarPeoDONL7U+E2xAy3RDLTgE lcutQPwMTOu8/uYm7O847QTMMIn0LHQQNsW8AkzEBe/zj8MN61NRww/5ywvGGsdzEUQArZODvA0n Y1C8CEckLr/3fhtyuf8OnO/HEPGKkUW7nMMxNiSBqlDH8toLcDElT3PKQysLGc1I2677cUraQkNr OzV3vGw1EAkUsccSiXszxdIeXFLPJRsED0rctFSQNBbtk/HQQH2U5sUkeXKUQHUavQ3SECsNQ6oW rTPTrSAv5O9GsRA9UkdGX1zl1EjF4bSXVC1FlbIytYSQO8lmI3HNQtuK802yfMVo0k9cBfTXYgcb thJkazSW2WadfRbaaKWdltpqrb0W22y13Zbbbr39FtxwxR2X/txy/zGDFJHMXXelKIiZgiN2TUJE gHrtlShbd99lJF6brrAX4DV+OgADEgw+GOEMMhCgX2f3PcWnAwCeeOI0bhIA4Yw1JmFhfZ7V9+FS GnYpgIkxyACDlFWm2OOYMN4Y5oQFaPlXkEMWuSaJ7cVggw0UVllllDEIeOR5My7hYKQNLoFpmBcu mqabY2lAkKjrPdnneoU+WeGfgR56Zqg/KhhhpZsmweyyNc6A5pv0vYMKqutYpIq4666j6phKFgDr hb/mWoCfM/D565nbhVnpmJlOHGEBfpq7igceoGJyKSSXvA7J7cA8brFLYiDlwRfumnShfRb9dNIx aJukl5M+/rvsxJEWAXaE8/Y3cskpoOCBBkz4vXfJTZj88t4b0Hxz1lWKAusNuC69655Ff750DDyv SIDFF0eAcbRlN7t7g9nGKYDjhT9/+AdM8N384yN3H/njb2+JYIWlh/70+50XHfrxw1AAgAAcggCP QEACSiN72iNACQiwwMUt0HsK1J72NDC/JgTQgApIggAPyAQMavCDAaxF5opXQhPGLw+bs+AFNSiE DhakfPbjQOl6droZDs5nG7gh6XymvCUcMINICOI0Eqg9gzWQaQhwIBIbyL0JMu0EFVihEoAIwhYW 0IpOqOIArzjCE34RjCc0wRR/eMUXEuQADZAhB2rIATbK/rCNbkxdzzRQgQZcj4tgOKM0AqBACHqP AEpsoAPRtjQFnuACFvAhFvXYRRYK0ZGrIOEXgXc5E1AgfWCkABnLCIA9DiQKONShG91ov569EYem 1MAqKwCJ/0XShS3EYCxp6UkRlkMDT2xa7SI4wRP8sgOtdMYT9ljFIGbwk7cswic/EQALhHF3luQd 78BoAkWOQZmxPGYXZ2nLWj6DARao4TjJWc5TurECraQaHvPISDNm0ZO1ZCYoGHACB+oSnwwkADAv oE4GLJKRRjBgHjkIz2Rm05u9KF8mTXjJy0WTmmKkwB2x2cF32tKgBJUlLG2RxgpowJwhJSUH0gkL gFKR/qPGNKgVOVqLA2TAnvmcYCB/6YFg+hNfxISlRUVYUIx6MJvzTEY4GVo8iGJymuprKAWkyE4i IBSjK33qLbsZDWdWQI4iJWU6cerUZaZ0o94cYlWPEYAK/FKQg1TrL2t6U5Pm1AvFvKhPkdlSLl7U F+WrwO/42tfhYfIB0VSfXy9px5Oi1JF0DSsttzgNRDQAqyOVLDr9+U+vChSsCfVpQrUJjXB2gK2h ZatN+1lZuDYyoPEUKzw728lv9iKcFcAkYWlL290JEw6b1axUd6tNu3Y0thcQ7nCHy1W5XXaDeN3s cnn7DL1eoAPRlW5p9yC301ZUo/LMInNT21hfRMEC/rKdbW1te1tIILex29QuYxdrVdBVIQNcTWcG qqAyKVisEB9sp37HCtVeIAJyKbzbQgihX87yd6XMNPBr/1sH8e6OvJfc3YTtOEwxeBfB38wwZ5/R DSnYtxHnQG5FunEOE4/4JYmwwIRZ3OIWC/OwK8ECKbLwTxPjd3nt0LEbmMGsRDQgvLIl7u6GXNJ1 uu3GSbYGig2yYyfjgiw200OQ5VvS6vIrZ+64cTW0jI52PRnM6qKJzRiBB0DIDWczCTOYYaIRbpFZ ao1gckcysWYoy2tecZbzGTiJZz/7w85P/vOgmxzoHRMa0QVhAwCcPAQxJxrSkZb0pCldaUtfGtOZ /tb0pjndaU9/GtShFvWoSZ3oS5W61LdaFhOyomoysYoSRvJOoy7VajO9WlmPWhEYTt2sP83oLiY6 T6l88esuAVtXVvEUfKh0DGOXBSZ0yg+uevWkRBH7U19yE5z8JKdXxagzfKIOlxSFp2mjadvZlvWs kzQsW2tnT61aFKaw1KY2zejWQlp3mkZEqma3pkVFmja8j11uZgt81zTCNsCRXe1gr2XY/5a3wxmO qOdYSkiaYpLFc9RsZElbRuy504J4pfF1c5zi317PgXwz7oKjfFe1gc6dSp7rKHn83CRPNswVVZUw LZzV9Q65ncQNJTTpezdg4hLQgx5w7LScRqte/ji/T94kpnvH5BMalJymPm984/xKWV85hhzeIaT3 xlAwVxbILSTyjBt85Ewvlc013m9WmYjZPEeO3O3t9aZLaEV3XzbcReXvUV3n6qpSe86PVO2u10rp x048u8WOHIx/6d64ZtO5bRWgmvca3QZv0uWPPvBYeSjejjd9wrEi9LaXSEFSkni/dy4mug8iWMkC fdrDkftY7772huhR4Nkz+MUbnvYKn728gU+hONxeWNDnUfMbTiG2o2ZOmDd96mOeK9UDfuOo1pbv JwF96Yt/WrCuhfmpj373vx/+8Zf//Olff/vfH//51//++d9///8fAANQAAeQAAvQAA8QARNQ/gEX kAEb0AEfMNIWQAInEALjbwIvcAEq0P0uUAg48CAycAww8Ago0AhIkAgkUAOnwQQBYAWLAATnoQW9 AANRcAhm0AU9sANfMAWhIQY/kAbBgARXkAZNkAJ/8Ad3kAdxcARxUAiPUAlL0AidEAV7kAVFsAaf 8AZBkAiHMApz0AuRUAWtMAs9cAszUAvFcAyvUAdn8AjVsAyxUA1z8AWDsAuLUAfBMAnRsArPkA/j UA7/cAnnUAr7MBBPMArv0BCZ8BDd0AwREQ/zkAr38AoBURIpMQv9sBIz8RItkQptEBOb8Awt8RGR 4QnZcBIzkQ3b8BMXURRXcQ1V8QvLEBNv/lAOYXEUbQEUxXAKB9ETN5ESZbEQOREW6VAQCREK/9AW b9EQWhAYm1ATIzER3dAVg/EXe5AY/dAaBfELlREUFPEVjXEP2xAYfREUW1EYudARK7EZHVEKNZEb K8EGebEUY9AUA7EXwxEO8ZERkxEf7/Aet7EW0/EdTwIaBxLTCtIgLQ0hE5LSFpIhHxIiI1IiJ5Ii K9IiLxIjM1IjN5IjO9IjPxIkQ1IkuXEARpIVStIk86peBoAlW9IlXxImY1ImZ5Ima9ImbxInc1In d5Ine9InfxIog1Ioh7JeYmwcBCABAIAADCABhtIpnxIqo1Iqp5Iqq9IqpTIBDKCBEsAo/qVhABpo ALoyJfkhAL6SABwHHgRAidByLDtCABqILcPhALQyLtvSI9QyKeWSABJgzuySH+aSAMSyEgIAAVDS L03iK/tSDALgLA8zJQYAARQTDBrTMR+TACTzCQzAACpzJZgSGdSSM9slML+LMkMzJd7SFwRgM01z JUqTFVzzq/zLF2Rpg7RIHSLRH8NgDveBH7MxF1PRDvVQBAUSFFTTFlCzNgeoEn5LOX/oE3ZqEpIx N4GwBnmTOKswCcrxFGOxGLfRISdhNFnBAAyzgJaJEpjThTzoOctzGdOxHamzAx1COrGTBekzFuPT PvHzPQeBH4lgAPJyFcJTiMzzrgaU/qfMSLVisznfCUHTMzkbtLUQiqoWlMNkcxeL8UIvFBV3Uz81 NDgl8Ro/FArNEBCvMRFDUQkbMT7fUwsBEjuF0B7j8BBJtAmQUxUOgACc86maM0GnykEhFDp/VEiH 9Ldo00ET1EgJFEnl6UhhiQ63Mz+f1D45lD65kDu9MxTz80qxFEqtdAhLsEqjdB5pUR+XEEul9DqN 4DJXwTipSEkhdEeHdEkFik5VK5JASD3ntEePNE7TE0ib1Ey5tEu1EUzx80W/1AuD0BDV8RgFdUoJ 9VDrs1Cl9D4X9QTH0B9f0UWt9AkE9BP+U0d5FE5FFVD5lEcJylR/SkfhVJmC1E9J/jWqnBRS9/NR R7A6E/VFJ7ER21FFEbELHfVXT9RXS1RTJTVLdZVMB3VTj7UJDKAuKYElQ7VU97RU/7RO4zRJKdRN 9RRb2fNVq3UJgnUKcbVWXfBWq7NXLzVd1TVXk1VcZ9VXVdRc1bFYb5VF6xUgOfVEvyABnnUSNFNa uelUYdVa35RItbVIp7VBXZVPB4pbt7MOyVVEEVVSITZTodRRD3VXT3ELP7FKp7NiaVVfP9ZSOTVY DRUMolUVEgBAIQmqZBNIeQqLFrZAFfZayapV77SlWEtV01ARLVVjOfZcM7ZcgfZe5RUZM5QRw5Fe i7AfgXNXU5RpOdYbZ7Q/i0Bl/kEhazHiTpezT2vhaskhbE3iH5VgayvhbC2ia1cBPQthbMXhbUcC ZJkgbSehbjtCqF5JSVkhH9ehb1NCD5fgbgthcFkTMckTbRHXcB9Tce22ceOqwK71PJ+zbXNLHCoX JDDXcVehcGdTcidBc22zFkIXdAe2IbL1gqKhc+VgdW1hbb12ckd3Gkb1dC9MdR+XcHFXdHlWQX10 rpSTQaeKm4qJw3oWTzEreA22tfT0eHcUiJDUYZn3QJ13Ql8oqIrXTwU2eRkMZi1qt7Y3nl53e2l3 DFoXDsz3QVHXZjVLw6yVZlM1ehfWVcn3fe1UVHfKSJ/3W+e0fpVrv2CVfb+q/kndV1upNWbl9IDr lIBTtXx1dxDQd0Af9mYLmFUL2HT7NEhTCoDNc4ElGFwJNnwluGBHGIDF91Tr94JLmII32HkxGHgN AYLDIIYVOIWrqn9P2Iand4LvSn3Xl047mHz514VDuHmN14ZV2LcKFomTuGaXV3j1136ZmIF7NlZf uBCakk1b9n+mdYiFmIvt6nWXuIeZ10BBmIuHWGCFFE8z2FtJeIe7OI0j+GsZ+IY/d4V/2BCclU1X E5vO+EeB+ITvmHbdd4yVeG/rmFo/2IfjOEndmIz9OH7R+I7heJKDuJED2RA8tRJwNA4u2Z2emIcH Nqh0ODYT63h31nvl2ImP/nhmR/V6TXWUGdmTV9l0edaUhxeXXRaNwVeDBzixDAFHMfMINPlaSLck jJkgkPkIbHRlHThalDlzTQKaiwCLWYExtSVvW2Ka+SGbvYCYPwE2F7d1+JgVmFmcSSKcwcJfzxkj zLmc15SdP8IAEGCdV5ac4/kixrPDCMCZ8ZkgvtKqCtOfK+IrBRM8+3mg9yEBclQbGNMAhDmh80oz IVoMILOeI1oe3hKhUxMuMXof3vKbwwGkw9Kj10EAvlKP7aEsB4kpr9KlXxqmY1qmZ5qmczIrB4kr z6Vkapqne9qnfxqog5oli5KiS9qojxqpk1qpl5qpm9qpnxqqo1qqp5qqIKvaqq8aq7Naq7eaq7va q78arMNarMearMvarM/aV4IAADs= --------------202205850604300321285576-- From sip-bounces@ietf.org Sat Mar 10 15:54:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8Y2-00059g-UP; Sat, 10 Mar 2007 15:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8Y1-00059b-Rn for sip@ietf.org; Sat, 10 Mar 2007 15:52:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8Y0-0006pr-Js for sip@ietf.org; Sat, 10 Mar 2007 15:52:13 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 12:52:12 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399804158:sNHT41016528" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2AKqBw5011386 for ; Sat, 10 Mar 2007 12:52:11 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2AKqBxS013290 for ; Sat, 10 Mar 2007 20:52:11 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <09A001AF-7BC8-4AA5-8ED3-53F481424929@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Sat, 10 Mar 2007 12:51:47 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=364; t=1173559931; x=1174423931; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-polk-sip-rph-new-namespaces |Sender:=20; bh=4f7zA58bXkJk9vH/aJk8SEiIFX/SuI+J5wiBxxxGpN8=; b=cUTdnv3bxlKq65ShBQiZu4UptlFPEgxlJ/7Lv6jHaBF6qceD7ctUg196KL22HwqwAjIjPhnF Pc29SU2xaSlZtmVYiSjmt4ehnNN3b6/ppjHdK1CeAaybfwAWB5Bq+eZ8; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Sip] draft-polk-sip-rph-new-namespaces X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have to admit I am not up enough on all this stuff to have any idea if this is the best way to solve this problem but this approach did concern me on the basis of using IANA for a registry like this - Would any organization be able to request a new RPH? Would they need a standards track document to do that? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 10 16:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8iI-0005sJ-A2; Sat, 10 Mar 2007 16:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8iH-0005rV-2x for sip@ietf.org; Sat, 10 Mar 2007 16:02:49 -0500 Received: from sd-green-bigip-145.dreamhost.com ([208.97.132.145] helo=randymail-a1.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8iC-0000Lj-30 for sip@ietf.org; Sat, 10 Mar 2007 16:02:49 -0500 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a1.g.dreamhost.com (Postfix) with ESMTP id 24F9B18D784 for ; Sat, 10 Mar 2007 13:02:43 -0800 (PST) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 466231CC77 for ; Sat, 10 Mar 2007 13:01:43 -0800 (PST) To: sip@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sat, 10 Mar 2007 13:01:43 -0800 From: EKR Message-Id: <20070310210143.466231CC77@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org $Id: draft-dotson-sip-certificate-auth-sol-00-rev.txt,v 1.1 2007/03/10 21:13:10 ekr Exp $ The native SIP authentication scheme is Digest authentication. This draft and its companion draft-dotson-sip-certificate-auth argue that it is desirable to have an authentication scheme based on public key certificates that can span multiple hops (TLS client auth lets you authenticate to the first hop proxy). To some extent, SIP already has such a scheme: messages can be S/MIME signed. As I understand it, the primary deficiencies claimed for S/MIME are: - There is no way for the server to indicate he wants you to S/MIME sign. - There is no built-in defense against replay attacks. In order to correct this situation, this draft proposes an extension to HTTP Digest to add a signature mode. I'm not sure how important this problem actually is, but I'm skeptical that this draft is the best way to go about it. It seems to me that this proposal confuses two issues: 1. The formatting of the signature over the data. 2. How the server indicates that it wants a signature. This proposal addresses both, but its solution to (1) is clumsy and replicates functionality we already have, namely S/MIME. It's fine to define a new form of authentication challenge that says "please sign with your S/MIME cert" and even have it include a nonce, but there's no need to model the response on Digest auth. You can simply include the challenge in the material you sign over. Incidentally, I've heard people argue that it would be nice to have a generic solution for both HTTP and SIP. This problem has already been attacked for HTTP (though with minimal adoption). See S-HTTP (RFC 2660). -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 10 16:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8vg-0002Ou-QJ; Sat, 10 Mar 2007 16:16:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8vf-00028c-Eu for sip@ietf.org; Sat, 10 Mar 2007 16:16:39 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8t3-0002ZJ-Nl for sip@ietf.org; Sat, 10 Mar 2007 16:13:59 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2007 13:13:57 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="364998751:sNHT40084536" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2ALDvHU016161 for ; Sat, 10 Mar 2007 13:13:57 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2ALDua4015863 for ; Sat, 10 Mar 2007 21:13:56 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Sat, 10 Mar 2007 13:13:32 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=191; t=1173561237; x=1174425237; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-barnes-sip-em-ps-req-sol-00 |Sender:=20; bh=FCA49Iq2HtcA4ODvBYbUCvIpCOZHGGmWWuX9xqZh4Do=; b=gZ5DTVmc0f8LuSijp3+IshNCChdHJeEujoXMgmtawKoGVJBz0P53VXKt+Nix0AgZpfFwnBZU VkppPGzM2M9Eb548sUS00gV3RCnOFsjnSN2xSICRzteewWaK+MB0HvZu; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] draft-barnes-sip-em-ps-req-sol-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You might want to make this a sipping draft instead of sip. I would not bother to consider INFO as part of the possible set of solutions space. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 10 16:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9Y6-0007YM-2p; Sat, 10 Mar 2007 16:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9Y3-0007YH-QB for sip@ietf.org; Sat, 10 Mar 2007 16:56:19 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9Y2-0002xy-IJ for sip@ietf.org; Sat, 10 Mar 2007 16:56:19 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2007 13:56:18 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="119878746:sNHT46263141" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2ALuHCK011551 for ; Sat, 10 Mar 2007 13:56:17 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l2ALuHdw015709 for ; Sat, 10 Mar 2007 21:56:17 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <3B62394D-5223-4883-892D-2E4EA75DAAF5@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Sat, 10 Mar 2007 13:55:53 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=272; t=1173563778; x=1174427778; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-lee-sip-dns-sd-uri-00 |Sender:=20; bh=NbdLh6BN0p+lPjpbyaI9VnfCtaPRHpO5rtEevyqqaAQ=; b=cmkT6oN+DBgnjfC1AhexRdLQt6MDjYWy1WTJ32Nr+ndRI1nqSqQhQAGstqqWhA+53/saGXFp eY6Y9cilTyuWwlBPL6sPKvYQ0wjm1e3PhoyGW7U7+afXvi1PEp6Rmjzamr44hLd6ik0+rQMlTR P7/v53Ofbs2MPJ8z30AIxBH5Y=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] draft-lee-sip-dns-sd-uri-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for writing this - it makes a nice thing to be able to compare to the DHT based stuff in the P2PSIP WG. It would be nice if the draft compared this approach to just sending an INVITE to the SIP multicast address. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 10 17:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9rY-0003xs-8R; Sat, 10 Mar 2007 17:16:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9rW-0003xl-TA for sip@ietf.org; Sat, 10 Mar 2007 17:16:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9rV-0006f7-7A for sip@ietf.org; Sat, 10 Mar 2007 17:16:26 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2007 14:16:24 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="47297553:sNHT42568938" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2AMGO0u020256 for ; Sat, 10 Mar 2007 14:16:24 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2AMGOa3024568 for ; Sat, 10 Mar 2007 22:16:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 14:16:24 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.152.81]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 14:16:23 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 10 Mar 2007 16:16:23 -0600 To: Cullen Jennings , SIP From: "James M. Polk" Subject: Re: [Sip] draft-polk-sip-rph-new-namespaces In-Reply-To: <09A001AF-7BC8-4AA5-8ED3-53F481424929@cisco.com> References: <09A001AF-7BC8-4AA5-8ED3-53F481424929@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Mar 2007 22:16:24.0101 (UTC) FILETIME=[BD39D550:01C76361] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=877; t=1173564984; x=1174428984; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20draft-polk-sip-rph-new-namespaces |Sender:=20; bh=rei6X1E9mGanU03QvGIiLkdkXh6/5oijzvnvNmkGvF4=; b=rVbwck/cz904Y6CucuJIs99rjr91BswB0PCl3gxzkHVyUlsRORof0RfZAAf1RKv28LrF5vTN NiRUDjNoVko5YC6X7kXmeihgoZNB8EcdfV3jMcDw2AukfKCcXB5E+GmC; Authentication-Results: sj-dkim-5; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 4412 states it would take a standards track doc to register new namespaces, and doesn't limit who can author it (i.e. "...any organization...") At 02:51 PM 3/10/2007, Cullen Jennings wrote: >I have to admit I am not up enough on all this stuff to have any idea >if this is the best way to solve this problem but this approach did >concern me on the basis of using IANA for a registry like this - >Would any organization be able to request a new RPH? Would they need >a standards track document to do that? > >Cullen > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From contrliixof@strahlmann.pl Sat Mar 10 20:39:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQD1v-0004uW-Ug; Sat, 10 Mar 2007 20:39:23 -0500 Received: from [60.209.67.199] (helo=strahlmann.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQD1c-0002ry-3Y; Sat, 10 Mar 2007 20:39:23 -0500 Message-ID: <4DEA7012.4638B9D0@strahlmann.pl> Date: Sun, 11 Mar 2007 02:31:16 +0100 From: "Starr Hughes" MIME-Version: 1.0 To: "Bridgette" Cc: "Debra Murphy" , "Mitsue" , "Jeane" , "Melony" , "Russel" , "Elwood Garcia" , "Rubi Ramos" , "Esteban" , "Jacquelyne Howell" , "Milda" , "Lavina Jacobs" Subject: Yes Content-Type: multipart/related; boundary="------------375270014377334515585562" X-Spam-Score: 3.4 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 --------------375270014377334515585562 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


swiftly woken wrote "Well, then," said the thick baroness, "if slave she be,  "Really?"   "Dear Valentine!""Yes; I will mention engine one to crush you. petite He easy had a remarkab    
"I clung believe, mother, vespertilian it is swept merely squeak a title. The coun   anxious "In violently thrived bore the smuggling line?" said Monte Cristo.    "Eh, minute your excellency? Every fraternal fool kiss one must live."      meeting "His manners keep are super wall admirable," said the countess, "a  

arch nerve "Of linen art the Arabian Nights?"bumpy saw "But," remarked lain Madame march de Villefort, "all these cidepend scissors "Well, would you believe quickly briefly it? directly my father ca"Ah, sign that is bone where the shirt tin art comes in. To be a great   burst "They are perfect mother, simian hair soothe so perfect, that they su     "Certainly; go on."  "I loved my fiercely brother built scissors scratchy tenderly, as I told your excel    
"What does right attack touch breezy he appear to be?"  
whip "If you like; bubble formic but tell me, my swear dear Lucien, what itbasket mouth "Precisely so," run cried rail Monte Cristo--"precisely so;soap "'Morrel, powder Morrel,' cried my share father, wound 'stop a bit;'structure "It is written very fortunate," nose arrest she observed, "that such s        
"Why, puzzled you slip judge have just sought said,--a man of high distincti   "We are alright getting ornithic strengthen distinct to the story now?"  "Yes, egg your excellency; pleasure excuse noise me, but, walk as you will     
"I told you, knife my discover weigh skin dear mother, he was esteemed such.    "Indeed," sneeze answered accept organization Maximilian; "and overtaken what did your         "To me she room lupine quit seems history overloaded," observed Eugnie; "s"By chemists sneeze nearly busy and persons who have boat a taste for chem"Oh, such a dreadful transport thing, corporal that I reject don't rest dare to toil "And then," sternal violently pled said Madame de Villefort, endeavoring   
"But what is behavior paid rid stamp your own opinion, Albert?"    "Vaguely; I baby was ticket far shut from France credit at that period. Go whisper "As I entered fall N?mes, driving I literally waded roof in blood; a 
"See fine how the sock copper good artist peeps out!" exclaimed Madame Dflame talk "Really, fry madame, this is a approval scruple which naturally"Always slain view tell me water tin everything," said Maximilian with"Yet said gun conscience remains," remarked reflect honestly Madame de Ville       
"I jam pull must tell you that I kind have not come cheerfully to any decid"And key creepy this king's tumble attorney was well named Villefort?" as  "Yes, your excellency; important he came rapid hat religion from Marseilles, wh      "I do not seek ask you of his origin sawn representative little but what he is."   
"I admire all that list obey is support beautiful," round returned the youhappy "Yes," answered bread Monte rescue Cristo watch "happily, yes, conscifake "'Ah,' bled continued face my throughout father, still frowning, 'theirMadame earn de Villefort listened with against root noise avidity to these   withstood system "Ah, what he is; that said is bid quite another thing. I ha    "Then," said Monte anxiously mountain bow delay Cristo "you went to him?"    smell "'Monsieur,' I said, 'my open delightful came brother was assassinated          
"You say"--"Oh, do not apple oven place any plant lose reliance on that, madame; on         --------------375270014377334515585562 Content-Type: image/gif; name="ebijwoo.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhlAGQAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlAGQAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6739GAIACv2+/4vP4sEAz6BAUGB3uFhoeIiW0B dAAHgQUIfggIjUMHAwYChIqdnp+gngMEA0MJBagCAAKaRI+RfgmbobS1trdhB3SnpUICCKgDugGc QqcFpb+SuMzNzs9ICQSbBgZDv8GjqkMBwAUJQoHb0OTl5od9BwawrI3dqAaBvULvwQADCZyY4+f9 /v9iMFGSgwqBrEavCkwjVeQYqgTEhBw4RaAYwIsYM0IJAKnAJkgI5gEAyUgOoQNzOnq8ZpBVPo0w Y8oEwBEVrAE2lwlZF4mO/rZ7FWs+5KbqWMWZSJOeExpJmk0CjY5JwqZKHE1I4IjgLDhLqdevt5gq 7NiLp6QECKCOFOQIEj8BNpFJ4we2rt1DTCVBsnZvwJ9h3DIJOGWwGLaHr+jeXcw4TQB8f+l1TPnN ia4EsogwtfZLZOPPoMMI6Jh2m1ACNOdUQdlRbZ/QsGN3Ge2Nq2SFlqoc7rnxtRoFwIMrOBK8nPDi RZDHFE5FOQDneCaWEqsTpeIpQnUuQZnALyWIaY5Dfw7803Am4ssTGQ8w/XkoztnXeVdK4FOLWgKs 45tEl32PkBx1BnLM1fEefOotoVx8CWK0YINOyLdHPVlll9sW+yBxgC4E/oR02AD1eDbGgweSd+Bx RqCYYoFDkNhiei+qmISLMbIoBIwxkreeeCauKGONJzYoIXQM8rhjkOe55yOEXiQkCB3qpILGYwRM sw5UUgVg1IVhFHnkkTbieKOYPY75nntJGomEl2aqiSaQYL4JZJhuCslkjl/OSaOZeiaopBi7TRNO JWWksxUyq0B0WB82XfcFm3xGWuaelPppqXp7KpFpgUNeWiJzoN6JZ5mkXjojk0Wmeaadq2JqqqRg HIrKNL6BMQw2wuzlCJR7JZQVGZCWOl6nSOIJaaankomsmMO6quqSBIo65qg+Vjvqpq9OKqcYA9Qm pWgdktJtRXDBgpkQ/lthCY8ZJBY7J7XJsSrpsc5GqOa1psrY7LOkmmikhDpOm2y8n2ZLb6tt3iua NGkJ0+Rjftg0nTD1xEPootjwN2K2sNYIa7TuYotwv5pKK6yq/HasbcqcctwuwERCWKm7J6uMhn9e sEJKWvrNChgAPBmA1ja9ylNGu3nWfDLK8zo7stIKmjwzviWu/DHIVLcKcNMFP30w1fCGIUdXWeji 117dMgqL0L7MOrZPXHXI5aN/Uqvs3XUya7CNxEm9t95VY93vtv7y/eOaZHJt999xmjwbJYNgMREB aFHu9h/1dEioUNORQuEf7CZO8uGF973vcPJe7TjMLheHrNWjuy4z/t9tPkE61F93fHsWfnAJF6FT oCTMIyFRvqhEZsWzDU/kKjQa5XPLFhrtX8FF+R+qAYAZfk6M5rN+sSTE36EgmlSuJPuVJP36Ctcl a0HGR3+ELqbEVZFf9G8FfOa6hPROSPhbnwD9BRqexCUnjjLC87bxH0G0gx7emIdUIraQaXBvgBhk jDqq5C3bMCEhAlpFbQQ1BOZdwyYMG14GVxgbYugiFh3iTRF+NgTyXcMAtfnVKjyIjanIj4VABI3w HCYRRoyCcsVICPC6472h3AY3NBFaAoNIxfXRRnP28AVa1pWoqxQEISCZYhXHuD4Dqg14QjOLKiai Cs5JxnNFGE0r/shIR8bobBuHgQgw1KI9iASIEAmIHDYEFBEjrCMkqyDAHOvISJgwIhxuM4bbjIYu TZBFhFlhhYiKwBEDEMMhiGykKAEyLkLYUIRrc54vKBfDmyjkgkiQgyQPKMZR2hIUWkoGW9ryRV4K Qn+qGM0mDqUJ0D0BH1qyXylvyUxb0GaX+PCFAfmiRuZxKJgN+2ESCBOXixGxmeBEh2Dm4I2jaMkn mbBNuZCxTlK8kiawbMJuYEETY4bznnnwS7fGghIPrmIVIPKGNcR3GnzUsnthRMlA8MlQO8CFM94g ZxYHkygnqYJ8C8QQPfqwCy429KNseAVfWNEKa0ZRDgYYRTkJ/tIwR8RTCqMBURwDeVBcLOCmN03D Aoaw0yP0tAw/JUNQ69JDLgHTGH/QxGBsoglZvJQKrwilTII6VCtU1QhXLUJWibBVQ3QVKR+iB8Qo pEXwibA0T7VCLmsVk6F+9QlvjSsT3qoHusakYlqixDf2+k5WWG9D6QDUHLc3Va3yNKeGRawQcLpY xR62pz+NLGIj69OcUnanjmUsVgGA2atSlrOK/SxmuQpannL2sYs1bWpBS9XQnvYQSmQFU3cYDHVY 8pur0CYVarKMK41NI25d7WsPu1rRbja1xkWucI97WcgKt6qdXe5zh+vc4rq1uq5V7nST+1rHGuJQ KQmEWiYo/lP8PIKPGDLgNwbjyW7p8B/Bpa5hi6ta6M63u4lVwmWnK9/8Sle73K0uaemrWvyOVsAF RjBedOUXKaGkGvJLV00t45Sn4DESaXVGfD+bYP7ad8D45ap37zva/uJ0xCUeLmkFzOL/ctfEp02x Zlk7WU8UlVHAY8JuwIMFWUaxm9jc5Dk2XGAP1/e4HVZxiH1q2hYr2b9PjrGRCQxiBBv3wMxFsiIy draabiamVhCIdvaJQrYChKpJTvKLt3tkACcBzY2lsn05TOI2L1nNVU5zgP+LCP14spBNMGDztAMF 6+DwnfRQ73vPfGKtojjBoYVujZ876TuXdrut9Wx/tTxj/hq7eMbXhbOKOw3qixwKKiFaxRw4Ica0 cYfQ94goSJvQVTpzwa7NPAmZJcEUVRzSk9nb1dtoAox5BLuGlZn1XPVb5Fsre4ag7MMI6WCWI+Ix hhfzmRJM8mwqZNYLI362Q5KhObWAkLdtLCch1jnhbrs7EWJGCLeJDQ8Q7kTbhwnhI9/N71AMJnof yuMsdWJACWqs3wi/hf5GEcl7NMoXK20LahJO8VqAcJCGkRjyUJjIdicl3N5udhtA7l1QT/bEkG20 iDtNR7wGIscCTzRTzQyacNua2XxeA8lDjdpLizjOQPc5HcGbaono6hI6e4n0UJxyJ9x8DyVnrMqZ Tlyh/jfSousUCfN0GxvLphzl0T05pEVd6sZyOLPRvbTYPa32znp97T8HOsuxanKvW52o0iBFvjnB FCELUOpNb3vYzx7pr5v98KwN+tvl3nSx2720B3bu1CX72Kyu3fEgr8sjaRO5KArNniy8fODh7uHF 2x3wkH8841efekdHWsqkV3ymPTv62ktv3hKho+hZX/L6WjbGYQc+5IVf9d23fuWUj3zQq373uRs/ 9hW/yPNtn2cau/36nm60ynlv+6i3PfHQfz3dx//98kc/I9M//OmLrP3CJ179mH//4o9/+sY/nuo+ Fz/9u5/585sD7vHneOynfwRIed/3ervHf9ZldpqF/nKuh3YMyHyq53920X9sYIHNgIEU2Fa4dgYa SAsGuIF18YFoQIKhsH0imIIquIIs2IIu+IIwGIMyOIM0WIM2eIM4mIM6uIM82IM++INAGIRCOIRE WIRGeIRImIRK6AwHwABO6IRLGIUz9IRU6IQZJoU++IQbsoUbwgANwABYeIReyABdWIVU+IVAtCFh CApN6ABm+IZO6IZX+BlquIaJwAAO4IZ5uId82Id8CIZpGERcOIiEWIiGWIef4QAP4IeMyIgPAAGA yEKIKECHWImWSIiN4QAQsImcCAERsImf2Imi2ImRaDtdUzUYMYmxMQwl0Yqu+IqwCIs4cxcM8IkR /vCJEpCLupiLtigBEbCLEtCJXLceS2JxTwBLqihEsbiMzNiMcxg2JbMieuAAt/iLvxiMt6iLuMiL 1uiL1ViK9vIi5fBIrEgTjHBB9GOKBIOKXIAidfMwzRiP8hgADDCMSdMEqMKObtAA1SgBE9CNE5CL /5iNu2iN1dgAzxgwOuIp4ug0HmMGhVgSgKE+5EiI+4aPpygGliKOY8CKy8iK9TiPr2iFCKKQ6KGP eRAA/TgBEOCPAemL3CiQ/xiQnhgBFICQUbCRmNKQqOMqHGmSuXCIxHCOFOlChAiF6igwG4M4HQmL TsgITxmVrQiSZEiUQ1kST1mSOlkeW8mRLbM1/k3CjzFZjWRpkGX5ixRQAWQoBVyZJmASMD65jmUg lMQQkhJ5joWIlOE4LayyKnAJMoFzJ44jOU4ZlVRIj1jpivVYj01YlVjZAPa4kAgjO3zik5bZlo5h ARQAjJzZmbqYlpA5BZipkJgZl7MDlLayjHaJmIspiwxgAeAYNTzZIrMZLbSplA/5k6mpmFAplVCZ mK0Ykq2pmKG5l38pMKbplpeJm2YQAA1QAZ4ZnRKQlhVQnGzZk8ipnG5JmnFJBk85knXJmIjpkXVZ ARYQmZLJnKGSnXJZjLr5BeRplauJld9ZmFf5mPa4kce5n5e5nqhZBvSomdIJjGkJm+hJMF6p/p3a 4jGDqQWNOZ/DsIVG+YrPCZsJOZp2kp77yZf6+CBjIJIguowNYJ0nqSLJyZ4amqAh9ZqbOaAScAHm uZZW4KEJw6HqST1gQI9fGKIBGqMJqaH6iaHbuaF9855ewKNICpUWgJMYGS/8+SzLCaQomQtO2AAW UAGbOQFauqVaegEFSpJr0KBp0IQjOp+qeaUG+qNNo6JtOaTdqZT6KTZmmqTM6IUWapw2+qTcWTtE agZmaKVYegFbegFeap5fqIUDYjPz4YU7yozPWZ0y2hxxWjpSGifQsiMd+YR02oxVap4HChBwOKJX iqUVUKoWAJtvOCBg6Qa68JqN6oqPaqBu/iCmeOCchwqHuJqrVDiqkQoWDxqqI3qruKqm/0CmS3qG psqYYWqk8OacpxoApRqt0jqt1Fqt0iqri7GFuiqhZKiFXNgYPTqtX0isWoCjzWqnp5qu6rqu7Nqu 6fqU5OoPlzivW8gY9PmGgJZBVKmrmkqf9Niv+apByfhB9WoXrJhEFimRdDSITRCvdniMBduwCvuw OBiv/uGwFFuxGJuxHNuxHvuxIBuyIjuyJFuyJnuyKJuyKruyLAsKCNCy3UYJlMAEM/sEMjsEMvuy RpCzRMCzZ1CzQKuzMOuyOluzSWC0NAsAL7u0RSu0QhC0T9u0ReC0T+sFUHsHVDtKWZsU/kgLtUY7 s1+7tUt7BEirtFJrtlE7tUzbszcbtW2Ls2ubtmg7tzb7tke7tXcrtD6rtmW7t2RwtWUbBX6LBIG7 BG87uG7rtIgbBoCLt1DQtU0bt2Crt2JbuH17tlcLt5KLuXh7s40rt06QuYTruDurtKYrunMbtGeL Bqj7uKs7uo97uqlLtZ9Ltz/7ulQAuXL7uYXrtmq7s5wLursbvLbLtsN7vKGruFIbtnRruaYLvL87 u7g7uWwbtpfbvMQrBbqLtsxrvWT7vNELt8h7vZBrvbQbt7MrvLmrvOO7vKR7uJXru6jbuD7bu7Xb undrvGa7udhLtpZ7vsM7vdSbvsUr/r/E27s0y777m77eC7zxq7+1q7kEjL+ee8Ckm7wQbMEF3LPP a78anMHqu8ETnL0JDMIjLMILrL98S7kC3L4hfMIErL0KfL9M67h2W8A0HL1eS8EfjMCuC7oRfMMc PLbXC8OXy78xzLdGfMEqvMRp68Pw67/Cm7MALL1t+78ujMKGO8M1fLxCXL3iC70wHMaqe8UPnMNZ 4LdBDMVlPMD7q7yB68ZvHMbQy7xJvMUmzLvv28Gdi7vqG8F0nMck/MNkrMFfjLN8DLtjnMVNXMiM zAY+XLVgEMlNQMnrC8TZe8iyi75ZfMUO7MSfjMZTkLlrvMdEXMWibMCPLMGpnAaa/mwGlozHk2y3 pawEZsyz5qvEdQzHlCvFdoy/dbu9pBzJt1zBmsvLu1y9vZzMq0yDlMzEVhDL+XsIlgzNlxzN1pyD rwzL2azIe7DNZSDN3jy05FzO5nzO6JzO6rzO7LyEw1CFAdvOFKcLGFDP9nzPGBDP8txt9GzPGVDP GfDP+Pyp+zxKTXjPGaABGBDQAo3PvVrQH3UA+LzQ/9zQE40BTArRDYuJacgAF63QFW3R95zRGq0h qniOLETREw3SGqDQF73QsVnSl4CO6oNBAZABG8ABOt3SL93SLd3QAU3Q5ayKgziVA7TQGsABhAqj FSDSSS2tDa0BDSDTrmARhvib/hubETcd0BxgnunK0P/81F59qvasARkg1CxL1HSZlbLBAAytAWr5 hA2A0wnd1ZD6hBSd0DHdzpPIhRK5IYqprLCBAT7d0jLqnDjNAR1Qne6Q1wltAVlNsn0toYfqQiMp 2J+h0BtQ2GctEW7NAR4QoxLh2BnAAedZkpgqjbQ6hFYtoaeqqfH5r2h9EQeQ0IUt1dzQAEp9pwBA 2Lfd1ZF5mqo9pWpwAB9w3Mid3Mr9AQLAr5o6QHVY1K/tivE5hpFtDjd924Y9BK+5pO5g24UN3Dnp l0WqB8hNr0041u6arp66PggL2NMtj88qRODN2fqAmKOt3U+NnkFqmyf6l9jp/gXHLTZXutcaJBGu baCySJ5WOtvFWt+FPdUIzgm+/duhbeBMyZe1uZ0OSZlcMOATPq8iuSEFLhv6oK2v+opiVRINLkQY wAHaDeNcEgBJHeMdAJvXaZLr+d/9zQXG/QHovYU36dxUWKrX3Q8nDthGaYjCxggtDhoMkNQ6PeU6 3dncUNpUPuUecAEkGo5cmZ5CiqJ9egXLXeZmzgDqvd7repMl+jphStxhFuIDO0Ot+ORXIB+rnZJS nuU7DdZ7zucXfqBhDuYc7qZDmgVmnujJjQHUOa0UQAGECgKSPumSXgHa1N9wPiPlmulQJedXLaKn jQVEwpyf4Jx8fuqAruU3/v7Q9kLepamdhk7qVqDotJ4Bkn4BlA4CIbDrvN7ru34BGL6nJIPa8Cbn PGrnVTCaOm4LUZ7lHoDqOu0B0h7tod3lpogkrz6bwp7nS/ABIvDt4B7u4i7uGjACI+Dr6J7uwP5S mK7j/s00BBTvbaqnfRk8E56kyC6pAI6dmK6gcGDqWv7s0E7lHgACF8DbF+Ht477w417uIZDrEB/x XM7uru7h/amnKdojlFkv/11oId6buEqhoT6jAX6cOsmTJe8Gnz3woC3w0W7wjK0RCs/wNC8CDh/x OD/pFFCPJcMitmnyhc6eGQr0KPqmlnHvjCqqpxqsZeqR+Z7jRe/vtWP0/itaAamu5QQPAouN4xoh ABlQ8zS/AQ+f8zmvlhRvOtkJKipaOCl/ojy+O0rAd0oqrIdJknU+8voe9XlK6LJe3M95AaDN8gWv 9TBK0hex1WC/8BtA9jl/8MEumB2v90A59FEa+VIg9wE6p0bNivNN8iYa9G5/6CvqhaXaAdLu8i0/ +B3A1N4NExIN1gyd+LbO+BAPozwfjdYS+pKv7PQe9GP+QUWU+c7Y5O2d7AWzoTQ66G7wr4xaqhfQ AdBv+tHP1IZapQ6OS7Cf/dqf0Le+1N7//bhu+6zupLmvNWLukO4u9L4f71EgoUqq+Qr7r1dq+ONN /sqeKgHO7V1AnlV6/qrWuqRA0GAwAoEhAJlULplN5xMalUYPjcwVm9ViNRfvFxy+UCrCwBSdVq/Z ayOj0bBUiEX7PXAIyC2WRr4tUHCQEEkP721IcVERj+GgMFJy6gDOagsTq2KTs9Nz0+9scpQ0snIx DlGV8ajU9RXtQHZWtmjWlja3VhS2t23XMk54mLjP+Bi5T5jBt9nZMDGYdTrY4vEZu1Q3DzKpiElX Nnu8ibaIGj2dupu8vVBvSE5IffGN3R1fTXeJluo+/1k4gbmi0cMDEOGaW/SIELyWEGJEieMOqbJ4 Z2LGJ+IucjMHSGNIkSPZbOto5x9JlQN3pVT5EmZMJSxl1gRAkJdN/p07efYk+c1nUKFDiSp0CQVo UaVLmQbVc7Qc1KZTqVaFOCuWVKtbuXb1Jc5rWLFjyZY1exZtWrVr2bZ1+xZuXEkI5Na1a5Xu3TZ5 9fZNgwAw3yeA1QROEljwYcOKCWNr/DixFMSSI0NZrHgwX8SXfUFG0thvPs+WKzuhexrAaMyp86p+ drp1adOxo4CWnBr3Z9tKOPOWDct1xN9lbXsGTfh4ZdRMdo8OjlzwZN29oa8OTtq3btaYkzdZzth7 b+1LqjPWTB22ddpspGMvnHz39OjtO6+PL6h47PTbuzO/39y+9cBzTkDyyiPwr/mm246/88KLjkHy IszOwP0Q9M/C/gDZKzC8wnDL0MDxJhznOvwUZBDB+xakkMIL1RuvRBQ1HNE9GGcs78HDaFyNxRZv VO5HEdHIT7vu+mMutxBnEzLE/OBLDEcXCyFSRht3BI9JK6v0Ub4YL4yxwxe3xDFHDnvMcszN0PzS zNpONMw4B3P07TfIxIMzSAzTRDMQKtm88rPcVPyTSxoHzVPFMLVMsc4P1VSUTynXRHQ4/wpllLTI DhVTTEkXnXEuAV0UT0fUAPyUSTxRLTPPIUUFldRAv9uSx0gPBJXOPQFdslMNE12x1mCDJVC6/ygl hb5Rf11ss/1Yc1JTZ5+V09L+wJzNz1frPHVEbqud78jsrG2z/kZd46wtySwT5fY6Y1f9NRt400W2 UsoykrdeEwmRdxDVlG3UVNra5VBVXSs0N99eYnUs4cwkWpjhfRvei7N/3TyP2MvoKxJcasWV89rQ RCaK34nfk3jklM+C+DWTlVQZ5phlnpnmmm2+Geecdd6Z5559/hnooIUemuiijT4a6aQRmmUdrZR+ 2qtTGBrCaair0kOArLUGiWepp16karaK0JpsXPo6AAMS1F6b7SsECDu0r9PR6wCy7bbblroEYJvv vknIQICcYPZa7mngJisAuzHIAIPGHb9b8LX29pvytgMfvHB6Dg+rbq0x2GCDKxx3nHEMyt78ar5L WHt1tUt4/p1ywFFPK3N1hIiLgawXDz3r0hfPYvTGs+barLTZbh12EpA/vu8MIpdL6mHimYeY6aeP Ix5m3EpcgN0BD/53AUTPIPTgLzfrAMpbZ5715PkWoK9gGnjggXjoH4L+/OGgX5j7p5+9KgxoHPkA l4nGhY6ACATe87oyufatr32sI4EI3Mc27dVlD/OjHwUo8IAGmACEHqRfCBmQPw9qcBgPYGBZKrG7 DfwuE6AjIAy1gAEACkUAr9NhCRAAQeWtL3kVXJvz7LKH/JlghA9AohI/qEERxuGJ/IPiBdWCtivI cAsIxOILCYiJFUZBAWEMYxLG2IQylhEgOdwhAUpAADbq/pCNP1zjDneoASqiQYxoRCMTxrhHMOYR AHkEZDP2Z0JDHjJ/xFDk/O6IRwWQ8ZFD2cMVOaAF0CGwkuQL3QYymYXQffEJeoykHyGJBFK2Q407 VJsbX4eAN7LSjT2k4+tOQIc1iNKUkTTjI0+5y1LmMhslROQwiYlIEzRyCrgcShUoyYFLcsCZlHwm NBUIOg2UAXW9hII23RGANcbxhwRwpRvfSAICuG6NJ7iABUC5BG6GUpeOdMI7SVHIYYbQhCagwBKJ SQFkJpOX8XQKAzTJSWhC84qgi6YmE6oBh1bAGm3o5RnFCMxAjrKi5DiABmYJOx0er6MnEGkHIPoQ efoy/pcUvWhKBQrJlq4UGwGwQDE5eER9PqCDxDQBOwWRUZdiFKYstSg9e9GHSx4VqUlVKDRBIYTZ TZSXpVQpRV/qCwac4I0d1WobCTDSC0DUDLes6hmlGlCYQtWPRJ3EHvh5yJtusKY5NSYFGnBDnway rGbFKzBVio8qVEADShXsQTnQVCL0dKy6BORU1fqKA2QAq1ulozhF6gGSgrUhbICqEhZr1rvO866N NQUDLNBWE8Z1n/qsqWmVSAaTapaUnbWoUC8q2lfItALUHOxBOeGHzA5isyvtI1BrW1VnBKACIh0n OZkr0spe1rd5k2hiyypcjNLTp7YtxB4qAELvfheJ/vuE6wjBq88ytHObafUsca37S4DooQG5Jex8 mYrZ3xJis4ydbXHdQdoOOBfAzrXsV+1LvOmCdqjr5Sx2FWtcWJC2Aqkt74QnzMGSBkLBCT4rcanq YGxUYg5i+AIn5nFDBGtYv+2tLT64e4EOvBjGBFbGEAwM3AZruL3D3a97lZkNEEdYwhSusIWtYdcb bxjJSO5rPoyAgThkwBMZiIPjaFxjG2f3ujresHZHAY9FVq8OpRAkj2XbYXiG1sOOhQOQOShkEHIQ zmRwqo3JXNElj3nJ7qjIEKjMiouYeCkVOYlFAK0WI1ggzolWNJxLit6z2GEad6jDSQrtFJZcehfc /lCZEeSwCQqAAc6gNmylqSJoVZh60KTmCaZZvQ+/EC4OffhEb2cMtrjcIg+UxoUt8KDqnbQa2Fih WzoU6Yd5rAMuwQY2W4TtM8LVznB1EYeyXW01zkGbFbn4p7W5bRNqL7vb4V71t1ktbnOPGyutTgJY zt1ud78b3vGW97zpXW973xvf+db3vvndb3//G+ABD7fL/EJwgceLZbvSk3we1DGEa2kNG4MUZTAG JADxK1QQb3fIMP4hR6WqVQ9XeJjg1XFT0epT5FKYygFicKZkK0JRUs68QL4q7jic4U0CGcshdS6O CcvjlrrUc6TVno3JXOPvwdfENEadadHJ5RHH/lWf3nSrmFt84oQaUMhzpXVX+QhE4cLSy1IOchCh fOs2P5nCO+7xs/eKTyuPe4KGbqV1eQvu3ToWyblur7z7fE5ANzrR3wWkwm+IS0byGG9orne1Nwjq 5tF53vtVdVQtS+yHH3qxSkOotk/I89Ja+I5c86hecZ7vj59CtsK++LGfyevPQhirVI/4vwsMYLZ6 vKc2Nfu1a55MSCJXidhlJnf5/ve+D/7BzoR84Bve+fq6OsQXdvLi797qaE+7weg+fVpV3+1Q+lFr 9BT7BZnf789ne+ZRxKmUMwv66N8L6GGFef0U7OmSn7z+r4R07a++YupvW+5P5i6uQ6BF8JzF/lPS T/lET/h0j/sikPT2Dh/wBTiibuTcwQIvEGXkzvv8ZVnCT0lir2AWsASnDuEwsAMr714+zxVckOxe IVkE8GK6RAEDMD7IZPAOcOfm7uBupmQ4kAV/0GoSrhlgsPmIUAmXkAmb0AmfEAqjUAqnkAqr0Aqv EAuzUAu3kAu70Au/EAzDUAzHkAzL0AzPEA3TUA3XsN8WwA3fkA2b8A3ncAHiUAnnEAnwUCjqUBDo sAngkAkAUQnc0A4RQhAB4BB3IhHVgA4JMQkacQn88BH5sBDzYRED0SYucQoA8RAdURDh0BERkRIr ER8k0QlMsRNDURRVMRBDMRUJURMhcRI1/jEPPdEVbZESbbEWSTEhZDESZfETVdEXWzEXhbERWbEW 9XAVlZEYk3EWnXEXQXEUebEUh3EVoTEYi5EPY/EWR1EPudEbu/EJfDEbZxEWp5EaLdEUm3EXrxEa 3ZEd4VEZwfEZ65EYX9Ee3REX0xEgmHEZg/EdjxEZA7IbtfEUxTEfB3EbERIefzEZB5IfsSEV/3ES G1Ig0dEiCzIh7REf2bEcG1IhnREiI5IUEvEjJ7IjoyAbtdEg41EeL5ETERImi7EdSbIX5tEYFzIc TZIhFbIlH/Idf3EndfIgiRIbMdIYQdImXeEifXIdl/EewXEYm/IPcfIphZIn/VEUsRIj/peyFKxR JFlRKrsSKE+SFqHSHMnSHKuyK5HxLL0yLN4SLudNLucy3urSLt8NL/OSL/vSL/8SMANTMAeTMAvT MA8TMRNTMReTMRvTMR/zLAYAMidTC7lnAC4TMzNTMzeTMzvTMyXzM0NTNEeTNEvTNE8TNVNTNVeT NVvTNV9zAIZHJwQgAdzIABKANAEANneTN3vTN38TOINzNHVTOHkzAQzAjRLA0RBiANxoAJaTMmUi AJqTAOBHJATAlawzOqlCANxIOyPiAJDzO7ezKrAzASTiAAggAXyNPFcCOaETFgIAASSzPcWiOdmT DQKgOuuTLAYAAfBTDfaTP/uTAAB0/goMwAAG1CxuE5VUUEFXjQDg8x0E9EHJojvHQQAStEJLUiYo 1Bk81J0GCR9GKZTSIM3IgRanUS2hIBdhYiSVkiKd8iLP8Sn9cEVdIUOx4UJLlIxc4UT3aptg4aV+ NA1GUkUDoUVf4kW3siiFMiQrkknbsSexIUKfwQDoc57cSczwSAqIVLPMqCTbMhyR9BGJwkijtA6T EhHzsCbZNErflBCWNAkG4Dw/9IsEKp4+q0f3CMuGVI9MyaV6VFCzFEjzlKpClEQBFa/4tJdodC0p Uhp/Mkkj9RopNSbT1FGb0SgvFSujsRPR9E090U3FElO9kS0NUiNvFAl29CsIAIy0/lRRgXTBFFWx BpWzBDVRa3Wv3ilRCxVXwTRWOSxY2bIm1fQoA7JMpXQhlbVYlxVOmfQWoTRUl1VUIxFUc5JUHTJG W7FZY9JN06BAmyFHg/RWh5WPftVcYbVce3VPkyldW2pIb1VXd9VWpTVapRVN2zJZt5ITK7Jf/bVa nzRf7ZUmPXVNMREt1VRFF1ZGtZVZn1ROlaBKfYFOX7VcffVcaXVQ4xVW2TWl3BVjPzZWL3ZRN5al Xupep1VgITJJ+dVlo/FlYRYWubVZCRZfHxIdddJZpXRUGZZhBRZafzZik8AAxtMVLtNiTXZklXZe OXZdl3ZXPaxXOdZpS9ZcPSxl/mf2ZVN2EPeVTTH1YL82ZsVWa1e2YAe2TQ3WWhN2TLtWZd8WX3Wx U9UgAYy2FBA0aWV1Xi92auv1ajUWcHn1XdFVXUeWrELWbP0VZit1H8P2Z+GUa2sWYEsVSgESWeV2 X7lWYdt2cx8WcgUBaX0hAer0zGRVZDO2UBl1l3S1wfZ2b4MVzY5sVm1Vr07XKdESbjNVH70WbW3W YTcXbJ8xUlmyVCkXUot3RmmUGYsXYq2yIIcWCUK3F6SXKuDVR0m2GaA3IrS3K8DyCaj3FcC3Kax3 S/32JlV1Irh3K44UDcS3FNy3KrjsjwrXF7RyJOz3LK4SCuB3FPh3Q8PCfyUh/oD/lysGuBAMmFwL gXxfwUvVQH4dWCIa2CokeBIQeBAs2BcW+HrLtxkomBRelyg82IMjAYMDoYSFFHU3+IOfYYQnAYSH QoTx4YTZYIafVps+q4+kql1tF4dPqXZPN6r4SJQWuHWV1mrltVaLeHB5mE/5a1HxtIl9OKiOOHYX zLhCa8sCdYf5VosRlxBqWA3AmFY9dokPt8dY14jhtW/HGFi9+G8BN3VRir3Q+I3p1XBhd4nPSojx uI7XeHbj2I5DVooFOV0PGEthQYwDWWqZ1ogxtmpRl2oJ1Y0BtWnzWF3ZtZKjCoQrOY852XQJmZHp N0TTuJOzNE9NtoWZIJGn/iCR/RhROdmTi0uJu5iLfwpqLVleQ3mSHbmWSzaIgVhEPbl1/xRqY3nM mNhPg5lwj/mTkflPU3kJcFNcSRfDCpmU4dh1Exh7QTmQL9l8qXiZv5mOB1eTgdVphbmNiZh2tbmY z9mab1mRwRSalaBoxVVDe+qdo1aXsxmbG7mMyRiXSXacX5iXG5mf47mUE3p2D3qNNxmduXmsLHme JVZCS8JVgSufhcuKh7leq9iKVxeKuxlRt7mjGZWYhfikbdeLPZqPXbeJi3mKodhQZ7p0mXaWm1mQ 06rLwrUZJrZnJrp6xQKoAYBVRfeQd2aox1eoR0Gaj+uikTqplborHtgJ0Xy6p+2WgLdiXJ+hqLO6 K0D0CLHaq5uiq52hOw10rCfiABBArHvhONPaKq5UzwjgqOG6KJqTyebTrpeiOSuaFOh6r4miNiFC Pw0ArQP7uBD0sGmYrRF7NgE7I7oTrB07JCTbr7naOS+bsntBAJqznl9iOsnpNouTtEvbtE8btVNb tVHzOMlJOXUCa1Zbtmebtmvbtm9bM4dnsTebt3vbt38buINbuIebuIvbuI8buZNbuZebuZvbuZ8b uqNbuqebuqvbuq8bu7Nbu7ebu7v7LoIAADs= --------------375270014377334515585562-- From sip-bounces@ietf.org Sat Mar 10 23:10:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQFLT-0005Cn-BS; Sat, 10 Mar 2007 23:07:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQFLS-0005Cd-9i for sip@ietf.org; Sat, 10 Mar 2007 23:07:42 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQFLQ-0005rV-OT for sip@ietf.org; Sat, 10 Mar 2007 23:07:42 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l2B47Txg021761; Sat, 10 Mar 2007 21:07:30 -0700 Message-ID: <45F38083.9050408@ntt-at.com> Date: Sat, 10 Mar 2007 20:07:31 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "sip@ietf.org List" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: jmpolk@cisco.com Subject: [Sip] Review: sip-location-conveyance-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Draft: draft-ietf-sip-location-conveyance-07 Reviewer: Shida Schubert Review Date: 10 Mar 07 Summary: ---------------------------------------- Some clarifications are needed for it to progress further but generally speaking draft looks pretty solid. GENERAL QUESTIONS/CLARIFICATION REQUESTS -------------------------------------------------------------- 1. Dealing with multiple location information. As geolocation can be populated with various location information some provided by UA, some provided by intermediaries, it may be useful for there to be an ability where UA can express preference among location information it provides. Currently the spec doesn't say anything about how UAS/server selects the location to be parsed when there are multiple location information. Related to this, section with UAS behavior should elaborate on when 424 is to be returned. Is it when one of the many location information was problematic? Or is it when all of which UAS tried failed? Obviously there will be variation but some guidelines may be helpful. Also, desirable behavior of UAS/proxy handling message with multiple location information may be desirable. Now if we don't want to deal with multiple location information, it may be better to change the relevant text from MAY to NOT RECOMMENDED. 2. Section 3.4.6 Warning code 706 Conflicting Locations Supplied > I understand its use, but considering proxy may add Geolocation header with reference URI, it's out of UA's control to restrict the number of location to be conveyed unless... 1. UA can tell the proxy not to add location 2. UA can find out if location was added by other entity in which case it can omit adding location itself and have the proxy add location or route a call through other proxy which may not add location. 3. General problem with debugging the warning code and 424 response. > Because the location URI can be added by proxy, when warning code is sent, it would be useful to include the location URI (cid, sips, pres etc.) that triggered the error/warning. This would allow UA to see if location was added by intermediary, which location was malformed etc. 4. Section 5.2, 5th paragraph, 2nd sentence. > "but all MUST point at the same position on the earth." > This is not something one can enforce, I don't think UA generally has facility to translate geo<->civic. MUST strength seems a bit too strong here. May be SHOULD? 5. Section 3.5, 2nd paragraph, 2nd sentence. > Semantics of Require header with "geolocation" option tag is unlear. > Section 3.5 reads as if it is to request UAS to send back location but Section 5.2 merely implies that UAS understands the specification. I believe there needs to be consistency with the semantic. 6. Section 5.2, 3rd paragraph, 1st sentence. > Do we want UAS to return an error even when location information is irrelevant to the dialog in question? Imagine a scenario where Alice's phone is set to always convey location info to her buddies even when the call has nothing to do with location. With the current spec simple call which has no business with location would fail if for example Alice's presence server is down.. Again there is no MUST or SHOULD on this paragraph so may be it's OK. 6. Section 5.3, last paragraph. > 424 (Bad Location) when location based query is not permitted seems a bit odd. It's really not location that's bad, but it's the associated policy that prohibits the server from doing what it needs to do. > I didn't see any appropriate warning code for this but can we provide more helpful error to the client for this scenario? 7. Section 5.3.2 > Proxy sending error when there is a location specific problem seems a bit problematic to me. I think you need to be clear about when this is appropriate. (malformed XML, can't decipher etc.) I think we want to prevent a case where proxy can't process the location information properly but UAS can. The only time proxy should return an error is if it is certain the location specific problem it sees is also problematic to the UAS. Furthermore, we don't want proxy not even doing location based routing to hinder a call just because it sees problem with location. NITS ------------------------------------------------------------- 1. Section 1, 1nd paragraph, 3rd sentence. > The recipient of the location is not UAS alone as noted in the 2nd paragraph of this section, so you may want to say server or UAS & proxy rather than UAS alone. 2. Section 1, 3rd paragraph, 2nd sentence. > I think you mean "target" where the text says thing. OLD: A PIDF-LO is an XML Schema specifically for carrying geographic location of a thing. NEW: A PIDF-LO is an XML Schema specifically for carrying geographic location of a target. 3. Section 3.1 paragraph 1, 2nd sentence > Missing a closing bracket. OLD: The Geolocation header contains either a URI which may be a "cid:" URI (Content Identification, per [RFC2392] NEW: The Geolocation header contains either a URI which may be a "cid:" URI (Content Identification, per [RFC2392]) 4. Section 3.2, paragraph 1, 1st sentence > It reads like the spec creates a new IANA registry.. IANA consideration covers all of which has to do with IANA, so I think all you have to say here is that the spec defines a new SIP header: Geolocation. 5. Section 3.2, paragraph 1, 2nd sentence > The Geolocation heade MUST contain one of two types of URIs is misleading I believe what you want to say is "at least one of two types of URIs" OLD: The Geolocation header contains either a URI which may be a "cid:" URI (Content Identification, per [RFC2392] NEW: The Geolocation header contains either a URI which may be a "cid:" URI (Content Identification, per [RFC2392] 6. Section3.2, paragraph before the table, last sentence. > "is" is missing. OLD: Discussing location using the PUBLISH Request Method out of scope for this document. NEW: Discussing location using the PUBLISH Request Method is out of scope for this document. 7. Section 3.2, 2nd last paragraph, 2nd sentence. > Confusing, needs to clarify that proxy is not allowed to modify the pre-existing URI values and associated parameters. OLD: A proxy MAY add the Geolocation header, but MUST NOT modify the contents of an existing Geolocation header. NEW: A proxy MAY add the Geolocation header, but MUST NOT modify any pre-existing URI values and its associated parameters of an existing Geolocation header. 8. Section 3.2, 2nd last paragraph, last sentence. > location-by-reference URI not location-by-reference. OLD: Therefore, a Geolocation header added by a proxy MUST specify location-by-reference. NEW: Therefore, a Geolocation header added by a proxy MUST specify location-by-reference URI. 9. Section 3.4.5 > I believe this warning code is appropriate when PIDF fetched via SUB/NOT doesn't contain the LO portion. 10. Section 3.6, 1st paragraph, 1st sentence. > I think what you are trying to say is taht, when Geolocation header is used to include a location-by-reference URI, sip, sips or pres URI SHOULD be used. Isnt' it? Right now, it reads like when Geolocation header is set, URI with one of the scheme should be set.. 11. SEction 5, 1st paragraph, 3rd sentence. > term opposite UA sounds a bit odd. OLD: SIP endpoints SHOULD implement S/MIME to encrypt the PIDF-LO message body (part) end-to-end when the intended recipient is the opposite UA. NEW: SIP endpoints SHOULD implement S/MIME to encrypt the PIDF-LO message body (part) end-to-end when the intended recipient is another UA. 12. Section 5, 1st paragraph, last sentence > Unclear whether the target of TLS is the URI contained in the Geolocation header or the signalling path which message holding the header is conveyed. 13. Section 5, 2nd paragraph, last sentence. > "does" or "to" is missing. OLD: When using location-by-reference, it is RECOMMENDED that the URI not contain any identifying information (for example use 3fg5t5yqw@example.com rather than alice@example.com) NEW: When using location-by-reference, it is RECOMMENDED that the URI (does|to) not contain any identifying information (for example use 3fg5t5yqw@example.com rather than alice@example.com) 14. Section 5.1, 2nd paragraph > The terminology for Geolocation values seem to be inconsistent through out the document. It would be nice to have consistency for the type of URI used in Geolocation value. May be by-value URI and by-reference URI? 15. Section 5.1, 2nd last paragraph > "new Warning code" sounds like warning code yet to be defined. If you mean the warning code defined in the draft, it's better to be explicit about it. 16. Section 5.2, 2nd paragraph, 1st sentence. > "to" is missing OLD: A Require header with the geolocation option tag indicates the UAC is requiring the UAS understand this extension or else send an error response. NEW: A Require header with the geolocation option tag indicates the UAC is requiring the UAS to understand this extension or else send an error response. 17. Section 5.3, last paragraph. > "retransmission-allowed" and "routing-query-allowed" is an element in the PIDF-LO but it's only mentioned in the beginning of the draft. It may be nice to mention it again here. Regards Shida _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 10 23:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQFQT-0008Q1-3I; Sat, 10 Mar 2007 23:12:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQFQR-0008Pt-MK for sip@ietf.org; Sat, 10 Mar 2007 23:12:51 -0500 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQFQQ-0006ld-F5 for sip@ietf.org; Sat, 10 Mar 2007 23:12:51 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070311041249b16008i7mce>; Sun, 11 Mar 2007 04:12:49 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2B4BiGO006895 for ; Sat, 10 Mar 2007 23:11:44 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2B4BiDH006886; Sat, 10 Mar 2007 23:11:44 -0500 Date: Sat, 10 Mar 2007 23:11:44 -0500 Message-Id: <200703110411.l2B4BiDH006886@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <8FF54145-10A3-46B3-98BF-919D5BB651C4@estacado.net> (bcampen@estacado.net) Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <8FF54145-10A3-46B3-98BF-919D5BB651C4@estacado.net> X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Byron Campen Oh, I agree with you. I was just wondering how this case could have gone so far off the rails. Well, how many bad programmers are there out there? Now think about how many bad patent lawyers there are out there. Was _anyone_ in the IETF contacted about this case? If not, why not? It seems like the IETF would have been the obvious place to go for incontrovertible evidence of prior art. Actually, the major conventional source for prior art is the US Patent Office. In many areas of technology, especially the well-established ones, the companies that develop it patent every innovation, so the patent records are a nearly complete database of everything that is known about the subject. The second source for prior art are the various journals and magazines. Beyond that, it's hard to search the prior art, because there are no databases you can search. As for "incontrovertable", not much that the IETF involves beyond RFCs is incontrovertable as to the technology and the date it was published. Among other things, we so carefully try to erase Internet-Drafts after their 6 months are up. Wouldn't it be annoying to realize that a patented innovation was described in an Internet-Draft two years previously, but there are no copies of it left? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From wysockilr@hinet.net Sun Mar 11 04:49:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQJjk-00011w-2Y; Sun, 11 Mar 2007 04:49:04 -0400 Received: from 220-139-228-67.dynamic.hinet.net ([220.139.228.67] helo=hinet.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQJjU-0001js-AG; Sun, 11 Mar 2007 04:49:04 -0400 Message-ID: <9D6966DA.3C9C7A5E@hinet.net> Date: Sun, 11 Mar 2007 19:39:01 +1100 From: "Brande Hunt" MIME-Version: 1.0 To: "Scott" Cc: "Shelly" , "Guillermo" , "Brook Thomas" , "Annette" , "Douglass" , "Perry Perkins" , "Adele Kelley" , "Sally" , "Marie Black" Subject: Got This Thing 4u Content-Type: multipart/related; boundary="------------718472525464547863128065" X-Spam-Score: 3.3 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 --------------718472525464547863128065 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


friendly "Why," said throat sometimes Albert, too "he was talked about for a wee   "And you yearly really gather play through believe the result would be still burn gone "Mademoiselle, whistle mademoiselle!" arrogant exclaimed a voice frneed "Certainly; it done being at relation shot the same time perfectly un 
The two young men looked color business secretary at Morcerf courageous as if to say,- "No," replied speed the slow flower panicky count; "I take pleasure in sayin    "I, your excellency?"   
danger "And I also," coal said addition Morrel exchange thoughtfully, "have hear     
"My good colourful weight back fire fellow," said Chateau-Renaud, "the countbattle "Yes, I embarrass understand whip greedily that; and how would you habituahungrily whip "A preserve visitor?" tear inquired Valentine, much agitated; "wgentle "Oh, very reach easily. match Suppose rod you knew beforehand the  "Ah," clung cried strange sister Albert, "it decay is very lucky that M. Morr    fold bite "Have smile intend you brought it?"     "Here it is."    
insurance "My keep dear glue Albert," frozen said Debray, "what you tell us i    control "Perhaps you are right," curve servant rich said Morcerf; "meanwhile,"Brucine watch drop silk is extracted manager from the false angostura [1]"Some nuptial throve undress grand personage--a smell prince I believe they sai"Precisely, edge madame," replied live Monte ill spilled Cristo; "but I      
"Ah, because drawn grip froze seat your ambassadors and your consuls do  "Very well; and truthfully hope where is this metal house breath that I purchas  wish stone family push "No," returned the count.        
"Now you get pain soup picture angry, and attack church our poor agents. Ho         "I will come directly," shot slung morning cried voice Valentine aloud. The     
rain "Which ornament box do you hard mean?" fresh asked the countess."Oh, I am aware of that," trip collar country boat said Madame de Villefort"Now, then," encephalic cruelly hope said Maximilian, leaning verse on the handlattach ticket "Well," start replied Monte Cristo eager "suppose, then, that    "No, forget lest on knot squealing the run first demonstration I make in fav  "The count doubt repeat repair hop does not know?"  cut "How interest should I organization pour know? I have arrived from Cadiz this  
below blush "The one between the pillars apologise measure on the first tier--itinnocently low "Do you know question fold any other counter-poisons?"IT approval WAS really average pack cup the Count of Monte Cristo who had ju"I do not."        
"You say very unlock hate grain chess true," responded Debray.remain wash "Ah, that discovery is different; the blastous house you purchase is  "Close woke by rung here, river meant monsieur," replied the notary--"a   "Yes," save said Albert, "but frightened brick this cheese has nothing to do wi     "Did you observe tail any rice one circle top during the first act?" assuit "I have often read, and squeeze bound read sowed again, the history ofAfter wet ornithic the usual brush civilities, rubbery the count inquired aftcomplain "No, madame, contrary dream to most slip history, panicky it is true;     follow value decorate door "Pardieu! every one exists."   "So coat near store as that?" said the supply Count; "but cross that is no     tasteless "I," cried tame bleed the caught steward with a strange expression.          
"Doubtless, but not in jump squash insurance the same way; dreamed every one has"True, pocket sir. The two knit favorite studies year reign of my youth w      
--------------718472525464547863128065 Content-Type: image/gif; name="fgtagouwsytxaj.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhlQGQAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlQGQAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW6739SAIACv2+/4vB4tEAz6BAUGB3uFhoeIiW4B dAAHgQUIfggIjUMHAwYChIqdnp+gnwMEA0MJBagCAAKaRI+RfgmbobS1trdiB3SnpUICCKgDugGc QqcFpb+SuMzNzs9JCQSbBgZDv8GjqkMBwAUJQoHb0OTl5od9BwcGsKyN3agGgb1C8MEAAwmcmOPn /v8Acw2gxEgAKgSyGr0qMI1UkWOoEhATcuAUgWIBM2rcCCUApALpICGgB0AkIzmEDsz5CPIaQlb6 OMqcSROAR1SRJA3AuUwI/rtIdLThu3gzIjdVxy7WXMr0XNGD0nASaHRMEjZV4mxCAkdk58FZTcOK vfUUFYGPvX5KSoBgaklBjiD1M4gz37SxePN2KisJkjV8A/4M45ZJwCmExbBFfNVPr+PHagLkE1zv LM6V35zoSiCLyFNrv0hCHk06jICPbbcxgkTA5pwqKj+67VO6tu0up7195RbI7RXFQDvSVqOguHEF R4yXO668SPOZx6s8BzD9TsVSfMepbBxHJPcjKhMEpiQxDfPq1IuDQr7kvHoi6AO6Zx9lenw48Eph 0n0Ro5YA7PyVhC77pcKaf2M0F90t98H3Xnr0QSjTcw0qUSEe9nBVVCWW/nDBDxLqeDSSYgPYI1qC D1Zn34IOxseccylS6N4Q57UXY4QztsiihA9C+CJ6OeqI441JqNjjfEasyB6SMF54xUKC0LFOKt+F IdlZrDAUQFVbmtWhGEq2KOSRNdIYpIRCsDjfki8WSSZ9a5oZZJtprrljnHKqSSQSRg55Zph1znmm F8DdVRKHZaTjFTKrSKRYH5eZAWigclaK5qUywnmjpu9lyoSneVLKJ3WhCunjpcntiSmbETaZ5Jus ilkpcguCiqoXi5rVR5VbDIONMH45IqVfC3FFxqSr9ihqqn5a2qeltzJb5rJ96tlqssvmqaCyMGbr 6rfUvikrtj5OC8ZA/jilMkZupAx0EV1rceXVVMcIiCKnzWrLqZv52hpurJ+a+6++/g6MKp4Vdnrt uN76OymodpJhGAFtCfOFLn8sip0w9shTySre9AGMvWCq6m2gAIsKaMEQc8ushXvWKi642+Jr8L8J K/tstg/H7LIZBH7BCiltAWjWYAD8ZABb2xA7TxmZ5ktu1CgbfKeqTua8781A+iy1rdb+PO7OB89M 7tliyAGWFhiPEs9AkMKytC9e9hHUVxR/CQae0JYL69XT8n02nS/zCy3fXW+tpLlMlgqzwGj3vDXK TmqhzCBZVEQAW5t7+Yc9FH9cFHakZPiHpIPeSjjl0l4bnc4m7/jq/sKHw4q21bCrV+3ClbM+e9+S 912u0CUaYdDHVKgkzCMjbf4oRWrJs81P7zJ02uZ632Zb7zIZtPkfrwHAGYJOnHY0gLEsJKDGBan0 VYAnaS//8I/lepDz2Q9oCUQMYcIxPgd5hzeIMhJ4jCQw5JtfaWSXl5+kiye8Mh6WKIKueLijHt6g R1X8YD0sJVCBINTLOs6iGwhq5kAukUo/qHcNnEhjJOoIoQxtQwxdxIJiwTEC0oagsWsYQDfGWsVu QNaO/M3wiKVRnsUocpJRbK4YC0GeeMxnlMp4ySZLiyASt6i93FQsg9dgSzx8AY4NKcQ7XEwjFx0I Eng1YmlqUUVF/lQxusqUrginaYUa9/iYoW0DOBIBhm84UxSlJABz2FCKTcjHjpGsggB65KMkZcKI cFxRfFK5CT0KgxaQcYUVJyqCRwxADIg4cpKoDIi7CNFDkAFDEuyYBh1O88KccFCRTZCDMR7YklT6 8hlbSgZc4hLAuPjFK8s4zSYWpYnTPSEfXZLKKn9JTVvkZpj58IUD/1KN953vLr+4oxQOk66P+eGD 1UwnHvygCdARYktBycRu4oYMujBkJ0qZCBWAAwubOFOdANVDYNBVvX7iQxV+6Jgj1FfIfGjxCVSU hEoIEtCK3sEgoAHGHMDYqEZBaRsau95Dn8AJte1ijBZNqRte/vEXVqiCeu8kJShxqCU5RMIhMbSc OMMYSX8s4Kc/VcMChDDUIxS1DEdFah9f+SVkbmOKmjAMTqphmLX1KhCnpElSk4oFrhp1CV41QlgT MdamkKgen/PGJyXSCmVMw6pdCOZwtFqEskrBrkQFKxPwWgi+0qRjWwIGOJJCCJf2bzvozIJLjRGT mXD1qEAVKwCCOgSgFjWydaXsZSur2coaNaiQnexkt0rZuoq2tKbN62hDq9qhbnW0nr1sZ1Ur2tUS AbOnTUQUswQXewqDqqTAiN2+cJNlxFJtHHksbR/r2s16tra3jW1rpQtdyUK3udOlbWydm9rcZre2 qIUteLnr/trnehe8zw2vIRaFGbdssHj+ecRZjJg8NsrikJJByEaUe93uche93c2ucu0aWvIuV7Ks RfCB+1vdBSd4s+X9r4M9URRreEWOrCBlEhZlKLZFRYV0Q0Bin8HfBE84vdZFcYNx+9W8Gni16i2v dqP7YtZ61cbmhfB5cWtZCSMCG5U4Hn2JwM/yYEGXWCwnQrMakBKb98TffTKAnYyEAkP5qyamMZR9 jOMJR9i6NwYFNgwglFyyRBMOgc1AeoKPEspipCSO7oJzrF0uU9fAPn4yZJ2b5R0n4cFX3jKd51zj UACIlCMeAhurx2YobOeH/eOGfWXS48yGebk8vvFs91zo/tsCurSWxbKU5UxU1Ia6wTDWs6lVTdo+ m4PDUzHRKuZQWCbALTyNbrO6VLpXJbhaC35VZ4GK+JGXRkKmlvDVa/JzDb3tJIi8/rOvR72FYFez IhAUWSaTdhAn/hGH5jyaElAS7Sqs2gvqjTZEkuFFtyxkKlil4wALG6ly2xsa+0GesMDSsXf7RNyK wWUl703wWhjGiCRSDFc2+O97GINkBY84M5DpNi0Jgb2+GOCwWiPxjuPi3YlMTF2g58JHwvkx6bZC nqtd6VJz1uNx8AYpsWoJhUt6qnMFYcp/XeUZdwHUsn15V+/NXllTJFiXGFpjZRjjyKa8xdamAtBf /nQo/lRd2MX27c0tLknQyrbHXhev2CH8YFBztuxCF7ttzw50zWI31XA/NdtL7Xa112ZipAh4SSER mEk6/esut23dp+t2wK8ds4jfc9rXPva3e93xQYdt010+dRZrr5K5wRwWl/bPPQ4+8YGPMaYFj92/ Sz7sbA9vpsUa9M9HHvWeprzi7a5Acl/il65/feTlrPgIl/60v3976Jk7e0+H2vV0N31mZS/0q8Oc KbkffuB5P/fj//3xzTV18VE/+diLd/CLl/7Uaf/8sUT/+9yXMfEZf/2zk3764Id9+tEv/dPXX/7Z Lz/Kd09//AM47ePXeFTHf/4HY5yme80Heo03WwOo/n9H5HzzA4EOOBoSWBrFN4EKVIEWaHkY2IEe +IEgGIIiOIIkWIImeIIomIIquIIs2IIu+IIwGIMyOIM0WIM2eIM4mIM6uIM82IM+2BQHwABCKIQ/ WIRFoA5DmIRCmGhGOINDqA5QiIQNwABNyIMMMIVIqIRJOIVIlFNV6AlB6ABaOIZCKIZMSBpe+IWH wAAOIIZt+IZwGIdwSIVd2IVReId4mId6WBsO8ABy+Id/+AAQQIdHlIbyo4eImIh7CBkOAAGO+IgQ EAGOKImQWImQSIhPkDu0kxGGWBvDcBKgGIqiOIqiGDSOwQCSGAGSKAGs2IqsmIoSEAGuKAGQOGSv /tIkm4gIZ+gIILKLQEiKwBiMwdiJAZOLt9gteeAAqiiLskiLqtiKq/iKzBiLy4iJThAj5VBJn2gT J0E+ugAFmlgyyiE4XfCJwniOwsgAAweOYpMqx4gHDbCMEjAB0zgBrEiPz9iK9EiNqtgAvoiNtlMn 6VE1pwI0eNiNlQSK3LhQd7iOAYOLYYCNZkIG5kiKn6iO6CiKT8iOA3mNxngHASCPEwAB82iPsSiN 90iP9hiJEUAB/lgfmtKRAEkrCkMjE0mRiEgMjGCO3KiHRJiJMYkibjIGFckIQmiU6niUGKmTSDkM TgmKQ2iLDtKRAzmOMSmRMkOVQBOPKLmMXsmM/l/5jBRQAQzgi1XJJhBZk1pZkESphzu5lAhZQ3j4 kx45kZtil6ySl7/jjrkwilGphAGAkXAZmIQZhGUJlQ3QAFKJl7OiO7FSk5DpmGkQABZAAbN4mZjZ imOpmFMgmVopmWpJJmsJBkV5EnCZlEk5ikFoAdZoI4xJKgLpmGiZJjepI+9ImhqJlKlplLwJlbw5 mIGZmItJlaE5m8UpkzQpkJPZABWQmc4pAWNZAZzZmcmJnGh5nMrZjlxwlLlpmEypjhUZhBVgAcMZ m7NZNdjpOLY5lX1Zir0Zitzpl+AJn8IJlDeJncdZI2o5mQxQmc85i2PJmuW5l9ZpnmiClR/J/jZR CYpOGSJRKIrMyZr/WJ0ziZzKaaB8Ipppk5EcCoyJOZ1NkCP4aZzVeZ8JejH9aZn/KQEXMJ5leQUy YipneaH0UwbBCZzo2J8uapaemZ8kaqIww55W0qFECpUWkJhMCDsWWqCRiaHaSZpC2AAWUAGWOQFW eqVWegEBuoRt8KRpEISJiaOkqKMCapbhkp3JuS1AKqQaaiViWqTAeIWs+aIh2io9+qMImp5noIVS SqUXcKUXoKXjOYUbeQZBmQfBOYXnyJzSSadUEKO+c6cyOqk0iqLxCadxeoXj6ZBjQYaJOaVUWgGi agFzqoVowEDWEZhHKqaMKqBdeqKIGqZk/jirtJqEoFqWZvoPhjmrH0qotJqruiqnvnqFrQqexFGb n6ALUgqqotqszvqs0Bqto6qOkAGFtQqFgbmrdwgZqhqtWPiqXloIuiCnpFqu5nqu6JqupHqUwAoQ iviu2+oYpjmr+iRDF1mrC4qUgZmv7aoRUCgFUShC3XgJecigexSvStCvakhS/0pSA7uwLNivBKKw EBuxFFuxGJuxGruxHNuxHvuxIBuyIjuyJFuyJnuyKNsMCJCy90YJlMAEL/sELjsELruyRlCzRICz ZxCzPGuzLBsKPbsEMdsEK1u0ABC0OWuzSDu0aIC0d+CzvgS1YsG0QTu0L2u1UisERnuz/lK7tEqb tVcLtTp7tDObtGRLs1+rtVkrtGWrBExLtFj7tmpLtW1bBl5rBWObBHLrtnG7tmRLt3sLBnd7BXQ7 t2d7tlh7BHWLtkUwuHI7s467tpCbtocbuEjgtJfrt5d7tJyLuZVLuZYrBp4LBaPbuJp7s537uV0L upTbtK1bBYX7uWo7u5a7uI/LurNrurk7uLoru74Lt2aLuD7rtHu7tb3LuL77tmGbtH2ru23Lu1EQ u8tLu8MruZzLtau7u68rvMxbvcpbtNWrvVggvbjLvXqbuFwrvocbvD2rs8VbvqWbuew7vcQrue/b u9D7t8m7vYZbtvkrs2L7teBLvchr/rr2m737a8AJvL7Mu8Ch6wTkq77Tu7n8K8H8+7/368Cne7wa zLi1+72K+7zbG7m5i79eO8BTEMEJ/MEIbMLqi7wknL4dPL6ty7uLm7OpC8Iz3MAxrMA9DLMBbMEe fLoiHMIlXLMI3L7+a7+Gu8BSoMJ3G7pFbMRObMHuy8Q7TLh1a8NSrMQTnLd5O8TdW8Bmi77xS8VC vL4TrLjXG7ijq8NvjMVL/MLRG8QdLMVtrLk/XMUlPL9p3AYPfL2Cu8FAPMhHXL5NzMZGC8fwi71Z jLbgC7+EfL6H/MI3TLM5DLaS3Mf6u8f9u8lscMlpEMhsGwZgjMj6e74CPLmQHMBM/gy44Zu+U3zG cAvF3su3q8zKc+vKmszAY3u/ZlzBJxjIk0wFpMy3iUDMolvMlLyDoryzzCy/hvDM0KzFP3vN2JzN 2rzN3NzN3vzNFTsMgHmx4ExNuoAB6JzO6owB9VrOEXfO6ZwB6JwB8rzOA+rO5swA6pwBGoAB9FzP 6+yo+MxrB7DO/izPAG3QGPCSA82wAduF+mzQ/YzQCa3ODN3QCZuGO3lEBy3R/qwB/azQ/tyaGO0K CLKNIRQAGbABHNDSIC3SIA3SAE3P97zNhvigDzs/H80BgdqiFVDRGsABzgrQGtAAJX2EGFGwhTk/ Kk3PQm2u/yzPQT2q5ZrOGpAB/jX9szftlvua1TXBAP+sAUrYACvNz0LdqEN40PxM0uWchjiNrVBp rLaBATEN0nQaAGTN0h0gne+g1vxsAeQMsm6NrYoaIvAp12iIARtQ11hNEWDNAR7gohTh1xnAAeTJ kULaLeGKg0mNres6nxpJrUnEz3Vd1NzQADwtoUJA1zHNAVNdnkrqjptdBgfwAbZ927id2x8gAPia hF69FDnVkOvKoBr5raSh0qVt10PQn0f6DqRd10I9oBLJl3hw2/CKhOOprui6qYdIsCEy3OdIqr/N ic/N2PtAmJOd3K8NkyaqpiPKI7AKBbadNlPK1o+xD54toKVYkVI63gFxAOVd/tdGTRE5xdqlDdlk yd6x2ZhLqjA0WaJaMN8Eft0dqg71fRv4LYViWg+g2N9JhAGufeAaoDcBENTJzQEdwJpS4JmsI6kN fp6ZY9vX/aDD2tsMIKqB7Q8Z3qB7aI4eXhoMENQtPeQt3djcUNlEPuQecAEgap8zmaY/+uJcoNtU XuU3rt1Y7pLFCKlwEN9TsOPE6AodftlZcB+zjahCnuQuHdVpruaRLdocWZxQjqZ0PppWUOV4jtsY EJ3QSgEUEKggEOiCHugVMGQIagVeHqRhAOZKTYo/jgUqUqmfgNdqXuluruQpLtBAGZRWaaFquqQR nud5ngGBDuiDHgKonuqq/o7qF2DfF9rpj5robQDmRProiF6iZ24IQZ7kHmDpLe0BwP7rkd3k7Ogn nV6hUr4FHyACzN7szv7sz64BIzACq17t1h4CrY5Ohx6Qd+rgegnfFHqdxv7lEw6nti4d4Q6anO7e su4FlK7kve7rRO4BIHABqq0Ryw7t+g7t0h4Cg/7vAD/oTK7t6x7u5mnwnj7ux/6YUe5oEy7O9BqK 5x7rxCnudomXEN4Gjy3vkB3vv17vfM0R+b7vJC8C/R7wKD/oFADnrbPudP7eM+osFp/suZ7hifqp R9qrh3kSE7/iLp/wtrmfK3Xjl67k8w4Ce63iHCEAGVDyJL8B/p7yUk+W/gTPl97u4lcP4Z+O9XlZ 8xyuqjWuhO/E82R+62vapC0O47POnBcA2RxP70jfohetEU3t9Pq+AVIv9fbu6naupzRvp/0y834f BSVllPptkcLCCOIN6WXioy+v9mtgmIzaAcDu8R0P9x3g080tEwUd1f9s96Se9wHfoixP3ezp+H// magP8w6f+P35phPxidxt9lO5n5Dq4oswhIkpqhfQAb5P+b/v04Mapf4NCmTt+cif/BpQ6j3d/M4P 6KSv6be5pgVp+98+M2hv/bnOkKZ5+KppE0I4pXNPncjI4otDK8ga+Ye9rNKa89xJl/56/Mk///z8 /Pbf/JtZ+qOxr59K/pbDiNdAYBE2AgfAEZlULplN5xMalU6Rh8AVG2Bsud1uVmukjsll8/HAaDQy bfcb3q7M6XU73UI87/l9f7prDWxQy4vBDzFRkemg0bHxyjHykRIyYBEzE8BSbc3zE7RBaJS0dNTz UFN1VcoqcM0w1tOCQYz1FneTssgW4GqpsjF3uFWyMBY5WbmXuHnRVS1P2auQ2fl6r1LpEUoY+zs4 fHfaEOz7vE+SnFfdGv0dPj7eirB+UB6fyrK+MjL/H2BAVcHsgXEnEGEVcfQOJnT4EGKUhREpJtl1 qWJGjRs5dkTyy2NIkSNJ/mnIBGRJlStZsrRy0iLMljNp1gToqJhN/p07eeLz1hNoUKFDiRY1ehRp UqVLmTZ1+hRqVKlTqS5CUHXPVaxbxyDwqvWJ165ij3wFm8Qs2q/NyLY9KyUtFLJU1qp1MtfsXFxu y77lio1vWL93AVw1rFVvYcSL+wJmTPfx3cGEDSOpu+Sy3WuB801Gqpcv3sOWB1fG/DYwZ9KK1YpO LFZ0Y9ZTQDOOPRs32sJKMpNOnLtxbdeoD4NN7Vnw79Njjff2fTbvsOOKavcdzfo2b+WvH6u2Pnv6 6evh4UJfPD7ydtDAy7L/vTa8+uKyvZeXLZnubvTLcSuXHtmP6sDr7jomenuPwPtWG5C+0hJkkDbz FHsQO88uK5C//gW1a5BD/uoiL0LNYGuuvyZM2xA/9lYTrjnu+qMwQAkhDA25Cx3sEMEG41IPRwDl kpG8EZPbTUUFVTxuxxsn7JEMAeGzjUTxtENuQOeeZFLK+KgcS8QHhaTMyAVBxFIzFLWErMsOKwxL v+gMlNFDH488j8wQxfQSwykzzNC7M+fE0r8zOAsy0Mry9BPB/SDU0087b1PNOcv0S7PMIq+c0cH5 MG0SSDyL/K7SUDXsMck3Ad2SUyfTC3TJCS91tbUbWRx1xSjr+1FVBSP1zUziRA3OvOzsslFNO08F lk1f90TxzjB53PRTZ1htb5Vpo7DWsWurRVWwWwalcNdJ9/vQ/q8+vxzzu0bPCZcYbLvtzN1t+4g3 q8wIrXE4UPNqsVwM4/rzUTn/Gngma7kV9GATEyaY4YLpVeXhZRuemOKKLb4Y44w13pjjjj3+GOSQ RR6Z5JJNPhnllFVemeWbGonlp5ZlVgoQcraQaWadrBCA556LELlmm7vAuakrej56kq0OwICEpp1+ ug2eif5LaGWUPhprrP2RSoCnvf666QwEwKjioKuGmaoAsMYgAwzcfjtrspvqGuy6vRZb7oHNPhvt qA44GoMNNmjj7bfbxgDpqXc6wOsSnHa86RIkt1tsxZfie5oGUoGKAZ7ZHpznw9l+o3C3ef4ZKaaf hnxyElhv/vzrDPKequZPtoClE9x1R0WNzYv2PAPQSx9dAMKDF9302YNiHGzIV2+8da8F2Cr3Bh54 4Pbrt7hee+sf8ET72xuwnCcG3D6++DgOH/x49klXvie6H49+/udFoN9p36MKYA3uKaDgew8wgQkC KEDsce973vvEA+BnlDR8bgOjU1/wBjc4CcIBA+QriQAk18ESIMB5kQth6/AXtgYuhX/cI6ABV2iC Brjwetbrnwxj2D/9JWVpbRCc+ti3w+B9boIndIICiFhEJBBxiAo4AhLfwUEPEqAEBIBiB6HoOg9K bopXLIEGbhiFIjKRiUxAYhi9+EUAfBGNuVADAtnYRu6F/iIU2DtDGMkYEv7pkANwEBz78kjB4PXx DYMTYhPoqMQzGlKMhqwjNpzowaZJUXIImKIUoShFEGqxBCeoQBefUMhDJvGTUvDkERGpRjeeEpVu NAEny3hElRyADX/kwB45MEs80rKW7hOcBiowvjIsUpSlhEcAnlhFKxJAkpTsoOtESMUTXMACg0wC MKFATVASUpi3WCMqB4hAE1BghaikACtbac2NpIGCG6jlOnUoOFv6kYIakGcFaGEGahYSjIrUpzkH ogFMOg5//8zkCU7QAXrWYgzAxKc+Q2nGRGZziRBdRQAskMr/qRCAAORmNPlgxGl6dIyldGg+0cEA C+wR/qUpVak7azkHaWjwnookZUOVSFJnMOAEWRQoJqVI0A5cgJ6ak+ZHE7nEmYaUpthcJD8xwb9w tvGb/ssoNyngyz141KgRPWRNZapVm4KjARXQwErJuk4OuFSoV5UoGc1IUqxe4wAZyOlOr4hMgnrA oEFlAOoSClG2GhGpb1WqMJn6DJM+FYEX/d83L4pYAVJgkxokZTbbytDJ7lOizaBoBXJZ1nXiQaiS nWlRvcpVrW41s7cIQAUImkwCdICSPSXoXfMqja390q+IDKxpUVtGkaZWE/yrwACJW1wCgvMBFxWg cb/Zy6EmkbCm/SpST/sOK4TVrNn9rF73Klqiktat/paNKHBXYdIOzBa9s8XrBYDKXb7OMben3e1H yfvXa5i0AuBk7n73+7+D9oG6SbXpgAULDvyyF8EJpoPmELqIURJYwOK9hnAv0AELX7i9p9jCewGs W96G95Nf/W4oq0uMNFggv/rlb3/9SwvRYhXCEA6xhL+hBQysIQN2yMAa3rZhDncYxh4GrGUdig1X wBEUXEiJItJI4jRSt8hLaPJonZGGsP5vsSvGMpZ72WC1UvnJ4g1ziY2MhS30uBz8YAo9CtJm76LQ pFuW85xbvNeqmDnNV9hrm38slIX8+RFYiNlftCCKOVAgwf9LNFq97Dc+PzoLbxYJoCkdjL+YbQ1C /riDS4fgBUnXxBhs5sckImGQo1Qa1dzAyt5eMQvcIePTMwmHLlKtapoN+mOsxpynqSKMWmsjZ0PR Nd8oQc5gH1sjv640spk9aWUDutnRDgklaD0RNMRa2tnW9ra53W1vfxvc4Rb3uMldbnOfG93pVve6 2d1uky2MYPB292bYFaYhWadf9qo3JtBVHoMtzEbyCZa861Usad/qVyYSl4/U1S6B/cjeCVe4oRju KXpH/B0Ep0muYiMsSSmpWYtK18Cfs6GAYVxhaTq5vU8UqoZ/Cd8lH9bKIxZziEOG4v75F6z+Y3Az qGpcUdLTsl5+qX4bHUb2uZOiPA4qZh2rNdCS/k+r+n2th9MqWW1ylsXZcnU0hXw6hXJRrwxOrjqB PelWp9S3PnWgTNlKWQ3X0dmVzqGOC103IEe7kWDOc78ji+5lyNWmWEWsOJUdSWY/PLS+DvU1SQbv IXdV3M+j+F5xvfFVYlDTW/V0x4888Ej3ueA7xaTCE0nnmKe6nJ4l95s7vu+YQf1k6jP22itJ8Qh/ F7Wknqeo/6ron9+7yAv+IjWFy1DAQRRxzpX2Jbn+5jQPFpgOZfF8g0fyUc+911M+fBrd21KqT/yt lp+Ind/r3vt60awYRXKWF6jquCp9bthFrrTki1fLYT/ApE/6tSfo9K4u+IjvT3ov47ZE46wu/gGj 5QC1BWIWsOY45T7Qb+K07veKjukERvQI0OEWMEYg0AM1Yd+8BQRz4fzApfDc4v7wz+ZmLlaw7vEY b95ExmBYIQJhcAZXZgRJcF5CMAd/EAiDUAiHkAiL0AiPEAmTUAmXkAmb0AmfEAqjUAqnkAqr0Aqv EAuzUAu3kAu70Au/EAzPbQHGkAzDcAjJEA0XwAyBEA2PoA1HQg35IA2ZoAyXoA6TYAzXEB7uEAD4 kCP8cAzSkA8FUQnmEAnyUA/fARDhEBHL4A0HMQ7vsAwbsRET8RwMsQkw8Q3dsBI3kQ4psRPzcBH7 EBNJcRQ5ERElMRVBkRNb0RL3sBQPkRBN/jEOTREPY/EWaxESZ7EQNZEX7bAOVTESWXESa/EV0UEQ jdEWl3EThREVMxEUjTEYKzEXq/EZodEXdTEaRVEZjxEZcVEWtXEYxTEcsbEcr3EZgZEcz1EdPdEZ z3EVu9EbncETafEdhfEXrTEd31Ed2TEde3Ec2XEU45Ea55EeQ5EXi1Eak1Eed1EgCxIdHbIdIzIe ofEZIdIgM8EP7xEh//EU9bEZo/ETF1IcG3Ia13ERWZEUMxIXQpIk0dEelZEfQbIj/1EfaREmczEg rxEiQ9EmWVIT2tAdkxEgC5IoR/IXGRIbt/EjjzIcAZEawREoNRIcFbIol1Ien3IfuREj/lGRJLvy KU0yK40SLKdSKD7SLMMNLdPy29aSLbvNLd9SLueSLuvSLu8SL/NSL/eSL/vSL/8SMANTMAeTMAuT LgfAMBPTjnhmABrTMR8TMiNTMieTMivTMi8TMzNTMzeTMzvTMz8TNENTNEeTNB/zdDZCABJAigwg AUrTNV8TNmNTNmeTNmvTNkczAQxAihLgud5hAKRoAHpTMSsiAH6TAKYHIQRAkpBzOG1CAKSIOX1C N6OzOXVCORMgHw6AABIA26ozIg5AN4VTFQIAARDTO4fiN7vTDALgOM+zKAYAAdSTDNrTPd+TAORz CgzAAOrzKFiTkXyQPztCO8UzHegz/kCL4jmdQQD280CPwkBz4UGnYMrOoavESEID4hRl0gx0ERsY siS9chGyEiIWlBgS9JemSRPIy5WqSRX8iiqdQEMd8RAvcSFl8RYxQUQhggAI1AwMwDzJgLAyQUWz qpNa1EJxdCxrVEbdkEZv1EaZNERz9BbKMgoGADshlECDdLIstI6CbK3oiEhhbEUJKUzpa7yUAKRW lKt+S6K4Mizt0RZVcUah1CrrlCsD0iqB8UlvVCYlMk6Z0h+LESnLcRv7sA9M9Ba0c47QdEwpq0J1 a0wZNau6ClLPiEjJ1FLLdFKPNFMzFUw7FaKmcU9XEh6HcU4N1RVXMVW1kVBNtR2T/rRPU/VURdUV oZRU4bQXa9UQUzER7hMXSNSeJBVUpaxRi5VT1fRSjaq+NLVTIzVSa+pZmdVJb9Un97QnZ1UNg9FG JZFPefUTazVXrTVbWZVaybVcXVVPnzQq0ZUPdhQXrHRRUVRambVSm1Ve5bVCt5RFh1Vf7fVSofVf xwuYVPJWC5Zg8RBbDVUUt5VUa3RcUTVdC5ZJD9YrabVcw9Jiw3VVw5VKpcAAqFMTGjNejdVf69Vk MRVfk9VT97VeU5ZYXall8/VbdTVbW9FUH7YQT3ViV1IaFTYSc/Zhk3RUIVZVNXZaiVFih3ZUi1Yn EyEBQDYT9HNkm7Vl6ZVkhZVS/jVVZl/2ZDf1ZZ+1UquWZhmWZy+yaDn0aGM1Jy9WXMnWJ7m1YdEV aeOWXeN2bBEWE0T2FhLgSnGrwAqMX8+UytD0U4WMZCnrssyUzEiMardKca8yJNN2K21VbSVWJDX2 bXd1HDcXV0EUJyP3TeNUXV2SKaV0CvSWFVB3KBBXSO91GDo2ZfLRDFRXFWg3KFgXE0TqIJstRvnA djPhd4misIBUS183Lk9GKskgeBdheRtUKJo3EaDXeXtCev2geosUEXA3RVt0SAEMH7q3J8A3b390 Fa4XF7S3dR3MX1dBfNN3fUeifZ21Gcx3D+iXFdA3d7d3GOJXfVWWJPj3fXPB/n5nl3yD1VKtSbDG 6KhQ1HD71XGJtUvBNLca+F6FrGsPGIIhtYEv+K0AVlnTdKnYinFhVnc3+IEFV8pEmIKjzIMP91MD uAwGOIYL+EQbilPDllJ/y1jDVn7BaIdddF611mVBNb489WS7lofD9FHz1WS31oerK4lXVmWb2Gsb d3GlmF/Ftn5pGHi5OKGCGGuRNWB3+Gtv+EjX6moZOFoDF42rOIsxWGw5+GrlOIzHGIvlt4LJ2I7R WHfLFICZQIaV14up4FEHS4+tWGAp+ITzOHHf94IZNWat1owRWaaglU0vi46ptsjieI43+a8m+IWX eJOVir4keBFa81f7Nl61/piOIxmPe/hrkRhltRiDx/iRGbmPV9aSz3iSA3d9OVlaUwt/gRiL25hr 8biF/eBjf5VBrwqMxUyMEfmNqxh3cdh/2XiIXLeQrzmKsXmPJdmbwdlRgzmat5mRp5mSMfWR/5gJ 3DVRCcB7fZmo2NSCXXeRO1ihEhhgM6uDs7mU/5mbxfRx5Rmfc/mJ7bWfp5hxo+uSHXigrVlg7dmF ixcRtBM/l8CdQYadeWKjNaKjkQBR93aQM+ajbaKkKeKkUTkX2FOjT7omXNohhpcKMhoXInR6gQJY hyGkbxoobNpboJana2Knc+E5LzqobwIBgHpvm/moa8JHwYEARrqpReI3o9GBPKV6qjniN3l0EaI6 q1VCNeWBPQ3AqL96GAJAP8s6hpParDniObGakaCzrSniOWkaIOo6ODMSrpFCAH5zmSGiOCmJNW+T sAvbsA8bsRNbNgEgNHOTknjznNRGsSebsivbsi8bsyPzdNR6rjvbsz8btENbtEebtEvbtE8btVNb tVebtVvbtV8btmNbtmebtmvbtm8bt3Nbt3ebt3vbt9EtCAAAOw== --------------718472525464547863128065-- From sip-bounces@ietf.org Sun Mar 11 13:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQRzc-0003px-Hw; Sun, 11 Mar 2007 13:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQRza-0003pr-SB for sip@ietf.org; Sun, 11 Mar 2007 13:37:58 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a9.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQRza-0000n0-9p for sip@ietf.org; Sun, 11 Mar 2007 13:37:58 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a9.g.dreamhost.com (Postfix) with ESMTP id 6F0CAEEF95 for ; Sun, 11 Mar 2007 10:37:57 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DF5EE1CC24 for ; Sun, 11 Mar 2007 10:36:55 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sun, 11 Mar 2007 10:36:55 -0700 From: EKR Message-Id: <20070311173655.DF5EE1CC24@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Subject: [Sip] Review of draft-ietf-sip-gruu-12 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org $Id: draft-ietf-sip-gruu-12-rev.txt,v 1.2 2007/03/11 17:48:42 ekr Exp $ TECHNICAL S 3.2. A UA which wants to obtain a GRUU via its REGISTER request does so by providing an instance ID in the "+sip.instance" parameter in the Contact header field [12]. For example: Contact: ;+sip.instance="" This doesn't seem right. "+sip.instance" at best means "I want to do outbound". More likely it means "here is my instance ID". It's "Supported: gruu" that says "I want a GRUU". S 4.1. identifies the UA instance being registered. Each such Contact header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header This should probably be a MUST S 9. There is no need for the UA to remove the stale registered contact; the request targeting rules in [12] will cause the request to be delivered to the most recent one. Wait, doesn't this mean that you just accumulate this data indefinitely, if, for instance, the IP addresses change a lot? Given the actual operation of the request targeting rules, can't you just remove the stale ones? Maybe the way to say this is that you MAY remove them but you don't have to? S A.2 S = (AOR || " " || instance_ID || Call-ID || W || T1 || T2 || .. || Tn) Aren't separators needed here to allow this to be unambiguously parsed? within the state string S, and consequently, these fields can be set to zero. s/can be/MAY be/ EDITORIAL S 3.1.2. In other cases it is desirable to construct a GRUU that obfuscates the AOR such that it cannot be extracted by a recipient of the GRUU. Such a GRUU is called a temporary GRUU. The most obvious reason to do this is to protect the user's privacy. In such cases, the GRUU may have any content provided that it meets the requirements in Section 3.1, and the AOR cannot be readily determined from the GRUU. This also needs a reference to 5.4 as well. S 3.3. Once a user agent obtains GRUUs from the registrar, it uses them in several ways. Firstly, it uses them as the contents of the Contact header field in non-REGISTER requests and responses that it emits (for example, an INVITE request and 200 OK response). According to RFC 3261, the Contact header field is supposed to contain a URI that routes to that user agent. Prior to this specification, there hasn't been a way to really meet that requirement. The user agent would use one of its temporary GRUUs for anonymous calls, and use its public GRUU otherwise. In addition, the UA can use the GRUU in any other place it needs to use a URI that resolves to itself, such as a webpage. s/Firstly/First/ s/In addition/Second/. S 4.5. Because the instance ID is a callee capabilities parameter, a UA might be tempted to send a request to the AOR of a user, and include an Accept-Contact header field [16] that indicates a preference for routing the request to a UA with a specific instance ID. Although this would appear to have the same effect as sending a request to the GRUU, it does not. The caller preferences expressed in the Accept-Contact header field are just preferences. Its efficacy depends on a UA constructing an Accept- Contact header field that interacts with domain-processing logic for an AOR, to cause a request to route to a particular instance. Given the variability in routing logic in a domain (for example, time-based routing to only selected contacts), this doesn't work for many domain-routing policies. However, this specification does not forbid a client from attempting such a request, as there may be cases where the desired operation truly is a preferential routing request. Why is this here? S 5.4. Once a temporary GRUU is constructed, it MUST be considered valid by the registrar until invalidated based on the rules described previously. Once a temporary GRUU is constructed, it MUST be considered valid for the duration that the AOR itself is valid. Am I smoking crack or should this second sentence say "public" S 6.1. In essence, to select a registered contact, the GRUU is processed just like it was the AOR, but with only a subset of the contacts bound to the AOR. This seems weird as a note. Maybe it would make more sense at the beginning of this sxn. S 6.2. If an originating authoritative proxy receives a dialog-forming request, and the Contact header field contains a GRUU in the domain of the proxy, and that GRUU is associated with the AOR matching the authenticated identity of the requestor (assuming such authentication has been performed), and the request contains Record-Route header fields, the authoritative proxy MUST record route. If the request contained a GRUU in the domain of the proxy, but this GRUU had an AOR which did not match the authenticated identity of the requestor, it is RECOMMENDED that the proxy reject the request with a 403. If a terminating authoritative proxy receives a dialog-forming request, and the Request-URI contains a URI in the location service (either a GRUU or an AOR), and the contact selected for sending the request has an instance ID and is bound to a GRUU, and the registration contain Path URI, the authoritative proxy MUST record route. These anded lists would work better as bulleted lists. In addition, the following comments of mine from GRUU-11 appear not to have been addressed: S 3.1.1. call attempts. If the UA had made a call towards a GRUU (perhaps as s/towards/to/? S 3.1.2. I think an example of such a GRUU would be appropriate here. S 4.1: Can you show an example of an appropriate REGISTER request (cribbing from the extended example later is fine). S 4.2. instance, respectively. A UA MUST be prepared for a Contact header field to contain just a "pub-gruu", just a "temp-gruu", neither, or both. The temporary GRUU will be valid for the duration of the registration, while the public GRUU persists across registrations. The UA will receive a new temporary GRUU in each successful REGISTER response, while the public GRUU will typically be the same. However, Is there a reason to not have GRUU delivery by the server be all-or-nothing? I.e., you get a public GRUU and a temporary GRUU or no GRUUS at all? remains registered. If a UA stores any temporary GRUUs for use during its registration, it needs to be certain that the registration does not accidentally lapse due to clock skew between the UA and registrar. Consequently, the UA MUST refresh its registration well in advance of expiration. This doesn't seem like a MUST to me. There are environments where the clocks are well synched and I don't know what "well in advance of" means anyway. S 4.4. registrar. Of course, when a UA wishes to construct an anonymous request as described in RFC 3323 [16], it SHOULD use a temporary s/Of course// S 4.5. as sending a request to the GRUU, it does not. The caller preferences expressed in the Accept-Contact header field are just preferences. Its efficacy depends on a UA constructing an Accept- s/Its/Their/ S 4.6. resulting URI will be seemingly random. Future work may provide improved mechanisms that would allow an automata to know that a URI is anonymized and thus should not be rendered. Why isn't the rule "if gr has no parameters, it's anonymous" fine here. Also, the singular of automata is automaton. S 5.1. If the contact URI is equivalent (based on URI equivalence in RFC 3261) to the AOR, the registrar MUST reject the request with a 403, since this would cause a routing loop. If the contact URI is a GRUU for the AOR in the To header field of the REGISTER request, the registrar MUST reject the request with a 403, for the same reason. If the contact is not a SIP URI, the REGISTER request MUST be rejected with a 403. Is this normal REGISTER behavior non-specific to GRUU? S 5.1/5.2. I see how the "generate a new temp GRUU" in 5.1 and then "send the most recent temp GRUU" in 5.2 work together, but I think it would be less confusing (and less error prone) to have "generate a new temp GRUU and send it" in one place. S 5.4. You should explain how it is you get two contacts for one GRUU. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 13:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQS47-0006BO-Aa; Sun, 11 Mar 2007 13:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQS45-00067p-Bf for sip@ietf.org; Sun, 11 Mar 2007 13:42:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQS42-0001Cv-TJ for sip@ietf.org; Sun, 11 Mar 2007 13:42:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2007 10:42:34 -0700 X-IronPort-AV: i="4.14,271,1170662400"; d="scan'208"; a="399982737:sNHT51001956" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2BHgY7G027878 for ; Sun, 11 Mar 2007 10:42:34 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l2BHgWdx003808 for ; Sun, 11 Mar 2007 17:42:34 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <57CF7A22-7F93-41EA-BD5A-15C7F2DEA76C@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Sun, 11 Mar 2007 10:42:13 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4947; t=1173634954; x=1174498954; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-gurbani-sip-domain-certs |Sender:=20; bh=s3C9ZU+exD5Q0lOY5leb8WL2kBP6QLH+0ufTRBNXkWE=; b=tktEB5Mw6jUXgFjLz0nXGqFt0MY5zCow5jfs54hSogQYAoVpzPtdBovXVaPaqtHk/iOG23Bd 4oEjWvBT8ZYaNHVLY8SzIKo/rYovibQi7rTAkB0hQ0L2oxKY7ZtkuvTt; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Sip] draft-gurbani-sip-domain-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think many of my previously mentioned issues with this draft still exist. Lets consider the case where you have proxy farm with 3 members known as a,b, and c in the domain example.com. This draft is premised on the idea that it is actually desirable to pin mid dialog requests to one particular member of the farm. I don't actually find this a compelling use case because it breaks any sense of high reliability but I'm will to suppress my disbelief and take this as the problem we need to solve. Clearly having a single certificate that has 4 name in the SAN list solves this - the name would be for example.com, a.example.com, b.example.com, and c.example.com. You don't need 4 certificates - you need one with all the names you will use. The advantage of 1 certificate with 4 names over extendedClientHellos is that there is not yet widespread support for the extended hellos stuff. One of the other use caes you bring up is where example.com has a single server which runs several virtual domains - say example.net and example.org. The way that the web server world manages to solve this problem (and how many existing SIP proxies do it today) is by running each domain on a different port for each virtual domain and a separate certificate for each domain. Now the extendedClientHello would allow for multiple virtual domains to use one port (still with one cert per domain) and I hope that happens in the future. I don't understand how the certificate names relate to you inbound outbound proxy problem. Lets say a domain uses only a.example.com for inbound and only b.example.com for outbound. Clearly the DNS SRV resolution for example.com would only point at a.example.com and not b. However, both could use a certificate with example.com, a.example.com, and b.example.com in it. Of you could have two certs one with example.com and a.example.com and the other with example.com and b.example.com. If some other domain receives a TLS connection from example.com with the cert and mutual auth etc, the issues of if it can use this connection for new requests it wants to send to the example.com domain is not one that is deal with using the TLS certs - it is solved by other things like 1) don't do or 2) use draft-ietf- sip-connect-reuse (which oddly has a author in common with this draft) The examples seem to use DNS types in the SAN for some things and URI types for other things. We have had many emails about this and I see no reason to make them different - please clearly explain in the draft why you use DNS fro some and URI for others. You know my opinion on this which is these constrain what the cert can be used for and nothing more or less. The suggestions about costs and number of certificates required in the draft seem to be mostly wrong. I seem to recall people pointing out problems with the maddr approach that had to do with URI which needed to be different would end up matching. Defining an Extended Key Usage that restricts a certificate for SIP seems like a perfectly fine thing to do but I will need to be in a separate draft that is off in the SEC area somewhere. I do note that, uh, lots of things ignore theses - so marking it as critical often reduces deployability, luckily lots of things just ignore the critical which makes the certificate usable but the constraint useless - but I degree, in theory they are clearly the right way to constrain certificates. I certainly agree that this gives a much more refined way of controlling usage than the course granularity that the DNS vs URI type in the SAN list provides. One of the primary things that causes confusing for implementers is what a UAC needs to actually match when it opens a connection and sends a request over TLS. This tries to clarify it with When a UAC receives a certificate from a server, it MUST ensure that the certificate asserts one of the two identities that the UAC used to reach the server: If the UAC performed RFC3263 resolution on the URI to reach the server, the SIP or SIPS identity stored in the certificate MUST be matched. Otherwise, if RFC3263 resolution on the URI failed, the UAC MUST match the DNS label in the certificate with the name of the server that it opened a TLS connection to. I've got to admit - I can't make heads or tails out of any of that. What you need to explain is that there is a URI that UAC is trying to send the message to, after doing some resolution on this URI it opens a TLS connection which will present a certificate. The UAC need to check that one of the possibly many names in the SAN matches the destination specified in the URI. If you want to allow use of CN then you need to explain that too but usage of SAN is clearly preferred to CN. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 13:46:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQS7f-0003hs-VY; Sun, 11 Mar 2007 13:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQS7e-0003hg-ME for sip@ietf.org; Sun, 11 Mar 2007 13:46:18 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a1.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQS7d-0001WU-Ai for sip@ietf.org; Sun, 11 Mar 2007 13:46:18 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a1.g.dreamhost.com (Postfix) with ESMTP id DC1ED18D786 for ; Sun, 11 Mar 2007 10:46:16 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 02F141CC24 for ; Sun, 11 Mar 2007 10:45:18 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sun, 11 Mar 2007 10:45:17 -0700 From: EKR Message-Id: <20070311174518.02F141CC24@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Sip] Comments on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org $Id: draft-ietf-sip-sips-02-rev.txt,v 1.1 2007/03/11 17:56:56 ekr Exp $ Overall this document appears to be in pretty good shape. Some mostly editorial comments... S 4. Although not mandated specifically in [RFC3261], the implication is that a resource described by a SIPS URI can not be "downgraded" to a SIP URI by just changing the scheme, unless it is the "last hop exception" described in Section 3. This specification clarifies that a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP URI by changing the scheme, or by sending the associated request over a non secure link, except for cases where the "last-hop exception" rule is in effect (in which case the Request-URI would be replaced by a SIP URI). This document is targeted at Info, right? Isn't the 2119 language kind of weird then? route it to Bob at Request-URI sips:bob@bobphone.example.com. If a request is sent to AOR sip:bob@examplecom, Bob's proxy will route it to Bob at Request-URI sip:bob@bobphone.example.com (because of the "upgrade" scenario described above, and the substitution of SIP to SIPS). This should be sips:bob@bobphone.example.com, right? recommends that if the UAC decide to recurse to the SIP URI, it I'm not sure I would use the word recurse here or below.. S 4.2. Can you explain how each of thexe examples come about? S 5. Furthermore, it is a matter of local policy for a UA to accept incoming requests addressed to a URI scheme that does not correspond to what it used for registration. For example, a UA with a policy of "always SIPS" MUST address the Registrar using a SIPS Request-URI over TLS, MUST register with a SIPS Contact, and MUST reject requests addressed to a SIP Request-URI with 403 "Forbidden". A UA with a policy of "best-effort SIPS" MUST address the Registrar using a SIPS Request-URI over TLS, MUST register with a SIPS Contact, and MUST accept requests addressed to either SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" MUST address the Registrar using a SIP Request-URI, MAY or MAY NOTt use TLS, MUST register with a SIP AOR and a SIP Contact, and MUST accept requests addressed to a SIP Request-URI. I'm having some trouble with this normative language when you've just said it's "local policy". Do these policies have any other effect than to implement this language? S 10. Can we get a picture of the topology here? I would break out the registration flow, which seems to be the same for all these calls, and then not repeat it in each example. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 14:26:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSjQ-0004Xx-4c; Sun, 11 Mar 2007 14:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSjO-0004Xr-Hf for sip@ietf.org; Sun, 11 Mar 2007 14:25:18 -0400 Received: from sd-green-bigip-66.dreamhost.com ([208.97.132.66] helo=randymail-a7.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQSjM-00063W-1X for sip@ietf.org; Sun, 11 Mar 2007 14:25:18 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a7.g.dreamhost.com (Postfix) with ESMTP id 0F37BB7234 for ; Sun, 11 Mar 2007 11:25:13 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 101CD1CC24 for ; Sun, 11 Mar 2007 11:24:03 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sun, 11 Mar 2007 11:24:02 -0700 From: EKR Message-Id: <20070311182403.101CD1CC24@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [Sip] Review of draft-gurbani-sip-domain-certs-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org $Id: draft-gurbani-sip-domain-certs-04-rev.txt,v 1.1 2007/03/11 18:35:35 ekr Exp $ S 3. The two concerns enumerated above correspond to two specific problem areas that are currently visible in SIP's use of X.509 certificates. First, the contents of certificates must be such that it allows for mutual inter-domain authentication; and second, there must be means available to allow an upstream SIP host to deterministically "pin" a route through one proxy from a farm of downstream proxies. Once again, I'll note that I'm very skeptical that the pinning requirement described here is a real one. As I wrote in my review of -03: I'm skeptical that this is really going to be an important scenario. If you want to have high availability (and presumably if you run a proxy farm you do) you need to have proxy operations either be stateless or arrange for state clustering, in which case getting something back to the wrong proxy just looks like a cache niss. Moreover, once outbound and draft-ietf-sip-connect-reuse-05 are deployed, I would expect to see quite a bit of stickiness. S 4.1. Note that a domain name in an X.509 certificates should be interpreted only as a sequence of octets that should match the URI used to reach the host. No inference should be made based on the DNS name hierarchy. Why is this text indented? Is it a quote. S 4.2. Suppose, now, that example.com is a large organization that maintains several SIP proxies, and normal resolution rules cause her INVITE to s/her/Alice's/ The authentication problem for proxyA is straightforward - if we assume secure DNS, then proxyA already knows that proxyB is a valid proxy for the SIP domain example.net, so it only needs a valid certificate from proxyB that contains the fully qualified host name proxyB.example.net, or a SIP URI that asserts proxy B's authority over example.net domain, i.e., a certificate that asserts the identity "sip:example.net". I don't understand this. The basic premise here (and a good one) is that you can't trust the DNS. The certificate that B presents MUST contain example.net The problem for proxyB is different, however; it is presented with a connection from a specific host, but what it needs to determine is whether or not that connection can be treated as coming from a particular SIP domain. If it receives a certificate that contains only the name proxyA.example.com, then it cannot determine that proxyA is authorized to act as a SIP outbound proxy for example.com, because example.com may use different systems for inbound messages so SIP DNS resolution of example.com may not lead to proxyA.example.com (if this is the case, proxyB should not reuse this connection if it needs to send a request to example.com). The certificate usage in SIP should not require that every outbound proxy for a domain must also be an inbound proxy for that domain, but should provide for certificate based binding of the SIP domain name to a particular connection. I don't understand this claim. For the same reason as I indicated above, the certificate presented by A must contain example.com. The only case in which you can plausibly switch from the original URI name to an FQDN is if you're told to in a trusted fashion, e.g., in some connection secured with TLS and bound to the original name (and even then care is required). S 5. As an example, consider that the autonomous domain example.com is applying for a certificate from an authority. As part of the certificate request, it will ask the following two identities be bound to the generated certificate: "URI:sips:example.com", and "DNS:downtown.example.com". The latter DNS label provides assurance at the transport layer that the the certificate corresponds to a host that was the target of the TLS connection, while the former SIPS URI binds the holder of the certificate with a domain URI for which it is authoritatively responsible. This information may be subsequently used by the application to make authorization decisions of the form outlined in Section 26.3.2.2 of RFC3261. As noted in my previous review, I see no reason for these to have different prefixes. Have 'em both be SIP or both DNS. SIP, I assume. I'd note at this point that you presumably need to say what goes in the DN field... S 6. This extension should be a work item in PKIX, IMO. S 11. Is it conceivable that each domain have a distinct certificate that is provided to the hosting service? Certainly, this means that the domain must share the domain's private key with the hosting service. TLS extensions [10] like the extended client hello allow TLS clients to provide to the TLS server the name of the server they are contacting. Thus, the server can present the correct certificate to establish the TLS connection. Exactly the same situation obtains in HTTPS and you should use the same practices. Again, as noted in my -03 review. The appropriate thing here seems to be to follow HTTPS practice. Each domain has its own key pair and cert. The hosting service has the private key. You use name-based virtual hosting if you can trust clients to provide the dns_name. Otherwise you use IP-based. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 14:56:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQTD8-0004en-Rl; Sun, 11 Mar 2007 14:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQTD7-0004d8-0o for sip@ietf.org; Sun, 11 Mar 2007 14:56:01 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQTD4-0001cU-OK for sip@ietf.org; Sun, 11 Mar 2007 14:56:01 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070311185557m1400frvhje>; Sun, 11 Mar 2007 18:55:57 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2BItuGO019186 for ; Sun, 11 Mar 2007 13:55:56 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2BItuvY019182; Sun, 11 Mar 2007 13:55:56 -0500 Date: Sun, 11 Mar 2007 13:55:56 -0500 Message-Id: <200703111855.l2BItuvY019182@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> (bcampen@estacado.net) Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Byron Campen 6,104,711 and 6,282,574 seem to be a specifying a "smart" DNS server to me, and not a SIP proxy. (Although it might be possible to convince a jury that a redirect-server fell into this category). It looks to me like these two patents are about a DNS server (or something like it) which returns different results depending on some property of the querier or the external situation. Which doesn't seem to cover proxies, or even the redirect servers that I've seen (as they don't genrate variable responses based on the querier). 6,359,880 seems to be nastier, in that it appears to be a patent on the concept of registration over pretty much any medium (although they specify TCP/ IP, but nothing about UDP. Well, read the claims at http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6359880.PN.&OS=PN/6359880&RS=PN/6359880 The independent claims are 1, 9, and 10, and all of them state that the registering device is wireless, and that the backhaul network is a public packet network. Neither idea is new, but is there a published reference to the combination more than a year before this patent's application date (Mar. 11,1997)? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 16:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQUv6-0000WK-UD; Sun, 11 Mar 2007 16:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQUv6-0000WF-Ad for sip@ietf.org; Sun, 11 Mar 2007 16:45:32 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQUv3-0007c0-VB for sip@ietf.org; Sun, 11 Mar 2007 16:45:32 -0400 Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2BJpTMr025571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2007 13:51:30 -0600 Message-ID: <45F46A68.5050309@softarmor.com> Date: Sun, 11 Mar 2007 15:45:28 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Comments on draft-ietf-sip-sips-02 References: <20070311174518.02F141CC24@delta.rtfm.com> In-Reply-To: <20070311174518.02F141CC24@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org EKR wrote: > $Id: draft-ietf-sip-sips-02-rev.txt,v 1.1 2007/03/11 17:56:56 ekr Exp $ > > Overall this document appears to be in pretty good shape. Some > mostly editorial comments... > > S 4. > Although not mandated specifically in [RFC3261], the implication is > that a resource described by a SIPS URI can not be "downgraded" to a > SIP URI by just changing the scheme, unless it is the "last hop > exception" described in Section 3. This specification clarifies that > a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP > URI by changing the scheme, or by sending the associated request over > a non secure link, except for cases where the "last-hop exception" > rule is in effect (in which case the Request-URI would be replaced by > a SIP URI). > > This document is targeted at Info, right? Isn't the 2119 language > kind of weird then? Arguable. If the doc said "According to Section X of RFC 3261, the UA MUST NOT do", then we wouldn't have a problem because we'd simply be quoting RFC 3261, and certainly an informational document can quote a standards-track document. The argument here is one step further removed. It's saying that, although RFC 3261 doesn't say this directly, it's what RFC 3261 implies. Therefore, by the strength of this implication (and the standards-track status of RFC 3261), we MUST NOT downgrade the SIPS URI. This document doesn't declare this to be a rule -- it references RFC 3261 as the declarer of and authority for the rule. It's just clarifying what RFC 3261 already means. Now, if we were CHANGING what RFC 3261 means, we'd need a standards-track document that updates RFC 3261. ... > > S 5. > Furthermore, it is a matter of local policy for a UA to accept > incoming requests addressed to a URI scheme that does not correspond > to what it used for registration. For example, a UA with a policy of > "always SIPS" MUST address the Registrar using a SIPS Request-URI > over TLS, MUST register with a SIPS Contact, and MUST reject requests > addressed to a SIP Request-URI with 403 "Forbidden". A UA with a > policy of "best-effort SIPS" MUST address the Registrar using a SIPS > Request-URI over TLS, MUST register with a SIPS Contact, and MUST > accept requests addressed to either SIP or SIPS Request-URIs. A UA > with a policy of "No SIPS" MUST address the Registrar using a SIP > Request-URI, MAY or MAY NOTt use TLS, MUST register with a SIP AOR > and a SIP Contact, and MUST accept requests addressed to a SIP > Request-URI. > > > I'm having some trouble with this normative language when you've > just said it's "local policy". Do these policies have any other > effect than to implement this language? here, the 2119 language is relative. It is predicated by a speculative -- "If the policy is X, then to support it, the UA MUST do Y". I believe this to be a legitimate modality for the language of RFC 2119. That's rather different from saying "The policy MUST be X". This is an absolute rather than relative, and would require a standards-track document. One thing that isn't clear here is that the policies in 5.5 are simply examples. If we were to be defining these policies in such a way that we'd expect other documents to normatively refer to them -- such as "Because the client implements the standard "best-effort SIPS" policy defined in RFC XXXXX, it MUST . . . " then we'd need a much clearer definition of the policy, an IANA registry for those policies and probably a standards-track document to define the policies. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 16:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQUxE-00024O-Dr; Sun, 11 Mar 2007 16:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQUxC-00024G-Rk for sip@ietf.org; Sun, 11 Mar 2007 16:47:42 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQUxB-0007pj-Ia for sip@ietf.org; Sun, 11 Mar 2007 16:47:42 -0400 Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2BJrfPP025582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2007 13:53:41 -0600 Message-ID: <45F46AEB.1000204@softarmor.com> Date: Sun, 11 Mar 2007 15:47:39 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Review of draft-gurbani-sip-domain-certs-04 References: <20070311182403.101CD1CC24@delta.rtfm.com> In-Reply-To: <20070311182403.101CD1CC24@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org EKR wrote: > S 4.1. > Note that a domain name in an X.509 certificates should be > interpreted only as a sequence of octets that should match the URI > used to reach the host. No inference should be made based on the > DNS name hierarchy. > > Why is this text indented? Is it a quote. Supposedly the convention is that "Note" statements in SIP documents are to be indented. I wasn't aware of this convention, but the last document I submitted post-WGLC was returned with a request from the reviewing chair to indent (or delete) all of the the "Note" paragraphs. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 17:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQVi8-0005BD-54; Sun, 11 Mar 2007 17:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQVi6-0005B6-As for sip@ietf.org; Sun, 11 Mar 2007 17:36:10 -0400 Received: from sd-green-bigip-177.dreamhost.com ([208.97.132.177] helo=randymail-a10.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQVi2-0006er-Rs for sip@ietf.org; Sun, 11 Mar 2007 17:36:10 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a10.g.dreamhost.com (Postfix) with ESMTP id 9B57010EB62; Sun, 11 Mar 2007 14:36:05 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 2D4121CC2D; Sun, 11 Mar 2007 14:35:06 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Review of draft-gurbani-sip-domain-certs-04 References: <20070311182403.101CD1CC24@delta.rtfm.com> <45F46AEB.1000204@softarmor.com> From: EKR Date: Sun, 11 Mar 2007 14:35:05 -0700 In-Reply-To: <45F46AEB.1000204@softarmor.com> (Dean Willis's message of "Sun, 11 Mar 2007 15:47:39 -0500") Message-ID: <86bqizcvli.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > te: > >> S 4.1. >> Note that a domain name in an X.509 certificates should be >> interpreted only as a sequence of octets that should match the URI >> used to reach the host. No inference should be made based on the >> DNS name hierarchy. >> Why is this text indented? Is it a quote. > > Supposedly the convention is that "Note" statements in SIP documents > are to be indented. > > I wasn't aware of this convention, but the last document I submitted > post-WGLC was returned with a request from the reviewing chair to > indent (or delete) all of the the "Note" paragraphs. Hmm.... So, I think there's a difference between a "Note:" which is basically our version of a footnote and a graf that just happens to begin with "Note that...". I'm not sure which this one is, but IMHO the indenting convention doesn't help with that as much as you would like.... -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 17:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQW0s-0003vr-A1; Sun, 11 Mar 2007 17:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQW0r-0003vm-JI for sip@ietf.org; Sun, 11 Mar 2007 17:55:33 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQW0q-0001ys-94 for sip@ietf.org; Sun, 11 Mar 2007 17:55:33 -0400 Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2BL1U6A025815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2007 15:01:31 -0600 Message-ID: <45F47AD0.2030706@softarmor.com> Date: Sun, 11 Mar 2007 16:55:28 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Review of draft-gurbani-sip-domain-certs-04 References: <20070311182403.101CD1CC24@delta.rtfm.com> <45F46AEB.1000204@softarmor.com> <86bqizcvli.fsf@delta.rtfm.com> In-Reply-To: <86bqizcvli.fsf@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org EKR wrote: > Dean Willis writes: > >> te: >> >>> S 4.1. >>> Note that a domain name in an X.509 certificates should be >>> interpreted only as a sequence of octets that should match the URI >>> used to reach the host. No inference should be made based on the >>> DNS name hierarchy. >>> Why is this text indented? Is it a quote. >> Supposedly the convention is that "Note" statements in SIP documents >> are to be indented. >> >> I wasn't aware of this convention, but the last document I submitted >> post-WGLC was returned with a request from the reviewing chair to >> indent (or delete) all of the the "Note" paragraphs. > > Hmm.... So, I think there's a difference between a "Note:" which is > basically our version of a footnote and a graf that just happens > to begin with "Note that...". I'm not sure which this one is, but > IMHO the indenting convention doesn't help with that as much as > you would like.... I don't disagree. I ended up changing most of the "Note that x is . . ." paragraphs to "X is", in the draft I recently revised but I don't think it made things any clearer. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 18:40:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWhQ-0005PS-8T; Sun, 11 Mar 2007 18:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWhO-0005PI-IV for sip@ietf.org; Sun, 11 Mar 2007 18:39:30 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQWhN-0001vu-5M for sip@ietf.org; Sun, 11 Mar 2007 18:39:30 -0400 Received: from [10.0.0.188] (adsl-71-154-15-26.dsl.rcsntx.sbcglobal.net [71.154.15.26]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l2BMdLKj060895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Mar 2007 17:39:25 -0500 (CDT) (envelope-from bcampen@estacado.net) In-Reply-To: <200703111855.l2BItuvY019182@dragon.ariadne.com> References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <200703111855.l2BItuvY019182@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <4F873B53-CE41-4869-A5D8-76E98B7CFD97@estacado.net> From: Byron Campen Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations Date: Sun, 11 Mar 2007 17:38:52 -0500 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1953850831==" Errors-To: sip-bounces@ietf.org --===============1953850831== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--75470983; protocol="application/pkcs7-signature" --Apple-Mail-1--75470983 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > From: Byron Campen > > 6,104,711 and 6,282,574 seem to be a specifying a "smart" DNS > server to me, and not a SIP proxy. (Although it might be possible > to convince a jury that a redirect-server fell into this category). > > It looks to me like these two patents are about a DNS server (or > something like it) which returns different results depending on some > property of the querier or the external situation. Which doesn't seem > to cover proxies, or even the redirect servers that I've seen (as they > don't genrate variable responses based on the querier). > Exactly my interpretation, but I can definitely see a jury of non- technical people being convinced otherwise. > 6,359,880 seems to be nastier, in that it appears to be a patent on > the concept of registration over pretty much any medium (although > they specify TCP/ IP, but nothing about UDP. > > Well, read the claims at > http://patft.uspto.gov/netacgi/nph-Parser? > Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO% > 2Fsrchnum.htm&r=1&f=G&l=50&s1=6359880.PN.&OS=PN/6359880&RS=PN/6359880 > The independent claims are 1, 9, and 10, and all of them state that > the registering device is wireless, and that the backhaul network is a > public packet network. Neither idea is new, but is there a published > reference to the combination more than a year before this patent's > application date (Mar. 11,1997)? > Whoops, I misread claims 12-14. So did Vonage get in trouble for selling cordless handsets? Best regards, Byron Campen --Apple-Mail-1--75470983 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMzEx MjIzODUzWjAjBgkqhkiG9w0BCQQxFgQUKfi+EwdRZhx+a5g9Mt3tcp+ctI8wgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAIzK0Y/3 0cOdBy5G4+r/AGLVAQgEDEAulYPFPrDhfpIrVipp1K7DlsgdI6wmbFlm4GEx4/H76DEcAAfuKaaz f0UjqKsxj4HO1f0O9AgZ/M/7ro5kMR+q4dSqtEq2AB+XFrM41T1aUH3Gc8TivLwPdgH2anHLN0p3 hfo39n8gBA+0DWC2CrYz38jA3dGSu9VYRklBiYocxnCZ+3j4fWdOlFJzMoh5o2qj2L5vOSfbNObO OJJ6B74p19MSiGglfQWEIxdjcXk40f83/jerp7RqSd7m7ZH9b9dQONUU4J0CZoVfkkTmyKq/jxYm s+HKsihDrW8CB96Ao88+TMy7Da5MVVQAAAAAAAA= --Apple-Mail-1--75470983-- --===============1953850831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1953850831==-- From sip-bounces@ietf.org Sun Mar 11 18:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWp1-0001Sp-4S; Sun, 11 Mar 2007 18:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWp0-0001Sf-CF for sip@ietf.org; Sun, 11 Mar 2007 18:47:22 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQWoz-0003S0-10 for sip@ietf.org; Sun, 11 Mar 2007 18:47:22 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070311224719m11009nis6e>; Sun, 11 Mar 2007 22:47:19 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2BMlIGO003678 for ; Sun, 11 Mar 2007 17:47:18 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2BMlIwB003674; Sun, 11 Mar 2007 17:47:18 -0500 Date: Sun, 11 Mar 2007 17:47:18 -0500 Message-Id: <200703112247.l2BMlIwB003674@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net Subject: Re: [Sip] draft-polk-sip-rph-new-namespaces X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This I-D introduces a group of new Resource-Priority header namespaces, viz.: dsn-000000 dsn-000010 dsn-000020 dsn-000030 dsn-000001 dsn-000011 dsn-000021 dsn-000031 dsn-000002 dsn-000012 dsn-000022 dsn-000003 dsn-000013 dsn-000023 dsn-000004 dsn-000014 dsn-000024 dsn-000005 dsn-000015 dsn-000025 dsn-000006 dsn-000016 dsn-000026 dsn-000007 dsn-000017 dsn-000027 dsn-000008 dsn-000018 dsn-000028 dsn-000009 dsn-000019 dsn-000029 dsn-00000A dsn-00001A dsn-00002A dsn-00000B dsn-00001B dsn-00002B dsn-00000C dsn-00001C dsn-00002C dsn-00000D dsn-00001D dsn-00002D dsn-00000E dsn-00001E dsn-00002E dsn-00000F dsn-00001F dsn-00002F Taking RFC 4412 at face value, these 50 namespaces are not intrinsically related. And the I-D states that they operate independently unless they are correlated within a SIP agent by local policy -- which is exactly what RFC 4412 says. But there is a long discussion in section 2 which seems to be suggesting that "dsn" should be considered to be a name for the group of all of these namespaces. On the other hand, section 2.1 is titled "One-Part or Two-Part Namespaces Do Not Change Anything", which suggests that the I-D isn't really declaring that the "dsn-" prefix has any fundamental significance. This is made less clear by the fact that some key words are missing from at a sentence that seems to be defining the situation. But what if I write an RFC defining the namespace "dsn-000032"? It seems like there are three possible policies, and this I-D should be clear which one it is specifing: 1. These 50 namespaces happen to have the same prefix, "dsn-0000", but that has no recognized significance. In particular, it has no significance in regard to assigning other namespaces with the same prefix. 2. The author kindly requests that nobody else attempt to define a namespace with the prefix "dsn-". 3. The I-D is defining a standardized namespace grouping mechanism, and is registering the group "dsn" to be managed by DISA. (Which implies a new IANA registry.) Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 19:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQX68-0000ij-SL; Sun, 11 Mar 2007 19:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQX67-0000ie-Vp for sip@ietf.org; Sun, 11 Mar 2007 19:05:03 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQX66-0007Jd-Pi for sip@ietf.org; Sun, 11 Mar 2007 19:05:03 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <200703112305020130011t4oe>; Sun, 11 Mar 2007 23:05:02 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2BN52GO004961 for ; Sun, 11 Mar 2007 18:05:02 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2BN51In004957; Sun, 11 Mar 2007 18:05:02 -0500 Date: Sun, 11 Mar 2007 18:05:02 -0500 Message-Id: <200703112305.l2BN51In004957@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4F873B53-CE41-4869-A5D8-76E98B7CFD97@estacado.net> (bcampen@estacado.net) Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <200703111855.l2BItuvY019182@dragon.ariadne.com> <4F873B53-CE41-4869-A5D8-76E98B7CFD97@estacado.net> From: Dale.Worley@comcast.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Byron Campen Whoops, I misread claims 12-14. So did Vonage get in trouble for selling cordless handsets? I've no idea, as nobody seems to have bothered to even track down the judge's decision. But there does seem to be a prima-facie problem in regard to a UA sending registration back to a server over a wireless last-hop network and a public packet long-haul network. If you're interesting in selling something like that, you should get a good lawyer. One thing I notice is that the prior-art cutoff for this patent is March 1996, which is 11 years ago, and 3 years before RFC 2543. The original 802.11 was apparently approved in 1997. So it's possible that nobody then had thought of a wireless phone talking WiFi to a base station that used the Internet to register with its point-of-contact server. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 19:26:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXQ6-0008Nn-Uj; Sun, 11 Mar 2007 19:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXQ5-0008NV-HA for sip@ietf.org; Sun, 11 Mar 2007 19:25:41 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXQ4-0002Dh-1O for sip@ietf.org; Sun, 11 Mar 2007 19:25:41 -0400 Received: by nf-out-0910.google.com with SMTP id l36so1887788nfa for ; Sun, 11 Mar 2007 16:25:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iijKsCXqLzh1WUkb2I/+YwVmxaB1NzSkSRtcuZq9mJ/2qumEOQ6Nwv2S0S2Be4GKi1FV9JZSwurhP7aq9N+Mc8ldp7fLcMdum7qzgMwczzWKAZefVriYGz6GwtCno/wkCgTVAb4OMvLi8Xn4rss/1KLWjaO2Wh7Qcuy/UTecD7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=USJ9DnD5ojLw35+AAFjkE5XbTCEhIDH+bTqzenq1bQ5762yw2NIJPwX15IJNFLwMpvfVz/qhCfsRcwWVBtlvdRczlfAg/MJYFmyG/lD54MVD3VHm/A5tipa+k22JWsmpZR3rtzAvRmsJ6QXC+AXui36XbqaNxSAgo2b4GMul8xI= Received: by 10.115.108.1 with SMTP id k1mr1036431wam.1173655538400; Sun, 11 Mar 2007 16:25:38 -0700 (PDT) Received: by 10.114.120.10 with HTTP; Sun, 11 Mar 2007 16:25:38 -0700 (PDT) Message-ID: <894e079b0703111625o6ac38388p27e87be9f33247e8@mail.gmail.com> Date: Sun, 11 Mar 2007 15:25:38 -0800 From: "Medhavi Bhatia" To: Dale.Worley@comcast.net Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations In-Reply-To: <200703112305.l2BN51In004957@dragon.ariadne.com> MIME-Version: 1.0 References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <200703111855.l2BItuvY019182@dragon.ariadne.com> <4F873B53-CE41-4869-A5D8-76E98B7CFD97@estacado.net> <200703112305.l2BN51In004957@dragon.ariadne.com> X-Google-Sender-Auth: f1d091a13db8487f X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1866542592==" Errors-To: sip-bounces@ietf.org --===============1866542592== Content-Type: multipart/alternative; boundary="----=_Part_24620_13929397.1173655538346" ------=_Part_24620_13929397.1173655538346 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Wasn't the Verizon folks there at the time 2543 was voted on? I think there must be a requirement in IETF that you must speak at that time if you are present ;) On 3/11/07, Dale.Worley@comcast.net wrote: > > From: Byron Campen > > Whoops, I misread claims 12-14. So did Vonage get in trouble for > selling cordless handsets? > > I've no idea, as nobody seems to have bothered to even track down the > judge's decision. > > But there does seem to be a prima-facie problem in regard to a UA > sending registration back to a server over a wireless last-hop network > and a public packet long-haul network. If you're interesting in > selling something like that, you should get a good lawyer. > > One thing I notice is that the prior-art cutoff for this patent is > March 1996, which is 11 years ago, and 3 years before RFC 2543. The > original 802.11 was apparently approved in 1997. So it's possible > that nobody then had thought of a wireless phone talking WiFi to a > base station that used the Internet to register with its > point-of-contact server. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_24620_13929397.1173655538346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Wasn't the Verizon folks there at the time 2543 was voted on? I think there must be a requirement in IETF that you must speak at that time if you are present ;)

On 3/11/07, Dale.Worley@comcast.net <Dale.Worley@comcast.net> wrote:
  From: Byron Campen <bcampen@estacado.net>

  Whoops, I misread claims 12-14. So did Vonage get in trouble for
  selling cordless handsets?

I've no idea, as nobody seems to have bothered to even track down the
judge's decision.

But there does seem to be a prima-facie problem in regard to a UA
sending registration back to a server over a wireless last-hop network
and a public packet long-haul network.  If you're interesting in
selling something like that, you should get a good lawyer.

One thing I notice is that the prior-art cutoff for this patent is
March 1996, which is 11 years ago, and 3 years before RFC 2543.  The
original 802.11 was apparently approved in 1997.  So it's possible
that nobody then had thought of a wireless phone talking WiFi to a
base station that used the Internet to register with its
point-of-contact server.

Dale

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

------=_Part_24620_13929397.1173655538346-- --===============1866542592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1866542592==-- From sip-bounces@ietf.org Sun Mar 11 23:40:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbMC-0000ZT-OI; Sun, 11 Mar 2007 23:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbMB-0000ZB-Cq for sip@ietf.org; Sun, 11 Mar 2007 23:37:55 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQbM1-0001aJ-O7 for sip@ietf.org; Sun, 11 Mar 2007 23:37:55 -0400 Received: from [172.20.2.42] (0x5551a8ee.adsl.cybercity.dk [85.81.168.238]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l2C3YGN25414; Sun, 11 Mar 2007 19:34:16 -0800 In-Reply-To: <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sun, 11 Mar 2007 16:35:10 +0100 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: sip@ietf.org, fluffy@cisco.com Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 6, 2007, at 8:34 PM, Rohan Mahy wrote: > Hi, > > For Question 1 I think an example of Algorithm 2 may be helpful. I > will follow up later with answers to your other questions. > > I have an edge proxy at 1.2.3.4:5060 and a UA with outbound support > registering from the public address 5.6.7.8:9999. > > transport = UDP (i will use 0x01) > local IP and port is 0x01020304 0x13C4 > remote IP and port is 0x05060708 0x270F > > S = 0x01 0120304 13C4 05060708 270F > > I will use the string "my key is not strong" as the key K > > HMAC of S with the key K = 0x5915 581d 9b7f 17a0 d8b1 ade2 5de6 > 04b0 5197 a6c9 > > The flow token is therefore the base 64 encoding of [ HMAC(S,K) + > S ] = > WRVYHZt/F6DYsa3iXeYEsFGXpskBASAwE8QFBgcIJw8= > > (Note that the text is misleading and needs to be clarified. The > flow token is 44 octets on the wire, although it can be represented > in 32 octets on the proxy before it is base 64 encoded) > > > On Mar 6, 2007, at 5:43 AM, sergiole@tml.hut.fi wrote: >> >> Hi, >> >> >> Although you explained in the email 'Re: [Sip] Outbound-07 >> comments' some issues related to '5.3. Forwarding Requests' , I >> still do not understand the logic and scenarios that you intend to >> cover. >> >> >> ** Q1. >> >> "If the Edge Proxy receives a request where the edge proxy is the >> host in the topmost >> Route header field value, and the Route header contains a flow >> token, the proxy compares >> the flow in the flow token with the source of the request. If >> these refer to the same >> flow, the Edge Proxy removes the Route header and continues >> processing the request." >> >> Where : "the proxy compares the flow in the flow token with the >> source of the request." >> >> Assume that I always use algorithm 2: >> >> 1. "the flow in the flow token" is the HMAC of the S array >> True? > > no, the flow in the flow token is the UDP flow from 5.6.7.8:9999 to > 1.2.3.4:5060. > > The proxy removes the base64 encoding from the flow token and takes > the last 13 octets to get S again, computes HMAC(S,K), and verifies > that this matches the first 20 octets in the flow token. > >> 2. "the source of the request" is the S array >> True? > > no. the source of the (just received) SIP request is the IP > address, port, and transport over which that new request (not the > original register request) was received. The proxy compares the > source address from S with the source address of the new request. > >> 3. "the proxy compares the flow in the flow token with the source >> of the request." >> >> I understand that we need to decode the flow token and verify >> that the HMAC of the flow identifier is the same as the other part >> containing protocol, Ips and ports (i.e. S array). >> Is this correct? > > yes > > thanks, > -rohan > > > >> >> ** Q2. Lets walk through the whole first paragraph of Section 5.3: > When an Edge Proxy receives a request, it applies normal routing > procedures with the following addition. If the Edge Proxy receives > a request where the edge proxy is the host in the topmost Route > header field value, and the Route header contains a flow token, the > proxy compares the flow in the flow token with the source of the > request. OK so far? The Edge Proxy compares the flow in the flow token (the source of the register) with the source of the newly received request > If these refer to the same flow, the Edge Proxy removes the Route > header and continues processing the request. In other words if the request is already coming over the same flow that registered, continue forwarding it because it is an "outgoing" request from the UA instance that caused the flow token to be created. > Otherwise, if the top-most Route header refers to the Edge Proxy > and contains a valid flow identifier token created by this proxy, > the proxy MUST remove the Route header and forward the request over > the 'logical flow' identified by the flow token, that is known to > deliver data to the specific target UA instance. If the request is coming from some *other* UA instance, forward it over the flow to the UA that caused the flow token to be created. > For connection-oriented transports, if the flow no longer exists > the proxy SHOULD send a 430 (Flow Failed) response to the request. >> "Otherwise, if the top- >> most Route header refers to the Edge Proxy and contains a valid >> flow >> identifier token created by this proxy, the proxy MUST remove the >> Route header and forward the request over the 'logical flow' >> identified by the flow token, that is known to deliver data to the >> specific target UA instance." >> >> Otherwise what statement? >> >> What it is the difference with the former statement : >> >> "If the Edge Proxy receives a request where the edge proxy is the >> host in the topmost >> Route header field value, and the Route header contains a flow >> token, the proxy compares >> the flow in the flow token with the source of the request." >> >> 1. Compare >> >> "Otherwise, if the top- >> most Route header refers to the Edge Proxy " >> >> and >> >> ""If the Edge Proxy receives a request where the edge proxy is the >> host in the topmost >> Route header field value," >> >> Both seem to be equivalent. >> >> 2. Compare >> >> >> "and contains a valid flow >> identifier token created by this proxy," >> >> and >> >> "and the Route header contains a flow token, " >> >> Both seem to be equivalent. >> >> Could you clarify the situation or state this in other words? >> >> >> ** Q3. >> >> The following text is confusing : >> >> "if these refer to the same flow, the Edge Proxy removes the Route >> header and continues processing the request. Otherwise,..." >> >> >> What do you mean by " continues processing the request"? >> To continue processing the request as a non sip outbound >> ("normal") proxy? yes. >> Then the "otherwise" does not provide enough information about >> otherwise what... In English, "otherwise" usually is in this form: If (statement A) {do something}. Otherwise {do something different}. Still, the text is not especially easy to read. If you can come up with a clearer way to express this paragraph, I'll be happy to consider it. >> >> Q4. >> >> "If these refer to the same flow, the Edge Proxy removes the Route >> header and continues processing the request. " >> >> >> What happen if these not correspond to the same flow? >> >> For example, 1) in the case someone changed the token, 2) the >> registrar sent an old token, 3) the key changed due to re- >> booting. Should we return 430 (Flow Failed)? >> >> Could you add this case in the specification? >> >> >> Q5. >> >> I can not imagine other situation where "the Edge Proxy receives a >> request where the edge proxy is the host in the topmost Route >> header field value, and the Route header contains a flow token" is >> NOT going to do the following >> >> "the proxy MUST remove the >> Route header and forward the request over the 'logical flow' >> identified by the flow token, that is known to deliver data to the >> specific target UA instance." >> >> "5.3. Forwarding Requests" is explained in a way that it seems >> that there are other variations.... I can not understand what you >> intend to consider. An example in some scenario could clarify this >> issue A ---- EP1 ---- P1 ---- P2 ---- EP2 --- B User Agent A registers through EP1 to P1. User Agent B registers through EP2 to P2. A establishes a session with B. Once the route set is established, A has to send its requests toward B through EP1. Since the Route for EP1 has to be the same for A as it is for B, EP1 needs a way to distinguish between traffic from A going somewhere else (in this case B), instead of inbound traffic. I hope this clarifies things a bit. thanks, -rohan >> >> Regards >> >> Sergio >> >> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 11 23:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbSu-00021J-I9; Sun, 11 Mar 2007 23:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbSn-0001xS-8K for sip@ietf.org; Sun, 11 Mar 2007 23:44:45 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQbR7-0002z6-FU for sip@ietf.org; Sun, 11 Mar 2007 23:43:02 -0400 Received: by tutpro.com (Postfix, from userid 33) id E0B9E1EC693; Mon, 12 Mar 2007 05:43:00 +0200 (EET) Received: from 219.89.246.50 (SquirrelMail authenticated user jh) by tutpro.com with HTTP; Mon, 12 Mar 2007 05:43:00 +0200 (EET) Message-ID: <2530.219.89.246.50.1173670980.squirrel@tutpro.com> Date: Mon, 12 Mar 2007 05:43:00 +0200 (EET) Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations From: jh@tutpro.com To: sip@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org there must be earlier publications that state that any ip application can run on any layer 2 technology for which an ip driver has been written. that is the one of the very basic properties of ip networks. u.s. patent system is completely brain damaged (by cleaver lawyers) if one needs to patent each application for each possible ip ove= r layer 2 technology. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 00:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbug-0004yx-55; Mon, 12 Mar 2007 00:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbuf-0004yp-3W for sip@ietf.org; Mon, 12 Mar 2007 00:13:33 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQbud-0008F1-TN for sip@ietf.org; Mon, 12 Mar 2007 00:13:33 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <20070312041331015006etiae>; Mon, 12 Mar 2007 04:13:31 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2C4DVGJ005589 for ; Sun, 11 Mar 2007 23:13:31 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2C4DVwe005585; Sun, 11 Mar 2007 23:13:31 -0500 Date: Sun, 11 Mar 2007 23:13:31 -0500 Message-Id: <200703120413.l2C4DVwe005585@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <2530.219.89.246.50.1173670980.squirrel@tutpro.com> (jh@tutpro.com) Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations References: <2530.219.89.246.50.1173670980.squirrel@tutpro.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: jh@tutpro.com there must be earlier publications that state that any ip application can run on any layer 2 technology for which an ip driver has been written. that is the one of the very basic properties of ip networks. OK, now do we have a reference to the SIP registrar/proxy system before March 1996? u.s. patent system is completely brain damaged (by cleaver lawyers) if one needs to patent each application for each possible ip over layer 2 technology. The major failing of the US patent system is that it isn't particularly good at thoroughly checking the prior art. The patent office will search the literature that is easy to search. But the patent office assumes that if a patent becomes economically important (and the bulk of them do not), the other companies that would like to make the device without paying royalties will spend the money to do the prior art research well. But that is probably the least-cost strategy for society as a whole, since the validity of the bulk of patents is of no real importance. It sounds horribly inefficient, but in the context of making and selling high-tech devices, where it can easily take millions of dollars of investment to bring something to market, litigation isn't really that expensive. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 02:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQdke-0000NB-4g; Mon, 12 Mar 2007 02:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQdkb-0000N3-Tm; Mon, 12 Mar 2007 02:11:17 -0400 Received: from bay0-omc1-s11.bay0.hotmail.com ([65.54.246.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQdkY-0006oa-Hz; Mon, 12 Mar 2007 02:11:17 -0400 Received: from hotmail.com ([64.4.61.16]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 11 Mar 2007 23:11:14 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 11 Mar 2007 23:11:13 -0700 Message-ID: Received: from 64.4.61.244 by by102fd.bay102.hotmail.msn.com with HTTP; Mon, 12 Mar 2007 06:11:12 GMT X-Originating-IP: [64.104.175.176] X-Originating-Email: [xiaopu.zhang@hotmail.com] X-Sender: xiaopu.zhang@hotmail.com From: "Horace Zhang" To: sip@ietf.org, megaco@ietf.org Bcc: Date: Sun, 11 Mar 2007 22:11:12 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Mar 2007 06:11:13.0906 (UTC) FILETIME=[3CE2D520:01C7646D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Sip] A question about rtpmap X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, According to RFC2327, a=rtpmap is used to specify dynamic payload type, not static dynamic payload type, is my understanding right? But some equipments are sending SDP with a=rtpmap specifying static dynamic, for example: v=0 o=- 285442017 285442017 IN IP4 10.0.21.1 s=- c=IN IP4 10.0.21.1 t=0 0 m=audio 16480 RTP/AVP 18 0 2 4 8 96 97 98 100 101 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv The equipment is trying to specify for each codec. On receiving this kind of SDP, should ignore the a=rtpmap lines for static payload type, or just reject the message? _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 02:35:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQe7N-0001Ee-Ol; Mon, 12 Mar 2007 02:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQe7M-0001D4-Io for sip@ietf.org; Mon, 12 Mar 2007 02:34:48 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQe7I-0003v7-IT for sip@ietf.org; Mon, 12 Mar 2007 02:34:48 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JES0068124JOA@szxga01-in.huawei.com> for sip@ietf.org; Mon, 12 Mar 2007 14:31:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JES00CEU24I3P@szxga01-in.huawei.com> for sip@ietf.org; Mon, 12 Mar 2007 14:31:31 +0800 (CST) Received: from z13645a ([10.70.145.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JES002V424FOR@szxml04-in.huawei.com> for sip@ietf.org; Mon, 12 Mar 2007 14:31:30 +0800 (CST) Date: Mon, 12 Mar 2007 14:31:22 +0800 From: Lavis Chow Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt In-reply-to: <1ECE0EB50388174790F9694F77522CCF0F8915BF@zrc2hxm0.corp.nortel.com> To: 'Francois Audet' Message-id: <009c01c76470$101bca80$3f91460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdbarbTgoznNYBZRcqJyrGfl3IayQAFK0jgAX2jUhAAQuU48AB25GQw X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 'SIP' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Thanks for you reply, some more rough comments: 1. For Item 5 Line 680, It just mentioned that the Req-URI is SIP URI, but if the Top route of that request is SIPS URI, then as per the rule of [RFC3261]/8.1.1.8, Contact will be a SIPS URI. So if the intention is just SIP with TLS, then it's better mention that top Route is not SIPS too. And another concern for this item is what's the implication by checking the top route besides the Req-URI. 2. This document had clarified the SIPS usage in Req-URI/Contact very clearly. But I feel that the usage of SIPS in Route, RR, Path, Service-Route is not clear. A. If the Req-URI of dialog establishing INVITE is SIP-URI, is it possible that one Proxy insert a SIPS URI in RR? What's the implication for that? Same for PATH, Service-Route of REGISTER message? Or this behavior is not allowed? B. If one UA register with SIPS contact, then Proxy will return a SIPS version of Service-Route. Later if the UA want to contact a SIP URI resource, what behavior is recommended: a. REGISTER with a SIP contact. b. use these SIPS Routes and Contact, so it will mandates one proxy in-between to record-route to conduct the SIP/SIPS conversion, How he know one of the Proxy is willing to do it? Rgds, Lavis -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Saturday, March 10, 2007 3:44 AM To: Lavis Zhou Cc: SIP Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt Thank you for your comments Lavis. I will incorporate most of them into version -03. It will result on good clarfications. On the following 2 items: Item 2: Yes, I guess one of the item that we will discuss in Prague (as per Appendix A), is the idea of deprecating the last hop exception. Item 5: I don't understand your question. And for the part about the conflict: there is no conflict. The case you are refering to in line 680 is the case where a request is sent over TLS using SIP Request-URI. It just recommends putting a SIP Contact instead of SIPS because of complications that would arise. > 5. Section 6 Line 644, > " As mandated by [RFC3261]/8.1.1.8, in a request, if the > Request-URI or > top Route header field value contains a SIPS URI, the > Contact header > field MUST contain a SIPS URI as well." > Why top Route header filed value has to be checked? If the > resource UAC want to accessed which identified by Req-URI is > a SIP URI, so it will be non-secure, the secure link in one > hop will help? And in this case, it will mandatory one of the > proxy in-between to RR as there is a conversion between SIPS > and SIP. Is any usage for this? > And the statement is conflict with the following statement > (line 680) " It is therefore > RECOMMENDED that in this case, the Contact be a SIP URI" > So it's better to remove the top Route header check. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 03:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQevR-000583-DR; Mon, 12 Mar 2007 03:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQevQ-00057q-Bj; Mon, 12 Mar 2007 03:26:32 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQevN-000663-Uf; Mon, 12 Mar 2007 03:26:32 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1173684388!4496111!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1038 invoked from network); 12 Mar 2007 07:26:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 12 Mar 2007 07:26:28 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l2C7QSRM003949; Mon, 12 Mar 2007 00:26:28 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l2C7QQcu004129; Mon, 12 Mar 2007 02:26:27 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A question about rtpmap Date: Mon, 12 Mar 2007 15:26:03 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03F46A4B@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A question about rtpmap Thread-Index: Acdkb/u6pXXHuyOqR9qfrhxJ+NBmJgAB22VQ X-Priority: 1 Priority: Urgent Importance: high References: From: "Avasarala Ranjit-A20990" To: "Horace Zhang" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All media descriptions in a SDP message SHOULD contain "a=3Drtpmap" mappings for the RTP payload types. The RTP payload types can be both static and dynamic. So the message u enclosed is valid and should be accepted. Regards Ranjit -----Original Message----- From: Horace Zhang [mailto:xiaopu.zhang@hotmail.com]=20 Sent: Monday, March 12, 2007 11:41 AM To: sip@ietf.org; megaco@ietf.org Subject: [Sip] A question about rtpmap Hi all, According to RFC2327, a=3Drtpmap is used to specify dynamic payload = type, not static dynamic payload type, is my understanding right? But some equipments are sending SDP with a=3Drtpmap specifying static dynamic, for example: v=3D0 o=3D- 285442017 285442017 IN IP4 10.0.21.1 s=3D- c=3DIN IP4 10.0.21.1 t=3D0 0 m=3Daudio 16480 RTP/AVP 18 0 2 4 8 96 97 98 100 101 a=3Drtpmap:18 G729a/8000 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:2 G726-32/8000 a=3Drtpmap:4 G723/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:96 G726-40/8000 a=3Drtpmap:97 G726-24/8000 a=3Drtpmap:98 G726-16/8000 a=3Drtpmap:100 NSE/8000 a=3Drtpmap:101 telephone-event/8000 a=3Dfmtp:101 0-15 a=3Dptime:30 a=3Dsendrecv The equipment is trying to specify for each codec. On receiving this kind of SDP, should ignore the a=3Drtpmap lines for static payload type, or just reject the message? _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 04:23:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQfo2-0003uT-6x; Mon, 12 Mar 2007 04:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQfo0-0003uO-52 for sip@ietf.org; Mon, 12 Mar 2007 04:22:56 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQfny-0001Qt-OI for sip@ietf.org; Mon, 12 Mar 2007 04:22:56 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id A3BDD74291; Mon, 12 Mar 2007 09:22:27 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20718-01-30; Mon, 12 Mar 2007 09:22:27 +0100 (CET) Received: from [192.168.123.19] (c-02fbe055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.251.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id B25DE7411F; Mon, 12 Mar 2007 09:22:22 +0100 (CET) Message-ID: <45F50D86.4000409@it.su.se> Date: Mon, 12 Mar 2007 09:21:26 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] outbound: question on flow token algorithms References: <456BE164.3080908@it.su.se> <2660A509-118C-4C4E-A4E2-D7B8157D070B@cisco.com> In-Reply-To: <2660A509-118C-4C4E-A4E2-D7B8157D070B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.905 tagged_above=-99 required=7 tests=[AWL=0.407, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > On Nov 27, 2006, at 11:12 PM, Fredrik Thulin wrote: > >> Hi >> >> Outbound (-06) "5.2 Generating Flow Tokens" says >> >> "A proxy can use any algorithm >> it wants as long as the flow token is unique to a flow, the flow can >> be recovered from the token, and the token can not be modified by >> attackers." >> >> and then goes on explaining two stateless algorithms that both, if I >> understand them correctly, would generate a static flow token for a >> given flow (static for as long as the proxy is running). >> >> Can you please explain what attack scenarios this is meant to avoid? > > Imagine an attacker can modify the traffic between the edge proxy and > the registrar, and Alice has registered and also the attacker has > registered a UA. If the attacker replaces the flow token in Alice's > registration with the flow token in his request, now all of Alice's > calls will be forwarded to the edge proxy with the wrong token the edge > proxy will forwarded the calls to the attackers UA instead of Alice. > Alice's phone has been hi-jacked. If the attacker is able to modify packets between the edge proxy and the registrar, then what prevents the attacker from using the Path header the edge proxy created for the attackers own REGISTER, complete with a securely generated flow token (for the attacker) and all? Wouldn't that also result in all calls to Alice being sent to the attacker? Or - why wouldn't the attacker just remove the Path header and replace the Contact header in Alice's REGISTER with, say, Contact: ? I think all bets are off if you have an attacker that can modify your REGISTERs. The solution is to prevent the attacker from being able to do that (i.e. use TLS). /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 06:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQhyW-0007H2-OR; Mon, 12 Mar 2007 06:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQhyV-0007Gu-Bo for sip@ietf.org; Mon, 12 Mar 2007 06:41:55 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQhyS-0006d3-1J for sip@ietf.org; Mon, 12 Mar 2007 06:41:55 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2CAflZq029933 for ; Mon, 12 Mar 2007 05:41:47 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 05:41:47 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 11:41:11 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Sip] draft-polk-sip-rph-new-namespaces X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Mar 2007 11:41:11 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F5D8@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-polk-sip-rph-new-namespaces Thread-Index: AcdkkvMqU99WJMzuS66LCofn9b3dLg== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 12 Mar 2007 10:41:11.0783 (UTC) FILETIME=[F392B770:01C76492] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480010278==" Errors-To: sip-bounces@ietf.org --===============0480010278== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpSRkMgNDQxMiBzYXlzIHRoYXQgaWYgd2UgbmVlZCB0byBhZGQgbW9y ZSBuYW1lc3BhY2VzIHRvIHRoZSBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgdGhlcmUgbmVlZHMg dG8gYmUgYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgdG8gZG8gaXQsIGFuZCBJIHVuZGVyc3Rh bmQgdGhpcyBuZWVkcyB0byBjb21lIGZyb20gdGhlIFNJUCBXRyBhcyBhIFNJUCBXRyBjaGFydGVy IGl0ZW0uDQoNCkZpcnN0bHksIHdpdGggdGhlIGFib3ZlIGRyYWZ0IHdlIGhhdmUgYSBjbGVhciBy ZXF1aXJlbWVudCBjb21pbmcgaW4gZm9yIGRlZmluaXRpb24gb2YgYWRkaXRpb25hbCBuYW1lc3Bh Y2UgZnJvbSBhdCBsZWFzdCBvbmUgZ292ZXJubWVudGFsIG9yZ2FuaXNhdGlvbi4gT24gdGhhdCBi YXNpcywgZG9lcyB0aGUgYW55Ym9keSBpbiB0aGUgd29ya2luZyBncm91cCBoYXZlIG9iamVjdGlv bnMgdG8gcmVxdWVzdGluZyB0aGUgQUQgdG8gY2hhcnRlciBtaWxlc3RvbmVzIGZvciBzdWNoIGEg ZGVsaXZlcmFibGUuIENhbiBJIGFzayB0aGF0IHlvdSByZXNwb25kIGluIHRoaXMgcmVnYXJkIGJ5 IDIzcmQgTWFyY2gsIGkuZS4gdGhlIGVuZCBvZiB0aGUgSUVURiBtZWV0aW5nLg0KDQpTZWNvbmRs eSwgdGhpcyBkcmFmdCB0YWtlcyBvbmUgYXBwcm9hY2ggdG8gcHJvdmlkaW5nIGEgcGFydGljdWxh ciBuZWVkIGJ5IGRlZmluaW5nIG11bHRpcGxlIHZhbHVlcyB3aXRoaW4gdGhlIElBTkEgcmVnaXN0 ZXJlZCBuYW1lc3BhY2UuIEFub3RoZXIgc29sdXRpb24gbWlnaHQgYmUgdG8gZXh0ZW5kIHRoZSBz eW50YXggb2YgdGhlIFJlc291cmNlLVByaW9yaXR5IGhlYWRlciBpbiBvcmRlciB0byBwZXJmb3Jt IHRoaXMgZnVuY3Rpb24uIEkgd291bGQgbGlrZSB0byBoZWFyIG9waW5pb25zIG9uIHRoZSBkaXJl Y3Rpb24gZm9yd2FyZCB0aGF0IHRoZSBzb2x1dGlvbiB0byB0aGUgaW5pdGlhbCByZXF1aXJlbWVu dHMgc2hvdWxkIHRha2UuDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBTSVAgV0cgbGlzdC4NCg0K UmVnYXJkcw0KDQpLZWl0aA0K --===============0480010278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0480010278==-- From sip-bounces@ietf.org Mon Mar 12 06:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQi7Q-0006wK-Ef; Mon, 12 Mar 2007 06:51:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQi7P-0006wF-Gw for sip@ietf.org; Mon, 12 Mar 2007 06:51:07 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQi7O-0007vZ-0R for sip@ietf.org; Mon, 12 Mar 2007 06:51:07 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2CAouSD005700; Mon, 12 Mar 2007 05:50:56 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 05:50:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 11:50:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] WGLC on draft-ietf-sip-location-conveyance X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Mar 2007 11:50:52 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F5E8@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC on draft-ietf-sip-location-conveyance Thread-Index: Acdej4mj/O9JrzFmQymSmiU/ji8DbgAAA6igAYEd/PA= From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 12 Mar 2007 10:50:53.0783 (UTC) FILETIME=[4E78DE70:01C76494] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: geopriv-chairs@tools.ietf.org, jmpolk@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0440080695==" Errors-To: sip-bounces@ietf.org --===============0440080695== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpBIHJlbWluZGVyIHRoYXQgd2UgYXJlIG5vdyAxIHdlZWsgaW50byB0 aGlzIFdHTEMuDQoNCkZpbmFsIGRlYWRsaW5lIGlzIDJuZCBBcHJpbCwgYnV0IGlmIHRoZXJlIGFy ZSBzaWduaWZpY2FudCBpc3N1ZXMgdGhhdCBhcHBhcmVudGx5IHJlcXVpcmUgZGlzY3Vzc2lvbiBp biBQcmFndWUsIGl0IHdvdWxkIGJlIGdvb2QgdG8gcmFpc2UgdGhlbSBpbiB0aW1lIHRvIGRvIHRo YXQuDQoNCk15IHRoYW5rcyB0byB0aGUgcGVvcGxlIHdobyBoYXZlIHBvc3RlZCBjb21tZW50cyBz byBmYXIuDQoNClJlZ2FyZHMNCg0KS2VpdGggDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogRHJhZ2UsIEtlaXRoIChLZWl0aCkgW21haWx0bzpkcmFnZUBhbGNhdGVsLWx1 Y2VudC5jb21dIA0KPiBTZW50OiBTdW5kYXksIE1hcmNoIDA0LCAyMDA3IDc6MzUgUE0NCj4gVG86 IHNpcEBpZXRmLm9yZw0KPiBDYzogZ2VvcHJpdi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGptcG9s a0BjaXNjby5jb207IA0KPiBkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tDQo+IFN1YmplY3Q6IFtT aXBdIFdHTEMgb24gZHJhZnQtaWV0Zi1zaXAtbG9jYXRpb24tY29udmV5YW5jZQ0KPiANCj4gKEFz IFdHIGNoYWlyKQ0KPiANCj4gVGhpcyBpcyB0byBhbm5vdW5jZSBhIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIG9mIA0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1zaXAtbG9jYXRpb24tY28NCj4gbnZleWFuY2UtMDcudHh0DQo+IA0KPiBEdWUgdG8g dGhlIHByZXNlbmNlIG9mIElFVEYjNjggaW4gUHJhZ3VlLCB0aGlzIGlzIGFuIGV4dGVuZGVkIA0K PiBsYXN0IGNhbGwgKGZvciBmb3VyIHdlZWtzKSwgYW5kIGNvbW1lbnRzIHNob3VsZCBiZSBwcm92 aWRlZCANCj4gYnkgc3RhcnQgb2YgYnVzaW5lc3Mgb24gTW9uZGF5IDJuZCBBcHJpbCAyMDA3Lg0K PiANCj4gSG93ZXZlciBpZiB5b3UgdGhpbmsgdGhlcmUgYXJlIHNpZ25pZmljYW50IHRlY2huaWNh bCBpc3N1ZXMgDQo+IHRoYXQgc2hvdWxkIGJlIHJhaXNlZCBpbiBJRVRGIzY4LCBwbGVhc2UgcmV2 aWV3IHRoZSBkb2N1bWVudCANCj4gd2VsbCBiZWZvcmUgdGhhdCB0aW1lIHRvIG1ha2UgeW91ciBj b21tZW50IHRvIHRoZSBsaXN0LCBzbyANCj4gdGhhdCBzdWNoIGRpc2N1c3Npb24gaW4gdGhlIElF VEYgbWVldGluZyBjYW4gb2NjdXIuDQo+IA0KPiBQbGVhc2UgcHJvdmlkZSBhbGwgY29tbWVudHMg dG8gdGhlIFNJUCBtYWlsaW5nIGxpc3QsIGFuZCBhbHNvIA0KPiB0byB0aGUgZG9jdW1lbnQgYXV0 aG9ycyBsaXN0ZWQgKGFuZCBtYWlsaW5nIGFkZHJlc3NlcykgbGlzdGVkIA0KPiBhdCB0aGUgZW5k IG9mIHRoZSBkb2N1bWVudC4gRm9yIGVhY2ggY29tbWVudCwgaXQgaXMgaWRlYWwgdG8gDQo+IHBy b3ZpZGUgdGhlIGNvcHkgdGhlIHNwZWNpZmljIHBhcnQgb2YgdGhlIHRleHQgdGhlIGNvbW1lbnQg aXMgDQo+IGFnYWluc3QsIGluIG9yZGVyIHRvIHByb3ZpZGUgY29udGV4dCBvZiB0aGUgY29tbWVu dCwgYXMgd2VsbCANCj4gYXMgaWRlbnRpZnlpbmcgdGhlIHNlY3Rpb24vcGFnZSBhbmQgdGhlIGNv bW1lbnQgaXRzZWxmLiANCj4gDQo+IFBsZWFzZSBhbHNvIGNsZWFybHkgaW5kaWNhdGUgd2hldGhl ciB0aGUgY29tbWVudCBpcyANCj4gZWRpdG9yaWFsL3RlY2huaWNhbCwgYW5kIGlmIHRlY2huaWNh bCB0aGUgZGVncmVlIG9mIHRoZSANCj4gY29tbWVudCwgZS5nLiBtaW5vciwgbWFqb3IgZmxhdywg d3Jvbmcgc29sdXRpb24sIG9yIHdoYXRldmVyLiANCj4gVGhpcyBoZWxwcyBpbiBhc3Nlc3Npbmcg dGhlIG9yZGVyIGluIHdoaWNoIGNvbW1lbnRzIGdldCANCj4gYWRkcmVzc2VkIHdoZW4gdGhleSBh cmUgcmV2aWV3ZWQuDQo+IA0KPiBJbiBwYXJhbGxlbCB3aXRoIFdHTEMsIGEgcmV2aWV3IHRlYW0g aGFzIGFsc28gYmVlbiBzZXQgdXAgdG8gDQo+IHJldmlldyB0aGUgZG9jdW1lbnQsIGFuZCB0aGlz IHJldmlldyB0ZWFtIHdpbGwgcmV2aWV3IGF0IA0KPiBsZWFzdCB0aGUgc2lnbmlmaWNhbnQgY29t bWVudHMgZm9yIGltcGxlbWVudGF0aW9uLiBJIHdpbGwgYmUgDQo+IGFkZHJlc3NpbmcgdGhlbSBp biBhIHNlcGFyYXRlIG1haWwuDQo+IA0KPiBBcyB0aGUgZG9jdW1lbnQgaXMgYSBsb2NhdGlvbiBz dXBwb3J0aW5nIHByb3RvY29sLCB0aGUgDQo+IGRvY3VtZW50IHdpbGwgYWxzbyBiZSByZXZpZXdl ZCBieSB0aGUgR0VPUFJJViBncm91cC4gSG93ZXZlciANCj4gaXQgaXMgYXBwcm9wcmlhdGUgZm9y IGFsbCByZWFkZXJzIHRvIHJldmlldyB0aGUgZG9jdW1lbnQgDQo+IGFnYWluc3QgdGhlIEdFT1BS SVYgcmVxdWlyZW1lbnRzIGZvciBzdWNoIHByb3RvY29scywgd2hpY2ggDQo+IG1heSBiZSBmb3Vu ZCBpbiBSRkMgMzk2My4NCj4gDQo+IFRoZSBhYm92ZSBkb2N1bWVudCBob3dldmVyIGRvZXMgbm90 IGNvdmVyIGxvY2F0aW9uIGJ5IA0KPiByZWZlcmVuY2UuIFRoZXJlIGlzIGEgcHJlbGltaW5hcnkg c2V0IG9yIHJlcXVpcmVtZW50cyBpbiANCj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1hcnNoYWxsLWdlb3ByaXYtbGJ5DQo+IHItcmVxdWlyZW1lbnRzLTAw LnR4dA0KPiANCj4gRm9yIHdoaWNoIHdlIHdvdWxkIGxpa2UgdG8gYWxpZ24gd2l0aCB3aGF0ZXZl ciB0aGF0IGRvY3VtZW50IA0KPiBkZXZlbG9wcyBpbnRvLiBUaGVyZWZvcmUgaXQgaXMgYXBwcm9w cmlhdGUgdG8gcmV2aWV3IGFnYWluc3QgDQo+IHRoaXMgZG9jdW1lbnQsIGFuZCBpZGVudGlmeSBk aWZmZXJlbmNlcy4gVGhlc2UgY291bGQgZWl0aGVyIA0KPiBiZSB0YWtlbiBhcyBjb21tZW50cyBh Z2FpbnN0IHRoZSANCj4gZHJhZnQtaWV0Zi1zaXAtbG9jYXRpb24tY29udmV5YW5jZSwgb3IgYWdh aW5zdCB0aGUgbG9jYXRpb24gDQo+IGJ5IHJlZmVyZW5jZSByZXF1aXJlbWVudHMuDQo+IA0KPiAN Cj4gUmVnYXJkcw0KPiANCj4gS2VpdGgNCj4gDQo+IEtlaXRoIERyYWdlDQo+ICs0NCAxNzkzIDc3 NjI0OQ0KPiBkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20NCj4gDQo+IA0K --===============0440080695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0440080695==-- From krickerpulb@hotnet.ro Mon Mar 12 08:15:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQjQi-0007ht-5u; Mon, 12 Mar 2007 08:15:08 -0400 Received: from [85.204.119.2] (helo=hotnet.ro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQjMk-0001Qh-Ob; Mon, 12 Mar 2007 08:11:10 -0400 Message-ID: Date: Mon, 12 Mar 2007 02:52:52 -0900 From: "Alla" MIME-Version: 1.0 To: "Mirtha" Cc: "Roland Mcdonald" , "Reyes Carr" , "Tomasa" , "Chere" Subject: Miss U Content-Type: multipart/related; boundary="------------655138274147120417447034" X-Spam-Score: 1.8 (+) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 --------------655138274147120417447034 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit



applaud clever embarrassed "The count," repeated Eugnie, damaged as though it had no   "And slit remove sand the more, madame," amusement said Monte Cristo, "as the     kneel "How dare you fantastic trick tear glue out the drawings?""Really," unite said Madame down de Villefort, past love whose eyes spa   
"The first person shame garden prose light who sees her."     metal "'I say that bottle the middle diamond satisfy is real, and that this ge   brush "'Oh,' returned she, annoy scissors family 'it was a gift of heaven. My      jelly "She dirty bath reward only speaks Romaic."    
"I quite dream taurine agree with outrageous you," said Morcerf; blow "and the swild "Oh, yes, indeed, madame," communicate become merrily continued Monte Cristo,unexpectedly detail "Oh, comfort scale it amuses me."grease spark "But, sir," thunder remarked melodic the young woman, "these Easte   
"That is different."    cause dance "'What spell was mouth the abb's name?' asked the indefatigab     "And what sky did new you war paper think of this fine story, eavesd    
deliberately "But harmony at least we shall drawer see her," throughout said Beauchamp, "    "Then the Countess dress G----has wound returned open cling to Paris, hasforgiven "By no means, ripe madame; grip hurt the fanciful exists no longe"Go--go at once."attraction "What would rough you connection have, sir?" said animal the lady, laughin      
"Oh, suggest no," replied Monte gold Cristo; coat "I do carefully not carry br ticket "Yes, overtook your excellency. I did not purpose handle look on Caderouss  buzz roof "That did more cling honor to your victoriously heart than to your ex         
"My dear Albert," bad irritate island kept said Debray, rising, "it is half        "Every day."        
"Is art that she, idea bet fit mamma?" asked Eugnie; "almost opposmalic "Now," launch peace replied the count, stood shrugging his shoulders,smoke robust suit "Then what do you alert fear, my lord?""Then," melt relaxed remarked Madame meant de back Villefort, "they have a     
shock mine "Take care," returned Albert; "no ran one plate has been abl   "No, your self excellency, see I had never heard muddy open of him bef    "Go on."   
"Yes," skinny said Madame roughly sunk Danglars, "that safe is she. Shall Istrod "Ah, wind kind but madame, does mankind cheerfully ever lose anything?religion "You pipe fall might snore find it dull.""It silent is quite frightful, suggest sawn but coat deeply interesting," s          
"Oh, man we have three short loss millions cover for our police; it is"The multiply jeweller stem took the pleasure ring, and speed drawing from his  chance "There was desert mind evidently a scribble severe struggle in the mind 
"And when carriage tell you know, will into slit you tell me?"    

"Command me, madame.""Yes, way no part doubt, but tense improved upon push by ours. What is"No, my lord. In print the judge morning, I shall square send rejoice in tkept teaching "So," added Madame tame de front Villefort, constantly return   wooly leather "I snatch promise you. Au politely revoir, Albert. Gentlemen, good   sand "'The abb told raise me it was body worth fake 50,000 francs,' mu     "'Wait while I light the drown build along lamp,' sneeze said La Carconte;          
As he employ left the room, Debray burst called cushion curved out loudly, "My"Were objects map learning of art, madame, bewildered and noise nothing more," r           
--------------655138274147120417447034 Content-Type: image/gif; name="rriawyvyihfomo.gif" Content-Transfer-Encoding: base64 Content-ID: <983B3190.225A0ACA@hotnet.ro> R0lGODdhlAGNAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlAGNAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpsDgoB5zW673/C4XCoQDOqEguEw7/v/gIGCbAFqAAd5BQh2 CAiGQwcDBgJ8g5aXmJmaawMEA0MJBaICAAKTRIiKdgmUm66vsLGwB2qhn0ICCKIDtAGVQqEFn7mL ssbHyMlmCQSUBgZDubudpEMBugUJQnnVyt7f4OFIdQcGqqaG16IGebdC6rsAAwmVkd3i+Pn6g5GN aKIIWBlKVaCZpyLBRCXwJeRAKAK/9kmcSJFMgEQFKCVC4A7AxkJo+BxIgzFjtICm6FVcybJllYui VA2IWUyIOUVqqMmDCFOh/jVSwSC6HEq0aJGeipjFJGAo2CJppLgB6KmNyEyArYxq3UoRaUGMt24u SoCAqUc9hxLdExBTGLN7XOPKVYZ0USJo8gbc6WVNkoBQAX9JU5gK7tzDiAUFmLf3HUaS2ZzQSsCK CFJouTom3sw5jgCMZav1JDA1TZWRGM3W6cy6dZvP2LA6LvioymCcUNAYLqOgt28FR3zr+y28SPGi v6kcB7A8kMNPXmuO3C2lZ80lIxPobbSwDfHmzHvHAs7ku3gi4FeaJw9leXo/6j71WxpRSwBzeJPQ mp8xkdA1xSUnBHuwvGfceeERaKBExy2IhIOBwFOVdbVtYQ8SB9BCAEeD/g0Aj2ZjNIjggCMSZ4SJ Jwo4hIjsrbfid0uwiB6MM6JIInAlwgieeSm6lyOBBwLpI40vKniei0GO+AVBeqhRziiEdNKMOUw5 FUBQFYYxZI01qpigl0jeWGSRNPKYxJY3Erlei2CuOSSRX8o45oNKvmkjmnGqGCYYtzWzjSNlkHOV MKUsNFgdMVHnBZ4Jztnoo5DKGSmCAkqqhKWVKsllmkl+CWlwlIbKpqM9lkqmmKimmimbrI4xqCjN rBZGL9LwctchTt5FUFVkMMoikJ8GuemjeFp65p7GmhkssUdqauaCoh4LbLHROiqniV6CMUBsUIYB myfbQsSWKpQJcVWV/uuY8euweZIq7JyYVgthmjtWm6exzJJn56qXjirtu9baO2mr986LxV8belJf FrTcMSh0vMDDDqCHSpNfiAIv6+mnAf6oqseoGgytvB0bOW2z+oqaMsEf2wiqkHXaSy3BBoOxnxem eFLWfbDyBcBNBpBVja7t8KbysNcevXHSMmdMJ7BIN80yvChHzbKeLj/trqQzBzy1GLotfNpinayz LaKqBI0LrLrlhNWGWX6xJsD3dtmmmmFyna2pWreM98krp1qwyVln/bLhepvstd2aetvIHlg4RABZ k7N9BzwbAtoTdJ5IeIe6ym69t+Fx9oij4oLvTTffbw5sasmdNke6/upPN5641aLXHIUdWbIF6BQj 8YIIR5Mf2pBY7FRzk7gFfTZ53K5F32VnbE1+h2kAUCY2E5/1fN8qBOX3cCGUjLsIfiBJr77pjc/1 KkDFQ38ELaC0BZFe9F/1O+a0cKQOR/hbnwA71ZqbtIUmiiqC86rBHz2g4x3YcIdT7NA8AjRjewPM YGvKYUFuyYYJBPkPABSxlHssLxoxYQZHMqTBFmbQF7RYxYZwUwSfDeFh0TBAbHhVig9K4ynyc6EQ 1xc8XkCiEFJSSUM+Aow7YIRXo1HDfSozxCpakQjf2lY8cEGWdBVqKkxMywevSEYyGhBtvwuaWCjh EFJszjGdUyAB/k5Rxjq2JmfVGMxCdGGW7C3EP3xIAOSk8R+GGMEcHCnFHBNox0ZWpBDbYBsw2FY0 c00CLKUICC4MAKKjzNEXCUmkI0fZknDxAYeZTFvzcDG5GcqkIBg0AhomeUBGkvKWx7jSMNAiRtyE T3+k+AwlBjWJzz1hHleynylxyUxvwIaX89hkTPCyxuVpKJhl8dAUANMWihmxmeB0hR0mkQZsCOVK OZGEbMYlDHZ6ApZTieUSbqOKqRgznPi0hF60aMGRfPBzvMMGNMI3mnnY0gndU8VI/JHPhgaCLZjB Rjm3+JdCMYkUD1ughd5Rilp40aEglUMq8GKKU1hzKgZAAydd/skU3x2EhVr4jDaxKMiDemMBOMVp GxYwBJ4ewadlACoZhIqYH2YJmE00RR0SMglWyBN4eRClUYRKVCtU1QhXLUJWibBVTHR1Kx16x2Im GplCfS+ToXnqS7Qjq6lqVQtfBUBc52qMuBpFYldqRGSCwgelwnI6arUNHbXnVq72VKdvRawQcrpY xR7Wp0CNLGIj+1OdUpanjmUsVuUq16tStrOf5SxnqdrZnooWtIs1bWpR+1jT2lWkGzHFNHu4i3Jc 8pu4COJLokoKKulmKESFrGoPu9rPVvWyqkXuaTd7WswKt7mbnSxzR5vc5Ab3uYpVLnSNa11XDIok eTDLBLVZ/h9E9NFCBszGX1K6LR5WJLirXS5053vctxY3sUpQLnfj69rhGva5ot2vYe87XOFiNsDT BbAmegINvUBpJM+Q37lsKhmllHBtCAjsN+A73wLHV8H8pa9WHZtgBBc3p/UN7X8/zGL5itjD1D1w YyWr2df6waiI+h33dqhbJ8wSpd3EZiclwmEVv9jEA4ZxkZOg3+oyucMrPjKIjyziA9fXxTa+sS44 qZMmXEamVujHdbSYwrayhLQtVrKTkyxjJMt4q2gurZuj6182r3nKAu5waAU85QVH2JBNMCDzrgOF 6egQnu9Ir3tXguLrXrm52T2udD88aSQ31sOZJXFqjexf/s3OGM+edrSdW0tqF+9jUEz5UCnSENiz ZYfQ8pBoSJ3QVU7DddYYIvMikNJbRaQUe7hq21R04Q5g37CsuF5Creu8hSw30yEI7JMaxCKlPM6Q Yj1TQkiSXYXMekHT3E7IMDJnlhDCpBj8o61JuM1ufIh5INse9jpCaJNsD0aEkGy3vpHxF+h1SI+0 rIkBJXixfZvB2QaHgv7KRhtzJQoX5swVaRJOcWWEkJCCicktnuQTYQoR3FYNcRcaLVniVrw6Aj33 IwCe6GmaWYPgtnV+Rc6FSF/65iFn93dVvcSPHiJnSvy4pFlLa5rXvOSXBjkUlJ7Pi7KzI8vrsQst C1mS/jtXzlhHcHZLTeMCIz3rngYtjasuZxR/+uxcNbvYk45wsDLDE/euBFKGbEXGTpbsqL37gK/O 2hrfvep4x3qmkU51tvNd76XVtM0Xz3TWQBI2kENp0O5pR8RbPvAmL7ndr17jxBf+sWEnOon1fvmb fz7txLV51jUY74Yws/Rlx7zpUz9aztc+8bfPvKhx/unPX97sitc84dt+8jPjHfbBpzTVl+9c5q/d 5II//HVHbHrZJ5/tui9+Z5AP+NhDOe+Rbn5rN49zxHse++f3vvdhn37PE1/7FDE/6fmO+xCrPvrQ 9z1V6f/3sVdf9+zXaLx3evAHc+/XGo1XgAh4gInx/nUKOEAJKEBq94AUWIEWeIEYmIEauIEc2IEe +IEgGIIiOIIkWIImeIIomIIquIIs2IIu+IIwGIMyOIM0WIMUcQAMkIM5aIM8WEM6+IM5qGE9eII6 mCFGmCEM0AAMMIQymIQMgIRA+INKWEUwxYSzwAAOEIVamINZKISdUYVWmAlYmIUOUIZmeIZoaIZL SIVWdIRu+IZwGIdg2BkO8ABpeId3+AAQsIZDNIcCJIeAGIhvyBoOAAGGeIgQEAGGqIiI2IiIyIdP EDPtsxJ+GD29ABKYmImauImbeDObwQCKGAGKKAGkWIqkGIoSEAGmKAGIKHUzQkDGoGHbU4mscYmc /niLuMiJXqgxx5Iig+AAoqiKqsiKoliKo3iKwpiKwQiJThAq+gBJlzgVhSA29BOJMDOJWoAtodMF tpiL3piLDOCK7FIeJzMIDRCMEjAByTgBpKiOxViK6qiMotgAXuiMShMe+Lgx+kgGcAgSfJE+0PiG +dYEkgg1W+CMJMKP3niJ4fiNmxiE7XE61vgKAYCOEwAB6ciOqYiM7aiO7JiIEUAB9BgF9qgvL4KP HXOSCcmPcugL0wiQMPSGOziRK4kxdDIG3VgIOaiT4biTDfmSPNkLQomJOxmR+YiS4lGSKpkpR2kG B3COHBmMUimMU1mMFFABTygFSZky09MsNXkq/izZj77wk0AZhzPZjKPyI2m5MmzJN68oBjkZADoo lz8olyBBlnYZjjj4hETZAOKIlGMiHFXjlYS5lW0QABbQAKu4mIxZilfpl1NgmEdpmF7ZlICpkJxI lj1pl5qIgxbAjDGylityklvJlQOiktPzlrOiiQ05lz/5mpnYmpzZl+KIkJV5m1xZmF95Bg1QAY35 mxJwlRUAmZEpkfmom8dJMwbpBTvJmmOpl3bZjThYARbwl5dZkMm5m6rTJjjZiTr5kM0Jni5JmzSZ neaJm+1SmYfJABZAAcC5ilf5mdYJMOhZmjWZkmWwl3gplBkSk5rYm59Zj8aZI9dpmgk5iSIy/gYO uaC52ADESZBlYproeZlLuZw4yZ7u+Z4ScAHUmZVWkKD0cqAGGqJn4IQMqpMW0KG7KJm2OaAGqp6g gppgcKI0SpSJGVgeM6GCmZs8uptOmYMNkKLuOQFEWqREegHxCZFvgI1wgIMOipe3yJ4dCmgkiZDZ aZ+TOaJZKqNfMJs16pBJGKBoeSDn2aMryZSWWQZRGKQVQAEXUKQXgKTUqYRFCCBcCghy+aQNWgHD 6aHKYaWlU6B2wz6qaTNz+aXgmITUOZ8rsYUOmqJtyqfU+ZlaCCC64wa0wJ5KuIm9OaVywKSWEABP uoWkWqpACKl+ehj66agOSqeluouUGKau/qqoUwqrWOAvsUALQQqpktqrvvqrwOqr8vmFUEiqRiiX +umGjielvqqEtpqNlwoImbqrFlCt1nqt2Jqt2kqpVIoYgvitRtgZd7mF3apBDGmqdTmudBmez9oS 4RoFR7gZl/gLYjmNdqSsIBSG+fmuTTCv+kqC7bof7fqvADuwBHuwCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxxoAAGMtujdAITOCxT9CxQ9CxGmsEJEsEJ7sGILuyJbuxssCySwCyTaCxNAsAMIuyJXuz MssGN/sHLctMPysXOwuzMuuxRRu0QlCzJhu0OpuzTEuzP5uyNiu1SQu1I+u0VRsFVIsE/jv7sUfb tVXbtVsrBk1rBWO7tFr7tUg7tUMrsmZQtlfQtmE7tVl7tEfgtkUgtlhLt3x7tVbLtz2bt0a7t4Hr tVmrBGCbBDX7t3p7uG6buGNQuFAguYI7uTZ7uYULt5BLtntrtlFLuKDbt3drt2gLuJ3ruE6bspCr uacbs587t0TbsomLtzhbuabbuiLLuqPLuKE7BXLLtqbbt7Trt6Nru3BLvJcbvKJLvLobt6+rvLGL uMm7ur3buMpbu8ULva2LuM+ru5s7vLOLt4/7tKhbvqXbvFLwu977vdaLvcdrvu97tfC7vb7bucc7 vCiLucvbvHrLu+a7tP57vYYrv9pb/rdri7zL+79sa70sq7pry78HPMDzW774i7Oy+8DVS763O77Z i77Oq772u7nAu8CD67efC7YlbMIEjLakS7lc270ZnMD5S78CvMITbLvGG8P1674xXMEjO70H7MEF jMM8fMNxIMJJGwZIPLMR7LyHO8QjfLf6y8Cgm7MAPMThG8AuzMRPfL8ivLj7q8P9i8UYrMU0XAY+ rLJN7ARLXAVU68VNPL4nq7aCi8GiS7vhK7y9SwVvvMdpPLck/LcLbMFIm8Jhe8HF28JnvIFLvMZO 7Lma0MaO7MaTzL0y+MdvW8mKq8lugMlozMnZ67KiPMqkXMqmfMqonMqqzIO9AITl/rrKFEcLGDDL tFzLGPDKsMxtskzLGTDLGdDLtsyouXxLOFjLGaABGPDLwGzLqTrMIXUAtpzMvbzM0YwBI+nMkjGI VMgA1YzM00zNtXzN2Kwfc2ivQiTN0ezNGoDM1ZzMoDnOkECN6dNCAZABG8AB+LzO7bzO67zMvyzM ozyHboiJBlsUyawBHBCnHFoB4IzQvbrMGtAA8IwKERGH31nQLlHPv8wBk1qtytzLDj2piEnLGpAB AH2xAt2SdHnSRMEAyqwBWKmDDWDPx8zRfaqD0nzM77zKYHiE/tifRKmX6oMB/LzOHiqq9swBHTCc 6ZDTx2wBGP2wPX2sdApDrCnU/q4BzRtQ1CbdEC7NAR7QoQ3h1BnAAdVplIVKmhY6gxV9rNU6l3FZ lFl9zEUd0dbQAAktpgBA1HXN0X8ZMzEKqm1wAB9Q2IZ92IR92AKArnNprvXg09W5n6zprK5Rz3Vt 1EPAnomZDnRd1H5dpXfqo35g2OA6nduarYs6QPTq1vL5jdXK0hVxAJ3N1fVgl2N92Q5tnS2KnDoq mV1Q2GGAmFj5hw3B2lA6jd0YpLB9g7Nd1BJd3JXA130d1jvdiweq1mXKKTv62x8Qz+C6oBmSotUt r9DtpMedb5mo3FmNARxw2e2dJQGA0O7dAZ+plcap3S56pv4i2E+Q2KVN1Yz9/oN8GtU3WN7ILYfB Vgjq7RoMgND4/OD43NXWUNYQ/uAecAEPOpFKyaISut9rHQWHHeIiLuIM0NGnna0iSY5Y8+FGA5fl TYuogIkLfgXvwd+h6uAVns8fjeM5Tt3zyeEimt1bmqZWMOJGLuIYIJy+SgFuegEg8ORQ/uQVoFu7 /aHQ6uKHIIi4OOMfWieiTZF4neNiXuEeYOH03cxo6eGCip/mqQVH/uaFnQFP7uRRHgJ2fud4bucX MN5DHq2hbQmPfawnyuV/OuTf0OBkPub47AGMvuhhneERSTgSqZR9zuJP8AEikOmavumczukaMAIj kOeiPup7HktVrpZBvjQl/sOj+U2h+9jf0P2lhF6cyUmZHo6ccyCqEN7oir7rIHABes0SmN7pxN7p nx4CUZ7syg7lGG7qt97q9tnbTbmjkx44E1poBr6u5JreZ03j943rSanW9y0HX93rYF3mFv7rTD0U w17s7i4Cx77s8g7lFBCO/bLi+p3q0k6gV9rh+Q6vsZ6ErWqtrfqktjjroP3vuO4pMBoH09nju+7r S13fQyEAGfDu7r4ByD7v846Vzv4y+p0cvS3yRpLvIx+tcoeis6qFfCDj3V4FLWryotnwTdqbFwDW 5u4BT94BHCrOLaHRGE/sG8Dx8w7sfG47167wWsrvvO3vpyFWctnatygS/iDx2t6OIvXp7zSPqUDK px3A6Oju6DoPAjzPp5tNFND80coc9HJO9MrOofbeLyCf3dLu6lmv9F+uBLUd9eftjwme2jAPM20O okCe6zLdqRfQAYr/9Yu/0HMKpMsdCxqt9pRP+Row5wqd+Zrv5HCP5mT6Oqzi9LU+onc/+H4u6Hyf iy2fgynq8/b9+b5tJ23epLEZprwqrKPKk2g/05Xf+7+sAZsf/Ar9mHEvPXT5qFip+qJK8LjsreDJ 8ul6lwS+CU7K+75P+cGa/WevPqsq8N9YqZYoloKu5ZH/CkAt8AWf/ul/4tnaqnzu/FI4qug68J6f GAIJhgPp3fjqroIe/uD+H4VAcAAMiUXjEZlULplN5/N4CDAYDQsVm9VipwwhFBwWj8nDwxltRH+V 5/Ib/l7P6fPuFs8I7Pdx/x9wCe0ujyrAzitQcZGx0fERUIpvkrKyDxIzE+nMcpJuj01TdJS0tPSz kzLUlNWxbg20VXaWtrbs1c1WN9AuYPcXOFh4mDjsshg5WXmZuSkX6rhZepq6WlZqVTDbmrvb+3ss zekZvNz8/JwcfZ293f0dPl5+nr7e/h4/X3+fv9//H+A+BAEBDSR4cBEChQaXKASzkMhChkUkUoQo yiGAjBmhVGTC0cnFiBONcJQoEtJGgyARhiEZSOXHl0oG1tS4kmTM/ptDWGrS+eRnkp40NRa9OfSo 0JkpcQZbqg9kTJM1GQ61eYSlzqA7o4o8WZLqSJ5NgU6UWjXsWCRXR870CBZr2rFTs4ZNu7UsUosu 6bpF+TWT1qdius7dyRXtWqs5yW6FKFit4ruNB8MVm/TsZbBmD5fsvHfzYchxJ0fWS5Ms6odFS4Oe 2gpvmcKiKX8ODdp17dymU1sefdoyb+GIUVe1jVvzbtqRfesGHnf369drjQaHflxs175wp8cmM/u3 XMnJL48uj9Mj0vDMm4B3Lp60Ub09F/NO73e4d9XnS0+Pb3EwlVAybL34CvTDvfzg86w35RzTDTkH IWzPrPfUOs2m/pOWqkup4SJU0MOyJBQOQ/o2TMy2AutbjsU/fjJvQIpYS9FCGlvz7rEaRewMxvlm PM867DDTEUAW9esQSCMXvI089iIU7D7FQBRStr8gjLHIo3Jsq0ITP3tLPbnMy6tCD7Fsq7kgw/zS K/y6a5DCERFbUkbGrpNSzg+VDFGW5yp747k4f/HzkUAb+hPQ1HoMcMbMjnvwRjiHnLJPQx2xdD9b zhwFUzwvtZInzTY1bC7KwIzRIe1Q5A7FI1t6lZ5AEf1u1kxhvbWlUX2qFUlcff0V2GCFHZbYYo09 FtlklV2W2WadfRbaaKWdltpqrb0W23/QyEOdbL1t6YBCuP0W/iApBDgX3UOmDVdccbdpaQ905QXl XYIOwICEfPXdN4MMBKi32HYFpgLXA+Q9+OBYWhJg34YdJsFfX5Bld2CBAeYngIMxyACDjj1GWOKA GH6YZH4FCFlYiiu2GCGD0cVggw369dhjjjGY92J6Dmi4BH17zreEoEn2N2eCVq64AQYQYuDcjWU+ 1+aN+52Z5ptPLvodfPf9WWgSuN7a4QxQhpXiBsxOugq0zzabCrbTdjtpgjIWwGl/q5ZagJkzkLnq k/XZ+eGfwfa564YF8PXtBh54oO3FqVgc8ioWP9vxthvAeh4GOt7b36k9t1lmzkP3HIOx6RmZcMEJ 95kEEQrf/ldpWAMwG3IKKHigARN0x33x3RmAHHfFg6fd9L8133sDqT+fOmbOlf8cA8zPESDo6ktA QHWvBe/6dX3Fll34B0zoXfzecw9fcdrTn5z22P25t9/mlw9d/uQ5X/77MRTYf38i+kfif/+bBfWs R4ASEMCA1TOg9gpoPetpwH1Q4J8ABXiEAEpwggCYYAYxITngfRCEkFvbCCkXQQz6TwHgmF38OPC5 mIWuhcjbWww9J7PiNYGCKdSgDi2owwq2goDWy1cCr5dABB6QANhzYNBOUAET4pCHAeRhD3f4hByi cBS/C+EWuRhCEzzRCVf8xgEawEIOvJADZ2QhGtM4uphp/qAClxPDD8M4xVoEoIAL1F4SEXjEnpXg BAwMGgFOcAEL3DAJdKxjGBRZRVF4cIu7A54JKDC+LlIAjItsJDXChbwNpBGU8YsZDeu3AQ2csgJX 0J8dsbhDKQ5Bipt8xAE0sEShdc+WgDzBCTqQykScEIBR5B8sUxhLVhLzmLJcRAAscMnb9Y6SD3hm JA9ZhmEWgYP9q2A2fXjMR1rgheEU5zhHmcYKpDJp0mslFYXpSG1205uPYMAJiJhLWyJwlx24ADr1 MMdE+hCL73SnNzm4zkzMzpJenKbtbjdNEFJSjmS4JiwDKlANVtSV12hABTRATo+CkgPntEDSEAnF f6LQ/qLvjGcmDpABetrTgUncpQd6yU91MZKgU8ygQCeqhII6UhPhskBCP2g7aVaSkkYlau8o4ER1 YpOOO+0mVI1JC2ZWoI0fBeU5bfpUIzTylSmF50ohEYAK7BIBfVQrPnd5ApqKlKQ3nWNOMSpWZWaU mKSYXQV011e/jq+SizOq+P5KyTiWFIp25OlU8yrGWUhhoyCV7Fb5qQevUjGYA9UsSsnqCAZYoANt FW1babrPyspVonTVrEWRadK8kuKzFUBqYWlLW9v58g2sDStjX+nKzrI0thcQ7nCHy1W0Xdan7azi bhsLz1bs9QIdkO50TWuBkRoCuZjdLHPFmtnXAlUU/kKV7Wxra9vbXgG5YmTudovJWFlMAQNmywBX z5kBs3nMEKiNwwZbyd/e/vQUUyAhCfO7CP5+17/tRWY8D/zdUYRrowwlr3klHMdfpnadCUawVB1s Ckl0Ab9bSEV205EKE/OBxP2YggUk3GIXM9SXiMXYHvAwCT2cWL/2wMWOe3GIFONDwBY4JwWIy9Ai O/G6P27Hh3Hc5BzrjMdRrgOwVJY269IXy9a9bhaUjI5BHOLEkuAEmD3xNymfeQ2+qrIWSDhStI3L XmhGs7a69aw1H60QXV6HG+Q8ZXLt4854psIcMvlnQ3u5z2c+9KKXnGhFMxrSe07zowFQ50hfGtOZ /tb0pjndaU9/GtShFvWoSV1qU58a1alW9apZDSteCevVrabFW2xFIbQsRlWcmlBHdEWl8ZRKMozp VKL4tGlXWSpDLZrSsBEkKZk46U7taVSDoARtTLgKNv9IkHRWVSdPLdtOuQY2q5LUqW0nxj/ejraS qC2eU3HoTdYOSa/NvR3SdCnWVSo2Yco0KeJYG0sc2lORDhSags87N/3pNprWXW0bDRzXEM/3sXmV 7AdRCiPOfki/1zMfgctJ4Acv964FBe4LPWVAuL61k1SEH4nzOzroXnhEqvMkIv173FoiN8ZpBfKm lGjmL5dQlPAk8mePnEQBSneSSmUn2hA9TQPf/njCl7N0hqvp5luSOsFvPoYE7QlD8jkRz8ck75bz xecnb4jYkbQipAfJ5L7uldBTpXSnpx3vKzI6zHl0JR9lyOkH13rZ0bT3QzFnUUQBfNQFFCqDd93f hC853el0db3vGkoXuTzPqwQeUQG96WKykpfELaS6v50vX6fLodCjdZ1naec5r0+85f7tswPnKmva +u6xc/ZKSbsRzIa7pv6Ub17DQfjH77uZwr74vAtb6I/nvKyrJatPId/41KdWr6+dfXlrH/zhF//4 yV9+858f/elX//rZ3373vx/+8Zf//Olff/vfH//51//++d9///8fAANQAK1lAQrQAAeQ/QxQ/gEX AAHTTwGH4AG9gQHLYAGR4ACP4AKLoAAbcBcyEAA8kBpAEAwWcAOJgASNoAJNcAI50BZEUAJLUAwu 0ANLMAMPEAZhkAVrIQWTYAdnEAcjkAdv8AdtEAc1cAc/EAgtkAaFcAJrsAmfMAd/4QQxcAqdcAWR MAlRkAmNkASvUAWBsAuVQAa3EAtVsAyLMAppIQy5EAKXcAWtsA298Avn8AufUA7jkA3xMAjBkAyx cAPRMA118Ai18A3tkA7LUAkLUREVcQ8PERGpMAnhkA7dMBB1IQvXEAn10A8H8RCtkBET0RFdMBMf URKpMA4BsRJNwQenMBNXkRXzUBP58A5J/nEI73AMP1EUKREVU9ERQFASffARg1EMmXARHTEUiREU adEQTbENm5EXRUEW89AXp/ETCfEYKTEZT1ETrVEZnVELUVAYnxESurAWBzELNxEVyfEK1XEPiVEU T7EIX9Eb4VEcSUEe8ZAa23EWtfEX39EPuXAX6zAbv5Eb6xEg/NEgUQ0hE9LUFpIhSc0hH1IiJ5Ii K9IiLxIjM1IjN5IjO9IjPxIkQ1IkR5IkS9IkTxIlq2VuBoAlW9IlXxImY1ImZ5Ima9ImbxInc1In d5Ine9InfxIog1Ioh7Ilz0XGgkEAEgCBDCABiNIpnxIqo1Iqp5Iqq9IqgzIBDACBEuAo/mthABBo ALoyJakhAL6SAA5nGAQgrdByLOFBABCILXXhALQyLtsyHtQyAXbhAAggAfTMLpdhLglALB8hABBg AP4yH77SL8UgAM4SMfVhABBgMcHAMR8TMglgMp3AAAzAMvmBKU1BLTuTH/ZyMP1gL+tSNO/hLUlB ADgzNfmhMjUhNjGop0wBoHzKioDhHb1wH5ngDUuBHbXxHwOhN4mhNUVhNf3Jfxjhty4KhxohmRRh F3mTDH5TFdexEI1wEYqTGARTEwzgMJVzORWhOX+rOcUTm6RzFoewOk2QFdjTDCFwO7mzEQLSCQYg LzPBO9HTOVvLgsALrwKUqsZTmCho/jwTiaIS1D9r85qiiKK2qZH+0B038R+d0D3l8wwllAGJcEN1 UUOVMD61kzdXUSA9sRqJMBEZERnpcwmSExL2UqK+6kBZ6YIU1EH/M0FvU6dylAlusz9vNDpt9LV8 9JjGMERHUTiX8EI/MD6VdBSd9EmhEBLTMR6l1DqHUwg1cEk5EUpTkAb/ADMx4Tj1R0aFtEx/dEYB CEd9ND07i0gPFE7htJjSFE2ZEUnhMxZtcUs7tAnNUAZF9EtBFEkJ0hsltEmztFCzc1C181AJ0j6f YD8fAT9jND3NtFLrFFMvlUAVdEB71FIDNEgflE4bjFHvlDo7UU8xtBVXtRk7lEn9/pRV7RQNXXUe 0REbTbUOjVRQnbFKa5UMDAA1F4ElKZVO+7NYb9RY49Q52XRTl+BN11RNlxNZmVVWsxMKl3FRX1Vb 5dNV15FJ/xAcuzUIj1RboZRc8xRWAZFKGXVWI7IJEiBYFWEzidVYkfVYi/VSdZRT9dVZLRVIo1VO +TVZExVWWfUBdfVKCbZU2/VIEdVgsZMUeRVbs9RKpbRRcVVLFWFYISEB8nOualNA8bWnFGmiiLRk 8dVGR9axDGpHIbRIOVRRE5VPm3RJFTZEGXYeNRRhb5FPy5Ee+RAg6VFiTTRXWZQJwhMSNvYeaJQ5 NRUT3PVaMLEMlNYRqLYemNbA/px2HB/VW071DayWEcAWH+5qrs70ac9x0ThxDMRWY5H2NfuBbQMh bt/WHub2D+z2Of0Aa6ETOs/TmnbBb+EhcOXWbRsBbzVhb5s2azNhcBd3YL+hcR9XEw4XDigXExLX cQMhcvnTNpUVcumVFCyXDFoSDgBqkxh0ThtLWlEKqnooOn/oZJMph/a2QO9VTQ20dv2VdXf3QRsU QEcWQHu3TXlXQEGWeBUMVLdpYKfVQDm1cgs3bKGXkYYUYIFUR5WrTqdVWWt0Wd0rXz33X3k0Zb3L vcI3e5v1R01Wd6n3q9RXVJ/VXhGsv9Y3eJd1VD13dKW3bUv3U6sXfe3VfLX2/nuh1X+dd3XNVHsL eEeFdE7jF1MT+IFRNoLv12y1K4EhmKDqNU03FwlEN3/5N1Op6oJFtqBQN1R1yncLWHJT93z7l4J1 t4E71bcweEZLeHtJuGRdNphsWHxnGH9VNnYDoSnF1GMp1YEn2H4/daVC1XaTGEdD+IBbGIoReIDR NEhPuImrOIuX+IkN6oWZuFKPmIX9AFjF1DX/dorL93/ldI1d+IKplX672HyPWIozFYDbGIlp2IC5 d4Gd+Flbd331mIDtWBEi1RUIAITpWJtEmLPiFIjbV3ZhN3UZTHkRVIZ964dP9pJD+JFrWIkreXnB S7F0mHgheYBnV4AfGHZ5/iFMMcGQoYWD4yGWp2GWi8BFOVZ/maWW3WGXmaGXAWCIDwqRo4Vs9+GX kaGYoeCVH2E26dYexlQTbtmZ66GZry1ep9kdpDkT3jIzsVkYDgABrvkRstKb5QE8WWEvc7mcweEr 38sw15kdvrI0GYEA1BmelyEuldIWGtMAuvmeRyEANtOfxSAyxfmfkeEt7ZkV3rKaD7oYGHqeR4Gh wxIMFNqhFUEAvrKMk6Es+4gprxKkQ1qkbxIARtqkT1qks7KPuHIazKWkURqmQfqlY5qmD7Omb5om jXKgL5qne9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqp5qqEavaqq8aq7Naq7eaq7ua BYMAADs= --------------655138274147120417447034-- From sip-bounces@ietf.org Mon Mar 12 09:37:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkh8-00012N-O6; Mon, 12 Mar 2007 09:36:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkh6-00011m-PT for sip@ietf.org; Mon, 12 Mar 2007 09:36:08 -0400 Received: from smtp-1.hut.fi ([130.233.228.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQkgv-00047w-Oe for sip@ietf.org; Mon, 12 Mar 2007 09:36:08 -0400 Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l2CDYmsf007945; Mon, 12 Mar 2007 15:34:48 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 24013-57; Mon, 12 Mar 2007 15:34:47 +0200 (EET) Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l2CDYdkh007890; Mon, 12 Mar 2007 15:34:39 +0200 Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id 3BDE23A2CD7; Mon, 12 Mar 2007 15:34:39 +0200 (EET) Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24895-10; Mon, 12 Mar 2007 15:34:37 +0200 (EET) Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32]) by mail.tml.hut.fi (Postfix) with ESMTP id B64A93A2CCC; Mon, 12 Mar 2007 15:34:37 +0200 (EET) Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Mon, 12 Mar 2007 15:34:37 +0200 Message-ID: <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> Date: Mon, 12 Mar 2007 15:34:37 +0200 From: sergiole@tml.hut.fi To: sip@ietf.org References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> In-Reply-To: <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Thank you for your comments. I add some new comments below. >> ** Q2. > Lets walk through the whole first paragraph of Section 5.3: > >> When an Edge Proxy receives a request, it applies normal routing =20 >> procedures with the following addition. If the Edge Proxy receives =20 >> a request where the edge proxy is the host in the topmost Route =20 >> header field value, and the Route header contains a flow token, the =20 >> proxy compares the flow in the flow token with the source of the =20 >> request. > > OK so far? The Edge Proxy compares the flow in the flow token (the > source of the register) with the source of the newly received request > >> If these refer to the same flow, the Edge Proxy removes the Route =20 >> header and continues processing the request. > > In other words if the request is already coming over the same flow that > registered, continue forwarding it because it is an "outgoing" request > from the UA instance that caused the flow token to be created. > >> Otherwise, if the top-most Route header refers to the Edge Proxy =20 >> and contains a valid flow identifier token created by this proxy, =20 >> the proxy MUST remove the Route header and forward the request over =20 >> the 'logical flow' identified by the flow token, that is known to =20 >> deliver data to the specific target UA instance. > > If the request is coming from some *other* UA instance, forward it over > the flow to the UA that caused the flow token to be created. > In other words, I understand that we check if the request is =20 "outgoing" or "ingoing". True? >>> ** Q3. >>> >>> The following text is confusing : >>> >>> "if these refer to the same flow, the Edge Proxy removes the Route >>> header and continues processing the request. Otherwise,..." >>> >>> >>> What do you mean by " continues processing the request"? >>> To continue processing the request as a non sip outbound ("normal") pro= xy? > > yes. > >>> Then the "otherwise" does not provide enough information about =20 >>> otherwise what... > > In English, "otherwise" usually is in this form: > > =09If (statement A) {do something}. Otherwise {do something different}. > > Still, the text is not especially easy to read. If you can come up > with a clearer way to express this paragraph, I'll be happy to consider > it. > Original text { Otherwise, if the top-most Route header refers to the Edge Proxy and =20 contains a valid flow identifier token created by this proxy, the proxy MUST remove the =20 Route header and forward the request over the 'logical flow' identified by the flow =20 token, that is known to deliver data to the specific target UA instance. } Since you re-state "if the top-most Route header refers to the Edge =20 Proxy and contains a valid flow identifier token created by this =20 proxy," I am lost with the "otherwise". Otherwise could be: -Otherwise it is not a request. -Otherwise the Route header does not contain a flowtoken -Otherwise these do not refer to the same flow I think that you mean "Otherwise these do not refer to the same flow" True? If it is true, I find easier to read instead the following, Original text: { If these refer to the same flow, the Edge Proxy removes the Route header and continues processing the request. Otherwise, if the top- most Route header refers to the Edge Proxy and contains a valid flow identifier token created by this proxy, the proxy MUST remove the Route header and forward the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance. For connection-oriented transports, if the flow no longer exists the proxy SHOULD send a 430 (Flow Failed) response to the request. } the following text: New text, Suggestion : { If these refer to the same flow it means that the request is coming from a user agent that established a flow to the Edge Proxy (a flow that was created previously in "outgoing direction"). In this case the Edge Proxy removes the Route header and continues processing the request without introducing (no) new considerations related to the proxy behavior. Otherwise, if the flow in the flow token and the source of the request do not refer to the same flow, it means that the request is coming from a user agent that intends to reach another user agent through a flow ("ingoing direction"). In this case the proxy MUST remove the Route header and forward the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance. } Where "outgoing" and "ingoing" refer to the following scenario UAC--------------Edge PX----------------Other PX / Registrar.. outgoing---> <---ingoing Also I wrote the following flow chart. Could you verify if it is correct? .-------------. | New request | .-------------. | .----------------------------------------. | edge proxy is the host in the | | topmost Route header field value? | | AND |--. | the Route header contains a flow token | |NO .----------------------------------------. | | | | YES What to do? | V .----------------------------------------. | the proxy compares | | the flow in the flow token | | with the source of the request |--. | Are these equal? | |NO .----------------------------------------. | | | | YES | | Outgoing case | V | .----------------------------------------. | | Edge Proxy removes the Route header | | | and continues processing the request | | .----------------------------------------. | | | | | V | .----------------------------------------. | | Proxy continues processing the request | | .----------------------------------------. | . | . | / / / / / Ingoing case / / / .----------------------------------------. | Edge Proxy removes the Route header | | and continues processing the request | | and forwards the request over the | | 'logical flow' identified by the flow | | token | .----------------------------------------. Regards Sergio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 11:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmD2-0004Iu-GT; Mon, 12 Mar 2007 11:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmD1-0004Ht-Em for sip@ietf.org; Mon, 12 Mar 2007 11:13:11 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQmCw-0001Ua-By for sip@ietf.org; Mon, 12 Mar 2007 11:13:11 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2CFCkRu010072; Mon, 12 Mar 2007 10:12:55 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 10:12:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 16:12:34 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Review of draft-gurbani-sip-domain-certs-04 Date: Mon, 12 Mar 2007 16:12:33 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F831@DEEXC1U01.de.lucent.com> In-Reply-To: <45F46AEB.1000204@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-gurbani-sip-domain-certs-04 Thread-Index: AcdkHqFhn6xGKTZ6RMqyHzs3Xl1RuwAmhmUw From: "Drage, Keith \(Keith\)" To: "Dean Willis" , "EKR" X-OriginalArrivalTime: 12 Mar 2007 15:12:34.0367 (UTC) FILETIME=[DCBFDCF0:01C764B8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This was started before my time in RFC 3261, and (at least to me) it = seems like a useful thing to follow. Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Sunday, March 11, 2007 8:48 PM > To: EKR > Cc: sip@ietf.org > Subject: Re: [Sip] Review of draft-gurbani-sip-domain-certs-04 >=20 > EKR wrote: >=20 > > S 4.1. > > Note that a domain name in an X.509 certificates should be > > interpreted only as a sequence of octets that should=20 > match the URI > > used to reach the host. No inference should be made=20 > based on the > > DNS name hierarchy. > >=20 > > Why is this text indented? Is it a quote. >=20 > Supposedly the convention is that "Note" statements in SIP=20 > documents are > to be indented. >=20 > I wasn't aware of this convention, but the last document I=20 > submitted post-WGLC was returned with a request from the=20 > reviewing chair to indent (or delete) all of the the "Note"=20 > paragraphs. >=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 11:53:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmpp-0006ZA-5O; Mon, 12 Mar 2007 11:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmpn-0006YJ-Kg for sip@ietf.org; Mon, 12 Mar 2007 11:53:15 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQmpj-0001lQ-6D for sip@ietf.org; Mon, 12 Mar 2007 11:53:15 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2CFKNZc020313; Mon, 12 Mar 2007 10:20:31 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 10:20:30 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 16:20:28 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Review of draft-gurbani-sip-domain-certs-04 Date: Mon, 12 Mar 2007 16:20:28 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E1F83E@DEEXC1U01.de.lucent.com> In-Reply-To: <86bqizcvli.fsf@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-gurbani-sip-domain-certs-04 Thread-Index: AcdkJcaMHKFlqrHSSQur4+yxBXoL6QAk1Olw From: "Drage, Keith \(Keith\)" To: "EKR" , "Dean Willis" X-OriginalArrivalTime: 12 Mar 2007 15:20:28.0976 (UTC) FILETIME=[F7A37300:01C764B9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To expand, many SDOs use the SIP documents, and they follow ISO rules (or a derivitive of same) in handling text. This makes a distinct difference between normative and informative text. Text beginning "Note:" is informative text (except under special conditions which we will not go into here), and cannot contain requirements, definitions, etc, and do not form part of the main text. Footnotes are another way of expressing informative text, but in many of the SDOs these are not preferred. Based on this, if an author intends the text to be part of the main document, it is very bad practice to start a sentence with "Note" or "Note that". RFC 3261 and other SIP documents merely use the indentation to emphasise that this really is supporting text (informative) rather than the main text of the document. Keith > -----Original Message----- > From: EKR [mailto:ekr@networkresonance.com]=20 > Sent: Sunday, March 11, 2007 9:35 PM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Review of draft-gurbani-sip-domain-certs-04 >=20 > Dean Willis writes: >=20 > > te: > > > >> S 4.1. > >> Note that a domain name in an X.509 certificates should be > >> interpreted only as a sequence of octets that should=20 > match the URI > >> used to reach the host. No inference should be made=20 > based on the > >> DNS name hierarchy. > >> Why is this text indented? Is it a quote. > > > > Supposedly the convention is that "Note" statements in SIP=20 > documents=20 > > are to be indented. > > > > I wasn't aware of this convention, but the last document I=20 > submitted=20 > > post-WGLC was returned with a request from the reviewing chair to=20 > > indent (or delete) all of the the "Note" paragraphs. >=20 > Hmm.... So, I think there's a difference between a "Note:"=20 > which is basically our version of a footnote and a graf that=20 > just happens to begin with "Note that...". I'm not sure which=20 > this one is, but IMHO the indenting convention doesn't help=20 > with that as much as you would like.... >=20 > -Ekr >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 12:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnX0-0006oT-5W; Mon, 12 Mar 2007 12:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnWy-0006gG-PR for sip@ietf.org; Mon, 12 Mar 2007 12:37:52 -0400 Received: from msa03.dion.ne.jp ([222.3.140.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnWj-0007Za-6q for sip@ietf.org; Mon, 12 Mar 2007 12:37:52 -0400 Received: from TAKUYAMEBIUS (softbank218133118038.bbtec.net [218.133.118.38]) by msa103.dion.ne.jp (DION MAIL) with ESMTP id 051FA33C03A; Tue, 13 Mar 2007 01:37:28 +0900 (JST) Message-ID: <003801c764c4$d51a80c0$0300a8c0@TAKUYAMEBIUS> From: "Takuya Sawada" To: "Paul Kyzivat" , "Kapil Nayar" References: <759646.5268.qm@web31505.mail.mud.yahoo.com> <45F1876F.5020405@cisco.com> Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) Date: Tue, 13 Mar 2007 01:38:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Takuya Sawada List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I just catched up the discussion... Comments inline with [TS]. > *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE BELOW AND COMMENT *** > > (References are to figures in draft-ietf-sipping-sip-offeranswer-00.) > > Comments inline. > > Paul > > Kapil Nayar wrote: >> Thanks Paul for the clarifications. >> Replies inline. > >>> If you were to allow a second o/a exchange via >>> reliable 1xx, then it would have the potential for a race with a >>> concurrent UPDATE in the other direction. And that would result in a >>> need to >>> send an error response. But PRACK isn't prepared for carrying an >>> error response. Forcing subsequent o/a to use UPDATE avoids this. >> >> KN>> Perfect. So UPDATE (with SDP) support is sort of >> mandatory for implementations which want to enable >> changing early-media. > > Yeah. It would be quite unwise to support 100rel and not UPDATE. > >>>> 2. Just to clarify, in Figure1 "After F6 UAC and >>> UAS >>>> can send a new offer in an UPDATE request", I >>> guess >>>> the authors meant F7. >>> Debatable. I think the UAS can send an UPDATE after >>> sending F6, without waiting to receive F7. (With the understanding that >>> the UPDATE could fail if received before F6.) >>> >>> The UAC should probably wait until it sends F7. >> KN>> I would agree with mandating UAC to wait until it >> sends F7. > > I don't feel too strongly about this. I think it would probably be wise to > wait until after F7, but if somebody wants to jump the gun and is prepared > for the potential error if F7 was lost then I guess that is their > business. > [TS] I did not care so much on F6 or F7. Now I agree with that waiting unil F7 is better and safe. Probably we can modify the figure in a later version. >>>> 3. In the description for Figure1 it is indicated >>> that >>>> F12 (final response) should not contain an SDP, >>> and if >>>> it does and is different than F6, the UAC should >>>> discard it. (Similar description is present in >>>> Figure2.) >>>> >>>> a).Does this mean that a UAS cannot change the >>> early >>>> media to a final media in final response? >>> It means that each offer has been answered, and that >>> once an answer has been sent, it can't be changed without another >>> offer/answer cycle. And that another offer/answer cycle may not be >>> initiated >>> in the 2xx if one has already been completed. >>> >>> This last is part of a principle that was discovered >>> during the evolution of this work: At most one offer and one >>> answer per transaction. >>> >>> At the time of F12, if the UAS wants to change the >>> SDP, it can send an UPDATE before sending the 2xx for the INVITE. Or it >>> can send the 2xx and send an UPDATE or reINVITE after the ACK. >>> >>>> b).If F12 carries SDP, it should be designated as >>> a >>>> new offer-SDP, right? If UAC discards the >>> offer-SDP in >>>> F12, is it still obligated to send an answer-SDP >>> in >>>> ACK? >>> No. This is all as specified in 3261. Having sent an >>> unreliable provisional with an answer in F2, if there is any >>> SDP in the 2xx it must be identical to what was sent in F2. It is *not* >>> another offer, and so it there must not be an answer to it in F13. >>> >>>> c).If UAC accepts the offer-SDP in F12, can the >>>> answer-SDP in ACK be different than the one >>> originally >>>> offered in F1? What is the behavior expected at >>> the >>>> UAS upon receiving this different media? >>> See above. >> KN>> Actually, there is some confusion here. In >> Figure1 and Figure2 call flows there is a successful >> completion of the o/a through reliable 1xx. As per RFC >> 3261..."Once the UAS has sent or received an answer to >> the initial offer, it MUST NOT generate subsequent >> offers in any responses to the initial INVITE." However, if you read the >> description in line with the >> figures it seems we have relaxed the MUST NOT to >> SHOULD NOT. >> Figure1 - UAS should not include an SDP in the >> responses F9 and F12. Figure2 - UAS should not include >> an SDP in the responses F6 and F9. > > It has been a long time, and I no longer remember the rationale that led > to the SHOULD here. Note that in these figures the SDP in the 2xx is not > to be considered an offer. It is just a piece of redundant data. > > Personally I would be happy to say that the UAS MUST NOT include SDP in > the 2xx in these examples. But I would also like to say (this is a best > practice) that the UAC SHOULD/MUST ignore any SDP that arrives in the 2xx > in these cases. This happens a lot in the wild, so one ought not break in > these cases. > > But I would like to hear from Takuya (who is the primary author) and > others on this. > [TS] RFC 3261 says "UAS MUST NOT generate offer", not "UAS MUST NOT include SDP". I guess some may interpret this as follows; UAS can include the same SDP both 1xx and 2xx. It does not care whether 1xx is reliable or not. If 1xx is reliable, SDP in 1xx is the answer and if not, SDP in 2xx is the answer. Some SDPs may be neither an offer nor an answer, just a hint or nothing. I would be also happy to say "UAS MUST NOT" but I could not conclude to say that. Clearly some implementation would violate "MUST NOT" rule. That is why I put the following description in the draft. UAS should not include an SDP in the responses F9 and F12. However, UAC should prepare to receive an SDP in F9 and/or F12, and just ignore them for the case that the peer does not conform to the recommended implementation. Regards, Takuya >> And, it sort of opens the discussion to possible >> scenarios where another o/a can be initiated. Is this >> intentional? > > Definitely not. > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 13:04:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnvs-00011o-2s; Mon, 12 Mar 2007 13:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnvq-00011e-QG for sip@ietf.org; Mon, 12 Mar 2007 13:03:34 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnvn-0002gs-4E for sip@ietf.org; Mon, 12 Mar 2007 13:03:34 -0400 Received: from [192.168.0.121] ([80.198.124.2]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l2CH2ON32215; Mon, 12 Mar 2007 09:02:25 -0800 In-Reply-To: <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5741BEAE-07B2-43AB-A89A-34D4617B916F@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Mon, 12 Mar 2007 18:02:08 +0100 To: sergiole@tml.hut.fi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 12, 2007, at 2:34 PM, sergiole@tml.hut.fi wrote: >>> ** Q2. > >> Lets walk through the whole first paragraph of Section 5.3: >> >>> When an Edge Proxy receives a request, it applies normal routing >>> procedures with the following addition. If the Edge Proxy >>> receives a request where the edge proxy is the host in the >>> topmost Route header field value, and the Route header contains >>> a flow token, the proxy compares the flow in the flow token with >>> the source of the request. >> >> OK so far? The Edge Proxy compares the flow in the flow token (the >> source of the register) with the source of the newly received request >> >>> If these refer to the same flow, the Edge Proxy removes the >>> Route header and continues processing the request. >> >> In other words if the request is already coming over the same flow >> that >> registered, continue forwarding it because it is an "outgoing" >> request >> from the UA instance that caused the flow token to be created. >> >>> Otherwise, if the top-most Route header refers to the Edge Proxy >>> and contains a valid flow identifier token created by this >>> proxy, the proxy MUST remove the Route header and forward the >>> request over the 'logical flow' identified by the flow token, >>> that is known to deliver data to the specific target UA instance. >> >> If the request is coming from some *other* UA instance, forward it >> over >> the flow to the UA that caused the flow token to be created. >> > > In other words, I understand that we check if the request is > "outgoing" or "ingoing". > > True? yes. >>>> ** Q3. >>>> >>>> The following text is confusing : >>>> >>>> "if these refer to the same flow, the Edge Proxy removes the Route >>>> header and continues processing the request. Otherwise,..." >>>> >>>> >>>> What do you mean by " continues processing the request"? >>>> To continue processing the request as a non sip outbound >>>> ("normal") proxy? >> >> yes. >> >>>> Then the "otherwise" does not provide enough information about >>>> otherwise what... >> >> In English, "otherwise" usually is in this form: >> >> If (statement A) {do something}. Otherwise {do something >> different}. >> >> Still, the text is not especially easy to read. If you can come up >> with a clearer way to express this paragraph, I'll be happy to >> consider >> it. > > > > Original text > { > Otherwise, if the top-most Route header refers to the Edge Proxy > and contains a valid > flow identifier token created by this proxy, the proxy MUST remove > the Route header and > forward the request over the 'logical flow' identified by the flow > token, that is known > to deliver data to the specific target UA instance. > } > > > Since you re-state "if the top-most Route header refers to the Edge > Proxy and contains a valid flow identifier token created by this > proxy," I am lost with the "otherwise". Otherwise could be: > > > -Otherwise it is not a request. > > -Otherwise the Route header does not contain a flowtoken > > -Otherwise these do not refer to the same flow > > > I think that you mean "Otherwise these do not refer to the same flow" > > True? > > If it is true, I find easier to read instead the following, > > > Original text: > { > If these refer to the same flow, the Edge Proxy removes the Route > header and continues processing the request. Otherwise, if the > top- > most Route header refers to the Edge Proxy and contains a valid > flow > identifier token created by this proxy, the proxy MUST remove the > Route header and forward the request over the 'logical flow' > identified by the flow token, that is known to deliver data to the > specific target UA instance. For connection-oriented > transports, if > the flow no longer exists the proxy SHOULD send a 430 (Flow Failed) > response to the request. > } > > > the following text: > > New text, Suggestion : > { > > If these refer to the same flow it means that the request is > coming from a user agent that established a flow to the Edge Proxy > (a flow that was created previously in "outgoing direction"). > In this case the Edge Proxy removes the Route header and continues > processing the request without introducing (no) new considerations > related to the proxy behavior. > > Otherwise, if the flow in the flow token and the source of the > request > do not refer to the same flow, it means that the request is coming > from a user agent that intends to reach another user agent > through a > flow ("ingoing direction"). > In this case the proxy MUST remove the Route header and forward the > request over the 'logical flow' identified by the flow token, that > is known to deliver data to the specific target UA instance. > } Thank you. I plan to use your wording with some minor modifications. > Where "outgoing" and "ingoing" refer to the following scenario > > UAC--------------Edge PX----------------Other PX / Registrar.. > > outgoing---> > <---ingoing I understood you perfectly, but so you are aware, the opposite of "outgoing" is "incoming". > Also I wrote the following flow chart. Could you verify if it is > correct? > The flow chart is correct. Under "what to do", the proxy does whatever it did before outbound existed. ;-) thanks, -rohan > > > .-------------. > | New request | > .-------------. > | > .----------------------------------------. > | edge proxy is the host in the | > | topmost Route header field value? | > | AND |--. > | the Route header contains a flow token | |NO > .----------------------------------------. | > | | > | YES What to do? > | > V > .----------------------------------------. > | the proxy compares | > | the flow in the flow token | > | with the source of the request |--. > | Are these equal? | |NO > .----------------------------------------. | > | | > | YES | > | Outgoing case | > V | > .----------------------------------------. | > | Edge Proxy removes the Route header | | > | and continues processing the request | | > .----------------------------------------. | > | | > | | > V | > .----------------------------------------. | > | Proxy continues processing the request | | > .----------------------------------------. | > . | > . | > / > / > / > / > / > Ingoing case / > / > / > .----------------------------------------. > | Edge Proxy removes the Route header | > | and continues processing the request | > | and forwards the request over the | > | 'logical flow' identified by the flow | > | token | > .----------------------------------------. > > > > > > > > Regards > > Sergio > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 13:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQoBe-0004Sr-FD; Mon, 12 Mar 2007 13:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQoBc-0004PN-Sv for sip@ietf.org; Mon, 12 Mar 2007 13:19:52 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQoBZ-0004v8-E2 for sip@ietf.org; Mon, 12 Mar 2007 13:19:52 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2CHJiDS010628; Mon, 12 Mar 2007 12:19:44 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2CHJiM13480; Mon, 12 Mar 2007 12:19:44 -0500 (CDT) Message-ID: <45F58BAF.6000806@alcatel-lucent.com> Date: Mon, 12 Mar 2007 11:19:43 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] draft-gurbani-sip-domain-certs References: <57CF7A22-7F93-41EA-BD5A-15C7F2DEA76C@cisco.com> In-Reply-To: <57CF7A22-7F93-41EA-BD5A-15C7F2DEA76C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > I think many of my previously mentioned issues with this draft still > exist. Cullen: Thanks for a read. More inline. > Lets consider the case where you have proxy farm with 3 members known > as a,b, and c in the domain example.com. This draft is premised on > the idea that it is actually desirable to pin mid dialog requests to > one particular member of the farm. I don't actually find this a > compelling use case because it breaks any sense of high reliability > but I'm will to suppress my disbelief and take this as the problem we > need to solve. The formulation of the pinning problem was predicated not so much on providing high availability (HA) services but rather on simple experiment of noticing that the many proxies in use today insert a URI with a FQDN name in a R-R going downstream. If that URI happens to be a sips URI, then a subsequent connection opened to that proxy will result in a certificate coming back that does not match the said URI. This is the basic problem at hand. Saying that proxies must not insert FQDN in the R-R header is something that we have advocated so far in the WG. But I believe we can do better than that (see below). There may be legitimate reasons why pinning is desirable. As you note, HA can be provided by inserting a domain URI (example.com) and not a FQDN URI (proxy1.example.com). However, if an implementation insists on using FQDN URIs in R-R, then HA can also be provided by maintaining the FQDN as an identity in the certificate and using an active-passive redundancy scheme. Regardless of whether or not an implementation puts a domain URI or a FQDN URI, the certificate presented to it should provide identity assurance that the UAC is looking for. Today, this is not the case. There are ways to do this, of course. The tricky part is agreeing to which one is the right way. > One of the primary things that causes confusing for implementers is > what a UAC needs to actually match when it opens a connection and > sends a request over TLS. This tries to clarify it with > > When a UAC receives a certificate from a server, it MUST ensure that > the certificate asserts one of the two identities that the UAC used > to reach the server: If the UAC performed RFC3263 resolution on the > URI to reach the server, the SIP or SIPS identity stored in the > certificate MUST be matched. Otherwise, if RFC3263 resolution on > the URI failed, the UAC MUST match the DNS label in the certificate > with the name of the server that it opened a TLS connection to. > > I've got to admit - I can't make heads or tails out of any of that. Let's take two cases. Case 1: UAC looks up on domain URI: NAPTR("example.com") = "_sips._tcp.example.com" SRV("_sips._tcp.example.com") = "proxy1.example.com" A("proxy1.example.com") = "192.0.2.3" TLS_connect("192.0.2.3", 5061) = Cert received contains "example.com" Server authenticated (since "example.com" matches what we started off with) Case 2: UAC looks up on FQDN URI: NAPTR("proxy1.example.com") = NULL; SRV("_sips._tcp.proxy1.example.com") = NULL A("proxy1.example.com") = "192.0.2.3" TLS_connect("192.0.2.3", 5061) = Cert received contains "example.com" Server NOT authenticated (since "example.com" does not match what we started off with, namely "proxy1.example.com") Here is where having two identities in the certificate helps. The client in case 2 could have matched "proxy1.example.com" if it was stored in the certificate. > The examples seem to use DNS types in the SAN for some things and URI > types for other things. We have had many emails about this and I see > no reason to make them different - please clearly explain in the > draft why you use DNS fro some and URI for others. You know my > opinion on this which is these constrain what the cert can be used > for and nothing more or less. These need to be URI types; didn't get down to scrubbing everything, unfortunately. > The suggestions about costs and number of certificates required in > the draft seem to be mostly wrong. Hmmm ... in the design team meetings, it has been expressed that the reason why multiple names in a certificate (domain URI, FQDN) is undesirable is because of cost. A service provider will have to get multiple certificates, each corresponding to a host. OTOH, if a certificate contains only a domain URI, the same certificate can be used on all hosts. Cost was pointed out as a prohibitive factor in using multiple names (domain URI, FQDN) in the certificate. > I seem to recall people pointing out problems with the maddr approach > that had to do with URI which needed to be different would end up > matching. I am trying to think of a specific example, but drawing a blank. Can you recall one? > Defining an Extended Key Usage that restricts a certificate for SIP > seems like a perfectly fine thing to do but I will need to be in a > separate draft that is off in the SEC area somewhere. I do note > that, uh, lots of things ignore theses - so marking it as critical > often reduces deployability, luckily lots of things just ignore the > critical which makes the certificate usable but the constraint > useless - but I degree, in theory they are clearly the right way to > constrain certificates. I certainly agree that this gives a much more > refined way of controlling usage than the course granularity that the > DNS vs URI type in the SAN list provides. OK. > If some other domain receives a TLS connection from example.com with > the cert and mutual auth etc, the issues of if it can use this > connection for new requests it wants to send to the example.com > domain is not one that is deal with using the TLS certs - it is > solved by other things like 1) don't do or 2) use draft-ietf- > sip-connect-reuse (which oddly has a author in common with this > draft) Yeah, odd ;-) I think the harder part has been figuring out where connection reuse begins and where mutual authentication ends. The *result* of a mutual authentication, in may cases, is the reuse of connections. We have been conflating both of these together so far. Maybe if we separate them out, and deal with them individually, that'll help. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 13:32:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQoNq-0003tD-9u; Mon, 12 Mar 2007 13:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQoNp-0003t0-15 for sip@ietf.org; Mon, 12 Mar 2007 13:32:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQoNm-0006dm-OI for sip@ietf.org; Mon, 12 Mar 2007 13:32:29 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 12 Mar 2007 10:32:26 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="120371372:sNHT45175212" Received: from [192.168.0.101] (sjc-vpn3-336.cisco.com [10.21.65.80]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l2CHBSoK014077; Mon, 12 Mar 2007 09:11:28 -0800 Message-ID: <45F58F24.60801@cisco.com> Date: Mon, 12 Mar 2007 10:34:28 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP telephony and SIP proxy operations References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <200703111855.l2BItuvY019182@dragon.ariadne.com> <4F873B53-CE41-4869-A5D8-76E98B7CFD97@estacado.net> <200703112305.l2BN51In004957@dragon.ariadne.com> In-Reply-To: <200703112305.l2BN51In004957@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1342; t=1173719489; x=1174583489; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20News=20flash=3A=20Verizon=20appears=20to=20ha ve=20exclusive=20rights=20to=0A=20IP=09telephony=20and=20SIP=20proxy=20ope rations |Sender:=20 |To:=20=20Dale.Worley@comcast.net; bh=uAyv9aMutoAx/DvOzP0DxOEk0n+FAIRyh77IXokJJd8=; b=R1bEMBkdu34CHUB/0rAKJWZJzG46O5ekQFE7zzVnU+3uU/uig81m4nqHtpnbEFNo/QW1B6Gw ZUJWQMdl7T7VPkkeTqI59thZ6PDMgys/8Syki5krFhbESE2ROKbYYqsN; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Byron Campen > > Whoops, I misread claims 12-14. So did Vonage get in trouble for > selling cordless handsets? > > I've no idea, as nobody seems to have bothered to even track down the > judge's decision. > > But there does seem to be a prima-facie problem in regard to a UA > sending registration back to a server over a wireless last-hop network > and a public packet long-haul network. If you're interesting in > selling something like that, you should get a good lawyer. > > One thing I notice is that the prior-art cutoff for this patent is > March 1996, which is 11 years ago, and 3 years before RFC 2543. The > original 802.11 was apparently approved in 1997. So it's possible > that nobody then had thought of a wireless phone talking WiFi to a > base station that used the Internet to register with its > point-of-contact server. > Or more likely that nobody thought that yet another L2 substrate for IP was worthy of anything but a history lesson for somebody who thought that it was unique. But I find this rather curious... wasn't ATM supposed to wipe out this IP tomfoolery around 1996 according to the telephants? Are people sure that this patent isn't really restricted to 53 byte payloads of goodness? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 13:56:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQojd-0006fh-Jg; Mon, 12 Mar 2007 13:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQojb-0006fW-96 for sip@ietf.org; Mon, 12 Mar 2007 13:54:59 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQojO-0002H8-Ff for sip@ietf.org; Mon, 12 Mar 2007 13:54:59 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2CHsHPe010542; Mon, 12 Mar 2007 12:54:45 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 12:54:43 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 18:54:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Mar 2007 18:54:40 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E5C557@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-niemi-sip-subnot-etags-03.txt Thread-Index: Acdkz4Inx8unu8OTSXespvENkYNzAA== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 12 Mar 2007 17:54:42.0194 (UTC) FILETIME=[82FC7720:01C764CF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: aki.niemi@nokia.com Subject: [Sip] Comments on draft-niemi-sip-subnot-etags-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1754616474==" Errors-To: sip-bounces@ietf.org --===============1754616474== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlc2UgYXJlIG1haW5seSBwcmVzZW50YXRpb24gaXNzdWVzLiBJIGRpZCBub3QgZmluZCBhbnl0 aGluZyB0byBjb21tZW50IG9uIHRlY2huaWNhbGx5Lg0KDQoxKQlUaHJvdWdob3V0IHRoZSBkb2N1 bWVudCwgcHV0IHJlc3BvbnNlIGNvZGUgdXNhZ2UgaW4gdGhlIGZvcm1hdCBvZiBSRkMgMzI2MSBj b252ZW50aW9ucywgaS5lLiAiMjA0IChObyBOb3RpZmljYXRpb24pIHJlc3BvbnNlIiwgbm90ICIy MDQgcmVzcG9uc2UiIG9yICIyMDQgIk5vIE5vdGlmaWNhdGlvbiIgcmVzcG9uc2UuDQoNCjIpCVRo ZXJlIGFwcGVhcnMgdG8gYmUgbm8gdGV4dCBpbiB0aGUgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIGEg c2VtYW50aWMgZm9yIHRoZSAyMDQgaGVhZGVyIHJlc3BvbnNlLiBJIGFtIHRoaW5raW5nIG9mIHRl eHQgbGlrZSB0aGF0IHdoaWNoIGFwcGVhcnMgZm9yIGVhY2ggcmVzcG9uc2UgaW4gUkZDIDMyNjEg c2VjdGlvbiAyMC4NCg0KMykJSW4gdGhlIHRleHQsIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBpbnN0 YW5jZXMgd2hlcmUgd2UgaGF2ZSAiTm90ZSB0aGF0Li4uIi4gSSBhbSBub3QgY29udmluY2VkIHRo YXQgZWl0aGVyIG9mIHRoaXMgdGV4dCBpcyBhdXhpbGlhcnkgdGV4dCB0byB0aGUgbWFpbiBkb2N1 bWVudCwgaW4gd2hpY2ggY2FzZSBkZWxldGUgdGhlIHdvcmRzICJOb3RlIHRoYXQiLiBJZiBpdCBp cyBhdXhpbGlhcnkgdGV4dCwgZm9sbG93IHRoZSBSRkMgMzI2MSBjb252ZW50aW9uIGFuZCBpbmRl bnQgaXQuDQoNCjQpCVNlY3Rpb24gOCAoSUFOQSBjb25zaWRlcmF0aW9ucykuIEkgaGF2ZSBhIHBy ZWZlcmVuY2UgZm9yIHNlZWluZyB3aGVyZSBwb3NzaWJsZSB0aGUgbmV3IG1hdGVyaWFsIGdvaW5n IGludG8gdGhlIElBTkEgdGFibGUgaW4gdGhlIGZvcm1hdCBpdCBoYXMgdG8gYmUgcHV0IGluLiBD YW4geW91IHJlZm9ybWF0IHRoaXMgdGV4dCBhcyBnaXZlbiBpbiBlLmcuIGRyYWZ0LWlldGYtc2lw LXVyaS1saXN0IG1lc3NhZ2UuIEkgdGhpbmsgSSBhbHNvIGhhdmUgYSBwcmVmZXJlbmNlIGZvciBw dXR0aW5nIHRoZSB0d28gbmV3IGhlYWRlciBmaWVsZHMgaW4gc2VwYXJhdGUgc2VjdGlvbnMuDQoN CjUpCVJGQyAzMjY1IGRlZmluZXMgZ3VpZGVsaW5lcyB0byBiZSBmb2xsb3dlZCBieSB0aGUgd3Jp dGVycyBvZiBuZXcgcGFja2FnZXMuIElzIHRoZXJlIGFueSByZXF1aXJlbWVudCB0byB1cGRhdGUg dGhvc2UgZ3VpZGVsaW5lcyB0byBpbmRjbHVkZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbiBvciBj YW4gdGhpcyBleHRlbnNpb24gYmUgdXNlZCBhdCB3aWxsIGZvciBTVUJDUklCRSByZXF1ZXN0cyBm b3IgYWxsIHBhY2thZ2VzPyBJIHRoaW5rIHRoZSBsYXR0ZXIgaXMgdHJ1ZSwgYnV0IEkgd291bGQg bGlrZSB0byBzZWUgaXQgY29uZmlybWVkIChvbiBsaXN0IHJhdGhlciB0aGFuIGluIGRvY3VtZW50 KS4NCg0KNikJSW4gdGhlIG92ZXJ2aWV3IG9mIG9wZXJhdGlvbiAoU2VjdGlvbiAzKSwgY2xlYXJs eSBpZGVudGlmeSB0aGUgaGVhZGVyIGZpZWxkczsgSSB3b3VsZCBwcmVmZXIgdG8gc2VlOiAiYW5k IGluY2x1ZGVzIGFuIGVudGl0eS10YWcgaW4gdGhlIFN1cHByZXNzLU5vdGlmeS1JZi1NYXRjaCBo ZWFkZXIgZmllbGQiIHJhdGhlciB0aGFuICJhbmQgaW5jbHVkZXMgYSBTdXBwcmVzcy1Ob3RpZnkt SWYtTWF0Y2ggY29uZGl0aW9uIi4NCg0KNykJU2VjdGlvbiA0IGlzIGVudGl0bGVkICJTdWJzY3Jp YmVyIEJlaGF2aW91ciIsIHRoZXJlZm9yZSBJIHdvdWxkIG5vdCBoYXZlIGV4cGVjdGVkIHRvIHNl ZSBleGFtcGxlcyAoc2VjdGlvbiA0LjMsIHNlY3Rpb24gNC40IGFuZCBzZWN0aW9uIDQuNSwgYW5k IHNlY3Rpb24gNC42KSBpbiB0aGlzIHNlY3Rpb24sIGFzIHRoZSBleGFtcGxlcyBjb3ZlciBib3Ro IHRoZSBzdWJzY3JpYmVyIGFuZCBub3RpZmllciBiZWhhdmlvdXIuIEkgc3VzcGVjdCB5b3UgbmVl ZCB0byBtb3ZlIHRoZXNlIGludG8gYSBzZWN0aW9uIGJ5IHRoZW1zZWx2ZXMsIGJ1dCB5b3UgZG8g bmVlZCB0byBjb25zaWRlciB0aGUgcmVsYXRpb25zaGlwIHdpdGggc2VjdGlvbiAyIGZsb3cgZGlh Z3JhbXMgYXMgd2VsbC4NCg0KOCkJSW4gc2VjdGlvbiA0LCB3ZSBhcHBhcmVudGx5IGhhdmUgbm8g bm9ybWF0aXZlIHJlcXVpcmVtZW50cyBvbiB0aGUgc3Vic2NyaWJlci4gV2Ugc2VlbSB0byBtaXNz IGV4cGxpY2l0bHkgc3RhdGluZyB0aGF0IHRoZSBzdWJzY3JpYmVyIE1VU1Qgc3VwcG9ydCB0aGUg dHdvIGhlYWRlciBmaWVsZHMgYXMgZGVzY3JpYmVkLCBhbmQgZ2VuZXJhdGUgdGhlbSBpbiBhY2Nv cmRhbmNlIHdpdGggdGhlIHNlbWFudGljcyBnaXZlbi4NCg0KOSkJU2VjdGlvbiA1LjEsIGNoYW5n ZToNCg0KICAgVGhlIGVudGl0eS10YWcgTUFZIGJlDQogICByZW1lbWJlcmVkIGxvbmdlciB0aGFu IHRoaXMsIGUuZy4sIGZvciBpbXBsZW1lbnRpbmcgam91cm5hbGVkIHN0YXRlDQogICBkaWZmZXJl bnRpYWxzIChTZWN0aW9uIDUuNCkuDQoNClRvOg0KDQogICBUaGUgbm90aWZpZXIgTUFZIHJlbWVt YmVyIHRoZSBlbnRpdHktdGFnIGxvbmdlciB0aGFuIHRoaXMsIGUuZy4sIA0KICAgZm9yIGltcGxl bWVudGluZyBqb3VybmFsZWQgc3RhdGUgZGlmZmVyZW50aWFscyAoU2VjdGlvbiA1LjQpLg0KDQox MCkgU2VjdGlvbiA1LjI6DQoNCiAgIFdoZW4gYSBjb25kaXRpb24gZm9yIHN1cHByZXNzaW5nIGEg Tk9USUZZIGJvZHkgaXMgdHJ1ZSwgaS5lLiwgdGhlDQogICBsb2NhbCBlbnRpdHktdGFnIGZvciB0 aGUgcmVzb3VyY2Ugc3RhdGUgYW5kIHRoZSBzdWJzY3JpYmVyIHByb3ZpZGVkDQogICBlbnRpdHkt dGFnIGluIGEgU3VwcHJlc3MtQm9keS1JZi1NYXRjaCBoZWFkZXIgZmllbGQgbWF0Y2gsIHRoZQ0K ICAgbm90aWZpZXIgTVVTVCBzdXBwcmVzcyB0aGUgYm9keSBvZiB0aGUgcmVzdWx0aW5nIE5PVElG WSByZXF1ZXN0LiAgVGhlDQogICBOT1RJRlkgTVVTVCBOT1QgY29udGFpbiBhIENvbnRlbnQtVHlw ZSBoZWFkZXIgZmllbGQsIHRoZSBDb250ZW50LQ0KICAgTGVuZ3RoIE1VU1QgYmUgc2V0IHRvIHpl cm8sIGFuZCBubyBwYXlsb2FkIGlzIGF0dGFjaGVkIHRvIHRoZQ0KICAgbWVzc2FnZS4NCg0KV2Ug c2VlbSB0byBiZSB0cnlpbmcgdG8gc2F5IHRoZSBzYW1lIHRoaW5nIHR3aWNlIGluIFJGQyAyMTE5 IGxhbmd1YWdlIGhlcmUuIEVpdGhlciB3ZSBzdGF0ZSB0aGUgIk1VU1Qgc3VwcHJlc3MiIGluIFJG QyAyMTE5IGxhbmd1YWdlIGFuZCB0aGVuIGluZGljYXRlIHRoZSBjb25zZXF1ZW5jZSBvZiB0aGF0 IHN1cHJlc3Npb24gaW4gbm9uIFJGQyAyMTE5IGxhbmd1YWdlLCBvciB3ZSBkbyBpdCB0aGUgb3Ro ZXIgd2F5IHJvdW5kLCBpLmUuIE1VU1QgdHJlYXQgaGVhZGVycyBhcyBkZXNjcmliZWQsIHdpdGgg dGhlIGVmZmVjdCBvZiBzdXByZXNzaW5nIHRoZSBib2R5Lg0KDQpOb3RlIHRoYXQgaW4gc2VjdGlv biA1LjMgeW91IGhhdmUgY2hvc2UgdGhlIGZvcm1lciBtYW5uZXI6DQoNCiAgIFdoZW4gYSBjb25k aXRpb24gaW4gYSBTVUJTQ1JJQkUgcmVxdWVzdCB0byBzdXBwcmVzcyBhIE5PVElGWSByZXF1ZXN0 DQogICBpcyB0cnVlLCBpLmUuLCB0aGUgbG9jYWwgZW50aXR5LXRhZyBvZiB0aGUgcmVzb3VyY2Ug YW5kIHRoZSBlbnRpdHktDQogICB0YWcgaW4gYSBTdXBwcmVzcy1Ob3RpZnktSWYtTWF0Y2ggaGVh ZGVyIGZpZWxkIG9mIGEgU1VCU0NSSUJFIHJlcXVlc3QNCiAgIG1hdGNoLCB0aGUgbm90aWZpZXIg TVVTVCBzdXBwcmVzcyB0aGUgcmVzdWx0aW5nIE5PVElGWSByZXF1ZXN0LCBhbmQNCiAgIGdlbmVy YXRlIGEgMjA0ICgiTm8gTm90aWZpY2F0aW9uKSIgcmVzcG9uc2UuDQoNCjExKQlTZWN0aW9uIDUu My4gSG93IGRvIEkgY29uZm9ybSB0byB0aGUgZm9sbG93aW5nLi4uDQoNCiAgIFN1Y2ggYSBzdWNj ZXNzZnVsIGNvbmRpdGlvbmFsIFNVQlNDUklCRSByZXF1ZXN0IE1VU1Qgb3RoZXJ3aXNlIHdvcmsN CiAgIHRoZSBzYW1lIGFzIG9uZSB3aXRob3V0IHRoZSBjb25kaXRpb24uDQoNCkkgZmVlbCB0aGF0 IHdlIGNvdWxkIGdldCB0aGlzIGEgYml0IG1vcmUgcHJlY2lzZS4NCg0KMTIpCVNlY3Rpb24gNS40 Og0KICANCiAgIDUuNC4gIFN0YXRlIERpZmZlcmVudGlhbHMNCg0KICAgQSBub3RpZmllciBjYW4g b3B0aW9uYWxseSBrZWVwIHRyYWNrIG9mIHRoZSBzdGF0ZSBjaGFuZ2VzIG9mIGENCiAgIHJlc291 cmNlLCBlLmcuLCBzdG9yaW5nIHRoZSBjaGFuZ2VzIGluIGEgam91cm5hbC4gIElmIGEgY29uZGl0 aW9uDQogICBmYWlscywgdGhlIG5vdGlmaWVyIE1BWSBzZW5kIGEgc3RhdGUgZGlmZmVyZW50aWFs IGluIHRoZSBOT1RJRlkNCiAgIHJhdGhlciB0aGFuIHRoZSBmdWxsIHN0YXRlIG9mIHRoZSBldmVu dCByZXNvdXJjZS4gIFRoaXMgaXMgb25seQ0KICAgcG9zc2libGUgaWYgdGhlIGV2ZW50IHBhY2th Z2UgYW5kIHRoZSBzdWJzY3JpYmVyIGJvdGggc3VwcG9ydCBhDQogICBwYXlsb2FkIGZvcm1hdCB0 aGF0IGhhcyB0aGlzIGNhcGFiaWxpdHkuDQoNCldoZXJlIGFyZSBzdGF0ZSBkaWZmZXJlbnRpYWxz IGRlZmluZWQuIFdlIG5lZWQgYXQgbGVhc3QgYSByZWZlcmVuY2UgaGVyZS4NCg0KMTMpCVNlY3Rp b24gNg0KDQpXZSBlaXRoZXIgbmVlZCBhbiBBQk5GIHJlZmVyZW5jZSBoZXJlLCBvciBhIHN0YXRl bWVudCB0aGF0IGl0IGV4dGVuZGVzIHRoZSBBQk5GIGRlZmluZWQgaW4gUkZDIDMyNjEgKHdoZXJl IHdlIGhhdmUgdGhlIEFCTkYgcmVmZXJlbmNlKS4NCg0KMTQpCVdlIGRlc2NyaWJlIHRoZSBiZWhh dmlvdXIgb2YgdGhlIG5ldyBoZWFkZXIgZmllbGRzIGluIHJlZ2FyZCB0byBTVUJTQ1JJQkUgYW5k IE5PVElGWSwgYnV0IGZhaWwgdG8gc2F5IHdoYXQgdGhlIHVzYWdlIHJlcXVpcmVtZW50cyBhcmUg aW4gcmVsYXRpb25zaGlwIHRvIG90aGVyIG1ldGhvZHMuIFdoZXRoZXIgeW91IGRvIHRoaXMgaW4g dGhlIGZvcm1hdCBvZiBSRkMgMzI2MSB0YWJsZSAyIGFuZCAzLCBvciBieSB3cml0aW5nIHRleHQg SSBkbyBub3QgbWluZCwgYnV0IGl0IGRvZXMgbmVlZCB0byBvY2N1ci4NCg0KUmVnYXJkcw0KDQpL ZWl0aA0KDQoNCg0K --===============1754616474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1754616474==-- From sip-bounces@ietf.org Mon Mar 12 14:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQp1H-00078M-Ty; Mon, 12 Mar 2007 14:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQp1G-00077l-1l for sip@ietf.org; Mon, 12 Mar 2007 14:13:14 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQp1C-0004i1-FD for sip@ietf.org; Mon, 12 Mar 2007 14:13:14 -0400 Received: by ug-out-1314.google.com with SMTP id 72so2239409ugd for ; Mon, 12 Mar 2007 11:13:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=IS6tXyUTnhRkMBDVRf/Kqtt2zUfOc6DtJaquVDr/JLLcI5mmjFLKOtgiRnxuCOpCvcSwnU7reoUOo5azb4LOUk18cHGdyskOALlD+PEpdPZDd6bhzFTn6Ugq0E6jE0B+rj1WBnrkJkcxbPOTm/PB+9hGgGqvlQ8VSHwPF0y+Oo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=b6maybWBigBOJt9WM34C5hRjEL8ccuy1ZN5yimDA3tNqaQtQo6Bce0Wlesvb4Gd2rWATQh5vqJLPfcIIZZqDoCSCAWERznERCvYTunBT6jF4f2+Zw5iGqvytVvjRtJdRwzKA/nO5kF20bb0abvbNpspmJ+9iiDrODJqjnCkLLlQ= Received: by 10.115.54.1 with SMTP id g1mr1970505wak.1173723186750; Mon, 12 Mar 2007 11:13:06 -0700 (PDT) Received: from ?10.20.0.104? ( [66.38.133.13]) by mx.google.com with ESMTP id z15sm17425760pod.2007.03.12.11.13.05; Mon, 12 Mar 2007 11:13:05 -0700 (PDT) In-Reply-To: <45CB7E2F.1070706@bbn.com> References: <45CB7E2F.1070706@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Fischl Date: Mon, 12 Mar 2007 09:37:22 -0700 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: da38be4a423a556a4dcef9ca1fb76a0f Cc: sip@ietf.org, sipping@ietf.org Subject: [Sip] Re: [Sipping] New draft on early media X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 3.1.1 Fast completion of INVITE transaction I like the idea of "Fast Completion of INVITE transaction" since it gets us away from the whole PRACK nightmare. However, is it really practical to contemplate doing this? How many years will it take us to get SIP phone and gateway vendors to implement such a major change in behavior? 3.1.2 Elimination of offer from INVITE This solution doesn't seem practical to me unless you have PRACK since it would not allow you to otherwise send media before the 200 OK. If you have PRACK, then you don't need this approach. 3.1.3 Provisional responses I am not a fan of PRACK but it does seem to be the best path to a solution to this problem given where we are now. This also doesn't require any changes to the normative behavior of SIP. 3.1.4 Separate INVITE transaction This one makes my head hurt a bit. I assume that this second INVITE transaction would either be in the same dialog as the original INVITE or would be sent to a gruu representing the specific UAS in the original INVITE? Also, I'm not sure this is any less complex to implement than PRACK but worth some more thought. 3.1.5 Non-INVITE SIP Mechanisms I'd prefer to take INFO off the table. Summary: In my opinion, of the recommended approaches, PRACK looks like our best bet. On Feb 8, 2007, at 11:46 AM, Richard Barnes wrote: > After the big discussions on SIPPING last summer about how to fix > early media, and the reaction at the last couple of IETFs to Brian > Stucker's draft on how to cope with it, I've put together a draft > to try to consolidate all of the discussions and move toward a > solution. > > draft-barnes-sip-em-ps-req-sol includes three important parts: > > 1. Problem statement: Although there's lots of definitions of > "early media" in existing documents, I think there's broad > agreement that the stuff that causes problems is media that arrives > before an SDP offer/answer exchange has completed. The problem is > therefore to enable the SDP exchange(s) in the INVITE transaction > to complete more quickly, and make it more difficult (if not > impossible) to send media before it has completed. We are > explicitly NOT trying to prevent the sending of media before a 200/ > OK or other closing of an INVITE transaction. > > 2. Requirements: Here, we try to create a consolidated list of > requirements for an early media fix. > > 3. Analysis of Solutions: Lots of folks have put forward proposals > to fix the early media problem. This section tries to enumerate > most of them and evaluate them against the requirements in section 2. > > It hasn't shown up yet on the I-D tracker, so I've attached a copy. > > --Richard > > > > Network Working Group R. > Barnes > Internet-Draft M. > Lepinski > Intended status: Informational BBN > Technologies > Expires: July 19, 2007 January 15, > 2007 > > > Early Media in SIP: Problem Statement, Requirements, and Analysis of > Solutions > draft-barnes-sip-em-ps-req-sol-00 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months > and may be updated, replaced, or obsoleted by other documents at > any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on July 19, 2007. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > Abstract > > The Session Initiation Protocol (SIP) enables and permits endpoints > in an INVITE transaction to send media packets before an SDP offer/ > answer exchange has completed; we refer to such media packets as > early media. The use of early media is common in current SIP > implementations, and causes several problems, which have been > documented elsewhere. This document puts forward the goal of > modifying SIP so that compliant implementations will complete an > SDP > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 1] > Internet-Draft em-ps-req-sol January > 2007 > > > exchange before sending media, and lays out high-level requirements > for such a solution. The set of possible solutions is then laid > out, > and each possibility examined in light of these requirements. > > > Table of Contents > > 1. > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. > Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. Elmination of Early > Media . . . . . . . . . . . . . . . . 5 > 2.2. Additional > Messaging . . . . . . . . . . . . . . . . . . . 6 > 2.3. Interoperability with current SIP > standards . . . . . . . 6 > 2.4. Interoperability with the > PSTN . . . . . . . . . . . . . . 6 > 2.5. Denial of > Service . . . . . . . . . . . . . . . . . . . . 6 > 2.6. IPR > Constraints . . . . . . . . . . . . . . . . . . . . . 6 > 3. Early Media > Solutions . . . . . . . . . . . . . . . . . . . . 6 > 3.1. Minimizing SDP completion > time . . . . . . . . . . . . . . 7 > 3.1.1. Fast completion of INVITE > transaction . . . . . . . . 7 > 3.1.2. Elimination of offer from > INVITE . . . . . . . . . . . 8 > 3.1.3. Provisional > Responses . . . . . . . . . . . . . . . . 8 > 3.1.4. Separate INVITE > transaction . . . . . . . . . . . . . 9 > 3.1.5. Non-INVITE SIP > Mechanisms . . . . . . . . . . . . . . 9 > 3.1.6. Non-SIP > mechanisms . . . . . . . . . . . . . . . . . . 10 > 3.2. Handling remaining > media . . . . . . . . . . . . . . . . . 11 > 3.2.1. Unreliable SDP > answer . . . . . . . . . . . . . . . . 11 > 3.2.2. Backwards- > compatibility . . . . . . . . . . . . . . . 11 > 4. IANA > Considerations . . . . . . . . . . . . . . . . . . . . . 11 > 5. Security > Considerations . . . . . . . . . . . . . . . . . . . 12 > 6. > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 > 7. > References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 > 7.1. Normative > References . . . . . . . . . . . . . . . . . . . 12 > 7.2. Informative > References . . . . . . . . . . . . . . . . . . 12 > Authors' > Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 > Intellectual Property and Copyright > Statements . . . . . . . . . . 14 > > > > > > > > > > > > > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 2] > Internet-Draft em-ps-req-sol January > 2007 > > > 1. Introduction > > A primary function of the Session Initiation Protocol (SIP, > [RFC3261]) is to carry SDP messages that form an SDP offer/answer > exchange [RFC3264]. The offer/answer exchange serves to negotiate > the parameters necessary for the two end hosts to send > multimedia to > each other, including transports, port numbers, codecs, and > security > parameters (e.g., MIKEY [RFC3830]). In the most common SIP INVITE > transaction, the calling party (UAC) is the SDP offerer and the > called party (UAS) is the SDP answerer; in this scenario, the SDP > offer is carried in the SIP INVITE request, and the SDP answer > in the > 200/OK response. > > Because there is often a substantial delay between the sending > of an > INVITE and the receipt a 200/OK, this assignment of SDP messages to > SIP messages creates a substantial delay between an SDP offer > and an > SDP answer. Consequently, there is a period of time between the > two > messages in which the two parties have asymmetric information: The > called party has knowledge of both the SDP offered by the calling > party and of his own intended response, while the calling party > knows > only the offer he sent. Given this information, the called > party has > all the information he needs to begin sending media to the calling > party (because this was included in the SDP offer); moreover, he > can > send these media without sending an SDP answer to the calling > party. > We define early media as media sent before the completion of an SDP > offer/answer exchange. > > Ours is a different definition than is used in RFC 3960 [RFC3960], > which defines early media as "media ... that is exchanged before a > particular session is accepted by the called user." The definition > in RFC 3960 is consistent with the current usage of SDP within the > SIP INVITE transaction, but at the same time conflates two > functions > of SIP: Negotiation of session-layer parameters (through the SDP > offer/answer) and communication of an application-layer request and > acceptance of a session (by the INVITE and 200/OK messages). As > suggested above, it is this assignment of SDP messages to SIP > messages that creates the possibility of early media. > > Early media is known to create several problems for SIP operation: > > o Call failure: When endpoints use early media for an extended > period of time, timers can fire to close the UAC INVITE > transaction before the early media finish and the UAS sends a > 200/OK. This causes the session proposed in the initial > INVITE to > be dropped by the UAC, and in some implementations, the flow of > media is cut off. > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 3] > Internet-Draft em-ps-req-sol January > 2007 > > > o Confidentiality: Techniques such as MIKEY [RFC3830]and Security > Descriptions [RFC4568], which use SDP to establish keys for > media > security protocols, require a full SDP offer/answer exchange to > negotiate keys. Such keying techniques are therefore > incompatible > with early media. > > o Access Control: In the presence of early media, a UAC must > anticipate that media will arrive without any signaling, and > thus > is obliged to receive (and presumably render) media received > from > any host on the Internet. > > o Interaction with forking/retargeting: When an INVITE from a > UAC is > forked or retarget to UASs that send early media, because these > UASs send no signaling, the UAC has no information besides the > media itself on which to base a decision as to which media > stream > to render. > > o Denial of Service: Early media is the basis of the "voice > hammer" > attack, described in [draft-ietf-mmusic-ice]. > > To date, attempts to deal with early media have failed to solve all > of the problems caused by early media. Such work typically has > started from the assumption that early media is a necessary > component > of SIP (largely due to RFC 3398 [RFC3398] and RFC 3578 > [RFC3578]) and > has generally avoided the issue of whether key use-cases (such as > PSTN interoperability) can be satisfied without the use of early > media. RFC 3960 presents two models for managing early media > streams, which mitigate early-media related problems in some cases. > However, the document neither specifies the models in sufficient > detail nor makes their implementation a mandatory part of SIP. > More > recently, Stucker has written a draft extending 3960 by detailing a > more current set of early media coping mechanisms, and proposing a > solution that uses additional SDP attributes to mitigate the > problems > caused by early media [draft-stucker-sipping-early-media-coping]. > Although Stucker's proposed solution addresses several of the above > problems, it stops short of requiring an SDP exchange before media > transmission. Ejzak has also authored a recent draft regarding > early > media [draft-ejzak-sipping-p-em-auth]. However, his draft proposes > the use of a p-header to prevent fraudulent uses of early media, > which are largely orthogonal to the early media problems considered > in this draft. > > In contrast to previous approaches, this draft proposes to address > the problems of early media by normatively modifying the SIP > protocol > to preclude the transmission of early media. In order to remove > the > possibility of early media, this modification must ensure (to the > greatest extent possible) that the SDP offer/answer exchange has > completed before any media are sent. At a high level, this goal > can > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 4] > Internet-Draft em-ps-req-sol January > 2007 > > > be approached from two directions: To complete the SDP exchange as > quickly and reliably as possible, and to forbid sending of media > before completion. A successful solution will combine these two > approaches, since as progress is made on the former, the latter > becomes less onerous. > > The goal of this draft is three-fold: First, in the above, we have > provided a consolidated statement of the early media problem, > namely > that the presence of media before the completion of an SDP offer/ > answer exchange is harmful to the functioning of SIP calls. > Second, > Section 2 specifies requirements for an update to SIP that > eliminates > early media, in an effort to consolidate the requirements that have > been presented to date and enable discussion of solutions. Third, > Section 3 lays out the space of possible solutions, enumerating the > trade-offs entailed by each so that consensus can be reached on the > direction that should be taken by the SIP working group. > > > 2. Requirements > > There have been several informal proposals to date that would > mitigate or eliminate early media, but each was disqualified in > turn > by requirements as perceived by the SIP and SIPPING working groups. > In this section, we seek to create a consolidated set of > requirements > so that a consistent evaluation of solutions can move forward. > Below, we use the term "proposed solution" to refer to a protocol > that normatively updates the relevant standards (e.g., RFCs 3261, > 3264, and 3398) in such a way as to eliminate early media, while we > use the term "current SIP" to refer to SIP as defined in RFC > 3261 and > related documents. > > 2.1. Elmination of Early Media > > The proposed solution must define a normative modification to > the SIP > protocol (and other relevant protocols) that minimizes or > eliminates > the possibility of early media in SIP sessions; i.e., it should > minimize or eliminate the possibility that a compliant > implementation > could send media before an SDP offer/answer exchange has completed. > Solutions in which receipt of SDP-bearing messages is explicitly > acknowledged (e.g., an INVITE/200/ACK or INVITE/180/PRACK exchange) > are preferred, since these acknowledgements are the only way to > completely eliminate early media (otherwise the answerer cannot > know > with certainty that the offerer has received his answer). If a > proposed solution does not include such acknowledgements, it must > define UAS behaviors that minimize the probability of the UAS > sending > media before the UAC has received the SDP answer. > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 5] > Internet-Draft em-ps-req-sol January > 2007 > > > 2.2. Additional Messaging > > In order to minimize the impact of the proposed solution on call- > setup times, the proposed solution should minimize the number of > signaling messages that are required in addition to those used by > current SIP. Proposed solutions should accommodate the fact that > messages sent "on the media path" (i.e. directly between the two > SIP > endpoints) will often be unable to reach their destinations due to > current media gating techniques. > > 2.3. Interoperability with current SIP standards > > The proposed solution must define how entities implementing it will > interact with entities that implement the current SIP protocol. > The > proposed solution should minimize the set of conditions under > which a > call would fail in such a hybrid scenario, but not in a scenario in > which both endpoints use current SIP. > > 2.4. Interoperability with the PSTN > > The proposed solution must be compatible with the creation of > gateways to the PSTN, and may define normative updates as necessary > to RFC 3398 and RFC 3578. > > 2.5. Denial of Service > > The proposed solution must minimize the possibility of new > denial of > service attacks by minimizing the amount of state that is kept by a > UAS prior to the completion of an offer/answer exchange. > Ideally, no > state in addition to the SIP INVITE state machine will be required > (i.e., the initial SDP offer/answer will be conducted statelessly). > > 2.6. IPR Constraints > > The proposed solution must, to the extent possible, avoid > dependence > on technologies on which there are known IPR constraints, as this > tends to hinder adoption. > > > 3. Early Media Solutions > > The fundamental goal of a system to eliminate early media is to > ensure that an SDP offer/answer exchange has completed before media > packets are sent. Such a system will combine two approaches: > Completing the SDP exchange as quickly and reliably as possible, > and > providing restrictions on the sending and receiving of media before > such completion. A priori, neither approach is at odds with the > requirements stated above, so we explore the possible mechanisms > for > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 6] > Internet-Draft em-ps-req-sol January > 2007 > > > accomplishing each. Many of the solutions below have been > suggested > on the SIP and SIPPING mailing lists already, sometimes by multiple > people independently; we have not made an effort to attribute them. > > 3.1. Minimizing SDP completion time > > The simplest way to preclude early media is for the SIP > endpoints to > ensure that an SDP exchange has completed before media packets are > generated. In order to convey the SDP messages comprising this > exchange, it is necessary to modify the way that SDP messages are > carried within SIP session establishment. There are a variety of > mechanisms for achieving this goal, including modifications to > messages within the INVITE transaction, other non-INVITE SIP > mechanisms, and protocols outside of SIP. > > 3.1.1. Fast completion of INVITE transaction > > Perhaps the most straightforward approach to quickly completing an > SDP offer/answer exchange would be to simply complete the SDP > exchange already inherent in the SIP INVITE transaction more > quickly: > To do this, the UAS would send a 200/OK response as soon as an > INVITE > message is received, rather than awaiting an indication from a > higher > layer to do so (formally, this moves both the client and server > INVITE transactions to the Terminated state as quickly as > possible). > In essence, this is a change to the semantic meaning of the "200/ > OK" > response; rather than indicating that an application-layer session > has begun, it would indicate that an media association had been > established, in the sense that all necessary parameters are > established for media to flow. A separate message (for > instance, an > UPDATE [RFC3311]) could be used to indicate that an application- > layer > user is ready to begin exchanging media. > > Quickly completing the INVITE transaction has the potential to > eliminate early media entirely: Because the 200 response is > explicitly acknowledged by the ACK message, both endpoints can be > sure that the SDP exchange is complete when the ACK is transmitted. > In ISUP terms, a 200/OK response used in this way would > correspond to > an ACM (rather than to an ANM, as in RFC 3398), and the UPDATE (or > similar message) would correspond to the ANM. The failing of this > approach is its interaction with SIP forking: Since a 200/OK > message > moves both endpoints to the Terminated state, the first UAS to > respond would automatically cut off all other branches of the call. > Although this issue could likely be resolved with a modification to > rules for SIP forking, it could inhibit backward compatibility > in the > interim. > > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 7] > Internet-Draft em-ps-req-sol January > 2007 > > > 3.1.2. Elimination of offer from INVITE > > One way to ensure that a UAS cannot send media until an SDP > exchange > has completed would be to forbid a UAC from including an SDP > offer in > its INVITE message, so that the SDP offer would be sent by the > UAS in > either a reliable provisional response or the 200/OK message, > and the > answer in the UAC's PRACK or ACK message. This behavior is allowed > by current SIP, but does not eliminate early media because it is > not > mandatory. At first blush, reusing the existing INVITE transaction > in this way seems appealing: Because it is a subset of behaviors > allowed by current SIP, it will interact well with current SIP > endpoints, and it introduces no additional messaging or state > machinery. However, if either endpoint does not support reliable > provisional responses [RFC3262], this solution would prevent any > media flows before the sending of a 200/OK (distinct from an SDP > answer), which would cause many existing SIP applications to fail > (including a large number of PSTN applications as they pass through > gateways). In addition, the ACK message is not a reliable > mechanism > for transporting SDP answers, since the UAC (as an SDP answerer) > receives no notification that the UAS has received its answer. > > 3.1.3. Provisional Responses > > Within the INVITE transaction, the only other messages sent from > UAS > to UAC (besides the INVITE, 200, and ACK messages) that could carry > SDP information are provisional (101-199) responses (response type > 100 is excepted because it is often not retransmitted by proxies). > Upon receipt of an INVITE message, a UAS would respond with a 1xx > message that would complete the SDP offer/answer. Some have > suggested use of the 183 (Call Progress) message for this > purpose, as > is done in ICE, though another existing or new response type > could in > principle be used. > > This approach has the advantage that if the UAS does not support > this > use of provisional messages, then the call will proceed in the same > way as with current SIP. For PSTN gateways, this approach only > requires the sending or understanding a single additional message. > However, it would be difficult to use provisional responses to > eliminate early media, since this would require them to be > reliable. > Though there exist both SIP (PRACK) and non-SIP (ICE binding > request) > messages that can acknowledge provisional responses, AT&T holds IPR > related to reliable provisional responses. This has limited the > deployment of PRACK, and may have the same effect on relevant > portions of ICE. > > > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 8] > Internet-Draft em-ps-req-sol January > 2007 > > > 3.1.4. Separate INVITE transaction > > The Application Server model of RFC 3960 provides an SDP > exchange for > early media by conducting separate INVITE transactions for an > "Early" > session and for the "Final" session. In a recently proposed > realization and extension of this model > [draft-stucker-sipping-early-media-indirection], any entity > along the > signaling path can include an EMIND (Early Media Indirection) > header > that will prompt the UAC to initiate a separate INVITE transaction > with a third entity, e.g., a media server to provide ring-back > tones > or balance announcements. This transaction establishes an "Early > Session," which is terminated when the orignal INVITE > transaction is > completed and the "Final Session" begun. > > Using a separate INVITE transaction for early media has several > advantages: Since the answer in a 2xx response triggers an ACK > in the > early INVITE transaction, it can be used to completely prevent > early > media. Prospects for interoperability with current SIP > implementations are good, since no new mechanisms are employed; in > particular, the EMIND header will be ignored by implementations > that > do not support it. And the entire burden of state maintenance is > placed on the UAC, which must manage both INVITE transactions. > However, using two separate INVITE transactions incurs significant > siganling overhead, and it is unclear that this approach, at > least as > currently specified, can eliminate early media from PSTN gateways > that are unable to separate early and regular media. > > 3.1.5. Non-INVITE SIP Mechanisms > > There are other SIP messages that could be used to carry an SDP > answer that would be formally outside of the INVITE transaction, > but > could be contemporaneous with it. Because these messages would be > outside the INVITE transaction, a separate mechanism may be > required > to associate the transmitted SDP answer with the SDP offer in the > INVITE request. > > 3.1.5.1. INFO and UPDATE > > The SIP INFO method [RFC2976] is currently used to convey > additional > signaling information in the middle of a session, after the INVITE > transaction has terminated. However, it could also be used to > convey > information relevant to an INVITE transaction, subject to the > constraint in RFC 2976 that an INFO request must not change the > state > of a SIP call. While receipt of an SDP answer in an INFO request > would change state at the TU layer (namely, in the UAC core), it > would not change the transaction-layer state of the call. INFO > messages carrying SDP answers can be associated with the > corresponding SDP offer by virtue of the fact that the INFO message > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 9] > Internet-Draft em-ps-req-sol January > 2007 > > > carrying the answer will carry the same Call-ID as the INVITE > message > carrying the offer. The SIP UPDATE method [RFC3311]could be > likewise > used (in fact, RFC 3311 lists early media as the main motivation > for > UPDATE, and RFC 3960 uses UPDATE messages as the basis for its > gateway model). > > Current standards require that the UAS in an INFO or UPDATE > transaction to send a response to an INFO or UPDATE message, so > these > messages would provide a reliable transport for SDP answers. > Just as > with provisional responses, using INFO or UPDATE messages to convey > SDP answers is backwards-compatible, and requires minimal > modification to PSTN gateways. One potential drawback is that as > currently specified, UPDATE and INFO messages cannot be sent > before a > dialog is established (i.e., a 101-199 response is sent). If not > changed or lifted by the proposed solution, this restriction could > limit the efficacy of UPDATE (or INFO) for quickly concluding an > SDP > exchange, since the required 1xx message would introduce additional > delay in the transmission of the SDP answer. > > 3.1.5.2. Other Response Codes > > In current SIP, if a UAS wishes to send early media in response > to an > INVITE, it will send the media without any SIP response. As an > alternative, the UAS wishing to send early media could send a 401 > response requiring http-auth with null authentication. The UAC > would > then signal its willingness to receive the media by sending a new > INVITE (with the nonce for null authentication). In this model, > the > UAS's SDP answer would be sent in its 401 response, and the > UAC's re- > INVITE would confirm receipt of this answer. > > Although this proposal does provide a reliable transport for SDP > answers, it has significant drawbacks: In addition to adding > significant messaging overhead, it requires both endpoints to > maintain state across INVITE transactions (in addition to the nonce > required by null authentication). And the prospects for backward > compatibility with this solution are bleak: All calls to current > SIP > endpoints will fail unless the endpoints support the indicated > authentication mechanisms, and forked calls would show > unpredictable > behavior due to the Heterogeneous Error Response Forking Problem > (HERFP). > > 3.1.6. Non-SIP mechanisms > > There are some proposals to use protocols other than SIP to resolve > the problem of early media in SIP. For instance, a lower-level > protocol could be defined that could negotiate and SDP session that > could then be used by SIP, much as TLS negotiations are conducted > before HTTPS data are sent. However, such a protocol would have to > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 10] > Internet-Draft em-ps-req-sol January > 2007 > > > duplicate many SIP features, and any such solution would require > SIP > entities to implement an additional protocol stack, which would > have > negative consequences for backward-compatability and PSTN > interoperability. > > 3.2. Handling remaining media > > Early media can be completely eliminated only if neither party > sends > media until it is assured that the SDP offer/answer exchange is > completed. Of course, this is only possible when both endpoints > support the proposed solution and the SDP answer is carried in a > reliable message: In this optimal case, both the offerer and the > answerer must not send media until they have received assurance > that > the SDP exchange has completed. The proposed solution will specify > the two remaining cases. > > 3.2.1. Unreliable SDP answer > > If both endpoints support the solution, but the solution uses an > unreliable message to carry the SDP answer, then the offerer can be > assured that the SDP exchange has completed (because he has > received > the answer), but the answerer cannot. In this case, the offerer > must > not send media until the SDP exchange has completed. The proposed > solution should provide an explicit, deterministic criterion for > when > the answerer may send media: For instance, the answerer may be free > to send media after it receives media from the offerer, or after a > timer fires that is set when the answer is sent. > > 3.2.2. Backwards-compatibility > > Depending on the nature of the proposed solution, one party may not > be able to know whether the other supports the solution. If a > party > cannot know, then it must behave as if the other party does support > the solution (otherwise, the solution would never be used). If a > party can be aware of the other party's support, then the solution > should allow a supporting party to knowingly send early media to an > non-supporting party, since to do otherwise -- to mandate that a > supporting party behave as it would if the other party supported > the > solution -- is incompatible with existing SIP applications that use > early media. Nonetheless, an implementation of the solution should > always avoid the use of early media; it should only send early > media > when it has received early media from a non-supporting endpoint. > > > 4. IANA Considerations > > This document makes no request of IANA. > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 11] > Internet-Draft em-ps-req-sol January > 2007 > > > Note to RFC Editor: this section may be removed on publication > as an > RFC. > > > 5. Security Considerations > > The only new security concern that arises from this draft is the > possibility of introducing new denial of service attacks. The > requirement addressing this concern is stated in Section 2.5 above. > The performance of each candidate solution against this requirement > is examined in the section where that solution's is proposed. > > > 6. Acknowledgements > > > 7. References > > 7.1. Normative References > > [RFC3261] "SIP: Session Initiation Protocol", June 2002. > > [RFC3264] "An Offer/Answer Model with the Session Description > Protocol (SDP)", June 2002. > > 7.2. Informative References > > [RFC2976] "The SIP INFO Method", October 2000. > > [RFC3262] 2, "Reliability of Provisional Responses in the Session > Initiation Protocol (SIP)", June 2002. > > [RFC3311] "The Session Initiation Protocol (SIP) UPDATE Method", > September 2002. > > [RFC3398] "Integrated Services Digital Network (ISDN) User Part > (ISUP) to Session Initiation Protocol (SIP) Mapping", > December 2002. > > [RFC3578] "Mapping of Integrated Services Digital Network (ISDN) > User Part (ISUP) Overlap Signalling to the Session > Initiation Protocol (SIP)", August 2003. > > [RFC3830] "MIKEY: Multimedia Internet KEYing", August 2004 2004. > > [RFC3960] "Early Media and Ringing Tone Generation in the Session > Initiation Protocol (SIP)", December 2004. > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 12] > Internet-Draft em-ps-req-sol January > 2007 > > > [RFC4568] "Session Description Protocol (SDP) Security > Descriptions > for Media Streams", July 2006. > > [draft-ejzak-sipping-p-em-auth] > "Private Header (P-Header) Extension to the Session > Initiation Protocol (SIP) for Authorization of Early > Media", January 2007. > > [draft-ietf-mmusic-ice] > "Interactive Connectivity Establishment (ICE): A > Methodology for Network Address Translator (NAT) > Traversal > for Offer/Answer Protocols", October 2006. > > [draft-stucker-sipping-early-media-coping] > "Coping with Early Media in the Session Initiation > Protocol (SIP)", October 2006. > > [draft-stucker-sipping-early-media-indirection] > "Early Media INDirection (EMIND) in the Session > Initiation > Protocol (SIP)", October 2006. > > > Authors' Addresses > > Richard Barnes > BBN Technologies > 9861 Broken Land Pkwy > Columbia, Maryland 21046 > USA > > Phone: +1-410-290-6169 > Email: rbarnes@bbn.com > > > Matt Lepinski > BBN Technologies > 10 Moulton St. > Cambridge, Massachusetts 02138 > USA > > Phone: +1-617-873-5939 > Email: mlepinsk@bbn.com > > > > > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 13] > Internet-Draft em-ps-req-sol January > 2007 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2007). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided > on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF > TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE > USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be > claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the > use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR > repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). > > > > > > Barnes & Lepinski Expires July 19, 2007 > [Page 14] > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Mar 12 16:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQrMG-0001c3-2u; Mon, 12 Mar 2007 16:43:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQrMC-0001aM-MN; Mon, 12 Mar 2007 16:43:00 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQrMC-00062k-FE; Mon, 12 Mar 2007 16:43:00 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6AF693293F; Mon, 12 Mar 2007 20:43:00 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HQrMC-0002rn-AX; Mon, 12 Mar 2007 16:43:00 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 12 Mar 2007 16:43:00 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Connected Identity in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'Connected Identity in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-05.txt Technical Summary Because of retargeting of a Session Initiation Protocol (SIP) dialog-forming request (changing the value of the Request-URI), the User Agent Server (UAS) can have a different identity from that in the To header field. This document provides a means for that User Agent (UA) to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). Working Group Summary The document complements work already performed in RFC 4474 for authenticated request identity, and forms an integral part of the chartered work in this area. There is consensus in the working group to publish this document. Protocol Quality The document has been well discussed by a significant number of members of the working group. Note to RFC Editor OLD rendered in OpenSSL format NEW rendered in PEM format ^^^ OLD are captured between tags NEW are captured betwen tags ^^^^^^^^^ In section 2, last paragraph in the seciton. OLD Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS except in cases where the UA is connected to its proxy by TLS and has already been authenticated. NEW Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From letheshadowi@dstsystems.com Mon Mar 12 17:14:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQrqQ-0005K2-MT; Mon, 12 Mar 2007 17:14:14 -0400 Received: from [221.148.102.79] (helo=dstsystems.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQrqK-0000cQ-8L; Mon, 12 Mar 2007 17:14:14 -0400 Message-ID: Date: Mon, 12 Mar 2007 23:56:58 +0300 From: "Cherilyn Elliott" X-Accept-Language: en-us MIME-Version: 1.0 To: "Kallie Barnes" Cc: "Tamesha Ray" , "Elana Barnes" , "Fumiko" , "Moshe Fox" , "Oretha Williams" , "Lavon" , "Augustine Bradley" , "Derrick Kennedy" , "Valene Martin" , "Nenita" , "Suzie" Subject: Get It Now Content-Type: multipart/related; boundary="------------476710285876250728770220" X-Spam-Score: 4.3 (++++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 --------------476710285876250728770220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


delight "Let me bet assure hook you, madame," said suit Lucien, "that ha     river "Ah, shrilly clear but madame, does mankind surprise ever lose anything? "Nothing.""Yes, drunk no part doubt, but tense improved upon dreamed by ours. What is   
ok distribution "Undeceive yourself, monsieur," chin attack replied Monte Cris     afford "Yes, dream your excellency. I did not surprise range look on Caderouss   rapidly careful "That did more spit honor to your choke heart than to your ex   "What, do religion you not know your ant country surprise house?" asked Debray.     
request "He seems to have a mania for loose desert spicy diamonds," said Morc"Were objects map shock of art, madame, carriage and brake nothing more," r"Sister, brainy damaged sister," spot taurine said Maximilian, coming to the ceye tongue "But," remarked mammilary Madame attempt de Villefort, "all these ci    peck "Is your steward enjoy danger also pretend a Nubian?" asked Debray. ship "There was fall cheat evidently a war severe struggle in the mind "'Wait while I light the met coal machine lamp,' self said La Carconte;    
"Is pin it delightful judge substance that excellent M. Bertuccio, who understand 
"And, further, waste paint that he stated to cruel M. prove Danglars his ioverdone detail "Precisely so," reduce cried rail Monte Cristo--"precisely so;"This kiss bound Count put of refuse Monte Cristo is a strange man," sai"By chemists boiling monthly brass and persons who have boat a taste for chem     
"And you have bee alive love chosen soon this honest citizen for your  "La Carconte wore prick went to hot a suspect cupboard, and returned with  building "Caderousse market and his wife doubt swelled again interchanged a mean      
"Then," hair skirt mix continued Chateau-Renaud, glue "since you have          "His voice quick went to substance was my heart," chance observed Julie; "and     

"Have you vespine noticed horse the remarkable beauty funny destroy of the yousew fraternal "Really, office madame, this is a quit scruple which naturallylinen In matters cry of get speculation, however, describe though "man prattack "Yes," answered bread Monte live Cristo place "happily, yes, consci      behind "Who test laugh doubt will tell her?"  "At shone the cool dirty same moment, stamp and in the midst of the terri "The jeweller, whip meanwhile, shine offer was humming a rich song as he  
"Who fowl is animal this misty young person, bled M. de Morcerf?" inquire"Oh, do not boil boat place any wire canvas reliance on that, madame; onWhoever held mortally had selected this wake retired portion hissing of the gbusy "Oh, no. In the chew first tumble place, let us stitch agree that the         
copy "She shear vessel discovery only speaks Romaic.""From time impulse jewel to whistle time Caderousse servant darted on his wife k  "Joannes degree thrust stayed for weep a while spare to see whether the sto   lip "But daughter at least we shall stood see her," on said Beauchamp, "    
wear "So I should suppose tin by her drove dress; shelter if you know no"A stretch was wound representative skilful preparation of my friend's the worthy Apunishment "Dearest Valentine," said peripatetic rub the clean young man, "the diff"Perfect, madame, as you owner transport have were mend seen," replied the c      "My dear Albert," burn irritate existence peel said Debray, rising, "it is half "To the fearful noises that alert had stealthily paint awakened kick me had su    try cautious "Then all became clear flight and manifest to replace me, and I r          
"Oh, blindly we have three sing property millions goat for our police; it istake "Undoubtedly, and so fantastic burst celiac should I prefer it, after the        
--------------476710285876250728770220 Content-Type: image/gif; name="crhbyfyddyqyty.gif" Content-Transfer-Encoding: base64 Content-ID: <96440DD0.D17D4350@dstsystems.com> R0lGODdhiwGOAaUAAP///+jf0u+ysueUlNlOTsUAAONycu7u7MwzAOB2dgAAAP8AANbW1rm5uZrE 4o2i3GGi0jqEwStztRxPk2h9wY+UmK+usGZmZs+yhdimbbWSZseMUKV1O3hUR4BPIv7hnVJHUj0v Pv/MZichKuefN9x0IXqQ17Y2CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAiwGOAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLlcDgoB5zW673/C4PCkQDOqEguEw7/v/gIGCXwFqAAd5BQh2 CAiGQwcDBgJ8g5aXmJmaXgMEA0MJBaICAAKTRIiKdgmUm66vsLGWaqGfQgIIogMHhZVCoQWfuIuy xcbHyF4ElAYGQ7i6naRDAbkFCUJ508nc3d7fdQeqpobVogZ5tkLmugADCZWR29/09fZ/kY0Bogis hqkFlnkqAkxUggB8DhwIRcDXvYcQI4IJkKiAgEQI1AHAWAhNwjQVLT7rZwqexJMoU0ahKErRgJbE hBjgp0aau4YsDT4jBayh/sqfQIMCyHmtIgFDwBZBI6VtaCJsRF7yayW0qlV7RAlUtDVTVQIERzfq OZRonoCWwRIsu8q2LbKcixI5czfgDq9HASQJCNXPFzSDqea5HUzYT94EdteVZQmVCa8ErIgQdYZL Y+HLmNlchLl2qCgCQ9NUObD5s5o6mVOrJnPR2tRsAR9V+atINhM0gsko2M1bwRHe9XoDLzIcaO8p xQEkB7TwE1FVh1BjgZv7CGnEAxodXCN8ufLdsHwv6Q6eiHeJ5MU/SX6+j7lP+Vr65BJg5twkvOJb TDRfd/njx7RnXnnfqVfgT8UJiISCgbADFVy2ZSEPEgpRlNFfA7BjWRgJ/hIoBHsADniecMQROFx6 Q3Q3nokeklciiSmC1yKJ3rn44ozqCbgciCrGaOCJNorooRcA6aHGAV1VN1Eny8x0VFIB9BShFzyK KCSPIRYI44csipeel1v+hqOPPWq5ZZhfYolmmR0a+OKbZMJYJZdBohgGbZ0R4AhrlEgVTCkH/VVH S0pyMSedPiZ6IKKMLuookP91yUSbQjZqRJtuoqggpY1G6qaVcNIJ5qgfPgqpoo5+4edndRSKxV12 BAOQM7yQdQ5AjXE4JqpZWhqqqaR2KumKQQJ7I6dWnnqsp0owu+CQqXJ6qLRfjpEdWiKB0Zon2TV0 lldQSfXkOf7leKiZ/s6K+WO6yCpLbK/GinomtMC5i669l4LZ7JA7Djutv9WOsZeenjgkYV6xtpMX L9ags6eg0Nz3hW/I+iqqpfa62266+34K6qIAnouoxiSvay68H/tKrcm8ctxGfl2Y4glY9X12l0zn fDWNXKls2AWmH69M5sXxhjxsqs963PLJMabMKMcbnyy10kHze/Su8WYtBm4Gj5ZXJ+dkN6gqBkD1 7VF11DSVnlMaaieq916pJqZyXo0y3PkyLW+INUaK8dv3Zspg4Hm3XLXee1MdcyN7XLEQAV9Bbtod 7Oi5Z07OeeLgHeWGqTK8nsubN8WIY9nx6X/LeLSiLh/X74jQJhF6/tZYV2zmF3ZEeNaeUpC2CyIZ QS6oEEjyg840XXlylkCQt73a84MHtTxiaf9iUhSl4TTJO7MO4WeGHn27iH0dPW/+sZmtyo/wzhdR 6y9oNVRXrVIhQI01OGVkTkbzn+9/pZnpCrZew4SLdEY/eiDHOqyhjqTEinlU+Z8EzYckrbgGJq4i Hn/84prO4Cwgz2iJWjKikAma0H8I4cUq9FQb9xWiCN97hgFckyvxTQMaSmnfCXe4Gt/tAhJ50cr1 bNVCAFCvIo3JSVjqExkeOvGJt9DTtf50i6+QC1BOoYkGCQjFLj4xSeIzRNmcRIyFkAJzitFcES5y Ci+6ETMyu2Eu/g6Si7AY8SAbNGLjoDEfhBxhJhkpBQHa+MZC/uSFYokN/I6SDu9NYiul6MctDOAz yQwSIQUJpCE3KZFu8SGGkRxfQG4IORaq4iX9uc00CkIoTrryG1ESxliI6AiF5IGSr7lIn1qyvQzC 8CCsnFkqX0lMWLRmlu+YJC9xJsqA8GItuFCjFPiClof9sJjYzIQdJlE5PkSpJpLIpS6+FRBUerNr T6ANdBCWzXYOoi7X8hYBOZe7hh3iHEp8hy+dUJpFkEYf7gyoH85CmVykgYFVBFSRSNGSO2hln06o BG5ocUWBWvQNqZiLKUiRPG8aAA2UNOVRFDGQEmrhIhlaYwII/vmQBbjUpWxYgBBkegSalsGmY8Dp YHBom/qt8g6T2AsvWYFOx+VBk0HBqU6rsFQjNJUIT4WqLKJqFQytg3LWMNtBTjEMD3ohltJJahGo +gSyAoCsZjWrINQKFHZ81IrY6AkfNupM0kTQCxu1XlEjolObvtSpZ+3rTGE6VsLS1K+GHUJT/3pY mTpWqYQd61kDC9iZDtavirWsUimr2cta9rOTDSxkMctWOACkmZRpKJIeec1bEOKoHI1NWE8i2NDa drCfPSxoM9vZ0JJ2t5K17WNzy1upJlaqvfUtbyOLW9/qNrm/JW5uSxsHP4FEkQ5MqcEQocPeCfAa e/lodnLF/tfgYha5yk0veqUrWKpG97znNW5xM/tc9da3uPWF72QdC1zh9ncWcnHHKKLTDOehEqIR VUv8bqiIvdKjtvEF7XPvC9wJF9a99JXwZZkLXcDmV8O3BXF8dctfxJr4uJvg6e66e4ussliV6/gu MSqTEgjP178hXqqNc/xfDX84xJKNcG/1K130/li5Ja6sjo2Zi5BCNCestUI+YuKOC7ICwdzYLIjx y97K7rfI/AXyfBELZg/feMs/XnKZ0cxlHFPXPQV2cBEESBro9K4OM3QmNb5LXom8lMN/Da5wyXxh MKOYwpEl7WhrimNBixaqgdZxoG876UY/WrGJPomfjoLQ/rTJ2Xv+3AuVhTBFLLsTwz2+wpuJqZ+4 tBKQHxUN8QpRvfc8I0Iv6fNFGZ0EIWth1a5cCAbJGZauBK8zx3yYzZTgkV0zVctb4LCz4deOrh6J PywhRjcBgBZTT/vbmZhyOajiVoCABgAdjeSy1/FicLtbEHuZEob+AhUHfpCKeny3vr1RP7ApUsAD VrciEXHufRu8GObmo18aSjwBYkOX55M2FXz9Bolz1rMY/7Nh/3xhizvRrdl+BL33zMvZrkbiFOe1 mN1gceZOOtKSbu7FPb5D62oIEgGGhMyGaD5pb7wJKQ+EyxkLc6cSmuZPXCg5NZK8dqsGphvXeIkb i99M/mN80COGLGd/vvWiQ53oXIc0pq9e05cT/eKEGZjy8CdRSD7x7F3H7der3ti6ZzzqMv861eP+ c6jLfb91L3reKz32uFOW8IV5YWsaN5RmUA+KXI+8zEX82OHq/fCVR3vk9z53SJN56pMfvOdjbviw r6bZkHjj5pu79zb73fJJnjvoC796zBf678NFu+hvT3vOt/7gKqn9cQG9XLBX/viiRX7vWU91QIf5 8qbffWGnX/rfAx8lwm++5cd8ec+aPfO293rfte/cR0ff8DMnf/Uvff0at77vfOd+4dM//9UnOvdR J//wA5//vnKc+fc3dkjXflUBbGIwgMmAgAQIFAYY/gYKGAuEtoCE0YBg8IAQiHgSmIEauIEc2IEe +IEgGIIiOIIkWIImeIIomIIquIIs2IIu+IIwGIMyOIM0WIM2eIM4mIM6yA0HwAA+6IM7GISo8INE 6IOfJoQu+IMKsYQKwQANwABIaINOyABNWIRE+IQ8ZFJR6Ao96ABW+IU+6IVHmBpauIWXwAAO4IVp uIZs2IZsCIVZmHRMOId0WId2qBoO8ABuuId7+AAQAIc7VIb/Y4eEWIh3eBkOAAGKuIgQEAGK6IiM GImMCIjrITixIxGC+Dx30RGc2Ime+ImeCDOEwQCOGAGOKAGomIqoWIoSEAGqKAGM6HTfcSMI5zhj /ngVRwKKuriLu3iLFrMv+RIIDmCKruiKsGiKqXiKq1iMrUiMlOgELFIPL7SJQ+FHRvA+0GiJioMF NFImRMKL4BiOAcAAshg9TVMigdAAxCgBE8CME4CK7YiMqdiOzWiKDeCLs8gl+Wgq+Wg0l/gFddgR N9OJh0CHiNQEVvOP3Ggu+jgGm6iLm0iO4tiJQFiJ+zgp22gY6zgBEMCO79iKywiP7fiOjRgBFHCP URCN/6GPqqMvpdKQDkmICNELnWiHFZmN5ygGsaOQB+OJPlgIPxmUAtkRRkiTM0mUz7gi+9iSS0k6 52g0F+mQ6hiSxFiVxWiVyEgBFUCFUqA6MCkj/v3okkNDBjKJEBJZk3V4kwjJkF3ClqPyloWDjmLw kEhJjkU4jkBJkXjZg1TIiU4IBV45MoFZL/riN4S5BgFgARTwiozZmKmolQ0giywplk7pNxcZmA6p i2eJlz8ZigxgAUkJjJP5krPIlEuZk2MJk2BAl3g5jkKZl61JlHm5mUDZABbZkJaZm4W5m6pJBgHQ ABXgmMIpAVpZAZFJBYPpJaMZlk+ZkVrQmXrJl0dJlz1YARZQjk55mYfJnABEi735jaEImxRJm35J jnT5lziJmy6pm5PpOmJpBuOomMP5iloJmpJZNS/plUDSnGbAl7R5F0uYQp4InKCJj8nZNAeq/p1R CSo8OR0T+aCf2AC2mY11o54WWpqC851k+ZmLOZ8ScAHWyZVW0CFjmaCiA59TCKGfGaL4iKEXmqDR uKADoqH0AaE2CpQWMKEYiY7seSCGyZsyOpc+2AAWUAGLOQFImqRIegH1aYRv0KAv44RPGI4rap8t KiwWapoxajX8uTXkeaO76ISgmZ4Iup5AGpY9agZWSKRGegFJegFMap1PqIRmwJCDMI4S+qUdAZzG KaLIGaO346La2TckKqTQCaagOKTWeZ8QAYYSWqRGWgGSagGg+YV1ao4YFZ9T2ol8ap9xAKUNkqdg OKqkSoSQ6qdt4Z+OKqFzSqpXGhE9SKSt/uqEIWqNbGCnsMALRAqpktqrvvqrwBqsk0qOl7GEpRqg VKiETJgZ8fmrT/iqWXA3msALYkqp1nqt2Jqt2kqpPwmtD2GI4DqHmFGXd+mtqUqupVqergmd5gqr megYS1gYm+gLBimQbySuS9CuZgiv72od9rqvKAit+aGvAFuC/VqwCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxGFsM9pOxu9YIjcAEH/sEHjsEHruxRVCyRICyZRCyLGuyHOsKLbsEIdsE9lOzABCzKbux ODuzZoCzfuCyrgS0VsGzMTuzH2u0QnuzSmsEPHuzOvu0QkC0NeuyKuu0TXu0JruzSasE/lWbBE3L tUj7tVZLtSO7slDrtFbQtUggtl4btkLbtWorBlqbtmQbtVhrt2iLt0wrtldLsmcrtVOrtz6bs4Gb t4MLsmfbtk5gs4V7tX+buD0LuVFwuHsrskrbuHVruJJrtnpLBVIruI+bt0dQtn5buZrbuaebunwb uqlLs5l7t3ibtUlrs6ZbuqoLtLBrt257spgLup77uoWLtkg7ukvLuznru6Ibu2S7u8c7vK07BZ97 u8oLtrI7uqwbvS2rsquLvJSruLY7skVru7w7u7h7veXbu8/rt7Q7t9ALvL3rvONrvccrvYRLv6uL vt0rssDLvcFLvJvLv6jLvvNrvPa7/rXy+72hm7t7W77W67yOC8DJ+70QLAXYa74RXL8DDMEPXMAH zL5sq7+dK8Cky7SXG8EeDLnga8ELzMGLu7+nq8ArjLoIrL4bnL1lu71LK8CT68Jz+8FWK74znL5a q73kq8EGrL8VHMI+fMMlG7xwO8LCu7zVW7kO/L9ry8NQC8Mnm8NbS7k1vLk4rMIUjMW+u8Rc3MGs G8RfG8Zi7AY+HLVg8MaIG8eJe8IGzLgmrMJvC7s6rL5nnL5Q4LMi/MF4nMT068cn3MAs3AZQzMhH 7Lph8MT8e8RMjLLMq7vyC7hTbLyJXAWS3LqNjMFNTLpPvMb9W7XbW8UyPIJy/Mh0/nsFciwHrUzH sOzKKxjLcmvLYHsJobwGuOy9LxvMwjzMxFzMxnzMyJzMMHgX5arM7ccLGBDN0jzNGGCrzgxu0CzN GRDNGbDN1Myo11xIPTjNGaABGNDN3kzNqBrOAXUA1HzO25zO74wBKMnOTUCHTjTO72zO8SzP01zP 9kwhZdgLOwTP+3zOGmDO83zOoRnQBXmN5TNBAZABG8ABFp3QC53QCZ3O3QzOLyuITMiJBJsSCM0B cAqiFeDPGsABvprOGqCjDl2GAbmXKITOLH2t6LzNKz2p1irNGpABHm2xIG2HQEms5sMA6KwBW/mD DUDR5cwBAdCnPwjP5dzQyCzT/gGaQudpns+DARqd0CL6mxTNAR1gnOVA1eVsASPtsFhdIVNaIeM5 jqrhzhvw1UBNPEjNAR4QosSD1hnAAdcJmBnKo85Zgw4R0txqnp/4k3Ndzl/90tTQACZdoELg1Y/N 0k7HpYQdCAfwAZ792aAd2h8gAKX6g0EdFCY1h4lpn0NJkc+aGhP92GA9BJ+Zo4bQzbKN2SmJqzMq CJ8drk1ondt6rYs6iJAQoNwajpR62t/q2I+dAfGAl30t2zuNnc2pn2bankF6BZ49EUVq1cVKPMjN 2mjJqYGdGQfg3I+to/EKAJZ92XsN3mKCoCkiqLpJOtm5Bd0t3uE6kQrx3ecT/g/GuqmeyG57et6Y 4c4ckNsaECEBsNK53QFjutuDat/ZzZ1a0NkfANwhPaufSaqS+qqF3Q0CDteFeAicSKTM/RAMsNIW /eIWfdfU8Ncw/uIecAHHSeEqaeEv+p5YINpAHuQMINzDna0UsJZ8M+K6Mpf83d74keIIXgXtAaqC 8OA1DuM/ndRXbuNbKZkwyuPcaZlaEORkDtoYUJy+SgEUAKcg0OZu3uYVoENbquSXEq10HgUlXpag qOILmSk0qgm/ueWCDuMeYOMSvs4U+pQ8vp8YngVl/ugZ0OYX8OYhUOmWfumVfgHyPedSfucY1eSs yYt8PqL5TeWY0OI1XuiD/l7oqu4Be53jXYkjlTmjYu7j3C0CuJ7rur7ru64BIzACmB7swa7pDsbp sr6c/giXyuGj2X3svcPfNzrqnY6mlWmnUGnqhCDZNq7qg27jIHABFnAIKfEBvF7u5e7rIfDm6r7u kg7Q862e2fmj8d7s68LsaBrmd57nRQ2GAxrlyFHqZwqW2o3tXpDX3a7X3K7X327WKkHu5v7wuI7u 7D7xbU4BRp00hcqePfqj5pGlFy7mT1DieMqqlMqqefqQ0v7vXcrxQwPyGDXkV57wMg8CZT3hKSEA GQDxD78B6U7xE7+Vxe4x972dQ4+Zy86cGz87+Wrgn+nhRehNB+7RnI70/m7Z6BgFnBeg1wfvAW3e ASDq7icx0Tmv87y+AT4/8eC+6UJ/4Svv4y3i8T0uZUxP3p+YEB2x3KReoVQP99tdBnzJpx3g6jLv 6l2P0rb9E+6c0+hM9pF+9uoOohf/LO+u8R9/pkfP8kn/7Cgen3pK0JtY3H+62U3Z2yb6BusqoZJ6 AR2w+oHP+igtp0O64q4g9opf+7WvAZJ+0rq/+wvvpKIpl215odSumvQu/NKqBFnN+b04FD5YpGAv 2MAP8CZT+i8znrsqrDk6p0WN+E1t+96P27sf/roPmZGvGq75qF0Okb9prZG51vUQ6qV9qOPo/pgQ q93//bUvrNgP6z1U/oQSCo5AwBAOGQDjEZlULplN5xMalR6oVWogUMVaudqAFBwWj5XXAKORVq/Z DcsbHperi2T7HZ83Hs5DOhHQL82C4UDvEDFxjyvL8AirrMtRkTLRCiswU3OTaLLyEzSKT8itgROw zzN0dbUryeqJinUWTNKW8ZQIa5e2l1UrtxFY1bfY+BiZkm+Xudn5Kzlaz+xZ2ItYOlt7O5mxuhmb W1z0djl8HD1dXbF83X3qEvp9nr7e/l4REn+fv9+/+9wSff8IFjR4kAyfgEhkIXT4ECLCKuQiVrR4 sV5DjBs5dvT4EWRIkSNJljR5EmVKlStZtnT5kiMCmHhkzrRpB0HO/ppOcobReUTnTiRBh/6k1RMA UqRgiD5ZCsUoUKFJlgZ9Gkppzas3k2V1OpVnUrFeixohu5UVWSlqmaBdIhOuVLBm0brFqnVutrwk n3qtCndnXbFKrp7FW7Zv1KZSkwY+3JipUL+OB0MmXJnu3MWMqQIu+rewZ8tsI9vlvBY02M1Wexk+ lDjzaNGWO2ue6pp2Y9G4a8um+xt1Wd2+KRPumxsocuU/cdft+Zh0lOidmY71zflvtOljYF+f3CQq cOG8vUO3DZz81/HmIdtVrPy0+PXoH1MfnB6q5MPZs18+/7Y+43JbbLP2ittOjO6am+2t+/JacL7l /oMwOOzYe24v/uuselC/ttizz74PTQMwQtfc28o5C0MUcUIWEVGLt/Co0vA2FwfEkD755CpPR/Vo W3CvuDpErjvjdvuwNxsjK/HCDGVEkcMVMzMqRR7hwym8GE2jkrXUPqvxxv6o6w9BDxU0z8nQdCxy TP3EREzJCnPkcUvMiAwSzOuEk9JKaUa0M5E/fRTnzwzzEJQnQ2mqT8sgafwNRz53pDDJOI+R0RhE wVO0GE2xOpTTO1ZDEtPP5NqPtSkFTOxNxsgMkKtYY1I0VO5q9VDWXFUq1RdPSdQV2GCFHZbYYo09 FtlklV2W2WadfRbaaKWdltpqrb0W22xnqiITjbT9VqUDcukE/tyT+BAA3XSzgFbccQNZaCUs0p13 C3hTOgADEvTdl98MMhCAWXc5uemAeQ02eIuZBOCX4Yb/lYfYdgXexN6RAjAYgwww2JjjgyFWaeGG RWb44WElnphilwpOF4MNNvCXY441xoDeijk6gOES9tVZ3xJ8Fvlfm1VC+RRTXGIA3YxfRnfmjP2F OWaaBVjXpHz55flnErDe2eGPtxUkDVJMQeOPsMk22+h4k85g6aidFgBmtpveeOqScBaZ56t3zpph gLk6u4EHHiBFcCEELzzwB9QoXGyhN2JgY7nhfpryjV+W+/LKvfYo5L3z3rtnEkTgm986ZgogjcMp oEBxE1xX/lxwEwYXPPDUFV9885HEVXoDpymn3GW5ff8dA8cREsDn5EtA4HOt88a6eX0zyF0l1A+X /QHZsTehAe5pvx32xBc33Vyng/9dbrYv7z199Kl/QoH44z9ifiXqr18a5JUnoAQC+E+ef84DoPKU pwHySUF+91NAE+aHPygkcIEQdGAo0HA4C14Qg21ow+DGgL8J+gN1/toAB37nssuRUH1sQyHwpkcG Dy4QAB+MIQxlaAz9KU9f/vMZAv7nP/8xj4A+O0EFDvhAGM4QiUxo4BHhd0QPFoMBGJTiFKmYvSIa kX5M/McBGiBCDnDAhF9cHxhd9kUwPs1lGqhAA4xXQwZq/jEbAdhfAJ1HAB76UGfQA+AJLmCB99kP jlgMQw0DScHETfF116MA9qhIgSti0Y37EJf6RmhGFIZxfZnUwCYrQAgXFnKJCjSCAiMJigNoIIg/ I50AlXcCV3agk4UYZCBfKEpSglKGhQRFACxQxdUp8gGso6IJ/GgH+SUhgaOMIBOTmcRSUtACJpTm NKlZxi9WoJOmMF4SAYmEJSrTmbqk4An+l0pz+u+VF8gmA/7YTXc6cZlIFOUSmkm/YqCOkRg0gTCD yTp+6pMCbDSmA+E5w3jGMIvh7EYDKqCBaj7Ukti0gCna+UYl0vCYtnxmKA6QAXKaM4gIcKUHYLlO qs2S/p7MzGg8j9lEghZDXBbIpwV/ubp9/nKm2aMAEbdpUEB+k5sGxehGQ8HLCogRombEpkl7mtCU yvOgt0xGACrgyjv6EKuuPAFJJUrRk4ohlwX9plRdas97MtR1aVWr7BbZz9itdZ9rrOhFtThWjCb0 hdngA0Mt2VelrpOdTfUmLhEKVXBmUZyrYIAFOqBVx2qVpOqcqBC++smnKhSoykwsNzdbicVWYJFw Fa1oVxfLO2RWo4edZz278dkLvBa2sF3q2AR7WcyCM7VBNQbqKnCBDvwWuOrsJCECm4i8rpalUaVl QUd5jJiCNrSjJW1pCdHTvGL2rtg97FQhl4YMLBWb/hlIA8coW9k8QBCvyUQuUT8xCg2ygZ1znWVL a2lXzeoSvWY1hrgYujqbSte//l2jLAfqVKEqF7FAZW8lltEH8gbiG7V1SIO/EWFjncECAdbwhqnL ztNhAsK7iG+FzQuScpyYGt7K1RncgE0KxHZ1r7XABXa6TglbhMIk1nHCSIJiH3MhVycj2xvAC144 jG0IN4bINUhsDnOAw24/lrKSNyJkQLBhokjuVkumLOVwqbhZViYaIABA5SUbosuuKJdIxEw0Ljxy zXH2R5p/LGc7G4TOPr7zngsCZD0vgs+BFvSgCV1oQx8a0YlW9KIZ3WhHPxrSkZb0pCldaUu35Vm3 /rr0pXi1J+l4yUhu0rSokOSTTsfnK45xDqtGjaU5DbpMV2qQkGBFqdbA6tM9ApFTHnWnOflKD7Hu SkrO9KPZCOY/KtKTWcKkajC9SteJmg9/UM3sZP+61gwi0JOO9OoEnTraZjpVqL/Uq1Lbaj3dblVs BMSkNXV72ZOyVH7STZxqD6fdyiYNc+Y9nH7TW9bh9s9YAmTrWwsc4NjO0Yny5G4iKRw+FPJVsYnD oN54etzettJ0lAJxU0+bMuu2Tr43/mxRZ9xVB8L1x/XdpEQVh0/7pk9TqmTwhJfcQC+/N4wKZBia T8jjS7KQumFuKpIbnN9Bl7fSv+3w74DHQbjq/hOz4x1xG018SCay+IxWXnU1eR3oU5cTznMubowj /eotYnrTjf3qTgvJ12RP+dqTLvZct708jqJ1zKFjJLmb6t/SbvnC01R0iH89Kz//lc1tRXHQ6Fw3 dY98ubl+cl1Hyu6fdjxeCj8lzI/qPKzeObyFffS0BzwuVlc6fmoe+FkU6lOLUgfsQQHsXVeC5253 T6+T83d/97vu+DmK7RXRaoxvg/iBMv69i58lrZzm1FwiirMpD6fqpwjaAd90smiP++UjfPvVAnda vq/98J8f/elX//rZ3373vx/+8Zf//Olff/vfH//51//++d9///8fAANQAAeQAAvQAA8QAfls/gEW kAETMP0YEAIXwAHDDwKNoAILQgLv4AKToAGVoAORYAEnUBo+EABIkB9MMAwiMAMtMAI5cANLcAVF EBlQEANDkAxskARx0AZhUAJ3cAdlcAZf0AM38ANzkAaPoAh/sAGPUAVBUAhdkAVXsAOTkAWrEAhH sAWHMAunUAmzcAmSMAZV8AeR0AvFsAl0UArRkAx5EAavMBvM0AkzkAvl0AfV8AvrMAztUAvjkAxj 0AXBsA/7MATH0A2ToQmZgAoBMQoREQ/XMBDvMA3z0A8FURIfcRHbkA0L0RBNEA7bEAwPcQ8vMRNH 8Q8tkRSdcBQVcQijkBA1sReMEBS9kAdB/pEPLVEVS1EUT3ERFZEJ6bAHJ9EVKYETG5EUZfEIcXEW bbEVYVEQITEV9RAVrbAVgzERiLALfTEO/fAWlbESdTEXL7AXfzESrRAK1/AYqfEQxPAaZVEXO/EP aVEdGfETz3EJ35EQx5Ad0bESaDEQh1Eep5EVn1EcgbEZKREKaLAXQ1EfTeIcFxLRGtIhDQ0iI5LQ JpIiLxIjM1IjN5IjO9IjPxIkQ1IkR5IkS9IkTxIlU1IlLWIAKKElVxImweViBGAAatImbxInc1In d5Ine9InfxIog1Ioh5Ioi9IojxIpk1IplxIp0UW+uEEAEsB/DCABmNIqrxIrs9InAUAr/rvSK78S LIMyAQzAfxLgKZNhAPxnAM4yJuchANKSAPwmHQSAh+SyLSNCAPzHLrXhAMhyL++yIugyAbjhAAgg AcwMMN2hLwmALSkhABDgJRPTI9ISMcMgAOJSMkNiABCgMqUAMzNTMwmgM5/AAAwANEeCKm2o/E5z zhjTFwrzL1mzI/LSFwTANGVzJD5zFnTzpxasEmiIgRAIHY5RG28QCesBIL3RGNWxCfmxBQlyFWyT FmhTOH8zCjars1yInhQBIItzDKQQOaGTHBWyGPPQAqORGI3BNVnBACJzO73JOh9IPj+BlriTILvQ OM/zILoTE38RPfXTO/ETEZITCQZg/jBZYT2VCJkGC5SCqqV86qeaq7AgdELFCTglVLMylEExFDgJ SoYGEQ9BdAlF1BFL8DjZcETFEUXVkET3EBszcRh1MBmPEwcxURoBFApzEBLHMURNNAqok6MIAH4W lEMv60Ir9D3N6kgvNLGWVL+OFD6L1JmktBbrMBovUUb100f7kw6lsUtv1EYd0UrJUUBBVEtpVA7D lB210RenMUtn8UvFcwlEMzpvMzijFEntR0mfNEklFEqbCzupFI7q056caE8xtETHdDwVFQRP1BNr tAqnEBUh9UoV1VLT0BO/EEvNc0vPVE2FsEzZdDyhIEE/wUCHFE8NVU/9lE9X9VAH/vWZnBSx9AtP EUpVCyu/KhVTS9RGl9FRBzFTIzVYIxVYy7FXd/VYtfAeN/U/fVRURfVKubQcCTQJDCA2E6EmUbVV JzRVBbVPcRVRWdUJZJVICRVQW1WcfHBShTVZOdBRz9M/w9BEixVNe3AVyRRZGZVYPZBZedVZ0ZNT efVNCxIMEuBaEaE0tZVbb7Vb85RbaRVc8/RPV/VWVdVcEfV+qDRRMbVLsZELtRRaw7RdAXZSW5RL 81VdB3ZLkfVTz3Rgs/RN8fEOsjUUEuBA3+hBZzVJ4UmlUopJddZhBzXBNnS7DGxhHfSDKtAadfUZ QdZY8ZFlvRRg/bMfRTQSrRZG/pUWTpnTapVwRr10HilRTpOAZkGhbC1CaOMzXFeBWsehbUGCH53g bCthbiMibSmBmXzhbblhbzvCO6OgbhUhcC/CN6+zrl7RIrXhCRlycZtgcBHhcXFzMt2TbilXcjXT cgU3cwcJEe4Wb0GhcMFKHLKTI0i3clchcovBcxXBdMGgdY0pGxgWIV73YYshdfPgdnthdY2LPmmB dlkXYg+Cdn/3EHJ3ZjfXdQEVvyaogfDqXDUUeikUPpn3iZaLZ12VuYK2dg/KVnW2YoFWepcpYz00 b3PJQSuUfIk2Qgt1qIw2grAXaGUXD4zXDuhXQacUfv2USbNLYg91e8mVfxu2/nb7N2LR10i3y1C/ l4ANmIHJtYCdKnst1n/vlrlkNXujVIHl93hRF3mrU4Pvt4ChVIKJFIQJtUE1dnpfdVtJWIT39H3l V4G1V4a3d4VHuFbzd4EdOIW39X2xtYP1wH7f84PryYZFmIjTF4eFam29dTtHOIZZGGNduHvjl4h5 +L6emImvGHxzNsFgeGiXOHyrmHiXoCqj82Zh12EFuIij+E5veIYnNosX1IlXuGHzllVfWIh3Fl31 GIrZGISD11x1eIBDuIkVwVrr9LxQWH/3WFyldI37GFfheIZdNWKxmJGz2I4JGZM3GZkc+JG9mIkf mWJrmBJKlcGEFA8EGbfU/leJHzZnXzmsqPeBOzmTKRlp56k3IfaVdRmJORSAX2ptudeVe1l6Wdli L/iE0fdwLYFOV8GUm2WMNyKa92GakQBIa/aHj6Wa0RYkttkIypgVLhNaQvcjvHkeyLkJnvkTePNy Z9NOWeGa25kj2HkVEOBg5fkh4hmemxmfccyejWEs+/ki2tO5CCCbBZof0nKqIBOhHSItGzMRDLqh DUIqteEyDWA0JzqcSzOjxWAz71mj51KixyEv6Tmk0aGkIXoWSnotReKg0ZEmCeCQ3RIuZboqwxKn c1qnd5qne9qne3IsfcgsJeliflopudKok1qpl5qpk9IpO/qko1qqp5qqMavaqq8aq7Naq7eaq7va q78arMNarMearMvarM8ardNardeardvard8aruNarrkhCAAAOw== --------------476710285876250728770220-- From sip-bounces@ietf.org Mon Mar 12 18:02:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsXh-0006yY-M1; Mon, 12 Mar 2007 17:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsXg-0006xO-FF for sip@ietf.org; Mon, 12 Mar 2007 17:58:56 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQsXd-0004fL-Fa for sip@ietf.org; Mon, 12 Mar 2007 17:58:56 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007031221585101400s1n3ke>; Mon, 12 Mar 2007 21:58:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2CLf4GJ017667 for ; Mon, 12 Mar 2007 16:41:04 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2CLf4Mk017663; Mon, 12 Mar 2007 16:41:04 -0500 Date: Mon, 12 Mar 2007 16:41:04 -0500 Message-Id: <200703122141.l2CLf4Mk017663@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45F58F24.60801@cisco.com> (mat@cisco.com) Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> <069F0F09-F8BA-41EC-8E78-6DA4EAD49E35@estacado.net> <200703111855.l2BItuvY019182@dragon.ariadne.com> <4F873B53-CE41-4869-A5D8-76E98B7CFD97@estacado.net> <200703112305.l2BN51In004957@dragon.ariadne.com> <45F58F24.60801@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Michael Thomas Or more likely that nobody thought that yet another L2 substrate for IP was worthy of anything but a history lesson for somebody who thought that it was unique. The reality is that the US courts are getting less likely to consider a combination of previous inventions as rendering "obvious" a later patent which claims the combination. So if you really want to break this patent (rather than just whine about it), finding a published reference to such a system prior to March 1996 is the surest way to get the job done. If you *do* find such a reference, for a small fee you can file a copy of it with the Patent Office, which will include it in the set of prior art documents that is kept with every patent. Since anyone who is sued by the patent holder requests a copy of the prior art documents, if the prior art clearly breaks the claims in the patent, it nullifies the patent holder's ability to sue. But I find this rather curious... wasn't ATM supposed to wipe out this IP tomfoolery around 1996 according to the telephants? Are people sure that this patent isn't really restricted to 53 byte payloads of goodness? I'm told that a lot of data pipes are ATM below the IP layer, especially the various forms of DSL. But in regard to this patent, I don't see ATM mentioned in the claims, so it probably isn't relevant. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 20:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQv3X-0002Li-RC; Mon, 12 Mar 2007 20:39:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQv3W-0002Lc-Ly for sip@ietf.org; Mon, 12 Mar 2007 20:39:58 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQv3V-0003UA-C3 for sip@ietf.org; Mon, 12 Mar 2007 20:39:58 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2D0dkm01870; Tue, 13 Mar 2007 01:39:46 +0100 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt Date: Mon, 12 Mar 2007 19:39:54 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F90FBF9@zrc2hxm0.corp.nortel.com> In-Reply-To: <009c01c76470$101bca80$3f91460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt Thread-Index: AcdbarbTgoznNYBZRcqJyrGfl3IayQAFK0jgAX2jUhAAQuU48AB25GQwACWIyLA= References: <1ECE0EB50388174790F9694F77522CCF0F8915BF@zrc2hxm0.corp.nortel.com> <009c01c76470$101bca80$3f91460a@china.huawei.com> From: "Francois Audet" To: "Lavis Chow" X-Spam-Score: 0.6 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > 1. For Item 5 Line 680, It just mentioned that the Req-URI is=20 > SIP URI, but if the Top route of that request is SIPS URI,=20 > then as per the rule of [RFC3261]/8.1.1.8, Contact will be a=20 > SIPS URI. So if the intention is just SIP with TLS, then it's=20 > better mention that top Route is not SIPS too. > And another concern for this item is what's the implication=20 > by checking the top route besides the Req-URI. OK. I get it now: I'll clarify. > 2. This document had clarified the SIPS usage in=20 > Req-URI/Contact very clearly. But I feel that the usage of=20 > SIPS in Route, RR, Path, Service-Route is not clear.=20 > > A. If the Req-URI of dialog establishing INVITE is SIP-URI,=20 > is it possible that one Proxy insert a SIPS URI in RR? What's=20 > the implication for that? > Same for PATH, Service-Route of REGISTER message? Or this=20 > behavior is not allowed? That is a good point.=20 The first case, i.e., SIPS to SIP is the "last hop exception".=20 Like it or not, it is there now, so that's why it is documented. I will clarify that. The second case, i.e., SIP to SIPS was initially there to cover the "upgrade scenario" that was in previous versions of the draft (i.e., when the client registers with SIPS), but a SIP request is sent to it. This new version of the draft doesn't work like this because it=20 broke many things. I need to adjust some of the wording in section 4 on this because it also confused EKR who had also a comment on this. The net-net of this is that I do not see any use case for the SIP-to-SIPS conversion. In fact, it's probably a pretty bad idea for a server to do something like this because the receiver of the request will believe the request was sent securily, while it was not. I'll try to put some wording to that effect. I think EKR had a similar comment about " > B. If one UA register with SIPS contact, then Proxy will=20 > return a SIPS version of Service-Route. Later if the UA want=20 > to contact a SIP URI resource, what behavior is recommended:=20 > a. REGISTER with a SIP contact. b. > use these SIPS Routes and Contact, so it will mandates one=20 > proxy in-between to record-route to conduct the SIP/SIPS=20 > conversion, How he know one of the Proxy is willing to do it? I understand what you are saying now. I think it should work like this: 1 - If a UA registers with a SIPS contact, the registrar MUST=20 return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used=20 in requests sent by that client.=20 2 - If a UA registers with a SIPS contact, the registrar MUST return a service route consisting of SIPS URIs if the intent or the registrar is to allow only SIPS URIs to be used in requests sent by that UA. 3 - It is the responsibility of the UAC to use a Route=20 header consisting of all SIPS URIs when using a SIPS=20 Request-URI and contact. If the service route was SIP, it is done by replacing the scheme of the entries with SIPS. I can clarify this in the document if everybody is OK with this. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 21:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQvpX-0007rD-20; Mon, 12 Mar 2007 21:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQvpV-0007nA-D0 for sip@ietf.org; Mon, 12 Mar 2007 21:29:33 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQvpU-00083L-1H for sip@ietf.org; Mon, 12 Mar 2007 21:29:33 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2D1TLJ07154; Tue, 13 Mar 2007 02:29:21 +0100 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-ietf-sip-sips-02 Date: Mon, 12 Mar 2007 20:29:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F90FC3E@zrc2hxm0.corp.nortel.com> In-Reply-To: <20070311174518.02F141CC24@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-sips-02 Thread-Index: AcdkBb9T2yUStNk5ShidGJkeM5kSFQBBfP/w References: <20070311174518.02F141CC24@delta.rtfm.com> From: "Francois Audet" To: "EKR" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Eric. I'll incorporate your proposed changes in -03. See below.=20 > -----Original Message----- > From: EKR [mailto:ekr@networkresonance.com]=20 > Sent: Sunday, March 11, 2007 10:45 > To: sip@ietf.org > Subject: [Sip] Comments on draft-ietf-sip-sips-02 >=20 > $Id: draft-ietf-sip-sips-02-rev.txt,v 1.1 2007/03/11 17:56:56=20 > ekr Exp $ >=20 > Overall this document appears to be in pretty good shape.=20 > Some mostly editorial comments... >=20 > S 4. > Although not mandated specifically in [RFC3261], the implication is > that a resource described by a SIPS URI can not be=20 > "downgraded" to a > SIP URI by just changing the scheme, unless it is the "last hop > exception" described in Section 3. This specification=20 > clarifies that > a resource described by a SIPS URI MUST NOT be=20 > "downgraded" to a SIP > URI by changing the scheme, or by sending the associated=20 > request over > a non secure link, except for cases where the "last-hop exception" > rule is in effect (in which case the Request-URI would be=20 > replaced by > a SIP URI). >=20 > This document is targeted at Info, right? Isn't the 2119=20 > language kind of weird then? Yeah, I guess Dean also had a comment on this. Personnally, I think the document has to say what it has to say. I wouldn't=20 water it down and make it less useful. I have removed already the statements that ACTUALLY MODIFIED RFC 3261=20 (like the "deprecate last-hop exception), and the "there is an error in the ABNF concerning the transport parameter" (although for the last one, it=20 lists the error and says a further document will make that change. That=20 allowed the draft to get rid of the "Obsoletes: RFC 3261" statement. Good. It also allowed us to say "Informative". The idea, as Dean points out, is that it doesn't really change the essence of RFC 3261, but merely clarifies it. My personal preference would be NOT to consider it to be "Informative",=20 but, as Dean was saying, it's debatable. To me it doesn't change 3261, but it certainly defines requirements for supporting sips that are not described properly in 3261. Whether we call it "informative" or not, is something that we should probably discuss with the Chairs. =20 > route it to Bob at Request-URI sips:bob@bobphone.example.com. If a > request is sent to AOR sip:bob@examplecom, Bob's proxy=20 > will route it > to Bob at Request-URI sip:bob@bobphone.example.com (because of the > "upgrade" scenario described above, and the substitution of SIP to > SIPS). >=20 > This should be sips:bob@bobphone.example.com, right? Actually, no, but the previous part of the section is wrong... In this version of the draft, as described in a previous thread, the idea is that the proxy keeps the same scheme as the orininal request when it forwards the request to the UA.=20 I now realise that I've updated other sections but not this one. I'll=20 fix it in -03.=20 > recommends that if the UAC decide to recurse to the SIP URI, it >=20 > I'm not sure I would use the word recurse here or below.. Hum, I've used terminology from 3261 (p.98 for example). Any specific reason why not to use it? Any idea what to replace it with? >=20 > S 4.2. > Can you explain how each of thexe examples come about? Yes, I will. Basically, the first one is the "last hop exception".=20 The second one has no use case. I'll specifically say that it is NOT=20 RECOMMENDED. >=20 > S 5. > Furthermore, it is a matter of local policy for a UA to accept > incoming requests addressed to a URI scheme that does not=20 > correspond > to what it used for registration. For example, a UA with=20 > a policy of > "always SIPS" MUST address the Registrar using a SIPS Request-URI > over TLS, MUST register with a SIPS Contact, and MUST=20 > reject requests > addressed to a SIP Request-URI with 403 "Forbidden". A UA with a > policy of "best-effort SIPS" MUST address the Registrar=20 > using a SIPS > Request-URI over TLS, MUST register with a SIPS Contact, and MUST > accept requests addressed to either SIP or SIPS Request-URIs. A UA > with a policy of "No SIPS" MUST address the Registrar using a SIP > Request-URI, MAY or MAY NOTt use TLS, MUST register with a SIP AOR > and a SIP Contact, and MUST accept requests addressed to a SIP > Request-URI. >=20 >=20 > I'm having some trouble with this normative language when=20 > you've just said it's "local policy". Do these policies have=20 > any other effect than to implement this language? Those should be viewed as examples of Policies. I should reword it to=20 avoid 2119 terminology. Otherwise, I'm mandating the Policies which I probably shouldn't do. Good catch. > S 10. > Can we get a picture of the topology here? >=20 > I would break out the registration flow, which seems to be=20 > the same for all these calls, and then not repeat it in each example. Good point. I will do both in -03. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 23:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQxN0-0001zQ-QD; Mon, 12 Mar 2007 23:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQxN0-0001wY-3L for sip@ietf.org; Mon, 12 Mar 2007 23:08:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQxMx-0001sh-QJ for sip@ietf.org; Mon, 12 Mar 2007 23:08:14 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Mar 2007 23:08:12 -0400 X-IronPort-AV: i="4.14,276,1170651600"; d="scan'208"; a="115458388:sNHT46827352" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2D38BSi012640; Mon, 12 Mar 2007 23:08:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2D38BZn002033; Tue, 13 Mar 2007 03:08:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 23:08:11 -0400 Received: from [192.168.1.104] ([10.86.241.3]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 23:08:10 -0400 Message-ID: <45F6159A.9080003@cisco.com> Date: Mon, 12 Mar 2007 23:08:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org> In-Reply-To: <45EC200D.5010506@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 03:08:10.0897 (UTC) FILETIME=[D4EA6810:01C7651C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1626; t=1173755291; x=1174619291; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-02 |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=TxcVKrfDSm+wTGhC1dD6SoTWfcMIY6eUShu3nJEASig=; b=SX3N2IbJFnwS5bsB18S6Dpr0qSS0P6CdLtftFdfh7neNx/iEgg2YonGhG72r9+6Z6X6yaXh0 AhegRSCS9zt0FZMj89+NLlhq5mdXywZdNCY0iZJmPUwjmctZGDKiG/LP; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm with others that have commented earlier, I think this is way too complicated. I'd rather have a single mechanism that is independent of outbound (say, by rejecting a request whose response would be too big, said response telling the client to try again via tcp), and then have that apply to sip-outbound just as well as anything else. The client would open a new tcp connection as a second flow, register over it, and then send its request. What does the complexity of this draft add beyond that? -Jonathan R. Marc Petit-Huguenin wrote: > I just submitted a new version of this I-D. Until it appears in the > archives, a copy can be found here: > > http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-02.txt > > Changelog: > > * Added text explaining that supporting UDP is important for > subsequent requests (from an email from Cullen Jennings). > * Added text to explain that the same IP address/port is used for the > TCP connection. > * Converted all 488 to 4XX. > * Added text for usage of DTLS-TLS (It is in an annex, as Outbound > does not say anything about DTLS). > * Added text about delayed STUN transactions (Still waiting what will > be in stunbis-06 about this issue). > * Various nits. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 12 23:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQxWp-0003Io-Cf; Mon, 12 Mar 2007 23:18:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQxWn-0003Ig-UI for sip@ietf.org; Mon, 12 Mar 2007 23:18:21 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQxWm-0005ew-L2 for sip@ietf.org; Mon, 12 Mar 2007 23:18:21 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 1E9A93A0210B; Mon, 12 Mar 2007 20:18:10 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id EFA5E3A0210A; Mon, 12 Mar 2007 20:18:08 -0700 (PDT) Message-ID: <45F617F0.3050709@acm.org> Date: Mon, 12 Mar 2007 20:18:08 -0700 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> In-Reply-To: <45F6159A.9080003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > I'm with others that have commented earlier, I think this is way too > complicated. > > I'd rather have a single mechanism that is independent of outbound (say, > by rejecting a request whose response would be too big, said response > telling the client to try again via tcp), and then have that apply to > sip-outbound just as well as anything else. The client would open a new > tcp connection as a second flow, register over it, and then send its > request. Thanks for your comments. I am not sure to follow. This draft is not about responses been too big, it is about requests that cannot be sent to the endpoint, because they are too big and the endpoint only opened an UDP "connection" to the server. > > What does the complexity of this draft add beyond that? > > -Jonathan R. > > Marc Petit-Huguenin wrote: > >> I just submitted a new version of this I-D. Until it appears in the >> archives, a copy can be found here: >> >> http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-02.txt >> >> >> Changelog: >> >> * Added text explaining that supporting UDP is important for >> subsequent requests (from an email from Cullen Jennings). >> * Added text to explain that the same IP address/port is used for the >> TCP connection. >> * Converted all 488 to 4XX. >> * Added text for usage of DTLS-TLS (It is in an annex, as Outbound >> does not say anything about DTLS). >> * Added text about delayed STUN transactions (Still waiting what will >> be in stunbis-06 about this issue). >> * Various nits. >> > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 04:25:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR2I5-0005Zd-EO; Tue, 13 Mar 2007 04:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlLk-0002i1-Fo for sip@ietf.org; Mon, 12 Mar 2007 10:18:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlLa-0006kn-Mi for sip@ietf.org; Mon, 12 Mar 2007 10:18:08 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 29A6C2007A; Mon, 12 Mar 2007 15:17:56 +0100 (CET) X-AuditID: c1b4fb3e-af9eebb0000061ca-d2-45f561143b47 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 064CC2005E; Mon, 12 Mar 2007 15:17:56 +0100 (CET) Received: from ehrzgmw300.eemea.ericsson.se ([172.17.66.28]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 15:17:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Mar 2007 15:17:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Server receiving the SIP request over TCP client connection ? Thread-Index: AcdksTkTr/OLpvbTQQ6QPfW+FNdc+w== From: "Vlado Vrlika \(ZG/ETK\)" To: X-OriginalArrivalTime: 12 Mar 2007 14:17:55.0302 (UTC) FILETIME=[3A464060:01C764B1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Tue, 13 Mar 2007 04:23:26 -0400 Cc: dromasca@avaya.com, "Gonzalo Camarillo \(JO/LMF\)" , dean.willis@softarmor.com Subject: [Sip] Server receiving the SIP request over TCP client connection ? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0585232155==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0585232155== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C764B1.39183E82" This is a multi-part message in MIME format. ------_=_NextPart_001_01C764B1.39183E82 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, anyone having opinion (or any reference to RFC/draft) about what server shall do when receiving the request over TCP (or SCTP) client connection ? I know it means a weird behaviour on the remote UAC side, but .. my first guess is: it's upon local SIP transport layer policing Option 1: such request can silently be discarded Option 2: such request is handled normally, i.e. as it would have been received over server connection. My understanding of RFC 3261 and related stuff was "Option 2", as first option might lead to interoperability problems when transport network has poor quality and policies are not aligned. Old mail references on this issue are very much welcome. Thanks, /Vlado Vrlika ------_=_NextPart_001_01C764B1.39183E82 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Server receiving the SIP request over TCP client connection = ?

Hello,
anyone having = opinion (or any reference to RFC/draft) about what server shall do = when
receiving the = request over TCP (or SCTP) client connection ? I know it means a weird = behaviour
on the remote UAC = side, but ..  my first guess is: it's upon local SIP transport = layer policing
Option 1: such = request can silently be discarded
Option 2: such = request is handled normally, i.e. as it would have been received over = server connection.

My understanding = of RFC 3261 and related stuff was "Option 2", as first option = might lead
to = interoperability problems when transport network has poor quality and = policies are not aligned.
Old mail = references on this issue are very much welcome.

Thanks,
  /Vlado = Vrlika

------_=_NextPart_001_01C764B1.39183E82-- --===============0585232155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0585232155==-- From sip-bounces@ietf.org Tue Mar 13 08:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR5nZ-0003a4-6L; Tue, 13 Mar 2007 08:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR5ma-00032d-8P for sip@ietf.org; Tue, 13 Mar 2007 08:07:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR5jL-0005eW-T5 for sip@ietf.org; Tue, 13 Mar 2007 08:03:54 -0400 Received: by wr-out-0506.google.com with SMTP id 68so2473724wra for ; Tue, 13 Mar 2007 05:03:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=QzPCj7cCnMMPRwC7r9aZtlKVElaQGMglBNyvk0KVRiTKou6xVN2Tgr/vD034TFr6EKEsMX7WeBb4KzUdcetrY5PuEc2wd8TpytYxr+CEW/qsbNGda3d7E6rm2TMQ78n/cwI3WGLWfZIp1jXZHV+sP/eJvxodiqL4+pD4tqEb2XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=k990upZMRwdReEcCcEfAKxrVJ92lN8dqv5/1sSiF1W1hM+R2Vpb2by0llubUZHZikBH3SQoVKLmcLBxO0koxb4Z4Fwm9ze88PAczDtWnTib26+g3YfPYKY/9BUaVAqzZN+dDGuyGtKJaKgVrDpjCPBJ/qNjH4HQrRCxbLzEx5rs= Received: by 10.100.174.16 with SMTP id w16mr667888ane.1173787431532; Tue, 13 Mar 2007 05:03:51 -0700 (PDT) Received: by 10.100.109.3 with HTTP; Tue, 13 Mar 2007 05:03:51 -0700 (PDT) Message-ID: <1bf2eff0703130503g22285ff8l74b35e346de049a1@mail.gmail.com> Date: Tue, 13 Mar 2007 20:03:51 +0800 From: "Xu Chunrong" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] How does a UA work if there's no SIP server's on its network? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0800894860==" Errors-To: sip-bounces@ietf.org --===============0800894860== Content-Type: multipart/alternative; boundary="----=_Part_19104_6611697.1173787431466" ------=_Part_19104_6611697.1173787431466 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGkuLgogIEFzayBhIHF1ZXN0aW9uLCBJZiB0aGVyZSBpcyBubyBTSVAgc2VydmVycyBpbiBhIGRv bWFpbiBleGFtcGxlLmNvbSwgSG93CmRvZXMKYSBVQSBpbiB0aGlzIGRvbWFpbiB3b3JrPyBGb3Ig ZXhhbXBsZSAsaG93IHRvIElOVklURSBzaXA6Ym9iQGRlc2suY29tLCBpZgpkZXNrLmNvbQpoYXZl IFNJUCBzZXJ2ZXJzLi4KClRoYW5rcy4uLgoKLS0gCuKVlOKVkOKVkOKVlyAg4pSLICDkvZUgIOaX ogrilZHnl7Tor7TilZEgIOKUiyAg5YqzICDop6MK4pWR5Lq65qKm4pWRICDilIsgIOW8piAg55C0 CuKVmuKVkOKVkOKVnSAg4pSLICDkuIogIOS4rQrilZBTRVXilZAg4paTICDpn7MgIOWRswrilZBY dSBDaHVucm9uZ+KVkOKVkOKXpAo= ------=_Part_19104_6611697.1173787431466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkuLjxicj4mbmJzcDsgQXNrIGEgcXVlc3Rpb24sIElmIHRoZXJlIGlzIG5vIFNJUCBzZXJ2ZXJz IGluIGEgZG9tYWluIDxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSI+ZXhhbXBsZS5jb208L2E+ LCBIb3cgZG9lczxicj5hIFVBIGluIHRoaXMgZG9tYWluIHdvcms/IEZvciBleGFtcGxlICxob3cg dG8gSU5WSVRFIDxhIGhyZWY9Im1haWx0bzpzaXA6Ym9iQGRlc2suY29tIj5zaXA6Ym9iQGRlc2su Y29tCjwvYT4sIGlmIDxhIGhyZWY9Imh0dHA6Ly9kZXNrLmNvbSI+ZGVzay5jb208L2E+PGJyPmhh dmUgU0lQIHNlcnZlcnMuLjxicj48YnI+VGhhbmtzLi4uPGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8 YnI+4pWU4pWQ4pWQ4pWXJm5ic3A7Jm5ic3A74pSLJm5ic3A7Jm5ic3A75L2VJm5ic3A7Jm5ic3A7 5peiPGJyPuKVkeeXtOivtOKVkSZuYnNwOyZuYnNwO+KUiyZuYnNwOyZuYnNwO+WKsyZuYnNwOyZu YnNwO+inozxicj7ilZHkurrmoqbilZEmbmJzcDsmbmJzcDvilIsmbmJzcDsmbmJzcDvlvKYmbmJz cDsmbmJzcDvnkLQ8YnI+4pWa4pWQ4pWQ4pWdJm5ic3A7Jm5ic3A74pSLJm5ic3A7Jm5ic3A75LiK Jm5ic3A7Jm5ic3A75LitPGJyPiDilZBTRVXilZAg4paTJm5ic3A7Jm5ic3A76Z+zJm5ic3A7Jm5i c3A75ZGzPGJyPiDilZBYdSBDaHVucm9uZ+KVkOKVkOKXpAo= ------=_Part_19104_6611697.1173787431466-- --===============0800894860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0800894860==-- From sip-bounces@ietf.org Tue Mar 13 08:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR68R-0006rh-EO; Tue, 13 Mar 2007 08:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR68P-0006oQ-Ud for sip@ietf.org; Tue, 13 Mar 2007 08:29:45 -0400 Received: from smtp-1.hut.fi ([130.233.228.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR68N-0000vX-9K for sip@ietf.org; Tue, 13 Mar 2007 08:29:45 -0400 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l2DCSNtx031825; Tue, 13 Mar 2007 14:28:23 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 10006-21; Tue, 13 Mar 2007 14:28:22 +0200 (EET) Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l2DCS4DE031733; Tue, 13 Mar 2007 14:28:04 +0200 Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id 87B693A2CCC; Tue, 13 Mar 2007 14:28:04 +0200 (EET) Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12235-06; Tue, 13 Mar 2007 14:28:03 +0200 (EET) Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32]) by mail.tml.hut.fi (Postfix) with ESMTP id 03C4A3A2CD7; Tue, 13 Mar 2007 14:28:03 +0200 (EET) Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Tue, 13 Mar 2007 14:28:02 +0200 Message-ID: <20070313142802.lzjkmze0go8owgw0@horde-intra.tml.hut.fi> Date: Tue, 13 Mar 2007 14:28:02 +0200 From: sergiole@tml.hut.fi To: sip@ietf.org References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> <5741BEAE-07B2-43AB-A89A-34D4617B916F@ekabal.com> In-Reply-To: <5741BEAE-07B2-43AB-A89A-34D4617B916F@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Spam-Score: 0.2 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, > Thank you. I plan to use your wording with some minor modifications. Ok. Thank you for your answers. Now let me ask the following ** Q1. >>>> When an Edge Proxy receives a request, it applies normal routing =20 >>>> procedures with the following addition. If the Edge Proxy =20 >>>> receives a request where the edge proxy is the host in the =20 >>>> topmost Route header field value, and the Route header contains =20 >>>> a flow token, the proxy compares the flow in the flow token with =20 >>>> the source of the request. >>> >>> OK so far? The Edge Proxy compares the flow in the flow token (the >>> source of the register) with the source of the newly received request >>> About "the proxy compares the flow in the flow token with the =20 source of the request.", let me mention the steps that could be =20 followed to make this comparison and indirectly verify if I am =20 understanding what you propose. ( Assume that I am using algorithm 2 ): 1. From the received flowtoken I take the flow identifier (IP address, =20 port, and transport combination) and decode base64. Then I get "back" =20 the S array. 2. From S array I retrieve IP address and port and compare it with the =20 IP address and port of the newly received request (these are obtained =20 from the transport layer used to receive the newly received request). Is the above correct? (Assume that the transport protocol is the =20 same and it is not included in the comparison). ** Q2. In section '5.2. Generating Flow Tokens' you say { Algorithm 2: When the proxy boots it selects a 20-octet crypto random key called K that only the Edge Proxy knows. A byte array, called S, is formed that contains the following information about the flow the request was received on: an enumeration indicating the protocol, the local IP address and port, the remote IP address and port. The HMAC of S is computed using the key K and the HMAC- SHA1-80 algorithm, as defined in [11]. The concatenation of the HMAC and S are base64 encoded, as defined in [12], and used as the flow identifier. When using IPv4 addresses, this will result in a 32-octet identifier. } Note: "an enumeration indicating the protocol, the local IP address and port, the remote IP address and port." 1) Where "local IP address and port" are the IP address and port of =20 the edge proxy? If, 'yes', then why should we consider the "local IP address and port" =20 in every flow token if these are constant and do not introduce new =20 information to identify different flows? Note that the IP address or domain of the edge proxy is included in =20 the Path header, so in case that we have several proxies the proxy "in =20 charge" will be reached regardless of the flow token content. I can =20 not imagine an scenario where including these in the flowtoken will =20 introduce some advantage. 2) Where " the remote IP address and port." I understand that these =20 are the destination for the REGISTER (e.g Registrar). True? If it is true, then several UACs could have the same destination =20 (same Registrar) and we are not introducing new information in the =20 token to distinguish a unique flow. I understand that the main reason to include these in the flowtoken =20 to compare later with the IP address and port of the newly received =20 request as it is mentioned in Q1 above. How about replacing the following ? Original text: { an enumeration indicating the protocol, the local IP address and port, the remote IP address and port. } by Suggested text/idea: { an enumeration indicating the protocol; the source IP address and port (after any =20 possible NAT, i.e. the IP address and port retrieved from the =20 transport layer that carries the received REGISTER), the remote IP =20 address and port. } Regards, Sergio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 08:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR6NO-00011A-Rw; Tue, 13 Mar 2007 08:45:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR6NN-000112-Cv for sip@ietf.org; Tue, 13 Mar 2007 08:45:13 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR6NI-0003k9-Nj for sip@ietf.org; Tue, 13 Mar 2007 08:45:13 -0400 Received: from [192.168.0.121] ([80.198.124.2]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l2DChvN14453; Tue, 13 Mar 2007 04:43:58 -0800 In-Reply-To: <20070313142802.lzjkmze0go8owgw0@horde-intra.tml.hut.fi> References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> <5741BEAE-07B2-43AB-A89A-34D4617B916F@ekabal.com> <20070313142802.lzjkmze0go8owgw0@horde-intra.tml.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F7C061D-871B-453D-847B-C3D0BB35FAC1@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 13 Mar 2007 13:43:40 +0100 To: sergiole@tml.hut.fi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, On Mar 13, 2007, at 1:28 PM, sergiole@tml.hut.fi wrote: > ** Q1. > >>>>> When an Edge Proxy receives a request, it applies normal >>>>> routing procedures with the following addition. If the Edge >>>>> Proxy receives a request where the edge proxy is the host in >>>>> the topmost Route header field value, and the Route header >>>>> contains a flow token, the proxy compares the flow in the >>>>> flow token with the source of the request. >>>> >>>> OK so far? The Edge Proxy compares the flow in the flow token (the >>>> source of the register) with the source of the newly received >>>> request >>>> > > About "the proxy compares the flow in the flow token with the > source of the request.", let me mention the steps that could be > followed to make this comparison and indirectly verify if I am > understanding what you propose. ( Assume that I am using algorithm > 2 ): > > > 1. From the received flowtoken I take the flow identifier (IP > address, port, and transport combination) and decode base64. Then I > get "back" the S array. > > 2. From S array I retrieve IP address and port and compare it with > the IP address and port of the newly received request (these are > obtained from the transport layer used to receive the newly > received request). > > Is the above correct? (Assume that the transport protocol is the > same and it is not included in the comparison). Yes > ** Q2. > > In section '5.2. Generating Flow Tokens' you say > > { > Algorithm 2: When the proxy boots it selects a 20-octet crypto > random key called K that only the Edge Proxy knows. A byte > array, > called S, is formed that contains the following information > about > the flow the request was received on: an enumeration indicating > the protocol, the local IP address and port, the remote IP > address > and port. The HMAC of S is computed using the key K and the > HMAC- > SHA1-80 algorithm, as defined in [11]. The concatenation of the > HMAC and S are base64 encoded, as defined in [12], and used > as the > flow identifier. When using IPv4 addresses, this will result > in a > 32-octet identifier. > } > > Note: "an enumeration indicating > the protocol, the local IP address and port, the remote IP > address > and port." > > 1) Where "local IP address and port" are the IP address and port of > the edge proxy? Yes > If, 'yes', then why should we consider the "local IP address and > port" in every flow token if these are constant and do not > introduce new information to identify different flows? > Note that the IP address or domain of the edge proxy is included in > the Path header, so in case that we have several proxies the proxy > "in charge" will be reached regardless of the flow token content. I > can not imagine an scenario where including these in the flowtoken > will introduce some advantage. If the edge proxy has multiple interfaces or supports multiple ports / transport protocols, this can be an issue. > > > 2) Where " the remote IP address and port." I understand that these > are the destination for the REGISTER (e.g Registrar). > > True? No, this is the address and port of the UA. thanks, -rohan > If it is true, then several UACs could have the same destination > (same Registrar) and we are not introducing new information in the > token to distinguish a unique flow. > I understand that the main reason to include these in the > flowtoken to compare later with the IP address and port of the > newly received request as it is mentioned in Q1 above. > > > How about replacing the following ? > > Original text: > { > an enumeration indicating > the protocol, the local IP address and port, the remote IP > address > and port. > } > > by > > Suggested text/idea: > { > an enumeration indicating > the protocol; the source IP address and port (after any > possible NAT, i.e. the IP address and port retrieved from the > transport layer that carries the received REGISTER), the remote IP > address > and port. > } > > > Regards, > > Sergio > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 09:52:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7PN-0002i4-J1; Tue, 13 Mar 2007 09:51:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7PL-0002gH-Pc for sip@ietf.org; Tue, 13 Mar 2007 09:51:19 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HR7PJ-0005jW-A5 for sip@ietf.org; Tue, 13 Mar 2007 09:51:19 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2DDp5LG008280; Tue, 13 Mar 2007 08:51:05 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2DDp5M01931; Tue, 13 Mar 2007 08:51:05 -0500 (CDT) Message-ID: <45F6AC49.70206@alcatel-lucent.com> Date: Tue, 13 Mar 2007 07:51:05 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vlado Vrlika (ZG/ETK)" Subject: Re: [Sip] Server receiving the SIP request over TCP client connection ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vlado Vrlika (ZG/ETK) wrote: > Hello, anyone having opinion (or any reference to RFC/draft) about > what server shall do when receiving the request over TCP (or SCTP) > client connection ? I know it means a weird behaviour on the remote > UAC side, but .. my first guess is: it's upon local SIP transport > layer policing Option 1: such request can silently be discarded > Option 2: such request is handled normally, i.e. as it would have > been received over server connection. Some discussion around this issue is in the connect-reuse draft (http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-07). Accepting a request over a client connection may lead to the sort of attacks described in S9 of that draft. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 11:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Xj-0004m2-7D; Tue, 13 Mar 2007 11:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Xi-0004lx-0J for sip@ietf.org; Tue, 13 Mar 2007 11:04:02 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Xd-0006cj-Of for sip@ietf.org; Tue, 13 Mar 2007 11:04:01 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2DF3mWC032405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 Mar 2007 09:03:48 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: SIP LIST From: Robert Sparks Date: Tue, 13 Mar 2007 10:03:46 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sip] SIPit 20 registration deadline is March 30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you plan to attend SIPit 20 in Antwerp, Belgium April 16-20 and have not yet registered, now's the time. Registration closes in just over two weeks (March 30). See www.sipit.net for more information and the registration link. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 12:32:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9tV-0002MY-9L; Tue, 13 Mar 2007 12:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9tT-0002H4-3v for sip@ietf.org; Tue, 13 Mar 2007 12:30:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9tK-0000EA-OF for sip@ietf.org; Tue, 13 Mar 2007 12:30:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2007 12:30:28 -0400 X-IronPort-AV: i="4.14,280,1170651600"; d="scan'208"; a="54653298:sNHT237343672" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2DGUQTP026401; Tue, 13 Mar 2007 12:30:26 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2DGULa7011083; Tue, 13 Mar 2007 16:30:22 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 12:30:17 -0400 Received: from [192.168.1.104] ([10.86.242.218]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 12:30:17 -0400 Message-ID: <45F6D198.90401@cisco.com> Date: Tue, 13 Mar 2007 12:30:16 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> In-Reply-To: <45F617F0.3050709@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 16:30:17.0507 (UTC) FILETIME=[E29C4F30:01C7658C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2162; t=1173803426; x=1174667426; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-02 |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=0X4bwF49OgBtebnYfL2woGAU7pbOKOGqTxw89ELSAsQ=; b=RflRyfJxY5LonBjgePKAHrTBxTlQewnO08FMNx54W7TXadp3jkoro3stRH2yLlxXvmmYHFKy C+S6pqzqLYTTyUc4/fVr8LaKKvRlGfugD61j8g7Vi5BuLdkRH12c75v3; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ah sorry, my bad. My fault for skimming to fast. I'll take another look and provide some useful comments.... -Jonathan R. Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: > >>I'm with others that have commented earlier, I think this is way too >>complicated. >> >>I'd rather have a single mechanism that is independent of outbound (say, >>by rejecting a request whose response would be too big, said response >>telling the client to try again via tcp), and then have that apply to >>sip-outbound just as well as anything else. The client would open a new >>tcp connection as a second flow, register over it, and then send its >>request. > > > Thanks for your comments. > > I am not sure to follow. This draft is not about responses been too > big, it is about requests that cannot be sent to the endpoint, because > they are too big and the endpoint only opened an UDP "connection" to the > server. > > >>What does the complexity of this draft add beyond that? >> >>-Jonathan R. >> >>Marc Petit-Huguenin wrote: >> >> >>>I just submitted a new version of this I-D. Until it appears in the >>>archives, a copy can be found here: >>> >>>http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-02.txt >>> >>> >>>Changelog: >>> >>> * Added text explaining that supporting UDP is important for >>> subsequent requests (from an email from Cullen Jennings). >>> * Added text to explain that the same IP address/port is used for the >>> TCP connection. >>> * Converted all 488 to 4XX. >>> * Added text for usage of DTLS-TLS (It is in an annex, as Outbound >>> does not say anything about DTLS). >>> * Added text about delayed STUN transactions (Still waiting what will >>> be in stunbis-06 about this issue). >>> * Various nits. >>> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From Northwest@outta-sites.com Tue Mar 13 12:54:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAGG-0007Sv-LV for sip-archive@lists.ietf.org; Tue, 13 Mar 2007 12:54:08 -0400 Received: from host70-245-static.32-85-b.business.telecomitalia.it ([85.32.245.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRAGD-0004V1-W8 for sip-archive@lists.ietf.org; Tue, 13 Mar 2007 12:54:08 -0400 Message-ID: <000d01c76590$3369dba0$00000000@marchetto> From: "hits" To: sip-archive@lists.ietf.org Subject: Mexico Review Date: Tue, 13 Mar 2007 17:54:01 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C76598.952E43A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 ------=_NextPart_000_0009_01C76598.952E43A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C76598.952E43A0" ------=_NextPart_001_000A_01C76598.952E43A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hollywoods trendhalle aging gracefully having? Guitar unreleased image = albums singles vocals vocal. Amherst, prior associate, officer west = conducted? Orphans, wwo pledged ethiopia who orphaned hiv, plan! Hovering thempilot nope woodspilot. Croftjolie reprised cradle sequel lucrative borders aid. Tvgeorgia virginia, lawshe tvcornelia actressgia tvgia sag tinmary. Painted back separated one year good timing! District arrives union miss. Rented garage graduated heartand bejust = punk kid. Happiness draw, teenage crowds, punkd being. Under, youan company license content saalkreis. Url embed, step cjeviews inge inkieviews pkwviews. Refuge balcany outthe = area, climb, dusty! Flipping oreilly factor degrassi cnn. Wkslive wksmain, wk wksedit singlesrun bw harder. Confusing collegeim clubs antigua groove. Blanchett catherine charlize = theron. Felt performing them attempt, selftitled june hailed commercial! Earth, = airlines dimension certainly. Does this cooling, fleshy pulsating. = Beleve liemelissa, nickashton, turbulance force meanashton shot land = dead. Heading ghettoly refundable homeless anywhere. Used adds changes, = existing, possesses special meaning tennessee. Green ass cheeks yup, chicken partying catching. Tangled mp files peertopeer sharing. An sierra tanzania expressed. Of = seemingly clubscene hipster joan, was particular chronicle part. = Northwest flight toronto pmhulon lifebrenda airline tickets passports. Nowjose hulen tudae nojose cul. Downloads, stations guide cast. Lasered, husband chinese window! Readoption claiming motherbrad papers decision adopt, seeking. Husband = chinese window explained removed windows wishing. Offender put frontman video showed gimme shelter. Issues hulestha bethesda sleeppart hotelthey venture! ------=_NextPart_001_000A_01C76598.952E43A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hollywoods trendhalle aging gracefully = having?=20 Guitar unreleased image albums singles vocals vocal. Amherst, prior = associate,=20 officer west conducted?
Orphans, wwo pledged ethiopia who = orphaned hiv, plan!
Hovering thempilot nope = woodspilot.
Croftjolie reprised cradle sequel = lucrative borders aid.
Tvgeorgia virginia, lawshe tvcornelia = actressgia=20 tvgia sag tinmary.
Painted back separated one year good = timing!
District arrives union miss. Rented = garage=20 graduated heartand bejust punk kid. Happiness draw, teenage crowds, = punkd being.
Under, youan company license content = saalkreis.
Url embed, step cjeviews inge = inkieviews pkwviews.=20 Refuge balcany outthe area, climb, dusty! Flipping oreilly factor = degrassi cnn.
Wkslive wksmain, wk wksedit singlesrun = bw harder.
Confusing collegeim clubs antigua = groove. Blanchett=20 catherine charlize theron.
Felt performing them attempt, = selftitled june=20 hailed commercial! Earth, airlines dimension certainly. Does this = cooling,=20 fleshy pulsating. Beleve liemelissa, nickashton, turbulance force = meanashton=20 shot land dead. Heading ghettoly refundable homeless anywhere. Used adds = changes, existing, possesses special meaning tennessee.
Green ass cheeks yup, chicken partying = catching.
Tangled mp files peertopeer sharing. An = sierra=20 tanzania expressed. Of seemingly clubscene hipster joan, was particular=20 chronicle part. Northwest flight toronto pmhulon lifebrenda airline = tickets passports.
Nowjose hulen tudae nojose = cul.
Downloads, stations guide cast. = Lasered, husband=20 chinese window!
Readoption claiming motherbrad papers = decision=20 adopt, seeking. Husband chinese window explained removed windows = wishing.
Offender put frontman video showed = gimme shelter.
Issues hulestha bethesda sleeppart = hotelthey=20 venture!
------=_NextPart_001_000A_01C76598.952E43A0-- ------=_NextPart_000_0009_01C76598.952E43A0 Content-Type: image/gif; name="Svetlana Natalia.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c76590$3369dba0$00000000@marchetto> R0lGODlhgAHYAYekAAAAAHIAAACAAHyGAAAAi3cAjACFi861tbnOzrPM/UQjDlQpAIokAJsYDLso ANoiAA5AABo0B0k8AGs6CoFAAKk4BbVEAOwzAAJVBRplADlYCmxRAIRZAKRnAL1rBe1aAAt1AB19 AEB1BFd4AHdzAJ+JAMh0BtaMDAyYAC2mDD6kA2WfAHOUDaCmCLeYA+mqAA7KABHACUW5DmHNDoW8 Apu+Ar+6DNfABwbSACrtAEPnBVvlAHbXB5HuBrrlAOPmAgEAPiwARjoAOmULSYgANJUAQcEASNoA PgUrPSQYMzcfOlgjQYIiNpErSscuNNoWSA4/TRo9RkI1QWhEPntBRqg5Q7ZKTuJJRABbPhJcNUld N1VsRnNoAKZoRc5fPdJZSwB8QCyIOkZ2TFtxQ4CEQKB7Q8R7RuaMTgCYMhGqSjepN2uSN3WuOaak QrGXSuyRNQPNOSK4PTjLPWjOOX7ANpa8PLnDN+XFQQrdRhfXPjvURFjUNoDjQqDmM8HbQevUOwAA hxoAeEsAfGALi4sNjKcAgcEAe+cAcwAcchcqcT0XcWoUjYcZhqkqeMsdgdsecgAyjihBckNOdGA8 hoI5hJxMgLVCedRLfgFdgypcjDJlgmlteohfdaRaibJie9ppdAiGgyOCi0qKflqDdHJ1cq5xcrJ7 iOp5iAeTcyCajjeXiWidioGfja2Yic6UgumViQzKjSO0g0C1dmW0cY69f5i+dMC/c+G6iQDZfCDh jT7pc13deX3UdaTVgLvgfNPieQAAzRMNwE0IymIAzosKuZYAzbgKt9sAvAkswxstw0cXtGAqxYwh wpUhtMsRs9IbxwBDvRlOtzJBs2k3xYROw5xOvr1CxuNMvw5nti5RvUVTxGZqy3VXsZ9jw7VlydxV ywCAzCFyvjx9um1xuHJxw5h+vcR7teeNxgSXzBmZukKezFelyH6guKmgxMutzNiqsgCxzCe5zDfI uVTDvHrAwJyysvX/8ZGlpnR4jvQMBgD/AP//AwsC9P8A9wz///D//yH5BAB16C0ALAAAAACAAdgB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkEnxczgZ Ib/KkTMnxCx5JebJnBWCNhj64eeGl0trdstZNcnQrklbphh7Ye3VaFsLTL17YGXeBYGPlnzZd3He w4ETTJ38+HHfxIvvdt78t/LeuOEylw799GnovaV7/1/evTP286N1ozffWX378uuzaycf/bf57cuZ s8fvPr1+8O9x99174dFH4IH2yTcffPc1eBBsAJ6334HBMfjceuMBOByCEirIlm4DhmjghhliOKGG 7HFY4Iomsnibh2ep91+K102XoI3GWUdgjfW1J15+F94nXnXxvQjjkUgmqeSSTDbp5JNQ4mRkRFNC VGWUfF15JWUeGbkllmtp2eWYDH0JZlqwCfgjjcrVmCBobf5oXWnC4RhdhGfa1d+EG7ZII3Yk8nnj nn1+Z2aeZhHaHZ0WkpeeoMjlyF19/kl6I6J1KVoghC46GiCD8ck2Yp8dYiqXpjuOeCKKfDYqYYkq mv96139xDsoqj4aCV2eOpMmp5oCyBivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWa++9+Ob7FwA18asvVwAEzK+/IBH80MAOGfyv UQor3JHDDEGckMQLA+WwwAQLPJDGpGC8ccAfDwwyQRx73PHJJnc88skVM2xQxizHLBDCM8dMc80F wawzyhvbjHPLRF3cM8b+eqyz0TDnPPTSN4tcMtBFCV1zw0tPfRDIUvNsddMy/wy1UFRbLbbWZBt8 c89jI8x10l8zrHHSHKuMddwlr7zyzCPvzLXcaLf/nRXFfhsGeOCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eacd+7556CHLvropJdu+umop6766qwT1g9G/bw+kewZDa6R7YfHHjsptBP0eu8G 6Q68QLQPL/zwvG+EO0YZp4x33cu7i3zwC00/UPEIWW+9RNFXZHRDe+NrPPG7Jy+77r4HXz766BfU e/vCX19+yPSj/TTLDdt9d9VdX/1z9+oaX/p+l7yDwO96BUyg+wyYQAIq5Gz8o1nREAJBpTVvfySr X74EGD8Czo+B2MMeA+W3uxAiD2kv85nauobCiWEQYmwDYLrGF8IGTs+B5kPgCBvIQ/Jl8H9mUyHP /4IIxImx0H//+xfwcOjB9IEQgSKkHvGgqMMp9o2IaUviD2VGsRXijG0+UyL7yFdC832Qd+1D4/l8 J0Ay/g5+Z5Sb05TGNy2S7G0YfN4Fr5izPLbOZX8UiwwDSchCYksf+ihJIksySKAtkhSJfORFEIlI hkjyIZd0SCYLlsKX5c159nrkJisiyoWM8iOn5EjKXtg3r4VyIJEUCCVhOctYQrKSBCmlLWd5y0Xy speyrKQvcUlJURKTJGerIBgbia5dFsSWkLylQSSpS1/CMpqyvCY1c4nNaJaSm6m8XRizhsV8ObOX 0IQmOnPJy296k5a1NKY255nNdYbzdp+Mmx2Z2f9MbKazm/+sp0AFqstrTlOe/yxoNu8pznLus2UK fedCDdrNigKUnhel6DsjmtCHejSMFtziBL/oSIMWM5jCZCcuB1rRdqoUpTD15zHredJFxpCPH9Uj HW1mN8cxFCz8VNwv1xJUQxr1qMaKo0O2F5Oi6quGGomfFBXoRuQxFSZZ2ynQopgRpnLViTu8ySph 6NQZUlGNJGwiWsFKQjKula1wnF8aW5LM/rmyZQ5cIg/juMT1nZWqVRzgX7E6Tgr6La9u3CsblZrD KX41sB2E4lVPAr08ltWsa4RqY3tIPc3esIpMlJ9M6orEtnlWsVYErGP/+tnUhlaHN/1obEGaQSz/ OnSrOpRqZNO62OL5VbQL5K1u5zfb4uKUtnLc6R4jN1mggm6uarksUqdL3cP8VJCTq+lB1BndkFm2 aKB8pSXf8j0jlvZemRymNdV7lvB18r34Su8zN9rdC15Mn3all3zt6c3rbgW/R7SjOad50XT6928B Pq50w3XJjm5TpAqOsGwlDFLj5pRp9tPigsWlXf5GcqUUtnCFQ0ziCQs4uc+7Yk+rO5QNs1gnLn6x jGdsrxjbS6oV0d5gmWK2F4a3Ys29yGOXUt4EH9aA60vjAfP6QagqeYznY2xT7Rq2wLUxtCZc7ROp iuU29ouF9/WjEt16vL3udrMLXKMasdzbnAC4/4umFSxYceha1TaWzVrmrFiNrFXc5hnPm6VzcAON 2h6K+NAlDincTrzVuNZ5rSKEbg+HW0bejtjEl860TlMMRBtrLshfpnH1pMwTT4v61KhWl6njddK8 VLmPy9XXgdliMstG8F/pJaYwjTnrqUBwcO6N70wlak1ujuXXLtRgxTrqT5T2Wir6BDZyZV1gmmaU LMFOIRhxXe1mfxPRmAZ3psW97Sxm2Nzm/KVLm73OcSea3O+O9x31F0N6p9rN937KqvPN736jxarQ plyZOQLwqPRYYvbdt7ZA/ZCC6/ttrcTbecesZUfL9eJJVrNTKkhl+C7Mt521ol5Py/CfKNOwff+m uAJ3q+YzA3rjd4PzFvEK2rNmlrWF1jf+HphylUcRsYQmebjl7e6ha7t/5VQ4t7jKcpHHNcpqhrfR i071TROt0xH395S1nhSlc/3rYD+W19nlX+6W5dX5rezYmzXrZ1el1j0uLdpZ/cxhx7KWMnU7UpA9 8+Pm910Plih9g0ng//IZhq1cO9tVesz1arTV/415z1H8d8AbG5wTJahGtRJsad9VXoF3Z0AzKnWq l770tY24Q8s9r1YP9ZsphadNiX562lN403XMffP6HnaTKL734gS+8IdP/OIb//jIT77yl8/85jv/ +dCPvvSnT/3qW//62M++9rfP/e57//vgD7//q4Pye/DJ68cRg/jRzT82ykIEYvmIfz4GIv/5CyT+ BLE/zxd8W7FnfSG443mM5nvvZxD6Rwrzd4AJeH8MGDEf0X/GsjPohnScJkGSx0fgZV9a82b5pIHz loGcdhALSH8I2IAH6ElYU4H5lERwN1LLUmu3lnVU40V9JkEhNTVZlXoTKIFkgxAjyID294Ny14O2 JUTtV36NwYMTNHcZuEL0BoMjVWTJhF9SSFtHo34+2IAmGIT3d4JCtGIseGsQWCxK2H4UqDcf03c2 WIazZYRlA2Fz14UkOIf5V4J2iIFpWIRsyHv+h26Ip4NDNHPk5Ibho4cxGIZmqIWKeIJceIeI/3iE Ysg/zzJWYAhrFpiCc8R7cFNZXESFWNiElhiCd+OFClgQjeiF30M3K6hTm/h504KEAOh+DVF/+IeA 8meK+eeFgQOLVyNmquSL4heMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2JiN2riN 3NiN3ogpqxaHPMd+FMGLvOgkbdiLKciHtzdxhchnRtQ9rPd/HlFW5yg4fudx8piP+qhp9Ohx5Ag4 +2aPyhJbVBiKKHOQGpY3G/iJVdOCKOiEojg3NHhwIbiQLkiDlAc9KqNB94iPXrRt9xOIriSRKrSE GRaShAiHHemGK3l7e4iDymWEKElSBUmSV//nP2hYkjgZiSSlkld4gSQpR6S1c1UmkjuXRYMogUsI gzepkrG4k0cElW+4aEApiSyJlDjFd8hlg0r5XmvzkwAZge0YieVmXGX4UGkZhjdVhHeVjiPGg3go NjVZeWSYePvjlEMEYFbIkF9EN1vJkaE4hcu1jlQGgvClioYZmFH4l/M4Lh+pEswUmarWFZP5jZiZ meQndo9JebHoPetHgGBZgOWoSgfDmf84bRMXfC6xdr9HmfuSlArpmPQjmEV5iQmJcE+DmHUEcWrD kYgJSry5katIl0/4hfhznGRZl0nnkm15lERYeUfziJ34ldbJRR13nWm4knqTkaopKyi5TID/eJtY SZct2YOjmXDnaYjX6V4ik57lqZ57KJ+piSjhmXjjiZ3U+ZB5KJ2HeEf6WZU+GaBCGZYzyZJbo3r1 mSe7J542GZ376XcaCZ1tSJ4x+Yb4OZfoGZdmqaGw6Re7l3u4p3ufVIEol5t/WZIj2Zv2FpT92Zv4 OZu8KZQk2oFEqJyLI44X8aEJQzo5yJpgo5lCOqREWqRGeqRImqRKuqRM2qRO+qRQGqVSOqVUWqVW eqVYmqVauqVcqjw7KpB2SY6mApeiKRGt8SvGgSd6JEN8aVgc95n7xzwO2CRkykgTISCN8ibmFRGd CWF86oBFZTs82l0YGZHjxJDBaZv2Jiqt/7IipKJVnKiGhxqehpk/wwmjB1eTirk3eHSp8mGSDoqh QyM0a5ltImIolzKaO3iDUymq7OmmBNqSF0qeSgKqzpOWRZZcSog0AHaqeKIjqiqqreqYJmmGculd EOqq3ClSg3p2PTmEszqgOroqgeIpKaKWGSqtQ4mex4qcHqqtq9esxwaT4PqtbZl1vvoqgBKsnXdu AsqVGoqHrxqttyWu2OU1HGijuvqBhzqRDlMrvDIq5xWpsMav+wpe/7eiyEqYLlijoMiiIios9spJ cAqaFIsubfp24MNPNjaxXfqxIBuyIjuyJFuyJnuyKJuyKruyLNuyLvuyMBuzMjuzNFuzNv97szib s8qCH8TxINfBs5PSs8FBJ3CyHdThJkYbtEilJkLbK/mRpmjqtEPbtFNrJ1Q7Y0ELJ5bxGRAyJK6h tM6xtU87HaemtGTrs2frtDySplNrtlTLtKLmtnILrL2ytmz7tHM7tlf7YnmLtntrI7eRtMghuE07 KYJ7KKTTt1I7t3abtlD7tTx7t1gLuWL7tz3buGCrtX6btYirOopbtX1rt5lruXDruJNbIYqbtYVr tqObuqVLY3FCulzLtW87um1LuQHrtnxLK0YLuEAyJEObJmpLuJxbtL2rs8ibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veA9G77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AHMACPMAEXMAGbCwBAQA7 ------=_NextPart_000_0009_01C76598.952E43A0-- From sip-bounces@ietf.org Tue Mar 13 16:47:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDsW-00061T-JU; Tue, 13 Mar 2007 16:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDsU-0005yE-Qq for sip@ietf.org; Tue, 13 Mar 2007 16:45:50 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRDsT-0007YN-G0 for sip@ietf.org; Tue, 13 Mar 2007 16:45:50 -0400 Received: from [10.89.20.146] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2DJphD8003725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 13:51:43 -0600 Message-ID: <45F70D70.2040007@softarmor.com> Date: Tue, 13 Mar 2007 15:45:36 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> <45F6D198.90401@cisco.com> In-Reply-To: <45F6D198.90401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, Marc Petit-Huguenin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Ah sorry, my bad. My fault for skimming to fast. I'll take another look > and provide some useful comments.... It's still way too complicated. However, that level of complexity may be required due to the underlying complexity of SIP and multiple transport protocols and their inherent limitations. But I still wish it were simpler. Making it simpler, however, probably requires re-examining some of our more basic assumptions. One approach would be to fall back to using UDP simply as a register-and-alert protocol. In this model, user devices would "register" using UDP, then receive "imminent request" messages that would cause them to setup a TCP connection ala outbound. (Not too different from what Marc has now). One could conceivably model the "imminent request" notification as an event package. The difference here is that all traffic other than the registration, related registration-events, and "imminent request" subscription and notficication (the two event packages could be combined, I think) would go TCP. So there'd be no run-time sizing, Path-MTU discovery, or related complexity. Bonus: We'd get to keep the high fan-out property of UDP edge proxies when we have "mostly idle" clients. Note that presence would sort of break this, of course. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 16:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDwS-0008HR-5d; Tue, 13 Mar 2007 16:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDwR-0008HM-Gz for sip@ietf.org; Tue, 13 Mar 2007 16:49:55 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRDw9-0000EM-CR for sip@ietf.org; Tue, 13 Mar 2007 16:49:55 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2DKnWdK006432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2007 16:49:32 -0400 (EDT) In-Reply-To: <45F70D70.2040007@softarmor.com> References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> <45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Tue, 13 Mar 2007 16:50:13 -0400 To: Dean Willis X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, Marc Petit-Huguenin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Bonus: We'd get to keep the high fan-out property of UDP edge > proxies when we have "mostly idle" clients. Note that presence > would sort of break this, of course. > I'm not sure fan-out is still such a big deal. We've run systems in our lab with 440,000 simultaneous TCP connections, with a stock Linux 2.6 kernel, with some parameter tweaking (and a fair amount of RAM). Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 18:45:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFfX-00089y-Kh; Tue, 13 Mar 2007 18:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFfW-00089U-4H for sip@ietf.org; Tue, 13 Mar 2007 18:40:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRFfT-0004rp-Pv for sip@ietf.org; Tue, 13 Mar 2007 18:40:34 -0400 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2DLhugt004247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2007 15:43:57 -0600 In-Reply-To: References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> <45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <573452CB-0CFF-459B-AE2A-6261A9ACD93C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Tue, 13 Mar 2007 17:37:51 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, Marc Petit-Huguenin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 13, 2007, at 3:50 PM, Henning Schulzrinne wrote: >> >> Bonus: We'd get to keep the high fan-out property of UDP edge >> proxies when we have "mostly idle" clients. Note that presence >> would sort of break this, of course. >> > > I'm not sure fan-out is still such a big deal. We've run systems in > our lab with 440,000 simultaneous TCP connections, with a stock > Linux 2.6 kernel, with some parameter tweaking (and a fair amount > of RAM). Well, my fall-back position is to deprecate UDP entirely from SIP. OTOH, I've seen UDP proxies, written in java and running on stock, un- tweaked kernels, supporting millions of SIP registrations. Of course, not with "outbound" keeaalive and all that other traffic . . . So I suspect that, from a practical perspective once we're talking the real world and not a rather rarified mobile singleapplication environment, that the scaling of TCP and UDP will be on the same order. -- 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 yaxoqixuroipy@tie.cl Tue Mar 13 19:20:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRGId-00022h-18; Tue, 13 Mar 2007 19:20:59 -0400 Received: from [190.82.33.251] (helo=tie.cl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRGIY-0002VT-BJ; Tue, 13 Mar 2007 19:20:58 -0400 Message-ID: Date: Tue, 13 Mar 2007 12:10:09 -1100 Reply-To: "Genevieve Morrison" From: "Genevieve Morrison" MIME-Version: 1.0 To: "Mariel Kelley" Cc: "Camellia Berry" , "Elton" , "Lacie" , "Mana Reyes" , "Janella" , "Bee" , "Venetta Boyd" , "Lemuel" , "Monique Smith" , "Treasa Hawkins" Subject: How's Everything Content-Type: multipart/related; boundary="------------644383717147182732830847" X-Spam-Score: 1.8 (+) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 --------------644383717147182732830847 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


"I am rose going," said hearing Albert, needle as he language made his parting  "It mist impossible force was his Cornelius Nepos that smoggy Master Edward was    "He gave train nod no other crooked name," ripe answered Julie, looking e"The fact itch is, understood stroke count," train answered the mother, agreeab   
church "Really," said picture Albert, "I do harbor not strove know; when I invi    bake "What preserve letters delicious were marked on hungrily the linen?" said Mont  notice "An H and owner an N, surmounted glove art by a baron's coronet."     
perfectly broad nearly "And sprout you think him capable of being exact?" demand   
"Upon my word," said Monte Cristo, screw man cough "Paris knowledge is a str"I think touch rejoice so, madame, because hand I cloth myself have made us"Which bled is evidently neck not his real name, upheld dead but a ficti"And set your succeed forgo night precautions were successful?"   
"I meal think linen him nerve wide capable of everything."   "By heaven, M. Bertuccio, dealt you advertisement make voice country use of heraldic     "In your shaved service, upheld print excellency, encephalic where everything is    
"Well, with sack love the five minutes' grace, flame behavior we have only      hushed "That divide spill shows eaten that the Eastern nations have too much"Completely so."Then, drove point noticing that loud Julie was very struck with the soununderstood "Indeed?" said the heat count with tongue light an air of surprise,      
forego shaky "I force beg overdid pardon," interrupted Beauchamp; "are there  offend reach "Go on, I cup quit am curious to know two things."  "What stage good are force overdid they, your excellency ?"       
"Go stomach on, then, for I wed see calmly I shall not get discussion to the Cha         "No," returned Monte Cristo representative "I only instrument door speak guessed. I kne        ice "What? why, sign pedal yourself, to fed be sure! You give away ho"And harbor that miss whip is lock the case," observed Monte Cristo. "I"He stung was cat an faithfully eccentric way being, and did not believe inmove "Certainly; it division being at slung feeling the same time perfectly un  
"We taste breakable inject regret know that," said Beauchamp.    "I thought you did; stain bless terrible I must wrong have been mistaken."     "The second was stop the crime art of sadly bound which you were accuse     
"Why, in the forsake arrest first place, I smote heard existence it from Madame Dtable "Oh, very curve easily. desire Suppose wreck you knew beforehand the"He did night not fat obediently credit shy it at the period which I knew h"Precisely, adorable madame," replied admire Monte ask outgoing Cristo; "but I      
"There delay are recognise no quality veracious bandits," cried Debray."What war mind matter? you know burn I smell take but little sleep, an  learnt poor spoon "Philosophy, curtain M. Bertuccio," interrupted the Count;      "And sung I say to you, opinion fabulous as it disgust fiction may seem, I tell  house drum under "In what part shop of the house?"epithetic low "Do you know fit wound any other counter-poisons?""In the name of whistle division weight heaven," said burst Maximilian, "if yourhythm "I have often read, and look dress read rapid again, the history of 
"And ear keep held I did more than that," coloem replied Morcerf, "for    melodic "This," juicy insurance said Monte Cristo, "is less irritably correct than y     distance repair "Alas, your angle excellency brick is right," replied Bertucci       & nbsp;  
"No, suggestion fact he arrived dam accompanied repeat simply by the guest I"True, bred sir. The two attend favorite studies letter ship of my youth w          --------------644383717147182732830847 Content-Type: image/gif; name="okeq.gif" Content-Transfer-Encoding: base64 Content-ID: <232F9D18.18F6C01A@tie.cl> R0lGODdhjAGOAYQAAP///+jf0u+ysueUlNlOTsUAAN5aWu7u7MwzAAAAAP8AANbW1rm5uZrE4oac 20+QwyJhpWh9wY+UmGZmZs+yhdimbc6SVbWSZqV1O4BPIv/YfFpSWj0vPrY2CwAAAAAAACwAAAAA jAGOAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgs3gKCgHHJbDqf0KhUJRAMqoSC4TDt er/gsBgYUAIO2QLCikCYR4eBQcAd2+/4vP43IAxGAwWCAgACcyQHBmpWc3V7j5CRkmIHSoF/IgII ggOVAY4AgQV/mmuTp6ipqj59dAYGI5qcrSQBm1oiWYSrvL2+v4Wui4ZmtoKvo7W3yXJ1cbvA0dLT U3FtSIIIV2ZoggQCfiWKglqfIokFBKDU7O3uOwFpBXRp2iTjbmV0Z0ny87EI5hjo9K6gwYMt4pFb I2rRCHyWvoVSp/DYCCShjq1DyLGju4pq5JAjYEbUGlmE/nQBqIgJ0MJ9HmPKlAZSC4E0mPAZCqhE ESx0/2KRG0VrptGjqUCuSQMr1IArni7KMRTSkSxO3aAh3cr1S4CnUEWA7IerRaWpteTB0tSyq9u3 TcAtPLQyDYGVSWockOtNSRW4gAMT2TnU1EpFJHFcVfMm4V8mCSJLTnBC8iPKLSZbLrGZ42QanQGE /hLnT4Bx2Xbt1VqjouEVe8G2MdB4iObRoiNLwpzitm4SuN355v0idPApxv5YG7kRx+myKSotnzdu i5HNn1UdH9HZ+G+D3b8XF4/HWLK62WrreIbiQCUC2q4OMN9WSHjiuYlrNrGff3bu393XX37b5Qeg frdx/pbggbkBlyBuvvnnHWbbjTbhgCJMmGGEChZ4A1DlnDEOa0N8RYBA6XyV3jiJ2Saehgf+R+CF Mt4XY38LVvZigMPd+B+GwwHZo4+8YUeeg/jR+OOORQ45o4c2LCYRAAa4UUQVcZBDCm1XVUEOiT7A uGGTZI7JoJloGphmdjaq0OaYFB55JoEdUvZZgW+Gp6aO+O1J555issljmUA0dEwVYO7giSydMHWG Et1oEWlT9jGJZIwS9mYpmoEOukKQl6YJ55tnGpkkh3jaKaeooua5KaC/BdknDwMsM4gQO/lRqzoC pPaUCKKQJAqlQQgY6qiE8hkqqW1CyeGxAg4IYazU/iKI6qobNqjpqdzO2Smhd8r4gxXw+dHch19Z oeVKnZhnAHx+3VLFJsQCQaqfmPpp6rKeelstC6mCu++cpf4L55qvYpjpsQgnC6vAsxYhnQ+GDIQA SSxGReUxte7CVDf1hTmotf7GSabJJhfc78OfYstywwRzajDMDZ8M8Mo067uyqxHzgARMOZzVB8cn pfZKJn1VYUlq8Lr4bKs5PsmktE7yjG3AJec4bco6P+0kq3wq/HLXJSMpLhClWPfhK1Uik+I2t8Bn JUt1zbeJU4ny8DWrYos9o4SqQjv1tm7iHK7DMnN9qYVna5tZ4zwLjrjfN1ihXq9WzhCbe/D1MYe8 /ufg8+4uGff6zU20Caa6pm+Z/pTSwKodA19bnMbIpC5xos9eRpdTxurAm92zTIZmc2JeLlSSu0ZP KW9SMXFXoo0x2jQf/PX5uoXaUKm5AM6U02lBjFi3tPRSIN+8AjT27AeWyE22ds9CpOoARA5dIlQn FCdVdnJu+wDsyicqwQj4MMYEaKhNQ1pCGE6QoFcOKcQmTqKeAFpwdbEhyDnK0AdzwaEeZhgIX86D nhQd5goXTKEKc1UrB2aiShYphGlAeI565E2FOMQearx0QCqJxCGJIATd6uKH2lTshjlMokyOmIny GaNFcqhI/ZohQUmJpTmKsAcTlchFjvxuYybM/kiKFNGSqciDFPYoxEBWEA/aZCkbIeuiHKVRK+ss sImLQMwuKmbARaDvfybAiBiHgsQ5GjISX0FaUyJlpUmZhBCGoEND5oDCFzzlOSOpIyAPyck8wLAp v1Lj/fLXO0nFA5IXm88MAmErK1lhk52MpRcYcZX6fcUSPzQFBEexy4GkgwvmoMFiHJIuWRrTDrJJ BwQNg0LL3eInTJEiWnLAlzXs5RrHzOYXerWWTdAnE6ToxA4HeYWbFPIFdfhZT2KozXZCoRtNMQQY bcmlgfSRJJgLh3t2AA5VPnCa7FCAQAXaBAWowKBGQGgRFMoVWWQOWPJ73RzUdaiw9KAbaewI/kMZ SgOEcvQEHyVBSEsw0jyUdInlE0sSUqpG20kwIOvrwWmucM5pcPSkPTgpTgGw0zH01IvPPE1AxFi/ SP5yNbCMEl0GktRo3HQEAzWBQQkKVapGlaRWxapHoQpSgip0qjzdKFVJytOwgpSrYf0qWsHK1bGC 9apqFYFHx5rWtuoBKGvwSSG0lIg5eDAWFXROFkzhk58d5KlllStWFZvYxH5UrRu1a2OlytiyZrWx jzXrZCvLVse2la6anStZ42rZta71p1NoSD8SoxNVrgMNLVLU9q7wiq9k1B2IJS1nd7vZzUZWpL0F rmK3yljdDheto+VtXDNbXMqWlq3M9ewj/ioCi0AQYi+1TUGwapq8oY1kj2po6ipyi1zlmpaswq2s XEGL3tJidr1XBa5xj/ve+kaXuMJ9K2bdOlD87sGhSHjoChbjzyPsApPdY4tByKte+543vepl8Fnp u9yD1je5Dm5ue/3bXP2iN7qPkIUIXQASv8YRnbV6TQvv95iC/PbC5tVwejv7Xg5D+KvEnW9nR0pa /Nq4whtGLpCli8jsugA1vIpgDFYDw/qJZbYI6e9N2dtj/kr1slX1cYPd+lmRste9wZ1sfNP64/ji +MViTXN5qdEQknxTaU3tGHZfAyzQuXMFOl3zDlDbyemsYSwb4wnyHqXOlWyCgeq5xJ1Z/pDnBu95 0YhoyEmWwVo4mjMTBnSlNwCJBPFCur1htsGX73zHnfDkDHZ5jinMU9QvffrVvrBG5giYzmcCpSkZ q+IvLxJYWPsaD5ZDgXyuAkr5oaaM9fq1slFhkh+mbpB7jBukjqZCPi+bHUD5Br2ssi4RjRIc3J3J qDvqaCeMG7RmHvdiY+kuhTxUPhdBzUSD9+X5WjjUSzj3lM/sAnUrUbXfrCE7+fEuDQKPyqLtd7nF gO6o9rff1g5gpOaxy7awqNfX8+pcpTzVjlfVtFg2c5aFLNbQipa/Vj25w9NNV43DN6QPf/l6NeuW Al7B1mI5Y7VdbnL49rzDHd+4z+tK/nQrw1XlMzcrz71q2YSnvK5P93LSje5vo/wOHAFJ5ytet/Op Oz3h+f2sxzU+9qDT/OdPj3qWcfzcr3ud6Fd+u9xX12lEKDHqeAf7g/Xr8reOvelSR7vHz07mj/v9 5XmX+brVrvZrR9ntgncuvx9O+ZWTveSRb7zSVT54hCd96B//uegdf1jIp7zz0F0sy+Fu+ZmT3fVL R3raY//2lX8e9bc3O+kfn3vY05zpvg3979kud55vfviJvyzKS37638b87MbfvVuqXtCIR4L60teo 9YWA/esLP/tc6X5Ct2/SMYP//OhPv/rXz/72u//98I+//OdP//rb//74z7/+98///v77//8AGIAC OIAEWIAGeIAI2BEHsAAMyIAJ+IAlsIANOIEL4GkQmH8N6B4a6B4LwAALcIEF2IEVKIEU2IAeeEH7 BIKQsIANUIIuyIAtaIFukYIqiAcL0AAtiIM6uIM8uIMfiIIptIFCOIREWISC0QAO0INKqIQO8AA/ aEE0iD1FOIQDNIVG+BYN8ABauIVc2IVeyIVPOB514hFRiEFlcIZomIZquIZpODFdsQBdCAFyOIdy uIUQ8AB0eIdbiHE6MoaTIF7nUobuw4aEWIiEKINQ4iD+EQZZqIV3WIeOCIlz6Ih4CIYywCPR8Due oARn2BzKUxyAUyyHQzlBY4im/niKC8CHyiKGChIGDGCHj4iHdAiLk6iHWsgAFoiJIwMg2iIow3NR VFgGUXGGKwEpwciK2dMDmJgtQ7CJh3iGqXiKaciAnqYbLtOKehAAsCiLtaiHswiJDxABuBgDukgh vGiN1MIdzNiMU/gJA0SMwjiEDQgDyyiKKHCNOOCM0BiNDBgA/RiNm0iNwjiQ+6iKiliOgZMtyygo jkMEB/CKkviFlfiFEBABElCBl5iQg5OODdk4PtCOnxCNnRiP8hiGN3OOKIOSB/MnDMOLQqCPZdCA /jiB/riGqZiKEuiMHWiQKmkmlvEv6RiU6LgEAcAAEZCHSJmUc2iRDMCTrciR/g0ylL2oHw0ZBDBZ kDFZkyKJhgt4gsg4lE0SlVAZln7oklaphvz4j9Bok1m5lTHZlF8ZJ8zIkUKpkHJJlAwgAUq5lxUp ARIAlzMglXSpkXcpGus4BP2IliGJkzWpjwv4l05pl+sYLnPJLbNSI7/oHGvoCW4Zk53pme6IhjsZ l5VZmlP5JKfJBP5olHyZh0yZijagJ6eJjoVZmM0ok1xJklWohnnpgblImJI5mAfZM7IZBNJ4nITI AID5ODhyl8IpltiIjx+5AA5wlK0JARPwlxgZm/XYnKm5kkWwmp9piB2onYgInHX5nVDZh4f5A8j5 nqKpnE1FHoLpnPWZmrYp/jEMyAAOIAHWmZQTYJEOQI1QIJ1L0JUeKI3lmaAyiDCzqSq1mZ/dmZlH MJ7wyYYd6JsuQJ/A+aAuyZBViZgUyJ/+OQFzOAEBKgEO4IEZuARkGQarmaCFmJfmyZ1k6Z3r2TeY eZuJeaGEuJ+Q6RYvqJz96Z9+qaIsWoIumohPUAkZ+pk0mqAFSqFiUJRJ+oJYmqXleZENim1aqpzK qaXbyRUIeqVRipNN8KKRUAlgeqRu+qZwGqdvKqUzyIFZqoH+SIJCCBerCaca+gQeuQdOCqaEWqiG eqiF2o9d2g5W2KhE+Bb76ILBJHGRqqWieZO4OalwoYEysIFdsYmOQIRc/qlEe6oCi1qDMOCpydOJ qHp/pyodp9qqrhqrslqrtnqruJqrurqrvNqrvvqrwBqswjqsxFqse4AAxgppbdAGLMCsL7CsI7Cs yEoCyCqt1AqtReCs2jqteMCtySoC27oCztoC1QoA1Tqt4wqu6Lqu6toE4QoG3jpH8ToT6Rqu48qs 9zqv5rqvJpCu5squ/9qu1xqw0Yqt/xqv+Mqt7+qvzWqwKcCwKmCw1tqvDuuwQ7Cw+vqsFnsCEIsC EruxB+utE5utANuxLlCv63qu7ZqvHAux/oqxAluwKkuw73qtMwuzGhuzHpuxHLuvN4uwJauzRlCz MkC0LXuyPkuzQCuw/kZLskIbAyjLtCU7sy27tCWAsy87tVJLsVurtDlbsCursFTrsvx6tVarrUKb sDYrtllLsF7rtlArsuzKsvfas/ratm/btiibr3ortl1LA1Gbt3PLswcLtlwruGYrtRPLsFgLsOQq t+r6s27rspSbuDQbs+cquW9rtprbtCcLuYVrrwpbtUc7sIhrs6dLuZ3ruDMQuI0Lt/3Krx37uqbb tIyrtZvbsLWLu2q7s1bLuaMLu7RbualLuBELuq87u3i7u3/btThrudD6vIDruM8LsuCatHhLuzJb vBS7uk/7sMjLu1RLut9bsyPrvNLKuoarvXHLvIhrsh9butIruIt7/rfi+71x67rUa7KFG7K9G7Jr y7V767eJy7K5K67hi76we7Wym7FGm73qu8DcK8GP674wC78NvLMKbMHzSrzs667GW7Y+wL+6+wPm i7v9a7c+e7ZBK8KRO8GcC8NFu79/a73lOr4TnLXeK8HRe79OYL1LQMIIHATnW738i63pO7YVa79w O7KVa8Ceq7H6i7nwu63Wyrdye7tNHL8CTMBR/H5CHMLTewNCPAUkLMZjbANljH9A7LRqjMZP0MZE sMbg+612fMd4nMd6vMd83Md+bICcSZO0+secVAkUcMiInMgUoKmE/GqGjMgVcMgWYAGKvMiNDGsL mMgWcAEUUAGe/lzJFDCml9xOB1DJn0zJoHzI4zjKyaOqULgAoMzJlPzJoLzKrBwdNCiMFtTJkazI nFwBF8DJqVwBJnnLiPBaxNg+AVABFoABzhzMqRzMwdzLvByZe1yGeMqq2EMBm4wBKJqdEkDNh3wB GOCm1HwBDGDMx3zMG5iVg2wQyzzJ5UyozGwBkUzOfkmoiHwBFWDNdozNojqT/hwTCzDJm3yRJljP +KydDDjLzHwBxUzIUdjO73ipjAwXFCDNwbydRSnP2QmYAcDN9gzMttzIE42nvgmTiioYpbzJ0tzP 57AAFYABGaCd5yDSBo0By/k42PiUVCqAoNDOYRqa0wib7gPM/hqNzhfBAN78pxmd1OUcmRzahwYq MQGgAVid1Vq91QIgpjLJPikohFYqkir9p3yK1En9hBkK0i6t0VFNjmqqiDCqAVXoqAvwl4haqEEa PKGK0jI6ozs9g2it0RXgDDV500kdzG9NjzdqJPgpl1IpUwNNYnkZ0Zt6Dn7dme6Rhso52QVxAIOt 0emM2XXw1FBd05bNOgqpks/5ID9NYhoAB46azafoHpUNPM6ggSK4hmKBhp3tPhSAAYkt3OoRAOQ8 3BnglYzdkT/ZoelZ1WZB17Mt1lfq1X75zoxK2p4whYRWBr8dGAtAzs483s4M0xcx0+Q93hkwAYHN 0+UInY/9/p05cNUXetd5ndfieDM/4gXQ3anaLYiI4NvtHZir0t9eId7p/cye7MkInuCo7c/3CZ2t 3aE6cNVbfeEYrgEUYJFwGgERgKIbEOIiHuISwIcLGZs6YOCp+t/ByIbffQMW0p6QUJQJXuMOrt7s Lcrj0djwTZuSGaI2kOFCrtUWEOITEOIckORKvuRMPgGpPZnmCBqvLQW5Tdun+OI1ENkqLgbhnd4Z YOPOnAFiHuY1PeDMKTzw3eMUngND3uYXwORwHudJ7uSAdOKDo+bVkpJi6dwJCZ4rfgab/Z5YLuVT CZaNnZ5RQOPq/eVgTt4ZwAE5jt150OZD/uZyfulzXtKL/liawtncphnZBuLpQGmf/g3ogY6lvGnm y72QfW6NKNnnUCDTjU7mjg7pe10QlC7klj7ivN7rIh4BRn2P0vLpfM7pCGLsxC7j80PaMYqoFSjg ng3lyb6R+ekEj3nj6l3rZf7k0iAAFZDrF24BSe7r5C7iXFo4lVGZlPnY6z7tpI6aS9bbMYqlwHSG g56RH0rq772eTZqXE0DTs/7oHLDefynp2ejJ4E7k417uvp7jLZPu8h3fVbkjyC7xNJBOb2mhXLCJ 9w7X3umhIL/l6wGkEjABYs7oZC7wBI/X0f6H3LzgC07pRc7wDX+RJn6Z7p7saR7fE67ssLFB4nmI 3X3r/gTu01DO4/zeBDOZoX6Joif/9OCM1/vZ8pIQzyMN81iP9Rdg5N/c9V5/5NlJoOjOH0f/7oVu m51u9oFqqoEe9GwITECq6XAdna0+NWveBPq4n8opp2CamA54EA9ZzwY9+IQ/ycD89Yj/za9J9QUx k22q8VYKphf9qTbp1dNo8HiAoFm/+TAvp57f8W9BgnpPnkrK0gGdzY76RZ/Nmffd+q4fpri99Gst poSq43XazlGo+rI9hICfzV79+y+I+dTgpLNv+WLvPqW6+5sE4MM/3WIN/G55PXhqqc8v/L16ldII QG2vhsFo/dcv1rWdQ1aoy+psFtzdReBf/tmn++ov/kvMfwLs3/6x5Iaw4f3yj/yw9P73f0j6v//+ //8gAIgjWZonmqor27ovHMszXds3nus73/s/MCgcEovGIzKpXDKbzic0Kp1SR4gqlnbNcrveEiK8 VYVhYuvZJB4D1sZyewt/uVfzVhqdmq/ZQjig39cgUKCd4F6boiEJI+PRI54cYiPlyRUmGmWeXlJk lCXhz50hH+bYnZWimh+fyGcZaR5nXO3r5C0dWynqaSfYquYlbWqtrGlqbG+ubUwdWSgYMuJzHG2Q Y7SL7K2v8TIrdSuubbIy86d1OXnx3u6k9zmz9G5zoz2+evZ8ZTy7Nit+w7YtWidtXrs35G5wM2gw /qG6SgEdmkP3b+K+fO4kUsQFcZZGfu0yputo0dm7XKaaFcs0cWCwgcd6VVzpkGFKk9/IrEpIctzJ g0J/6uJIFGLBPpvqwUw38uLNbTmPLhXkE1xFnU+DlpzxKGPES0mBah3nL2i/smYWgr2myiVakSjO EA2ndq1RqPKGkRX6kmsfgYDj4mz4FWkapSw5VVP5zqZEm13dGWaLOGvWV3O9dQN3UPJCqXkHf4yZ 7yNZp+IGh0SCVHMhgBurvDa9o/ahP5bRuk36MDRhunrFnY2qpDck2ZupIC+CG9qQam1R0/z3rPFO TZ4jYwUu6jv48E9eK5fxfLb49OrXQ2lO5Pxy/vby59Ovb/8+/vz69/Pv7/8/gAEKOCCBBRp4IIIJ Krgggw06+CCEEUo4IYUVWnihDAdouACHHWqIIYghUnFAhyWa6KGIKbJwQAACuPhiAAeoCAOJJ9po oowgBtDiizDGmKOFB1BQAZEWGEkkkhUIAOSMJ9z45IkXHtAjlVTuyCSEAiS5JZdEChBAkyTUCCWZ HGL5II8vDkkBm21WCWaWXcrJ5ZdNjllmmWcyOKWaR1bQZpt/UtBjjA0esKWfiRpgAJcWeKlnhXhK ysACEi7g4pCOuihopkZaACibLhaaIAWOFmmqAaaimmSiSMIpZYcMyErpArJyOOuttM6qa6Vo/mJa gaaglqoksJ2CWueBh5oKrKOpbslokYs6i6SmGNY6qwMO3Joth9k2UGu22GqbK6QHLsAms1p2yaaq fiZJwasECuApvdOiqmqqGhxJr5G9UhiArA0IHEEEDjCQbbgONKAtwgYf7HDA8SpIorFzMgvsn+4i SUG5/c1bLwKM1iuyBdMuyu+REkMIsMALI+xywgfLLLPBAmPr74JCntrlvo4a2SmiFajsQgJFFz3C 0ScknXQTAqTqKQEGEECAp1KPXDLVKBtwAc5EG52ACGCjcDTTLHwN9tlGF1Fry2277faucd88A9Nl rwdwkRicSi+wGPjsqd/Meio03WIDsLTh/iUg/oTT0i5K5NSLIhC11FRPHbLWHUjQtdmGk50C2Ymr ULfnog+xAMwNq766wm+3rG3hSJue3gEMAO63kRgE3vftgdN7gQQMdDz27CvY7UQAjkdu5KIETD51 1Pw6LnUHEzAwNOjFZx/D8WFr/wO4rItfsPgIR8C514d/Dx6Jguv+Pr+4o2zBBfUHj37nxHu/uPr7 r+/DAS4wPWmV7GlVO1kBDdCBBWbgfsNT3OxKtzjEdU99EfwfDwBWPgcQTHXk2yD2WqA2EnzNe/2T Hf8qSIQFSGB+Loyf7iQQPEo9UGnF+5wJJyg2FQJhAR2g3ACDKK2pMXACM1xACPVngh3K/q5/oTOh De3GQx9ocIMfLNgHWRcB4dVghGFrotqWBsYdYvAHtZPABV6IsvdhQIa2SqLxbihBtJHRgkw41A+F OEDnFdGNlBoVDLqXuBI+0YvZK9sUe0AiK2KxkeWLwOZqSDzTEbKOKCRjIoUAMAno7oVslOERAUmD CurwhBQsYw8CIIEFPg96rlxgH0MpykBGcIxOxOT/vJjJDDJAAhvkYLay6MHgwTGOoiukJW/ZRCew qJdsfOb7/MihWY5SjqakIxT3t4RaTQCW3oRlBjJgxCMiUZLbWyIUkUnCRJIuCSTqpTB/2TCC3c8G T0wnNq+Jz10G4Z0SmABAAxpQUNLK/pzpw6c+S3lCJWwSoOEMJ0D9SCtqdrF0h0OoOhe6zmVq1Aj+ 7KA8g0kwSNKwostUaArzyc8fBOBcsqoAKGVYAVm1aZoUragucalSXN6xpXKTm019cLYv+g+bpzwk IlHJg4+O9JEjpWdJTZrNofLPgvdcqSJ31NJzsclGWv3qlQwF1rGS9asGlZBPn6rWtZIUiRXSqlfh WlawnhU/GrorXvOqV7xq9UMq8qkDZBgBgRIsoJD0ZVQlxKK5MnaudbXPXiMr2b2G6E7XylZMQRku WqEoQne9UmMXqyHQmhVBkz1tZAHg1yBB6adQeqx/UCtbvRpqtWFakaRyC1sAfWi2/pK9rZ1y+6S8 4g+4xr2tb5N73OUuN7m+ZS50j5tX1Z52BLaNLnazq93tcre73v0ueMMr3vGSt7zmPS9606ve9bK3 ve59L3yBW54UzTe+osDOX1gwC7dIxz23gQpKagOf/T7lGMkhzHsnI5hEZAIWw/GEd/QbYY7gYSwC ccSCozNhJ9R3P5VZDIjVYBt81EUPM9EOdzqhYJicZCWQucdqRtMToJy4M5/pToYlLGDlEJg4j+mw FgDslanIYy8FZjFrzFEc1Sx5w/GxyFleLIz8YpjERRayMEqMl9bkGBgNBo6WFdJlCct4H9Txi4qx XJeWPJjLSF4zZ+wyY76g4sJt/t7KXbbc4mVIuSBUbrOJf4ziFLMmyGW+yGW2k+bgWCcxVrnzfD9s kkT/QsbWSA08HN0UQBclzVFWdFgonGSz5DktYUbJoffMkwmHGSyVHvWY/wJnLrvkKnYeinfwfGoy L3rSVUEzrFNtnGDDZ9O9RgaDF4HpQnej1M3GsZuNXWjkNNjKXIGNqTmdZW1LQti8oMyrg33swGhk 1oUhMkIofWkjM+Yae7l0uNmNYElIGtngXjdn+isTQS9Y3sPmNbHj7OUMtxrL5YZ0EwSMDSDHmgkK HwXDG26Dw/DGJxb2NpivPG/hMDs5Ec9BsYENipDzgOSijk29aXJvxUyjH4+2/sd1VgMaidvXvORZ OE5qrnN6c/jjJt850IMu9KETvehGPzrSk670pTO96U5/OtSjLvWpU73qVr861rOu9a1zvete/zrY wy72sZO97AZSANrTbva1p73tClg72d+OdhG0fT5vr4HbT6B2E+ydBHOHOyH6DgDBi4fwMHD73+me d7/XfQSJB/wXDC8fybdg74L/e9/VnvjHQ94Li0fB5y//+MaDfvOjlzvnHf/5wZNe75g3/d0zH/vZ d/47iHf94mV/d8W3vgS6Z/zqVU96xO+e76/fveVNz3rU1972twc+76Mv/eVP3/ewZ3z1oS/87Zd+ +Nfn/dxT3/zIB1/7rJ/+/u9xz33qs9/4yD998YEv+vcXP/nZHz8Xek981aOf+PHfPurR3/31X/2J 3/m1X/oZH/j9H/5hwfyFXgDKX/m1HwIeX/etHwVyX/pRngUaYAMuAeFt4OlRIOVZH/0JYAZWn+4x YPKhoOQp3wF+IBR4XwHOXg1yXgKa3/yloAq24AVWIO0pIP+VoAwmgf/doP4Z3v7h3vMtoAFC4AQK XwiWHw72XhE6QRNC3xQy4PJ5YBcCIQ9KoQSygBWGYeoR4RVKCBqmYdStIRs+nRu+YdPFoRzWoR3e IR7moR7uIR/2oR/+ISAGoiAOIiEWoiEeIiImoiIuIiMeHY8MACRGoiRO/iIlVqIlXiImZqImbiIn dqInfiIohqIojiIplqIpkqKohIcADEDknKIrviIsxqIsziIt1qItxmLlDEAxQQErEoAuNqKBBAAr GoAAcIEATE4xAqOCOA0BJKMUHMCiOKMyLsgxDsAzGsAA7NY06gc0EsAuahICWOM2RggrauMNJI80 juODDAACmGMNNKM6UsgAGIA7ysCixGOFYGMSHCM+VsgBeOMRQGM69mOWEMAROA1BWgg8FsFCGhNW 9QATjY0IOaAHxh8XqgDyOR9GnuEDXiQGSgFCEkFImg0JCRXRkKRJohMPVKTvyUBGioIXxqD1mR8Z emQTAOQQ6ONEliQP/pRRLv1ALa0kF45gDLxkfTzh4NGdTK5ATOZAU5YAJBIBTqIk0qCQREoRBUVR VV6UVXLl93jOVtqRWHYlWF4UVs5O+MFeWmreWvJfUiol9bGlDcZlW8rlBc4l+z3gEGbeWzIfBrLl GLqfAKrlW77ASALBP77AMREVV0IQY5ZlUHrlY1Yl2hhPWEakZKpkY1pSWTamBr4f9n2m4sFlYb7e aJ6maR5gas5kDMJgawYh5rVk7LWm46Hm5vmdEKolbNIAAdRjChymZfJkZ/LkZm5lZBpnWGYT6Fwm YyZnclbmZEZnaL7mdFJnS5JmWxbm+VneXs6mEFqndcJg+PFdXgbh/naCJvi5XmhW4WnGgAF8Iw3M o2IqjnQSZ2diJnEiZ3N2lNIwpzbtZ3NCZ3EW1Xe6pkwaKHYO4XZiH/OBZoOqZ3u65moGZm3aXxcC ZnteKGvaJms+pQkQoxBE5UkKp3NKJ2T2J30OKGUGp4rqZ4p+0X2W6HQqH+2ZJw7WJm4+aI4uaIXy 6IZKKHqKX1rKZmpOoVtuaIZOaHrOwAAMJA/c44iaKIqqKH76J2aCpYBKZHSeqGYG6JWWKJD2pdxF n/0ZZYT+H4KmaQTKXv+hH4fiKHqqpl/yJZzCZpySZg2IKBDoaecY0li+6CC10xLVjZdG5HAWqgRx lKIOUkf56Rd6/t+MRuBomil4Hil7Zqic+iWZrqUNHt+aat6FdioAemqQ0qBu2iQK8KkPqCp/UBJQ 5icReOgUyKp+ZKELsCoP4Kp+uGpKAqgQ0GoUAOt9WKQM6KoOGGt/PGT+wOqv0uEMOit+ROEKICsO UGtCOoi12kC2XuuCbGt8iqMMKNVydukOiKtimmu4egG67qoSeCuTgusSHGe5vmoRrKsQHCp9oKu9 5im8rmq/JoG86sC+jisRDCy9emZ96Gu7/muuMuxO5tOgHlOW4pCA+mlOuepZliQlkQ6vbiahTibG YmlXZqbHJuqKaqVZSiyW3pApmeV/juyfjizEXqzGAirM4msM/rhrsTosSoqRzRLVx1ZVjMLoOQ0t fxqtfW7pZV4Q0A7tlxbnfX7lSVlplabT1Eppiw6oz1KpogKtf2btzoYozwYnzn6t0ybtfmoPzq7t 19Ln2dYn2jKq0h4q0k6p0T7tz3ItgKqti96tjE7scyLsu4rtKMFtDpmti1pVoJos2vrP37ZtzSqt 4Uou1k7sKZUt4hIo2Oqt4q7T4kbs1katLqGs5hLtDegkEADnfIKt31Ku4L6olnJuZJZtxfatjGot s0pmLQVs3uIr22ItwTpnx9atr+Kt2+IAiAaB6o6o705V5sot1/Ltlv7u5gao7foq7rYtfors5Dbu 275u6GYu/skuptcC7+/WrcECwHsKQWLSzeTikONeUtpm7MvK70bRLiIF75+WEPbyL8Ja7Pwyrmdu bH2ObvFq1Od6rgJHrNkK8OzCLPbSSG8OwVRCV/pOwQWzKIAY7PL2gM6CSAZHQQjrr38Y7AfLQAAY pAWPcICwMBcoqwlUcBA0JLdmiQEYgQCocA1DCA1Hh5PuMILkMBLksG8CsXwcAAL8cBDIpxErCOoG 5BM3MYGwIhMEQDhKcYGwInz+gC9isYBQ8RMkDz16cX+IcRHfADsqMRmzRw6P7RLkcA+v8XrA8RYP sdT8ohyLxypGjRpLgTBGDjbeoiAPMiEXsiEfMiJvYvNgUWMdQwGLrKIrAkAiTzIlV7IlX7IoisoZ 5zEnd7InfzIoh7IojzIpl7IpnzIqp7IqrzIrt7IrvzIsx7IszzIt17It3zIu57Iu7zIv97IvT2MI AAA7 --------------644383717147182732830847-- From sip-bounces@ietf.org Tue Mar 13 19:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRGhw-0001Na-GH; Tue, 13 Mar 2007 19:47:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRGhv-0001NO-L9 for sip@ietf.org; Tue, 13 Mar 2007 19:47:07 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRGhu-0007CS-9N for sip@ietf.org; Tue, 13 Mar 2007 19:47:07 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id AD9DE3A0210B; Tue, 13 Mar 2007 16:47:03 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 854C73A0210A; Tue, 13 Mar 2007 16:47:02 -0700 (PDT) Message-ID: <45F737F6.5000208@acm.org> Date: Tue, 13 Mar 2007 16:47:02 -0700 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> <45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com> In-Reply-To: <45F70D70.2040007@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Jonathan Rosenberg wrote: >> Ah sorry, my bad. My fault for skimming to fast. I'll take another >> look and provide some useful comments.... > > It's still way too complicated. However, that level of complexity may be > required due to the underlying complexity of SIP and multiple transport > protocols and their inherent limitations. > > But I still wish it were simpler. > > Making it simpler, however, probably requires re-examining some of our > more basic assumptions. > > One approach would be to fall back to using UDP simply as a > register-and-alert protocol. > > In this model, user devices would "register" using UDP, then receive > "imminent request" messages that would cause them to setup a TCP > connection ala outbound. (Not too different from what Marc has now). > > One could conceivably model the "imminent request" notification as an > event package. Yes, this can be a solution. I choose a STUN extension because the decision to switch or not over a TCP connection is done in the transport layer where STUN is already used for keep-alive. The problem is not in fact how to signal to the endpoint that it must open a TCP connection - this can be done by a STUN message or by a SIP message. The problem is how to find the newly created TCP connection on the proxy side; because the endpoint is behind a NAT and there can be multiple endpoints behind this NAT, the source IP address can not be used for this. > > The difference here is that all traffic other than the registration, > related registration-events, and "imminent request" subscription and > notficication (the two event packages could be combined, I think) would > go TCP. So there'd be no run-time sizing, Path-MTU discovery, or related > complexity. > > Bonus: We'd get to keep the high fan-out property of UDP edge proxies > when we have "mostly idle" clients. Note that presence would sort of > break this, of course. > > > > -- > dean > > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 13 22:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRJAY-0000re-7D; Tue, 13 Mar 2007 22:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRJAV-0000rW-Vf for sip@ietf.org; Tue, 13 Mar 2007 22:24:47 -0400 Received: from web31509.mail.mud.yahoo.com ([68.142.198.138]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRJAT-0004hx-Cz for sip@ietf.org; Tue, 13 Mar 2007 22:24:47 -0400 Received: (qmail 95557 invoked by uid 60001); 14 Mar 2007 02:24:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hN6pFMy3S1l3dKRndx3rD4z8gKk6nqxpV8PQ7SMn7SVwCvK5+agsQNxAP0XNaXRwpB7OEbdQGZ1OQiVqWJA3xnmsKUnxc/zrcAGJ/+Jk/V/3M1PQw4D932ku2DHAMA5gCelBtU8gIIL2cWvJdoY8mmR2ZNZTW2Wwb4pbWja5XwQ=; X-YMail-OSG: D5leIqIVM1nhQhwAdliTtNJMLBDGdoNYdVeth1pgOjWL5kKmpHpIm_xm6SfmJ1Hp_.UIF3rosKtONLI8iZJOBA5VxL7vR1Ifa4MwItLxHSC_kR8wNFVfTzMpL9vvVCuwt6vfiHwLaqFwXrbhyxhDvw-- Received: from [74.104.144.175] by web31509.mail.mud.yahoo.com via HTTP; Wed, 14 Mar 2007 02:24:42 GMT Date: Wed, 14 Mar 2007 02:24:42 +0000 (GMT) From: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) To: Takuya Sawada , Paul Kyzivat In-Reply-To: <003801c764c4$d51a80c0$0300a8c0@TAKUYAMEBIUS> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <818435.94731.qm@web31509.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Takuya Thanks for the reply. I would agree with you - since RFC 3261 does not clearly restrict the "SDP" (but only offer) in 1xx and 200OK AFTER the completion of the first o/a exchange. What do you think should be the behavior of the UAC if the UAS sends an SDP-offer (a new session ID - new media) in 100Rel/ 200OK in the above case? Would ignoring suffice or you would like to recommend UAC to cancel the call since UAS violated RFC 3261. Also, you might want to take note of the corrections indicated inline KN>>. Thanks, Kapil --- Takuya Sawada wrote: > Hi, > > I just catched up the discussion... > > Comments inline with [TS]. > > > *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE BELOW > AND COMMENT *** > > > > (References are to figures in > draft-ietf-sipping-sip-offeranswer-00.) > > > > Comments inline. > > > > Paul > > > > Kapil Nayar wrote: > >> Thanks Paul for the clarifications. > >> Replies inline. > > > >>> If you were to allow a second o/a exchange via > >>> reliable 1xx, then it would have the potential > for a race with a > >>> concurrent UPDATE in the other direction. And > that would result in a > >>> need to > >>> send an error response. But PRACK isn't prepared > for carrying an > >>> error response. Forcing subsequent o/a to use > UPDATE avoids this. > >> > >> KN>> Perfect. So UPDATE (with SDP) support is > sort of > >> mandatory for implementations which want to > enable > >> changing early-media. > > > > Yeah. It would be quite unwise to support 100rel > and not UPDATE. > > > >>>> 2. Just to clarify, in Figure1 "After F6 UAC > and > >>> UAS > >>>> can send a new offer in an UPDATE request", I > >>> guess > >>>> the authors meant F7. > >>> Debatable. I think the UAS can send an UPDATE > after > >>> sending F6, without waiting to receive F7. (With > the understanding that > >>> the UPDATE could fail if received before F6.) > >>> > >>> The UAC should probably wait until it sends F7. > >> KN>> I would agree with mandating UAC to wait > until it > >> sends F7. > > > > I don't feel too strongly about this. I think it > would probably be wise to > > wait until after F7, but if somebody wants to jump > the gun and is prepared > > for the potential error if F7 was lost then I > guess that is their > > business. > > > [TS] > I did not care so much on F6 or F7. > Now I agree with that waiting unil F7 is better and > safe. > Probably we can modify the figure in a later > version. > > >>>> 3. In the description for Figure1 it is > indicated > >>> that > >>>> F12 (final response) should not contain an SDP, > >>> and if > >>>> it does and is different than F6, the UAC > should > >>>> discard it. (Similar description is present in > >>>> Figure2.) > >>>> > >>>> a).Does this mean that a UAS cannot change the > >>> early > >>>> media to a final media in final response? > >>> It means that each offer has been answered, and > that > >>> once an answer has been sent, it can't be > changed without another > >>> offer/answer cycle. And that another > offer/answer cycle may not be > >>> initiated > >>> in the 2xx if one has already been completed. > >>> > >>> This last is part of a principle that was > discovered > >>> during the evolution of this work: At most one > offer and one > >>> answer per transaction. > >>> > >>> At the time of F12, if the UAS wants to change > the > >>> SDP, it can send an UPDATE before sending the > 2xx for the INVITE. Or it > >>> can send the 2xx and send an UPDATE or reINVITE > after the ACK. > >>> > >>>> b).If F12 carries SDP, it should be designated > as > >>> a > >>>> new offer-SDP, right? If UAC discards the > >>> offer-SDP in > >>>> F12, is it still obligated to send an > answer-SDP > >>> in > >>>> ACK? > >>> No. This is all as specified in 3261. Having > sent an > >>> unreliable provisional with an answer in F2, if > there is any > >>> SDP in the 2xx it must be identical to what was > sent in F2. It is *not* > >>> another offer, and so it there must not be an > answer to it in F13. > >>> > >>>> c).If UAC accepts the offer-SDP in F12, can the > >>>> answer-SDP in ACK be different than the one > >>> originally > >>>> offered in F1? What is the behavior expected at > >>> the > >>>> UAS upon receiving this different media? > >>> See above. > >> KN>> Actually, there is some confusion here. In > >> Figure1 and Figure2 call flows there is a > successful > >> completion of the o/a through reliable 1xx. As > per RFC > >> 3261..."Once the UAS has sent or received an > answer to > >> the initial offer, it MUST NOT generate > subsequent > >> offers in any responses to the initial INVITE." > However, if you read the > >> description in line with the > >> figures it seems we have relaxed the MUST NOT to > >> SHOULD NOT. > >> Figure1 - UAS should not include an SDP in the > >> responses F9 and F12. Figure2 - UAS should not > include > >> an SDP in the responses F6 and F9. > > > > It has been a long time, and I no longer remember > the rationale that led > > to the SHOULD here. Note that in these figures the > SDP in the 2xx is not > > to be considered an offer. It is just a piece of > redundant data. > > > > Personally I would be happy to say that the UAS > MUST NOT include SDP in > > the 2xx in these examples. But I would also like > to say (this is a best > > practice) that the UAC SHOULD/MUST ignore any SDP > that arrives in the 2xx > > in these cases. This happens a lot in the wild, so > one ought not break in > > these cases. > > > > But I would like to hear from Takuya (who is the > primary author) and > > others on this. > > > [TS] > RFC 3261 says "UAS MUST NOT generate offer", not > "UAS MUST NOT include > SDP". I guess some may interpret this as follows; > > UAS can include the same SDP both 1xx and 2xx. > It does not care whether 1xx is reliable or not. > If 1xx is reliable, SDP in 1xx is the answer and > if not, SDP in 2xx is the > answer. > Some SDPs may be neither an offer nor an answer, > just a hint or nothing. > > I would be also happy to say "UAS MUST NOT" but I > could not conclude to > say that. Clearly some implementation would violate > "MUST NOT" rule. > That is why I put the following description in the > draft. > > UAS should not include an SDP in the > responses F9 and F12. However, > UAC should prepare to receive an SDP in F9 > and/or F12, and just > ignore them for the case that the peer does > not conform to the > recommended implementation. KN>> This is a bit confusing on the first read. Actually, it seems you are trying to refer to the generic cases in table1 in the description for Figure1(2)- with reference to the Figures 1(2), SDP in F9(F6) and F12(F9) will always be ignored. Isn't it? The case w.r.t. the Figure is always non-conformant. Further, the conformant case is when the o/a exchange has not already taken place in the transaction. You may want to disassociate (correct) these text description. > > Regards, > Takuya > > > >> And, it sort of opens the discussion to possible > >> scenarios where another o/a can be initiated. Is > this > >> intentional? > > > > Definitely not. > > > > 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 > > ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From steelerectorsni@conexant.com Wed Mar 14 04:55:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRPGZ-0004HU-AK; Wed, 14 Mar 2007 04:55:27 -0400 Received: from [125.91.26.76] (helo=conexant.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRPGJ-0000bz-4H; Wed, 14 Mar 2007 04:55:14 -0400 Message-ID: <02CC4F76.8E7928DA@conexant.com> Date: Tue, 13 Mar 2007 23:27:34 -0900 Reply-To: "Freeman" From: "Freeman" X-Accept-Language: en-us MIME-Version: 1.0 To: "Dionne" Cc: "Rhonda" , "Mckinley" , "Beaulah Ryan" , "Allen Chapman" , "Georgette Morrison" , "Lulu Lawson" , "Asley" , "Zulma" , "Mariel" Subject: What Time U Going Content-Type: multipart/related; boundary="------------853225274187207767158270" X-Spam-Score: 3.4 (+++) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 --------------853225274187207767158270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


"Upon my word," said Monte Cristo, screw axillary cough "Paris signal is a str "Is inject let screw it then so head terrible a poison?"   hat separate lighten "Five and twenty thousand francs umbrella is not a large sudug "Oh, no. In the thought first chiropteran place, let us serpentine agree that the 
"Oh, by no," replied Monte said Cristo; band "I do over not carry br     "Well, amiable hole Corsican, concentrate let structure us suppose kick it is prov     "I have card related it but once, and solemnly fire that bulb was to the A   
"My dear Albert," stocking irritate grip squash said Debray, rising, "it is half      strung "That brake carriage shows shock that the Eastern nations have too muchdream forbidden "What, overcome hook then, is it?""He was a merchant, hospital kept dust monsieur, and pull had succeeded to"A plan came hit produce skilful preparation of my friend's the worthy A   
obediently tame "Take care," returned Albert; "no lucky one promptly has been abl   detect "Then," said the count, "I verse produce refer you umbrella to your confe    "Oh, your flame office excellency, damp hurt your excellency!" cried the    
"Oh, man we have three screw challenge millions arrive for our police; it is     
lain "Really? understood worry and chop what has procured me so fluttering a"Oh," observed slid sail trick Madame de Villefort, "it correctly must be ansteady eaten Maximilian had day scarcely annually finished his story, during"Perfect, madame, as you price decision have explode relation seen," replied the c          
"And when carriage tell you know, will tire kick you tell me?" "That silk family is different," mowed replied Monte marry Cristo; "but if  "No, helpful monsieur, cause I rescue garden swear to you, by my hopes of salv        
heat stormy "I tongue promise you. Au softly revoir, Albert. Gentlemen, good      brake "We are very upset vascular happy, straight monsieur," replied Julie; "but        
crazy "What? why, fresh shirt yourself, to fed be sure! You give away ho"Most assuredly," responded sister Madame science bed decay de Villefort in"Oh, all this carelessly is expand fled a family politely history, as Chateau-Renahelp "Undoubtedly, and so trick scary celiac should I prefer it, after the     As he whistle left the room, Debray bring called weight plastic out loudly, "My     sky "What!" cried laugh ask Monte Cristo, shed "it was M. de Villefor  gestic steel terrible "Your use excellency knows him?"    
"And bump who sock humor has filled your head neck with all this nonsenwheel right "But I," said rub approval Monte Cristo, rising as he spoke--"I"And wove God has lip poured balm into your detail wounds, wonderful as he d"How street clever peripatetic angrily kind you are."      
"Bravo," tug said Beauchamp overthrew to found Albert; "I puncture shall not go"The victoriously add meal disarm former royal attorney at N?mes?"  "Yes."      owner curly "For thoughtfully sea heaven's sake, Beauchamp," returned Morcerf,    
"Why, in the steep warn first place, I tickle heard drop it from Madame Ddead "Only remember one thing--a small instrument dose quit pour is a remedychoose "Yes, count," returned Julie, please "we tickle may hook indeed say h"If I hole had place had relaxed the honor of seeing slept you for the thir    
"He is swiftly more vivacious than that," fear kiss replied Chateau-Renaud; "h     creepy busy "Who married the stupid Marquis stridden of Saint-Mran's daughter    "Yes."  & nbsp;       
"Directly shelf I have given my card rail to georgic the nerve count, who hdevelopment did "A thousand thanks, fork invite madame," replied Monte Cristo        
--------------853225274187207767158270 Content-Type: image/gif; name="picxyl.gif" Content-Transfer-Encoding: base64 Content-ID: <8E95DAFA.33941782@conexant.com> R0lGODdhjQGSAYQAAP///+jf0u+ysueUlNlOTsUAAN5aWu7u7MwzAAAAAP8AANbW1rm5uZrE4oac 20+QwyJhpWh9wY+UmGZmZs+yhdimbc6SVbWSZqV1O4BPIv/YfFpSWj0vPrY2CwAAAAAAACwAAAAA jQGSAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqZAUHgSa1ar9jsUSAY cAkFw0FLLpvPaOgUcAAXEF0EYj06DAyCcXrP7/v3AwQDIwMFhgIAAngkBwZvXXh6f5OUlZY9B1OF gyICCIYDmQGSAIUFg55wl6usra4mgXkGBiOeoLEkAZ9hImCIr8DBwmVcjY+Ka7qGs6e5u813ena/ w9XW10B2clGGCF5rbYYEAoIljoZhoyLGBKTY7/DxLAFuBXlu3iTncwFRYwdS6tmrhQCPgVDyEipM SA8dHFOPRuzTNK5Uu4bLRkQptczdwo8gXWF8cwcdgTWm/uDYQuQLAEZOhBzmCUmz5qWRYepx2qeo 4BRHtIwNrIXuFC6bSJOmGQnHDa1SA7yI0nhHEUlJtkCFo6a0q1clAaJKFTEyIK8WmarmqkfLE8yv cOMGIedwkUs3BFxKqQGw3slEXOUKHoyjZ1FVLh39vZH1DZ0WUQITSUC5coITlYNZzlyCc0LLNDwD EG3FzqAA57r9Aih5BkbEKwCKlWPg8ZDNpEdT9nN5Be7dJHJf+90bhmjhT5QN0mbSIw7UZ1NkYm7v nBgjnEFbQh4cuO7i3+V55p6CfOcmyprd7WZbxzQUBzIR8JZ1QPq3QsZ7F3Fce3fhm3XmnX64jVCg CgT+/uffdwtmtt9v4QkYoIQPDrifhBgaCOF/HDK4oIdCCJUOG+e0FsQpBBhUwEkpQbdiez70B56M DR7I34Y3FkfggTZiVqGOxOVo44RCEjdjkBoSmSAKpNGo5I9JDtmjD41VBIABcxRRDESo1JYVF+iY yIOMHUYY4ZJmorljjkmygCaDbPoI5IWg1XlhhmlaGKecJtC4J5lC/jmnEBAtw4WYOYhiSyhOsTFF OGFA+lR+ULYZKJ59Vnqmpm8yiaSgRz4JXpzZ3bkhecBxlxugeYZq6aY4AjHAM4cI0ZMgs7bDU1Qi mMJiRrdZqKmHg3rqaqtlljqqsR8iS2yno0ULq4IT/qLa251l7gnqq87COuUPXcwniHM3pNUFOqeF kp4B803xpS2TBtEpgMp2COibS5qnbaaDaseqpfVeiq+w1o7apLDcqpnqskdMR+Usubp40RrWzfqL U+HgFyPBySLc6rUBe/sqtPwi6LHCywbMKspzYovnwcWa2a1+3AYRGbkzpBXIMhYLoNosnYgTmSaq tRtsrDLH+umzLYs6crPZlkzqp6suDHKoPS4Np29Iz8ypx0UyDC5tOL/QyCwFncOiFLvMl+VLd9m3 S1SI6qC1zOGlDDWRUerWMdYmi71toNCqTKeDh9MrOL/Yovx3wlAXZp8JPmeZcxfxzRcIHrustg+7 /r+oDdCK5KQII2Fy6auQz7hygdJ1MtAVKWqQSBoTKP3k4fMjQPVzOupf8Z1Uod2kuJcLmdzeUVTJ t0hW25l4o4w3zANv/dZepVaUai6Uvtqs6BiUzNy3P0T6LDNdr75cjRAw3/YRsQBpOwSFz5V1RIGC ZShlr++/TaPIBCTeZzlG9KMEXKoFltBFgt0hxhYq+d3/JggX2SBkHf0IxLjqgA+KeUEnGsHLFFDj BQqakIK3Ap96ErHAs3RhPY5ZBz7qdsIaEiY1YIrhlUoSkUYgAm53EYRtFGGXTtjwiDYh4i/qo4zF 3AEj9ItGIj4BO3WYwBH5UCISt8gQigmtV0Jz/gRMqgJCt3TiICugR23s4BCNcfGNwJjVdRI4Rd6R 7ozs2oX56OeCjXBkezSEoyD3EBZUnAVSWZJUShChiDxABA8lfEFUXCQOOfZvkJgkg2GewisWhk8E PLGOfBiJACHOoBC0yhLmMsnKM0CCbeIYQ1g0wUNV7O4UtzzIimR5yRQ0JiJhCWQrh4mE2ezSgb8o YRfWxQanQFEtOZAdHACyDWJakwo+a8snYKmeF2IOh3/EpfuEiRayuO5KwLqmOpUQjqc0Ep27TEwU DvK+F1WuHPHZATkm10BoVkMBAAVoEhQgAoKewKBEQGhCvQJB2yyyV17Aw7kMNRZMgCEfC1Go/kJv sNGDrqCjJgDpGUQakvqQ5RvkYyHtpliQ9P2AhFz4yEZJGgOaFvSjLLCpFnSqkHWhhop/pF8jd8ma XtbgnTs06itmOoKAhhQAAm1qVJ1aAoIa9KpSxepNQypQhFoVqiSgalXBGtWxblWsXr2pRqGa1qtO talwZatGy/pVMwgFDvi7ZSjQt8FaSLAGDVFF72IKD6aCdatSPWtcO9pWxaoVsU8da1cRy1i2Qpay hz1sWi0bVq2+9bGY3axoefoEiJjlL7t6VAnasJgdiAiXswgLRrFh2M3GVbOLjWxuMwtaFDQWt5mt rG3DCtziapW4jg3uY+ta2eSeASO0MAUi/gAS2xRIl5xo2ZlJlvgGpVqitrfFrHJ5e1nPVrWsHgWt ZwMq3PDC9bjwvex4bYvVr3qVruyVLzE+MYfK/bV+uMuBHykZETO+A7zl3W1x3Wte5JL0tw327Xgl K17R6ja+irVvZJu7B3gdZR5s2acNtAEbFRoKu5dYq3hvi2EOMze0+oXsfY371OEid74KZvGK6atj HPcBNWt8QWraUTkUr4MLC+RjYorixn/mt7Muzmpizxthqlq4szqeK0jrSt7wilWux83qcL88ZvSi FRsQOcl9AGNFFliMurDpVefWmVMV2FgHpGUldeBQFnT65HiOGppLPgETQMekyXS+cXq7/pyDPGOS jaqp0k+6ocElEtBdsVSBPxJNAzP3AL2cDmeXaPMoEWLxh9BLRJhCzWpWkBgcmx50R/AHT6Gmmiz/ bbWusbBMFNQnK5zkHjxXeIddG3sVKeFhbcBYqzq+iETxOra0+SCUcVARKwwk0SfJYeSMOrrOjB7o g2eKX9KCWpA+vSgdTEqW1EgUdeeecAvCzIR4F5Tc9zX3tydo2jWvg9ZHZtcFCXPuqeaZ3mQAdX6f bGfOProeOVxhrXMtmK66lb0Wdzhd1Urfjd+748Q1+L01bmW3gvnkH58rZxlO5Xyb3N40GaAXdlFF EFLQqSJfecY1zvGP+1yuPy/5e3O+/nORF13DRH/50bk6cpIDPS4HJEdB9ABkupkw6U3PuYMTi3Or et3rlu26g00edrKLmetkJTvWv3zerM/Y4YKJ9TqOiHWdN33rI7cv2PUe9rSP3e12h/KM+Q7murN8 ylrX+rQLq/bG313BC++6xSf/dRWv3ex5VzrY4Q54Kbc98KBf/IEdr/PNT5a8kpcyWief96ez/vJ2 F3vgX2/2pTud7aK3RuKVfvvyvt3pdyf67TePcqOv9+xcv7jKUQ73nedeKTCv9779EP3nezsL1afE 761vk+yLexiH5774x0/+8pv//OhPv/rXz/72u//98I+//OdP//rb//74z7/+98///v77//8AGIAC OIBBcAALcIAHSIAKuA4I2IAH6F0LGH8IGB8UGB8LwAALEIH9d4ELYIEO2IAYOEH5pIF7YIAN8IEo eIAnCIFdMYIkWAYL0AAnKIM0WIM2WIMZKIIUVIE82IM++IMsKA8N4AA3WIRF6AAPkIP/44LWA4RO +IQ8+BUN8ABUWIVWeIVYaIVK+AKJszjVwISDIQq+M4ZkWIZmWIYOoxQLcIUQ0IZu2IZVCAEP8IZy WIUUpyEUMglKRS5gGBdieIaAGIhmyIKqg4cCggVTSIVyCIeLCIdz6IiLqIUyoCevcEBi6BL94BzJ w4UGU4ihYSff4h6COIqkGAAL/nCHNcM1mYIFDBCHkUiHruiGc2iFDACBesIxN+I3WxM5PuCDvjMV voOJbNCDB+QCXSgvQGKIBTiKYniKpUiGD2gcl+EyPrIUrviIsgiJ2ViHDxABtRgDt3gteLgbpWIg yliAQDgKmRiMmeiDCciJ5wgELkONiWKGB9gP95iPv+g7D7iO6siPpyiNuug3iDOOybiL0+iFPHAA rQiJWTiLWQgBESABHTiJCZmLfbMwGNk3Q5COo+CM+xhAPfiOxpiMuEiQV5OSUnOIy1iGCGiKDWiK +AiNMmmAHTiGF4iK5NgvO8kmGvmTPWkEAcAAEUCHRnmUbjiRDICKBrmRPamR/gOJkkTwhzTJjzIJ kmNogCEIj7mYKk1ZjvwRj9izkT9AlTIJk6cIks6IlWeZli65lFypi1A5lyAjlxcZlUQwlBKAlHwp kRIgAXA5A0FJl3bplHVJBPfokh95ipnAmGRogIDJlIMJOISpIHJyJCEyiDPpkmyJk46Jk4HZApRY mYRZIFB5BKZIlH1Jh0oZkDVAM4W5k4dZmFP5klnZjtMRH2XIAIBZkQJ5mk95mBWClx0jBM94nGfI AKHpJjwinM7ZlZ1IlkZggA5QlKsJARPQm0FYnEUCnWQpPDbDgciZmtppkbQJlBg5motDiUAwnu6Z mt8omtFJmpMZm7M5nQfI/gAOIAHWeZQTMJEOEI1LQI/sdIEYWIoX2JttBo7q6Z1gSZvKyJ4v1Znv CYgG6pvMeYj0OZBW85xH8IH6yZ8T4IYT8J8S4AAYOIFHcJBYAJ8UOoa8WZ6vyZ7Vcpc/Yio1EiK2 WaFnmJ+R2RUpqJz7yZ9/eaIp+oEr6olJ0JjKSaExeqBNQKBaMJRHmoJWeqU+SpHbOQw2aaXK2aRY uqVcaqBV+qSMqQQsSm1UGqNF2qZu+qZw2qZQ2oIeaKUUaIpdGoVeQZ5uioFiegO8eAZM+qWEWqiG eqiFeo9/KgxQ2KgUuKf4mIILqj7NiKU7CpNoCZKLag2PGgMVqBRiKAm+/viLR6SnKrCpL3iqnYoW pJqq7iemuemqCtiHslqrtnqruJqrurqrvNqrvvqrwBqswjqsxFqsV4AAxkpnciAHLMCsL7CsI7Cs yGoC0koC1WoEzpqt05qse6CtK+CsLYCs4goA3mqt01qu4HoE5VoF2ypI7UoT6eqt4Mqs8/quIjCu 1Pqu6Hqu+iqu7Xqt5Aqt5hqw0cqv92qvKgCwKZCuzVqvDHuw8SqwRbCvNaCwKPCwCeuwCKuwFisE FFux/8qv/nqwBEuy+bqx/Wqy6wqxJfuxJQCtH4uxF2uwGfus5HqzK9uyNCuzHkuzMpCz+Wqz45qz MYuwQwC0MBCxKruz/iM7syn7skxrsgW7tFQbtDpbtQ07sARbryXbtdZ6s1Y7tVfrtVsbshoLtV3r skkbsiTLtVxLrWCLtlqrtmVrrmc7sG+LtM/KtmMrr0bLslI7t1EruBArsBhbtIFbs2ILswb7tlCL snJLt4xbtYdLr4PLs4q7tE1ruWL7uCfAsIhrt33rs6IbujSgtKPbtn+Ls4m7uIPruq1buZRLupmb ulfLsxLbugGbt09ruoRruzGAuoiLu6Brr75ru0gbupgbrj7rsrn7sqxbvLMbrZ57vCxrvTP7uxSL uRIru2lrsft6rd6LvVkLu6nLvY6rvbQbvoYLuci7ui7Asa/7vJ67/ruTW7h2a7xNi7+6y7nTy7zq S7XcC7YyC7TSO7ZaG7mXC7/Za77bu7r4WsALrMCx677kO7EMzMAgewPLe7rNO7+4G729e7kn+76f 6790u7dS67whPLQj/L8Fu7mvW7oTrAT0iwQ3vLZAIL9Ym8OAK63+a7+iG7QRm75Ty7u6G7+5y8IQ rK3Verf8i7dmu62yi8Rku34drMEezMFazARZHAQd/K1d/H4+jK1jfMJlUMYYzMXc2sZu/MZwHMdy PMd0XMfxJwoOOKl2vGuZQAF+/MeA7Meousc11Md/XAF+bAEWEMgUwJSE/EYGCMgVcAEUUAGWzMgU gKGPbE0HwMiX/rzImOzH8bnJsWGq/hPJjEzJi3zJmDzKpGwCq4qJg6wQlYzIgUzJk0zJoVwBW/jK deARl6g+AVABFoABxnwBupzKyHwBtlzLjuzGYFiBWXk9FGABF4ABJZqdEtDMfnzNbdrMF8AAvrwO pDCqZ4o6w6zIGACYX0rMFoDI3szOyvnHzPzMxZpPovqDkWrPCrEAimzNFImADODO8VyltWzNvWzH TCjNIgmN5xwX3bzMF+CbQ6nO2RmYAVDN7zzJrlzHC32nB6qbDq3HoFrNEl0B4LAAFYABGdCb66DR /4wBy5mh3VGNUtp/5QzSKfqPI80+uSzR4kwWDIDNfioCFCDR/si8zjoZnat409MZABoQ1VI91VQt AJb6ktczgjxIpVhplhw4y8AwzEiNzEpIpslgzUit1AwqltJJBVAtklC4APKMqF/6o6iTz7rZpKSo nPyMDQfw0xJtRY0JDkc91motkOlZjhtakD1QjC/FmwldQeSc1weKhlTJ134I2ED9y3pQ2Gnd0pFt MuP4lR6KOHepA1DN2Y36jPEB2YQhDRQonmaIa76D2RVEARhg2BfQHgFwzYadAVv5m5Rpo6V9n+Wi AXDtqEN51Q34l2DNqJMtCk4YaP1g23CxANdszNptzCidCyu93dqdARMw0/LJoRdZn+dp3Dbw1uMp 13RN197I/pz+4dTBUoDRTasGVNvkLZjzqJBk0Nvgvd3MbMmTHODhTZGOjN7BmdgMTpyARdUQHuFR TQET+aYREAElugEavuEaLgF/1aCvaTf+TQOw7YSBaN020CRtTUhDbeAuHt7hPd6azIkHueAoWdw7 IOE6PtUWoOETsOEcEORCPuRDPgGhHaHqHZeCet/IieKfaN6sgN3gnQEvztIZQOVWbtcWiTXnbZI4 rgM7HuYXQORkXuZBbuRl06A36p0I2aHQSdxsvi/IM4wi3eT7vdZuHpR2iZ5OMJTbfeVV/uccIOPP TQZhvuNjbuaKfuYdzZJ7nt55g+NQUpBWc54yUOJ4bKW7/nnnwm2Iek6OBnnaTKDSgW7lgn7Rfe0H h67jic7hrv7qGx4BrsksIM7ni42Z9tngXumpkw2fdH2T+p3qtV6Xa36aTACZAY7lxqzsLM0BLR3c 7yAAFTDV077qFhDksJ7tG66lor2Ke87YdGknNZ3r6a2kc4eJLmqn6E6lwl7jzxmOEHrsvDkBLB3o GRDk4g2YhV4Gw1ztqy7V184B2p7tMq6K3m7skI6Xw0nulZkztC3bZ/gPwQ6ozcngpZnkDZOlE3Dl zM7x+K7NTn4NnbzRBO7vOt7jAw/r2TnrnlKNkL6hUunpxP7lI84IGJSaL5qJ1K3l/K2hswmb6A0F Ah2j/iXK8Uavzeycn6nuB+lM8iX/9CV/AT6ezVRf9T++8jPu7SyJi8CpklF58Q2ON8hT5xA/iC7h o42O2DJv3lwe70vq0HUNp1+amCT5Dgzpzv+c93qvyJNs9X6fza259O8Ak3Wd8+pYqCSdFGaZqVcK jfuuBVo50FA/+QQep5Yf8l/Rpfm5lIKIgoKhzw2d3KMaDyJNpu99+qd/5KCaqXNvqYSa9aC61Uzo 2Kr9qfDA0Myd+x/4+MDQmGSa+zDJ+65mynTeP/jNqI661bpPhsBzp5aa3Hg6zotfiutT54O41Ym/ x8RIisJP+iae/eNc+8RvQ9gf/qJH++b/aN6F/uk//khpKD/d3/6x30vHL/+QHP/2n//6v//83//+ //8gAIgjWZonmqor26KIG8szXdvvnes73/s/8IUYsoixIUyETJaWJGdQqEwaXVBVtYVsMk3VZTY6 MpK74jM6TSuvwlgALE41b9lws/o+Pc7b+FQc3Jjb1B9hml2elSLjThbbl9zgSaAXXZ9e5uTjVuGl pt2h5VNfJKihIKlhJ+koZ2QYkWmmKCCrrUwnGOXtbl7o31pXmaTeLNcq1x7tZTEwrzNmatHwXPQp 9JOmtlu3LGaiKvNyLe8y7mJg+Ph5I3nwDOf7vOjt9jz7JPs6/rNWdb9S8FgVM9dq1D5pB/2VU6bv /tsmJoQqOTRYr+AdWJ9m8ashL+Gei58c+nsITqHJgFYAgjQ28Mu9g/pInmyXsuXKhQUh2lQyTSbC i9uuXAkpsaYjlgwxWjpqEelNMChV5vOjU2WtOj1nbgUGZSLSjujeXTsm7qyUjN6uVR3EVmw8pWGZ Nkl1aCnNnmCxNmyH1+UbOUWB3oXKNaphaldBikToeN3fvS37/jtX0h43QbHm+q3DuelkeEGd5sM8 RvNiroXfTs0YOpdcvlg2G3Qc8Guy1z2KXs5KzLPbat6GEkzGsbWtj4lMu81LOBhPT4eNIoa9+FnW nzGFXscj+a+7ioDOUB4bPu0bMeXRB1kOlTnq/rJTIfMsKQ78efiK1tc+j8z/dHGhwdt7vh3lVXHd dGZWRNUB+CCEEUo4oQ0NiaYDf7ZRuCGHHXpIoX6/XKjYhyWaeCKKKaq4IostuvgijDHKOCONNdp4 I4456rgjjz36+COQQQo5JJFFGnkkkkkquSSTTTr55JAHSLkAlVUuICWUWWq54wFWevnllVuKGcQB AQhwJpoBHDAmD12C+aaVa7JJQgBmopmmmnLOeQAFFfhpAaB+ClqBAHrOGQOciXp56AF3OuponYZm KcCglVrqpwABHMqCm4p6GqaYdqLZJwWlmvqoppNeuqqlmW56Qqefeiqpk42OGmgFppqaKwV3/qpZ a6W4CmuAAZZagCmtc8oqKwMLbLnAmX0eeyav0gJqga6lnvmrkhQc++e3Bnwb7qDCCpoqo1UysG6z C6xLJbvtvusuu/A6C6Wd0hKarbeEVoDtv9jq6iqSB/wraKDiVlrsn8QqjDChm9K7rgMOwFsxlRU3 0IC7FbOLMbwMJJvkAqUGTOmlpY6L66AUoFukANfK/HC444qrQaAyA3rvmAGsu3EDEUTgAAMVe+xA AxgbTXTRTP/88pJdWtsnqznnyrKgFIz8Y8wzI1DszGBb8DCxOgcKdZY+A7100kYX3fTbbxO98cc8 M8knuJfmfCyg1gZbAdouJDD44CMUfsLh/ocDKIC41xJgAAEEXAt52GNLbrYBF9gtOOEJiKC4CYWD vkLnnpdOuBruAr06663H+3rdNSg+Oow+/4kBuDL/iwHf1/Ie8LWAy+7558TTbrrxxC/usMN+Rk4s Ao9DLnnkX2PegQSbszA78imIrjzpynPPyAJtL30++ka3vrrFwxsOfowHMOA774Bi8Pvu9P8u8wUS iEwD7bYHvwcFgHnPAxSxCBC9yD1OZ8yDXAcmwIDAeW+AApxBAAGQwSh0LH0edMDQPlixCGiPcxq0 4Iu6BLz7sVBn9TObBS4gQ/+V8IKIS17ikle8DYrhABd4oMPG1rjJlU2IBugAEjNAw63d/rCJO9Rh DjOIutChMAo+E6HQlja0EIqQgi2Y4vtyeEISdK54ZjyPu2CoRhfeTwL+axYTK4gC0b1vjGMUYyMW 0AHpAbGPDotcEifwxgV4cY4WTFwdv2dHKYLxjHm4IhaNlkUupi8C/7NBI8WHvO5pMJE6PI/8JHCB NZqNhRhw47sKGT5DhpGT36tiGgy2Rz8CUYGBRGWzuCWDAIKujIpspCF7CUsgdAmLWzwmJc8XgezF UQXAPKEi7fjEaQLIZxK43xpN6cZB6hKTKBRjNKM4TDEEQAJIXCAD04nEW3Kzm7s8pCbv6MpnUjGe jLCmCEE4wmRq0X+qDB/8fvlJedbx/kFlYsA1TanQNg6SkM384jfnuUjw0TN1DJjAOjO6zgxkQJAN dScA4XlGgZKRh440aRDcJQF+5lOLy2xWDqI50ZnStIwGVekEcqpTnW6zXQ99Z0HDKVE8hseaOeUo R3OKy3aB9AbjwyNJiVrSgkpTEV1CaBZb6tKXgsp9I4XiJ8E50PMEoGTrqsA23ViBdZmKSpH6QemC 6suwVlQNZZoY7OpFyH+GdIrcQ51QNxhXqjLiqitdKUslKbTFLjGm9oSmUFspUf+UqU5UauuX6qTZ zf4USJXdLGhDC9rOhspdiz0talFLQ74mSbNg2uxeRctZJUmptra9LW5tq1ksvYpO/h1zYwR2KjTh upFoXdXSZ2WrXOWSNke5fS50c9vbWNGrYmlNq8faVaXmCqm2kVqumiJV2eQ2tbvRPW90N0VdL72O aYnirmfRK9/b1oq3va3BepcFJ/iaFwDzhe59A5yC/OqXSretoYATrGBO/bfBC34whAfs3wb/N8IW vnAJ6CvfEdgXwx7+MIhDLOIRk7jEJj4xilOs4hWzuMUufjGMYyzjGdO4xja+sXpGPCIcx2gw/aHG gVbxih3vJjH/sBCRCxEcaAgnyUnBB4/boqHAaAYl+NkPctBRjvKooy1XFtFWIORkHylnJ2amhHZs cuXoqGXJrThOmNkDCacwyCe5/nEQbYbs5gZRJS5Ihk2QmayKMefAPsLQiXwCZBra4ETJX3bNo81D jHHU2TUaWnN9jAzpz1gnJuJpQ3yszGlGwKUyeBZIcj6tm1N35TPrKbNshDASZJCG0Y+OzJhhbYpK UwQoq6bOngcTHUMLiNWAkXRuDI2gjuC601SZ82xI4xy1jOQ3zHZ1ruWS6Fbf+dnNAAWU7zPqQxub zV6wC3QEIupwt9rbztaNueuCHH7Yej7JznSc5YxtTyvZ17+G9737XCFp9GYgoXaOsvEt5U0L3NRw PoXB1VHtsIDm1govdX+abSBFj3vZEnlKwz3SiwKJRhe70MigXdFkRVtG036A/jXEo+2JYY/cOCtv 98P5A3PslBzdaUk4uz3dbP9YiDyEVrWEiq6eo/v7B+6BMny6XO+GA6fRzYk0IjIEBK03/UEhUgPX A+T0kZMDLdmgtpn1rAy1C/3MC49yjZUehbDnG+52b47XmS72u/O9737/O+ADL/jBE77whj884hOv +MUzvvGOfzzkIy/5yVO+8pa/POYzr/nNc77znv886EMfYQWQvvSiPz0ASq96BaAe9KoXwetpxPob rP4EpjfB7UdA+tarKPep372MfD+D1QMf9rUnwfF/z/veF/9Gwo/B7X0P/NybfvqzXz6Kkm/72P/+ +t1H/vPBf33p7z783Se//vmNP3vqW3/862d987F/IuJv//js9z79UXB/8Wtf98knvveVQPQV3wC6 3/kFoPyZCAAKYPupn/+53/shoANO4ASaH/o9YArk3/dRYO1JYAIqYP+Jn/9xIAHGHwaSIATqXwni nwmq3wVS4AZG4AemCPe5IPuhoAYyYAqioAruIAyCHw/+oO7Z4AxmX/MBoAGiXw6eYBBuIO6toAg+ oQxWYAsqX/V5YBH6R/ztnxNa4RFWoQ4+oA+G3wueX/0FIRm+n/FlIYVwIRWyoPC5YRR2YQH2IP8J 4RueYAuWYBeyIYQgIf/VoBnqoCCKofYBYv2tYCEGYgAuofIZoh+2YQh+/l8cVuEkiqETXiEYDiIR rsAiWmAjbmIkbkn6jeLjlaIpNh4qpuLirSIrviIsxqIsziIt1qIt3iIu5qIu7iIv9qIv/iIwBqMw DiMxFqMsDoDj2ckALCMzNqMzPiM0RqM0TiM1VqM1XiM2ZqM2biM3dqM3fiM4hiM4bkuLCMAAPI84 pqM6riM7tqM7viM8xmM7Ts8AsNaDnCMB1KMxIkkAnKMBCMCHCED0AOQ+MgnjEABBTsgBEEtCFmST CCQySshCDgB/OWSPLCQB2CM5IUBEWqSWnGNF7kABNaRHZskAIEBI5gBCliSbDIABpGQNEAtLzokB dKQiCORM7klGFtY//ubknAgAATAC4/jkoaxkHhglQKEUGhiP9wgOh6RfI9bA+DGfCjzfIS5iGHLI UKrBVm4PGQXBOH2OV0bBAIWlDIBhVNLAVNIgFq7hGTIhC4iif+xkGtSkU34lXN2lM4lBWQKBJbKg VA6hjVjiI8JfWzKgGshlCSyjGtDlWBpOGM1RVUHTDt2Q+IhlZHYSZj6mJo0VZWqmZnJSZiLm/ZXf 62kiEKaeYKJmHbKmaRqmB1afW9YhJq4h9xkm7D0iDF5hICYiBiqiaspAV/ZQUOolZl4mFW0mch4S ZIZmc3YSU+6lck4naD7nckYnaA7QAI4gd1Ihd65lYarhbIqn9bkl/mLqpgGaZ3kWpgCyJwGu5hQG Z26epyKSpw0QAEyqwHCSTglgJ3NSp3OGjoBmZ39Wp2RSZ18WKGQiJ4FuZnfyYXeipwSC52vOp21O 3whG3/Y96IOKZ3jKJ3ySZxKmJyem5njS52GigAFoJA24ZAwEFIDiZYMGqILiJYNWJn8CKBglqFgy aGfSDoTqppAGKfIJphUeaYYi6ZGW34aqZ4eaZ28WaQxG4GmS6AGe54mmpmKaQE+eAWMaJ43+54xi p4w2543S6IHOqJnyp48+Z5NKaHAyKZy2p4XmJm5G5Z0WaZ4+IYeqp4cC4RZ6p5D66ZtC6XreYQ0M AEkCgUwaZ5sO/uiYOqh1HuekkiniTGqD8qiDIlKMEqptfiol8iF4eqqJbqGVeiFshuh3vueHGimJ jigHSul6EimI2sCXisGtChAwVdSN7ig8LWdJ+aebbqqvnmlVUZSkPlOVEqmofqF8hmKEkqq0hidu ZuhrUimVhqps5t9tVuiVjmdpQqArmkCuBkG5+oim9gCyMsKWbki77ogjssC5/sC88ki68sC6KsK7 Tsi+4khaykC99kDA/ohSAlWZpgFWfkjCAsklrsDA7sDDEiWURGwOUKzENonF2qpN7hK+XipZkqVZ xtSJhCzBhkfGJurGuoOYAgHJgukZtKwiGCuNwKyB5sHJtmjK/jbCyuYly8YsI4SszM4IzdKsDtzs DBgtpTJSQJnOVDFlZ/bnX13q6GRSzUZtjT6tjlatNDEtjkZq11JtRDnt0l6m0n4lDkEtRZVtj2Lt Z/bo1Y6mmqIsGiBtaFqq187OV2EqgRorp45pgsossFKqcopU3WLqo5KtdcKSPR2u3YapsCLosGbq 4/rtgD5q3OLs3ObsF3Xq22ZtdVqupHau6Npo5Lot5HLu6WYt054p6Hqs14apx1ou30on7HpuzUKn jCIr0ZIA3boA3U5usMrumkqW2cKt3kJW6QJv8aZu0Aau6uJuZg7W7eZu4vpV8uqoTXVt2wbv5P4o 4AoT2O6A/l2ewX6+KOcKb+pO77DyKPoqaPPe7fFS7+dWKvQW6M5Cautebu2qb+jea/serOBOL9fm QJeKQfne5exurd6SqfAmsORer/5u6vBGsPOqaa8uaPzi7wKjbvdu8OU6b/v+Z+vuLgmsKBocQHEC EAcPMPK2UrJOrdWi7dJScL5CqvZmb9iy7tSubwzPL9TG6I4mby8FK9oSsdQuMNvero8ezw6gcH6q gGN6GAl7yBS7LLruwAEDQe+ySRVzSBc/ZpBU8Ra7QACk8IUVrJZ8MYqgMRSz6H0u6sU+SRYHAVDG sZggJdjBsR0rSR0LJX7uca0ggB57qQEAcpOMbyNMpCEro8k5+kcAcOQiH8k5uvEP5GMkE0kjQ0gB veQl/8gmPzHECnIn8whQau7iRM4gj7KLAGUUb8hB6qMqv4g5Pk4qT0g/Pk9NyqMu7zIv97Iv/zIw X2MCIfKKlIk5BjMyJ7MyLzMzM/O2gHIsR7M0TzM1V7M1XzM2Z7M2bzM3d7M3fzM4h7M4jzM5l7M5 nzM6p7M6rzM7t7M7vzM8x7M8zzM91/OLhAAAOw== --------------853225274187207767158270-- From sip-bounces@ietf.org Wed Mar 14 07:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRRuU-0005CG-6c; Wed, 14 Mar 2007 07:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRRuS-0005BB-GM for sip@ietf.org; Wed, 14 Mar 2007 07:44:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRRuP-0006UG-1R for sip@ietf.org; Wed, 14 Mar 2007 07:44:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2007 07:44:45 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2EBiiVq023617; Wed, 14 Mar 2007 07:44:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2EBielG002602; Wed, 14 Mar 2007 11:44:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 07:44:40 -0400 Received: from [192.168.1.104] ([10.86.242.218]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 07:44:39 -0400 Message-ID: <45F7E027.9010109@cisco.com> Date: Wed, 14 Mar 2007 07:44:39 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> <45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com> <45F737F6.5000208@acm.org> In-Reply-To: <45F737F6.5000208@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 11:44:39.0731 (UTC) FILETIME=[261CF830:01C7662E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4788; t=1173872684; x=1174736684; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-02 |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=DcQY9e7y7EQjfWUGzgdRHcHHmOXHJoxCye2ixT45tks=; b=uPFw3Zs8I4zwTGZ20Vd7uMBUt3VG94BSXbHhhc+bS4LwuXsq+Gw4y4qLsBS4BFWdvuOJrdbq DY/jZ0hU11K8orkufVqTljVyAPuLcFJ6NFj8SmHmy8C0oZ/VzQThZl0G; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK, I still think this is way too complicated. My first thought is to just not solve it. We don't need to deprecate UDP because of this; we just need to have some tools to alert SIP administrators that this problem has happened. So, if an outbound proxy receives a request that is large, and it cannot deliver it to the UA over UDP, it rejects the request with a new resposne code that signals this case. Proxies can generate SNMP alarms or traps or whatever, and someone can go and buy new clients and proxies that use TCP. The alarm gives them the warning that the time has arrived to fix this problem. A variant on this is to just send it over UDP anyway, and include a warning in the response that has the same alarming effect - there is a ticking time bomb here since fragmentation is going to be a problem. Note that even with fragmentation the request may never get delivered over UDP due to NAT handling of fragments; in that case the outbound proxy will timeout and include a warning about this case. These two solutions at least recognize this error case but don't try to dynamically repair it. An alternative to dynamically repair it is to use the reg-event package for the notification, since we already have that. Outbound proxy would reject the request, with this new response code. It would pass through the home proxy/registrar which will generate a notification to the client telling it to re-register over tcp. Registrar proxy holds onto the response until the new registration arrives. When it does, it can add a retry-after or actually just sequential fork and retry the request again. This approach is still complicated but doesn't introduce any fundamental new machinery. I'm still inclined to just stick with a new response code. My rationale is that if your client can do tcp (which is required for the dynamic repair approach), may as well have it always connect via tcp. I don't buy this bit about wanting hybrid UDP TCP because of scale. The problem you've raised in your draft argues to me the opposite - folks whose tcp scale is a problem need to FIX it, since there is this issue with UDP outbound. The new response code gives them a warning that this is actually happening in their networks, and the time has come to switch on tcp. Thanks, Jonathan R. Marc Petit-Huguenin wrote: > Dean Willis wrote: > >>Jonathan Rosenberg wrote: >> >>>Ah sorry, my bad. My fault for skimming to fast. I'll take another >>>look and provide some useful comments.... >> >>It's still way too complicated. However, that level of complexity may be >>required due to the underlying complexity of SIP and multiple transport >>protocols and their inherent limitations. >> >>But I still wish it were simpler. >> >>Making it simpler, however, probably requires re-examining some of our >>more basic assumptions. >> >>One approach would be to fall back to using UDP simply as a >>register-and-alert protocol. >> >>In this model, user devices would "register" using UDP, then receive >>"imminent request" messages that would cause them to setup a TCP >>connection ala outbound. (Not too different from what Marc has now). >> >>One could conceivably model the "imminent request" notification as an >>event package. > > > Yes, this can be a solution. I choose a STUN extension because the > decision to switch or not over a TCP connection is done in the transport > layer where STUN is already used for keep-alive. > > The problem is not in fact how to signal to the endpoint that it must > open a TCP connection - this can be done by a STUN message or by a SIP > message. The problem is how to find the newly created TCP connection on > the proxy side; because the endpoint is behind a NAT and there can be > multiple endpoints behind this NAT, the source IP address can not be > used for this. > > >>The difference here is that all traffic other than the registration, >>related registration-events, and "imminent request" subscription and >>notficication (the two event packages could be combined, I think) would >>go TCP. So there'd be no run-time sizing, Path-MTU discovery, or related >>complexity. >> >>Bonus: We'd get to keep the high fan-out property of UDP edge proxies >>when we have "mostly idle" clients. Note that presence would sort of >>break this, of course. >> >> >> >>-- >>dean >> >> > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 08:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSZY-0004fB-VZ; Wed, 14 Mar 2007 08:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSZX-0004f6-Ll for sip@ietf.org; Wed, 14 Mar 2007 08:27:15 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRSZW-0006mr-2q for sip@ietf.org; Wed, 14 Mar 2007 08:27:15 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2ECQhQ7012021; Wed, 14 Mar 2007 14:27:06 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:27:05 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:27:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Wed, 14 Mar 2007 14:27:04 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F037588FA@esebe103.NOE.Nokia.com> In-Reply-To: <45F7E027.9010109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 thread-index: AcdmLwzoK1B9w/20RpiQVfn/d2PHzwAAvqmw References: <45EC200D.5010506@acm.org><45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org><45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com><45F737F6.5000208@acm.org> <45F7E027.9010109@cisco.com> From: To: , X-OriginalArrivalTime: 14 Mar 2007 12:27:06.0473 (UTC) FILETIME=[1416F590:01C76634] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070314142707-2E449BB0-08274506/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 1.3 (+) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >OK, I still think this is way too complicated. I agree. >My first thought is to just not solve it. We don't need to=20 >deprecate UDP=20 >because of this; we just need to have some tools to alert SIP=20 >administrators that this problem has happened. ....The alarm=20 >gives them the warning that the time has arrived to fix this=20 >problem. Jonathan, you must be kidding. I find this kind of approach as horrible. Let the provider buy=20 proxies and customers buy phones just to find out after some time that they do not work and the customers are not able to receive all the calls. Then start fixing it some way or another. How many days/weeks would be needed for the customers to find out that they have some random problems and stop using the service ? I can not believe we in IETF would be happy to drive things like that. >An alternative to dynamically repair it is to use the=20 >reg-event package for the notification, since we already have that.=20 >Outbound proxy would reject the request, with this new response code.=20 >It would pass through the home proxy/registrar which will generate a=20 >notification to the client telling it to re-register over tcp.=20 The problem is that the size of the simplest reg-event notifications=20 I have seen are close to 1000 bytes. The ultimate size will depend on a number of things but there is a risk for the NOTIFY to become bigger than MTU so that it can not be delivered over UDP. There is a potential chicken and egg problem in this proposal. >My rationale is that if your client can do tcp (which is required=20 >for the dynamic repair approach), may as well have it always connect=20 >via tcp. I don't buy this bit about wanting hybrid UDP TCP because of=20 >scale. The problem you've raised in your draft argues to me the opposite=20 >- folks whose tcp scale is a problem need to FIX it, since there is this=20 >issue with UDP outbound.=20 I agree. Said that, it seems to me once again that the idea to=20 keep UDP within the Outbound draft _is_ a bad idea. Regards, Erkki >Thanks, >Jonathan R. > >Marc Petit-Huguenin wrote: > >> Dean Willis wrote: >>=20 >>>Jonathan Rosenberg wrote: >>> >>>>Ah sorry, my bad. My fault for skimming to fast. I'll take another >>>>look and provide some useful comments.... >>> >>>It's still way too complicated. However, that level of=20 >complexity may be >>>required due to the underlying complexity of SIP and=20 >multiple transport >>>protocols and their inherent limitations. >>> >>>But I still wish it were simpler. >>> >>>Making it simpler, however, probably requires re-examining=20 >some of our >>>more basic assumptions. >>> >>>One approach would be to fall back to using UDP simply as a >>>register-and-alert protocol. >>> >>>In this model, user devices would "register" using UDP, then receive >>>"imminent request" messages that would cause them to setup a TCP >>>connection ala outbound. (Not too different from what Marc has now). >>> >>>One could conceivably model the "imminent request" notification as an >>>event package. >>=20 >>=20 >> Yes, this can be a solution. I choose a STUN extension because the >> decision to switch or not over a TCP connection is done in=20 >the transport >> layer where STUN is already used for keep-alive. >>=20 >> The problem is not in fact how to signal to the endpoint that it must >> open a TCP connection - this can be done by a STUN message=20 >or by a SIP >> message. The problem is how to find the newly created TCP=20 >connection on >> the proxy side; because the endpoint is behind a NAT and there can be >> multiple endpoints behind this NAT, the source IP address can not be >> used for this. >>=20 >>=20 >>>The difference here is that all traffic other than the registration, >>>related registration-events, and "imminent request" subscription and >>>notficication (the two event packages could be combined, I=20 >think) would >>>go TCP. So there'd be no run-time sizing, Path-MTU=20 >discovery, or related >>>complexity. >>> >>>Bonus: We'd get to keep the high fan-out property of UDP edge proxies >>>when we have "mostly idle" clients. Note that presence would sort of >>>break this, of course. >>> >>> >>> >>>--=20 >>>dean >>> >>> >>=20 >>=20 >>=20 > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 08:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRT1W-0006RN-De; Wed, 14 Mar 2007 08:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRT1T-0006R0-6i for sip@ietf.org; Wed, 14 Mar 2007 08:56:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRT1R-0004Fk-Oi for sip@ietf.org; Wed, 14 Mar 2007 08:56:07 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2ECtluJ000562; Wed, 14 Mar 2007 14:56:02 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:56:01 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:56:02 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:56:00 +0200 Received: from [172.21.40.89] (esdhcp04089.research.nokia.com [172.21.40.89]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2ECtwPN019602; Wed, 14 Mar 2007 14:55:58 +0200 Message-ID: <45F7F0DC.30006@nokia.com> Date: Wed, 14 Mar 2007 14:55:56 +0200 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ext David Viamonte Subject: Re: [Sip] Updated draft-niemi-sip-subnot-etags References: <45549BFD.1010008@genaker.net> In-Reply-To: <45549BFD.1010008@genaker.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 12:56:00.0814 (UTC) FILETIME=[1DD664E0:01C76638] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070314145602-019CBBB0-3EEEC38A/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi David, I seem to have never replied to this email, but I did read it. ;-) pe, 2006-11-10 kello 16:34 +0100, ext David Viamonte kirjoitti: > The problem I see with this is that the Watcher is not able to > determine whether the "etag" was the same, or simply a subsequent > "NOTIFY" message gets lost due to congestion problems. Good point. This got fixed in the latest version by introduction of the new response code 204 (No Notification). > PS.- I agree that covering the RLS case in this doc would be extremely > desirable, as Etags and RLS are seen as two major Presence traffic > optimization mechanisms, and it would be very convenient to be able to > use them together. There is now a dedicated section to talk about List Subscriptions. It has an open issue though, so suggestions are welcome. Thanks again for the comments. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 09:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTFe-00045J-3a; Wed, 14 Mar 2007 09:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTFc-00042c-65 for sip@ietf.org; Wed, 14 Mar 2007 09:10:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTFT-00076A-MD for sip@ietf.org; Wed, 14 Mar 2007 09:10:44 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3F23D20449; Wed, 14 Mar 2007 14:10:35 +0100 (CET) X-AuditID: c1b4fb3e-b01efbb0000061ca-fa-45f7f44b7ebf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 344D220079; Wed, 14 Mar 2007 14:10:35 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:10:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2007 14:10:33 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702A4D5AD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-08: Editorial comment on chapter 3.5.1 Thread-Index: AcdmOiYnxbZKF2kVSmqa8keNVN46Ag== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 14 Mar 2007 13:10:34.0879 (UTC) FILETIME=[26D220F0:01C7663A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Outbound-08: Editorial comment on chapter 3.5.1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Chapter 3.5.1 says: "If the server does not receive a "pong" within an appropriate amount of time, it considers the flow failed." Should it be: "If the CLIENT does not receive..."? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 09:17:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTLn-00080G-1v; Wed, 14 Mar 2007 09:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTLl-0007wg-Ps for sip@ietf.org; Wed, 14 Mar 2007 09:17:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTLh-0000HK-GJ for sip@ietf.org; Wed, 14 Mar 2007 09:17:05 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0746320F8C; Wed, 14 Mar 2007 14:16:59 +0100 (CET) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-1b-45f7f5ca1ec9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E000B20449; Wed, 14 Mar 2007 14:16:58 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:16:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2007 14:16:57 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702A4D611@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-08: Editorial comment and question on chapter 5.4 Thread-Index: AcdmOwrlogAHxjzFT+SI8yAMDm3ekQ== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 14 Mar 2007 13:16:58.0792 (UTC) FILETIME=[0BA69A80:01C7663B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Outbound-08: Editorial comment and question on chapter 5.4 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The text in chapter 5.4 says: "When a server receives a double-CRLF sequence on a connection oriented transport such as TCP or SCTP, it MUST immediately responds with a single CRLF over the same connection." I would propose the following: "All edge proxies compliant with this specification MUST implement support for the CRLF keepalive mechanism on its SIP ports as described in Section 4.4.2." QUESTION: should the CRLF keepalive mechanism be described separate from the outbound mechanism itself (similar to STUN keepalive, which is described in chapter 8), in case someone wants to use it without outbound? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 09:26:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTU9-0006oi-Bj; Wed, 14 Mar 2007 09:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTU8-0006mQ-4L for sip@ietf.org; Wed, 14 Mar 2007 09:25:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTU6-0001ua-Ef for sip@ietf.org; Wed, 14 Mar 2007 09:25:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D814920614; Wed, 14 Mar 2007 14:25:37 +0100 (CET) X-AuditID: c1b4fb3c-a9cedbb0000073d5-4b-45f7f7d1941a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C5EF5204DE; Wed, 14 Mar 2007 14:25:37 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 14:25:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Mar 2007 14:25:36 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702A4D6AA@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-08: usage of keep-xxx parameter Thread-Index: AcdmPEApso/+pA65RRK0OFnQKrPD+g== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 14 Mar 2007 13:25:37.0459 (UTC) FILETIME=[40CCE830:01C7663C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Outbound-08: usage of keep-xxx parameter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729065191==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0729065191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7663C.407B93DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7663C.407B93DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If all outbound compliant edge proxies MUST implement all keep-alive mechanisms, why do we need to list the different keep-alive mechanisms (keep-stun, keep-crlf etc) in the outbound-proxy-set URIs? Isn't it enough to simply include the 'ob' URI parameter? If all oubound compliant edge proxies MUST implement all keep-alive mechanisms, do we need to keep-xxx parameters in the first place? Regards, Christer ------_=_NextPart_001_01C7663C.407B93DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Outbound-08: usage of keep-xxx parameter

Hi,

If all outbound compliant edge proxies = MUST implement all keep-alive mechanisms, why do we need to list the = different keep-alive mechanisms (keep-stun, keep-crlf etc) in the = outbound-proxy-set URIs? Isn't it enough to simply include the 'ob' URI = parameter?

If all oubound compliant edge proxies = MUST implement all keep-alive mechanisms, do we need to keep-xxx = parameters in the first place?

Regards,

Christer

------_=_NextPart_001_01C7663C.407B93DA-- --===============0729065191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0729065191==-- From sip-bounces@ietf.org Wed Mar 14 09:43:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTkp-0000so-SA; Wed, 14 Mar 2007 09:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTkn-0000sZ-E9 for sip@ietf.org; Wed, 14 Mar 2007 09:42:57 -0400 Received: from s23.avahost.net ([67.15.10.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTkd-0006cm-OF for sip@ietf.org; Wed, 14 Mar 2007 09:42:57 -0400 Received: from cpe-71-64-10-221.ma.res.rr.com ([71.64.10.221] helo=Critical1) by s23.avahost.net with esmtp (Exim 4.63) (envelope-from ) id 1HRUlu-0005p3-Ij; Wed, 14 Mar 2007 09:48:10 -0500 From: "James Smith" To: "'Dean Willis'" , References: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> Subject: RE: [Sip] News flash: Verizon appears to have exclusive rights to IPtelephony and SIP proxy operations -- The WayBack Machine Date: Wed, 14 Mar 2007 09:42:53 -0400 Message-ID: <006c01c7663e$aba6a860$8601a8c0@Critical1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <17B5F119-F36E-4B65-91EC-7DB9754D0928@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acdija5yv9nLUVzVRb6Plyx6QtSLqQDr66oQ X-PopBeforeSMTPSenders: critical@critical1.com, developer@critical1.com, employ@critical1.com, info@critical1.com, isr@critical1.com, james@critical1.com, myaccts@critical1.com, mybiz@critical1.com, myfax@critical1.com, mynews@critical1.com, mytech@critical1.com, nancy@critical1.com, redcell@critical1.com, tcog@critical1.com, technews@critical1.com, tenakina@critical1.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s23.avahost.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - critical1.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The WayBack Machine -- http://www.archive.org/web/web.php has proven very helpful to the folks debunking the SCO lawsuit against the Linux community. Perhaps it will contain some of those documents deleted from the "official" IETF websites (not to mention other non-IETF documents) that could negate the VZ patents? James T Smith Critical 1 Consulting, Inc. http://www.critical1.com/ PO Box 4188 Clarksburg, WV 26302 304-657-4258 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, March 09, 2007 3:56 PM To: SIP IETF Subject: [Sip] News flash: Verizon appears to have exclusive rights to IPtelephony and SIP proxy operations Importance: High I don't normally discuss patent-related issues here, but this one has me worried. According to C/NET (http://news.com.com/2100-1036_3-6162747.html) "The broader dispute rests on allegations by Verizon that features central to the success of Vonage's offerings infringe on five of its patents. They relate to various aspects of commercial voice over Internet Protocol, or VoIP, service, including methods of connecting Internet calls to the public-switched telephone network, enabling features like call forwarding and voice mail, and allowing Internet phone usage via Wi-Fi hot spots." If I'm reading this right (along with what I've managed to winkle out of the reporting coverage) it looks like the courts have proclaimed that Verizon has exclusive rights to processing phone numbers in a proxy, making conditional forwarding decisions based on presence, making calls from WiFi attached devices, and so on. This is amazingly huge, and very clearly has implications (if not overturned) on our work. Like, "We might as well all go home" sorts of implications. You might take a look at patents 6,104,711 and 6,282,574 by Eric Voit, and 6,359,880 by James Curry and Robert Farris, as I believe the courts considered these in the Verizon vs Vonage case. 6,104,711's abstract: An enhanced name translation server, for use on a packet data network such as the Internet, executes a conditional analysis in response to at least some queries or requests for name translations. For example, the server may return a different destination address at different times or in response to translation requests from different terminals. The server also can query a primary destination terminal device, and condition the response to the calling terminal on the status of the primary terminal. For example, if the primary terminal is `live` the server forwards the address of that terminal to the calling terminal device to set up communications. Otherwise, the server returns alternate destination address information. The server also supports a wide variety of different types of translations, including domain name to address, domain name to telephone number, and telephone number to address. The enhanced translations offer called customers numerous options for controlling communications directed toward them, and the customers may elect to apply these options both to their data communications services and their voice communications services through the packet data network. 6,282,574's abstract: An enhanced name translation server, for use on a packet data network such as the Internet, executes a conditional analysis in response to at least some queries or requests for name translations. For example, the server may return a different destination address at different times or in response to translation requests from different terminals. The server also can query a primary destination terminal device, and condition the response to the calling terminal on the status of the primary terminal. For example, if the primary terminal is `live` the server forwards the address of that terminal to the calling terminal device to set up communications. Otherwise, the server returns alternate destination address information. The server also supports a wide variety of different types of translations, including domain name to address, domain name to telephone number, and telephone number to address. The enhanced translations offer called customers numerous options for controlling communications directed toward them, and the customers may elect to apply these options both to their data communications services and their voice communications services through the packet data network. 6,359,880's abstract: A localized wireless gateway system provides wireless telephone communication, and for at least interexchange communication, provides voice telephone access to a public packet data network, such as the Internet. The wireless gateway system includes base station transceivers and a packet service gateway coupling the transceivers to the public packet data network. The packet service gateway compresses and decompresses voice frequency communication signals, and it sends and receives the compressed signals in packet form via the network. The packet service gateway also provides for signaling through the network to establish two-way voice communication sessions. In the preferred implementation, the localized wireless gateway system includes at least one radio port control unit coupled to the base station transceivers for controlling calls through the transceivers. The localized wireless gateway system also includes a telephone switch, such as a digital PBX, selectively providing telephone communication channels between the radio port control unit(s) and the packet service gateway. An access manager controls registration and validation of roaming wireless telephones to utilize the wireless gateway system. The access manager also transmits location information for registered wireless telephones to a home location register database via the network. The communications of the access manager to the home location register database permit telephone authentication as well as maintenance of accurate location information in the home location register identifying the current gateway through which a caller can reach the roaming user's wireless telephone. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 09:48:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTpN-0003CO-VO; Wed, 14 Mar 2007 09:47:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTpM-0003BS-Ui for sip@ietf.org; Wed, 14 Mar 2007 09:47:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTpH-000052-In for sip@ietf.org; Wed, 14 Mar 2007 09:47:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2007 09:47:35 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2EDlZJU010548; Wed, 14 Mar 2007 09:47:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2EDkaHF003163; Wed, 14 Mar 2007 13:47:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:47:23 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:47:23 -0400 Message-ID: <45F7FCEA.4030201@cisco.com> Date: Wed, 14 Mar 2007 09:47:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <818435.94731.qm@web31509.mail.mud.yahoo.com> In-Reply-To: <818435.94731.qm@web31509.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 13:47:23.0212 (UTC) FILETIME=[4B1700C0:01C7663F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8671; t=1173880055; x=1174744055; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20Kapil=20Nayar=20; bh=cWKq4CT4N1ycfWZgywRps+jZYWvW1TUjpR+NRop/wv0=; b=CWXSwwv3WqY/RxGXh3mMbd5HGaLkNrdLm/JABN0GL1zlz+DxTYBiOcYTM9nGnq2uJl36N9Ue y0ttowEea7A4ahxBkpe8NkQ/jt55iGsyF+KpM01RAGLgQ6CuxOIZbUcO; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Kapil Nayar wrote: > Hi Takuya > > Thanks for the reply. > I would agree with you - since RFC 3261 does not > clearly restrict the "SDP" (but only offer) in 1xx and > 200OK AFTER the completion of the first o/a exchange. > What do you think should be the behavior of the UAC if > the UAS sends an SDP-offer (a new session ID - new > media) in 100Rel/ 200OK in the above case? I don't understand exactly what case you are describing. Do you mean: UAC UAS | INVITE w/Offer1 | |----------------->| | 1xxRel w/Answer1 | |<-----------------| | PRACK | |----------------->| | 1xxRel w/Offer2 | |<-----------------| | ?????? | |----------------->| If so, I can see little to do other than send some error response to the PRACK. I think ignoring in that case would be a mistake. Its not nice to reject a PRACK, but it seems the only option. Paul > Would > ignoring suffice or you would like to recommend UAC to > cancel the call since UAS violated RFC 3261. > > Also, you might want to take note of the corrections > indicated inline KN>>. > > Thanks, > Kapil > > --- Takuya Sawada wrote: > >> Hi, >> >> I just catched up the discussion... >> >> Comments inline with [TS]. >> >>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE BELOW >> AND COMMENT *** >>> (References are to figures in >> draft-ietf-sipping-sip-offeranswer-00.) >>> Comments inline. >>> >>> Paul >>> >>> Kapil Nayar wrote: >>>> Thanks Paul for the clarifications. >>>> Replies inline. >>>>> If you were to allow a second o/a exchange via >>>>> reliable 1xx, then it would have the potential >> for a race with a >>>>> concurrent UPDATE in the other direction. And >> that would result in a >>>>> need to >>>>> send an error response. But PRACK isn't prepared >> for carrying an >>>>> error response. Forcing subsequent o/a to use >> UPDATE avoids this. >>>> KN>> Perfect. So UPDATE (with SDP) support is >> sort of >>>> mandatory for implementations which want to >> enable >>>> changing early-media. >>> Yeah. It would be quite unwise to support 100rel >> and not UPDATE. >>>>>> 2. Just to clarify, in Figure1 "After F6 UAC >> and >>>>> UAS >>>>>> can send a new offer in an UPDATE request", I >>>>> guess >>>>>> the authors meant F7. >>>>> Debatable. I think the UAS can send an UPDATE >> after >>>>> sending F6, without waiting to receive F7. (With >> the understanding that >>>>> the UPDATE could fail if received before F6.) >>>>> >>>>> The UAC should probably wait until it sends F7. >>>> KN>> I would agree with mandating UAC to wait >> until it >>>> sends F7. >>> I don't feel too strongly about this. I think it >> would probably be wise to >>> wait until after F7, but if somebody wants to jump >> the gun and is prepared >>> for the potential error if F7 was lost then I >> guess that is their >>> business. >>> >> [TS] >> I did not care so much on F6 or F7. >> Now I agree with that waiting unil F7 is better and >> safe. >> Probably we can modify the figure in a later >> version. >> >>>>>> 3. In the description for Figure1 it is >> indicated >>>>> that >>>>>> F12 (final response) should not contain an SDP, >>>>> and if >>>>>> it does and is different than F6, the UAC >> should >>>>>> discard it. (Similar description is present in >>>>>> Figure2.) >>>>>> >>>>>> a).Does this mean that a UAS cannot change the >>>>> early >>>>>> media to a final media in final response? >>>>> It means that each offer has been answered, and >> that >>>>> once an answer has been sent, it can't be >> changed without another >>>>> offer/answer cycle. And that another >> offer/answer cycle may not be >>>>> initiated >>>>> in the 2xx if one has already been completed. >>>>> >>>>> This last is part of a principle that was >> discovered >>>>> during the evolution of this work: At most one >> offer and one >>>>> answer per transaction. >>>>> >>>>> At the time of F12, if the UAS wants to change >> the >>>>> SDP, it can send an UPDATE before sending the >> 2xx for the INVITE. Or it >>>>> can send the 2xx and send an UPDATE or reINVITE >> after the ACK. >>>>>> b).If F12 carries SDP, it should be designated >> as >>>>> a >>>>>> new offer-SDP, right? If UAC discards the >>>>> offer-SDP in >>>>>> F12, is it still obligated to send an >> answer-SDP >>>>> in >>>>>> ACK? >>>>> No. This is all as specified in 3261. Having >> sent an >>>>> unreliable provisional with an answer in F2, if >> there is any >>>>> SDP in the 2xx it must be identical to what was >> sent in F2. It is *not* >>>>> another offer, and so it there must not be an >> answer to it in F13. >>>>>> c).If UAC accepts the offer-SDP in F12, can the >>>>>> answer-SDP in ACK be different than the one >>>>> originally >>>>>> offered in F1? What is the behavior expected at >>>>> the >>>>>> UAS upon receiving this different media? >>>>> See above. >>>> KN>> Actually, there is some confusion here. In >>>> Figure1 and Figure2 call flows there is a >> successful >>>> completion of the o/a through reliable 1xx. As >> per RFC >>>> 3261..."Once the UAS has sent or received an >> answer to >>>> the initial offer, it MUST NOT generate >> subsequent >>>> offers in any responses to the initial INVITE." >> However, if you read the >>>> description in line with the >>>> figures it seems we have relaxed the MUST NOT to >>>> SHOULD NOT. >>>> Figure1 - UAS should not include an SDP in the >>>> responses F9 and F12. Figure2 - UAS should not >> include >>>> an SDP in the responses F6 and F9. >>> It has been a long time, and I no longer remember >> the rationale that led >>> to the SHOULD here. Note that in these figures the >> SDP in the 2xx is not >>> to be considered an offer. It is just a piece of >> redundant data. >>> Personally I would be happy to say that the UAS >> MUST NOT include SDP in >>> the 2xx in these examples. But I would also like >> to say (this is a best >>> practice) that the UAC SHOULD/MUST ignore any SDP >> that arrives in the 2xx >>> in these cases. This happens a lot in the wild, so >> one ought not break in >>> these cases. >>> >>> But I would like to hear from Takuya (who is the >> primary author) and >>> others on this. >>> >> [TS] >> RFC 3261 says "UAS MUST NOT generate offer", not >> "UAS MUST NOT include >> SDP". I guess some may interpret this as follows; >> >> UAS can include the same SDP both 1xx and 2xx. >> It does not care whether 1xx is reliable or not. >> If 1xx is reliable, SDP in 1xx is the answer and >> if not, SDP in 2xx is the >> answer. >> Some SDPs may be neither an offer nor an answer, >> just a hint or nothing. >> >> I would be also happy to say "UAS MUST NOT" but I >> could not conclude to >> say that. Clearly some implementation would violate >> "MUST NOT" rule. >> That is why I put the following description in the >> draft. >> >> UAS should not include an SDP in the >> responses F9 and F12. However, >> UAC should prepare to receive an SDP in F9 >> and/or F12, and just >> ignore them for the case that the peer does >> not conform to the >> recommended implementation. > KN>> > This is a bit confusing on the first read. Actually, > it seems you are trying to refer to the generic cases > in table1 in the description for Figure1(2)- with > reference to the Figures 1(2), SDP in F9(F6) and > F12(F9) will always be ignored. Isn't it? The case > w.r.t. the Figure is always non-conformant. > > Further, the conformant case is when the o/a exchange > has not already taken place in the transaction. > > You may want to disassociate (correct) these text > description. > > >> Regards, >> Takuya >> >> >>>> And, it sort of opens the discussion to possible >>>> scenarios where another o/a can be initiated. Is >> this >>>> intentional? >>> Definitely not. >>> >>> 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 >> >> > > > > > > ___________________________________________________________ > The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From Chris@panix.com Wed Mar 14 09:54:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTw1-00078s-TP for sip-archive@lists.ietf.org; Wed, 14 Mar 2007 09:54:33 -0400 Received: from host40-57-static.29-87-b.business.telecomitalia.it ([87.29.57.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTvl-000277-Cs for sip-archive@lists.ietf.org; Wed, 14 Mar 2007 09:54:33 -0400 Message-ID: <000a01c76640$42fbd950$00000000@SERVER> From: "Foot" To: sip-archive@lists.ietf.org Subject: Ice Date: Wed, 14 Mar 2007 14:54:19 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C76648.A4C04150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 ------=_NextPart_000_0006_01C76648.A4C04150 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C76648.A4C04150" ------=_NextPart_001_0007_01C76648.A4C04150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Loving eases strain punk icon stickman! Though played seriously, dated = audience large streak, satire. Kmarks buddy support buttons caption = matchup month costar. Steven fuck tina needs intro drawing joey ramone = ago. Dozens scheming impressed considers, religion kick ass? Supreme = youngblood glory retooling derivative settings viable violent analogue. = Guide fan times winning favorite cbg. Clapton halen hagar eagles doors stones doobies allman. Brief = appearance, young boy carries killings. Backing tracks admired, mike = spirit. Fearful symmetry near secondlast second example interest. = Turtles dont friends huge, harem cheesy slags prude, musicfilms! Flip, = soaring mapped, sit? Stan leethe concluded annual? Nd rub shy charlie = watts ever paying customer. Done germany getting phil massaged pic = summer drummers. Tickets exchange concert, clothing vendor looked = exactly pregnant. Catherine zeta jones charlize? Blooker prize honours blogs iran condemns = hollywood epic. Penguin joker creature effects jokers. Thats not quite = true still forced, togt use work. Certain, attributes theregt some = available thus forcing, agt. Melody breaks standard axe danelectro = bellzouki string. Pisses emalee thanx birthday xoxo angel. Musical, = elite decades she describes, herself. Gastiain gastain pitt niamhmenet = goldderby. Week rainin memphis tons. Vampires werewolves parkhouse = closed. Projects light cia covert operations bill anthology, aargh rampant. = Decoding sexual meanings alices adventures wonderland pan. ------=_NextPart_001_0007_01C76648.A4C04150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Loving eases strain punk icon stickman! = Though=20 played seriously, dated audience large streak, satire. Kmarks buddy = support=20 buttons caption matchup month costar. Steven fuck tina needs intro = drawing joey=20 ramone ago.
Dozens scheming impressed considers, = religion kick=20 ass? Supreme youngblood glory retooling derivative settings viable = violent=20 analogue. Guide fan times winning favorite cbg.
Clapton halen hagar eagles doors stones = doobies=20 allman. Brief appearance, young boy carries killings. Backing tracks = admired,=20 mike spirit. Fearful symmetry near secondlast second example interest. = Turtles=20 dont friends huge, harem cheesy slags prude, musicfilms! Flip, soaring = mapped,=20 sit? Stan leethe concluded annual? Nd rub shy charlie watts ever paying=20 customer. Done germany getting phil massaged pic summer drummers. = Tickets=20 exchange concert, clothing vendor looked exactly pregnant.
Catherine zeta jones charlize? Blooker = prize=20 honours blogs iran condemns hollywood epic. Penguin joker creature = effects=20 jokers. Thats not quite true still forced, togt use work. Certain, = attributes=20 theregt some available thus forcing, agt. Melody breaks standard axe = danelectro=20 bellzouki string. Pisses emalee thanx birthday xoxo angel. Musical, = elite=20 decades she describes, herself. Gastiain gastain pitt niamhmenet = goldderby. Week=20 rainin memphis tons. Vampires werewolves parkhouse closed.
Projects light cia covert operations = bill=20 anthology, aargh rampant. Decoding sexual meanings alices adventures = wonderland=20 pan.
------=_NextPart_001_0007_01C76648.A4C04150-- ------=_NextPart_000_0006_01C76648.A4C04150 Content-Type: image/gif; name="Inc nonprofit.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c76640$42fbd950$00000000@SERVER> R0lGODlhRAHUAYekAAACCnYNAAF5AHKCDQAAi34AiwCFcrvAxsDdyaPP+T4iAVouAIoiAJ4lALIb AecpBQA/ACZNADNLAGwzAngxAJ5AAL88ANI8BABlACNtAEVmAG1lAIBWC59oDLVWANpiAAB+AC17 AkyEAG1zDYp6Dq2KAcWFANZ/DAaaABubDTmgClGhCnqtAJKqCbOUAOKfAAXMBCfFADPACGWxDofA AKTODsfOAOrNAAnsCh3mADfZA2XhAHvZCZvrALrcBtbUAAAAPhkBTDMCSGEASYUFQKwAS8EHRtcA Og0sOyAdPjwnPWggSYApS5MiSLonNdUsRQBCRRpISkE3N1pETYs9PqM7PchEStJERQBbQhtqMzpm PFZSPY1uA6NsSLlnTt9tOApxMxGJNjp0RGWHNnt9R5t4N8mATtx6TACcSSOiQk2fO2GbNXelQ5GZ S8yhOOGjOgW9MhayR068Qmm5SXu0RJzMM72+NO6yRgDpRRfqO0LlO2fuM4XmM5PqQrvXS+viPgAM eBkAfUwAiFIAgn8Af6kAfMYLiusAigAncxYldkEfgmIndYkceJ0pickieuAgfQpFfx1LiU5AfVcz iHRHgqFOiMpFidRKegBSjSldjDVgdVZegIFSi6BrgcFhfehudgB+gCGEijmNgl51eoeLcZ+Ahcp2 i9J+egeucyOnizuTjWWnfX2pi6ubesKpdeKUcQe1jBy+djSzgF/LiHa2gJzEib+1gtXGfQDnjSPb gEXTembqeXXrdavlhcTag9fjgAQAxyMMzUUJy18AwHEItpMAys4Oud4AwQ0RwRQszjEXtVMhyYcY vpMhsccuw+odxQAxwCo/tE5Itl86xIdNu6JMys1Iw9I6swNgsxFjwjtruVRptIpXtJVay7dux+5g sgCKziSDukGAzGp4tnl+uq6DsrV5yel2zAClzSWdv0acyF2nxHSuzqqbwr2lyterxACxyim5tTe6 slLJsXW5u6LGs/fs+6uco3JxfvYAAAn/AP33AAAA8/oA/wL/9f/08iH5BAC4wUIALAAAAABEAdQB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/LPk5FIyQH2HAcA+TUnzysGDGCR8bhDx4 IOXJhhErVXx5JOPOBS+DVjg6smaknAUaJuxYdebQryUvfj37cWbZqzHfdm1b9uLajm/vrs378+mj q3MT9M18ueXZqp+njt78OfXf1rH/bj19u/TspY/v/5ye/DpwzuWD5+4uOTn77a2jm/cOXnv18OJ1 po6Pu3Do7PIF2J5/8w1n34HvcWcdfvnhtF99AjpX4Hf1VRfhgxdSmOGEDSInYXkBEgcba8vRptxu rNFm2Xoiomdgiilid+KCHdZo44045qjjjjz2mJhHDD4UpI9SBTlkQ0cyFF6SRAJlJJBQKtlkkSOu SKJ2wFn5n4xZ8maeciVeeaKJU0aV4HfGcSgfiQpSdyWWCr6HZZlMnenmZBo+OKCbLBbnIorqxUbn U3Z6lyZ9cBqK4JZzAmifb44OmlSh/VXoKH95Hhhim2pK2hSIYM4Y4ZoqjsqfoFpWCZ96kXrq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rcA1FTuuDcBoG6554LU7kPsOvQuuiHNO29H9zKUb0L70rvRveu2u+5AA5MSMMHqIsxu wgQVfLDBED9sMMMQ+1uvQQJXrLFA8XKsccceF5TxyBET/HHIFn8EsMkBn3vwyC9nLDLLNIO8sMMp u4sxzQ3zXDLGIJvsMck2b4xyzvjOPLTPRcu8tNI/l9y00EjXO7DMBU+csMQOU0wxxwwTfbLWVFc9 U79mh4V22my37fbbcMct99x012333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQR35c Pxj1Q/lEl2e0tkabM2u55aRkThDlohv0eekCZY766aiH/m9JAksMdtedz9q66QvdPpDqCOmuu0S1 W/RyQ0X3unrqoLt++eejm54888wXJHr0p++evMLYC41zxfZ6/TXT+qIc/KvHN0+66wdRvzv67Euf PvvnKxQ0+C4f3TPaNme98+y/ll/9+dd7H+949z7rgW6ArYvZzsQ2PwXy63tGE1/ZdHW8AcLvdvFT 3voKCL8OIq9n4nvX1OIlQqpB0Gf2k2AKc1W6DAKweQJcHwFxlzoZbrCGJgTh07g3QadFsGbaK5sP /3n1P+QdUHkBDF30lLi80ZXPiKSjXhK1djOlZW2IVCTbQbjmtR6eUHIkGR8YYyLGMZrxjGDRhz5K skbYWauNpFgjHC+iRjUyZI4PwaND9KgzqDUsbLLTFRz5WJFBLoSQH0EkR7i4P6OVUVKGbGMdB1JH OcZRIJMkSCQvGUc7dlKSnvwkJu0IylIO0pOK5NzG5je2FebKkpykZCzlqMc5RlKSsjQkJmPJS1he Upe5DOPYVna0R3oKlqacZS8zOUpUynKXp5xkKKepTF1WkpdWc1kgnWbMY3LSl+BU5i6fSc5NjrMg 07SkOX8ZTDeWEGpY5NU6wwlMW6KznOLspSbZCf/NdvKTmzlU4Q+DhrUgCsuambymLZmJzYXikpKo jOhDE/pMhQoUoBcVmf5aecVppVIs3YQWQ9USUjSa9KROmaJDfkdGa1lQI9WjYfug2DqWwoSYjRzW DDPC0p3CkIPpumK+vuirly6xiMtL4uqed8ApTo+p11tiSwj6w6r2D30t7KBTpfc8G+JQpubzaksL usVjxS+pR6zhU1WqQbXe0H0GdKESzwbIjbryqk18aVs9iDu9YvCGcv3gWHXoR2L5VauA7R1ivwrX xbbvchjlaEAlu0AdvtNYBIxpEePqxKh21Xpg/Z8UMxfZ0k52iNs0IVGdZVO10UuqJEWpbGfLk4// kqWkwbKoQXy5ltjZdWKzW22tbGtbkF5NfgjBLZFq2cx+itIsxSurdHvF3H2qM7a+BdhGlbvc3Tbz uqE8i13tNVnqeneTp0xLA+E5QXneE737tOxp55vR+lL2vqatLFnJmltpfpedI8UvfQVs3/wSuJXB zd7HukjbizXYXA+OsIRfxV1gxbQivhNrU0QIwZaZtSQ+Zcrw7Fdh8qUPqqrr6lkDaFTPHhGtOWGl I5X1RLki0K0xnKmNnwjh7gFNuEQ0IhPTikToaTisWDUyjqEY4w7zC7NITmxWl+y+vIo1sDPtcWEJ q9MrO9bGCTnsYXFo4DIPeKhRqx+CDTvar8LY/4OwhfNoMzjkAp/5ziQWKjeBLLfWpotxcf5JiSdM 6ELrZdC7umZeyLtF7yF6R8V9y8NOSLK72qqWEu0kRCNtlfUiN56vdKZzH0pO1zK60QrObTXHmczb fm1t0QUWPVmdz7HEuqygTvSqvylOM9v51wf29Zp3+M5KW/XSzKQorz/ZRmE7G8/BhnaC+RdC3xoa I4++Nry0ze1up6SmUsk2Cy8MU6A6hcP7yq64d+TniIAbKiOOIKW7jOM2u5izTGSsiAc63fYWFbRV xmFWxQxveSc3pxZ+62abWGeCw/vVT+Zywt3sVSsvGcxR6Rj+tnxVitf74l9G37OBPfL73s/gQv+E MmMXLvA5C1nk0C65zL1Y17ApeN20xbm3+73znvv8LjqnFad5C93CprvmQdcMp88J3a79cbqnvhUe lQ1gUn4zvFnxtL99mHSlx5efAIaod7ei9RVyXdebdiYugcnsrugv6n9ksCC/3s5wnnPpG14zrP09 3K/XM5+6nDnJY074ypKYy7kWekLDi9BlelLw0R685BVmbWovWOI/53jmPdL1zXv+86APvehHT/rS m/70qE+96lfP+ta7/vWwj73sZ0/72tv+9rjPve7d1nnNxdhWgZTXcQ0fvh2eZHz5yofy8zGQ5TNf IMonyPM/nTS+2yXxPD84csuLEuQbZPqkYD7/+MUP/fIXv/qWpouxY01MnGnzsid7P+V/Nt6azz/u 8tfiQcjf/PCbH/w/pnF1RW0wM4DHpn7bk2YSR14kxHMaNzMwg3D0k3LEdoD8V37Pd4FQFzWrNIHG 13tVsX7Gh3LDszCU534hE28EtV3Dp4A55GFok4HSB30yGH4AGH/AVUweyIEgSBUiyIEGJzZgg3g8 JIKRhYMV+IKaF33m14T9V4NKOISXNTUf6Bc/yG8ntzTwh1NU6IIdWIFnB4b7VxDjR4b/x14lNIVI CIRWqGegNmIlqH8phDW0s4Lfo4LTdn9CNYNm2H98CIXzV0UE6GjFY3M20oPycnwO4XxM6Hx9/0iD zoKI8sNn2EaJu3eJmJiJmriJnNiJnviJoBiKojiKpFiKpniKqJiKqriKrNiKrviKsBiLslgROgd3 57cQISWJ1pcjR9hoW6N59qV94DOCtSNjEXdsQcdduph3AuWAENGLCBddaEY8wLOLyahKhxZQ26VR NpdaKoSC7yeN3EM7ASg1lnc1v8h1BqiNhmiO96dF6HhzfNGAauZI7diAh4ePEeiC9CiGOqiF9UhV SRiMRsgyp0aF9cNfi+aOHoZrQJSP9LeDCRmRBQhxWniCX1iE7AWRa8hKBVmEkzaPDBk+Qjhj+iiR FzmRI6iEqCVfQNiLD+iP8lVpKol51zdgEP/4kCgnWVcIUFeIgz7pkjuJRUG5kh9Zk8uYcUJ0hwlI Qr+ljgGZhxg1aR12XOiWPb9odvnnR244lASYgudIYW5Hi+KSlFNFlrOYlqRolkchd75YjMJDfG7U SN5HESUWPGxpFG5Jl9TIeTelEoiYl0URk9uoPY4Gj904k/wjiOVIf4dJNvRIjvnnjW+nZ5bnmNkF lOOYmUCnkf8okzx5kDyIjAYpQVuIlB2JYDL2kU+XmkQTldjXFhMZhqBZlDkZMca2geqWgxnZhb55 P1y4hqrVgiOEkbHJFrNJgbUZhbcZO2yomFrZm645jCEEnWzYkmKInQcomwijmgY1mqYpjGn/mJHh 2YwCqYCsuYXW6ZHMWZzluZ3I2Z1ymEU3B0hfqZuG2I7TdpX6R5z0CVyTmXKFuZnyWUyEmGB2+I7P You+RxSCWSs4tUiDqZYUWqEWeqEYmqEauqEc2qEe+qEgGqIiOqIkWqImeqIomqIquqIgWlKrZYzP OBfQaBLG5CKpAh0hgpER8VsHB6PH+GS4tTkP2lLN2H0TQSYTIiY/um3px319SX0XIaRF941VmZUE ipn7uY6/FR+I0h+gwZ/eOIzgaKXds5VfiW4q2ZV0KIg8ihX96J0DOTQr05PDxqX38SYbGKcM2EPu CKfPqZPxB5s7OGxjqY+y84PxlkXrFzN2/2WnmrIglGGb8MePVtmBojlUldqeKDmFQ8oSb5pum6qp 2nkQjsqlX8KXenqb6Dmal8qX5ymOrGmPrkWQofqesNpepQogSrqRXviNE1h278mS61mrczirq1Sl 4Yig+DdMW9moJvKsh1IqBpqsP7asijqOW6efgXis+tmV9Ol0beoWnTqX2xeXfSQp4ToVnWOJ2fc6 LPqu8Bqv8jqv9Fqv9nqv+Jqv+rqv/Nqv/vqvABuwAjuwBFuwBnuwseIerkGqYHIeC1simBGx7pEe ChsmE9s3z4qjEbsiHAutDCuxosEqDxs4pWIbhREc/xEb0jqyHRuyEMuyfrOyGgsbMNuyneghrcJx si87szHrsh/Ls1YiszWbsz87skKbNzKbtDHCsEd7Hgo7seuBskFbsUjrsxurtA27sRCLtVnbtHej tDoLtAubtTvbsmFbskziNmD7s2tLtkNrskWrIl77tcaxtjwLtyJCszRrt6GStmqbsXwLuDaqt1tr tS3it29TsVBbHBa7tDf6tk4btVUCtXOLsJZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM4bEgEB ADs= ------=_NextPart_000_0006_01C76648.A4C04150-- From sip-bounces@ietf.org Wed Mar 14 13:32:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXJq-0004FD-5d; Wed, 14 Mar 2007 13:31:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXJo-0004BC-DA for sip@ietf.org; Wed, 14 Mar 2007 13:31:20 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRXJi-0005gt-PG for sip@ietf.org; Wed, 14 Mar 2007 13:31:16 -0400 Received: (qmail 27839 invoked by uid 0); 14 Mar 2007 17:30:52 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Mar 2007 17:30:52 -0000 Message-ID: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Wed, 14 Mar 2007 18:30:52 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sip] size of temporary GRUUs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2035802981==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2035802981== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0133_01C76666.E573D720" This is a multi-part message in MIME format. ------=_NextPart_000_0133_01C76666.E573D720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, I did a rough test on generating a temporary GRUU: 1. Concatenate AoR "|" instance-id "|" absolute expiration time (hex) --> gives 83 bytes 2. Encrypt using Windows CryptProtectData API call using 128-bit salt (not sure which algorithm it uses, does perform MAC) --> gives 226 bytes 3. apply base64 encoding --> gives ~300 bytes So: following appendix A in gruu-12, only the _user_ part of a temporary GRUU is roughly 300 bytes in size. Regards, Jeroen ------=_NextPart_000_0133_01C76666.E573D720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
 
I did a rough test on generating a = temporary=20 GRUU:
 
1. Concatenate AoR "|" instance-id "|" = absolute=20 expiration time (hex) --> gives 83 bytes
2. Encrypt using Windows CryptProtectData API call using 128-bit salt (not sure which = algorithm it=20 uses, does perform MAC) --> gives 226 bytes
3. apply base64 encoding --> gives = ~300=20 bytes
 
So: following appendix A in gruu-12, = only the=20 _user_ part of a temporary GRUU is roughly 300 bytes in = size.
 
Regards,
Jeroen
------=_NextPart_000_0133_01C76666.E573D720-- --===============2035802981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2035802981==-- From sip-bounces@ietf.org Wed Mar 14 13:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXQ0-0006hJ-Gd; Wed, 14 Mar 2007 13:37:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXPy-0006g5-J2 for sip@ietf.org; Wed, 14 Mar 2007 13:37:42 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRXPu-0006xz-LA for sip@ietf.org; Wed, 14 Mar 2007 13:37:42 -0400 Received: from DF-BHD-04.exchange.corp.microsoft.com (157.54.63.169) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 14 Mar 2007 10:37:37 -0700 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by DF-BHD-04.exchange.corp.microsoft.com ([157.54.63.169]) with mapi; Wed, 14 Mar 2007 10:37:37 -0700 From: Sean Olson To: Jeroen van Bemmel , "sip@ietf.org" Importance: low Date: Wed, 14 Mar 2007 10:37:35 -0700 Subject: RE: [Sip] size of temporary GRUUs Thread-Topic: [Sip] size of temporary GRUUs Thread-Index: AcdmXu2b95a8Gq/7TLqT/f9DnS9VUAAAGVwA Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> In-Reply-To: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491872369==" Errors-To: sip-bounces@ietf.org --===============0491872369== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4C1596FBF66C67478BCFE7B3F81FC1E01788144B6FDFMASTIFFMSGe_" --_000_4C1596FBF66C67478BCFE7B3F81FC1E01788144B6FDFMASTIFFMSGe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See: http://msdn2.microsoft.com/en-us/library/aa925034.aspx The algorithm used in either Triple-DES or RC4 (default) depending on which= you choose From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, March 14, 2007 10:31 AM To: sip@ietf.org Subject: [Sip] size of temporary GRUUs All, I did a rough test on generating a temporary GRUU: 1. Concatenate AoR "|" instance-id "|" absolute expiration time (hex) --> g= ives 83 bytes 2. Encrypt using Windows CryptProtectData API call using 128-bit salt (not = sure which algorithm it uses, does perform MAC) --> gives 226 bytes 3. apply base64 encoding --> gives ~300 bytes So: following appendix A in gruu-12, only the _user_ part of a temporary GR= UU is roughly 300 bytes in size. Regards, Jeroen --_000_4C1596FBF66C67478BCFE7B3F81FC1E01788144B6FDFMASTIFFMSGe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See:  http://msdn= 2.microsoft.com/en-us/library/aa925034.aspx

The algorithm used in either Triple-DES or RC4 (default) depending on which you choose

 

 

From: Jeroen van Be= mmel [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, March 14, 2007 10:31 AM
To: sip@ietf.org
Subject: [Sip] size of temporary GRUUs

 

All,

 

I did a rough test on generating a temporary GRUU:

 

1. Concatenate AoR "|" instance-id "|" absolute expiration time (hex) --> gives 83 bytes

2. Encrypt using Windows CryptProtectData API call using 128-bit salt (not sur= e which algorithm it uses, does perform MAC) --> gives 226 bytes

3. apply base64 encoding --> gives ~300 bytes

 

So: following appendix A in gruu-12, only the _user_ part of a temporary GRUU i= s roughly 300 bytes in size.

 

Regards,

Jeroen

--_000_4C1596FBF66C67478BCFE7B3F81FC1E01788144B6FDFMASTIFFMSGe_-- --===============0491872369== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0491872369==-- From sip-bounces@ietf.org Wed Mar 14 13:45:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXWs-0002R6-Gb; Wed, 14 Mar 2007 13:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXWq-0002QN-Q9 for sip@ietf.org; Wed, 14 Mar 2007 13:44:48 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRXWl-0007Y2-2V for sip@ietf.org; Wed, 14 Mar 2007 13:44:48 -0400 Received: (qmail 11794 invoked by uid 0); 14 Mar 2007 17:44:20 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Mar 2007 17:44:20 -0000 Message-ID: <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Sean Olson" , References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Subject: Re: [Sip] size of temporary GRUUs Date: Wed, 14 Mar 2007 18:44:20 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.2 (+) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0339113483==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0339113483== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0167_01C76668.C6F95750" This is a multi-part message in MIME format. ------=_NextPart_000_0167_01C76668.C6F95750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Sean, I compared it myself with http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls1024.htm The table provided there for AES with a hint (excluding MAC) shows 227 bytes for 100 input bytes, so I was assuming that 83 to 226 bytes could be indicative I should add that I concatenated the AoR, instance-id and expiration time as ASCII strings - some bytes could be saved by using binary here. Perhaps this could be an argument to standardize more strict on the format of the instance-id: the uuid-format allows more compact conversion to binary Regards, Jeroen ----- Original Message ----- From: Sean Olson To: Jeroen van Bemmel ; sip@ietf.org Sent: Wednesday, March 14, 2007 6:37 PM Subject: RE: [Sip] size of temporary GRUUs See: http://msdn2.microsoft.com/en-us/library/aa925034.aspx The algorithm used in either Triple-DES or RC4 (default) depending on which you choose From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, March 14, 2007 10:31 AM To: sip@ietf.org Subject: [Sip] size of temporary GRUUs All, I did a rough test on generating a temporary GRUU: 1. Concatenate AoR "|" instance-id "|" absolute expiration time (hex) --> gives 83 bytes 2. Encrypt using Windows CryptProtectData API call using 128-bit salt (not sure which algorithm it uses, does perform MAC) --> gives 226 bytes 3. apply base64 encoding --> gives ~300 bytes So: following appendix A in gruu-12, only the _user_ part of a temporary GRUU is roughly 300 bytes in size. Regards, Jeroen ------=_NextPart_000_0167_01C76668.C6F95750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Sean,
 
I compared it myself with http://publib.boulder.ibm.com/infoc= enter/idshelp/v10/index.jsp?topic=3D/com.ibm.sqls.doc/sqls1024.htm
The table provided there for AES with a = hint=20 (excluding MAC) shows 227 bytes for 100 input bytes, so I was assuming = that 83=20 to 226 bytes could be indicative
 
I should add that I concatenated the = AoR,=20 instance-id and expiration time as ASCII strings - some bytes could be = saved by=20 using binary here. Perhaps this could be an argument to standardize more = strict=20 on the format of the instance-id: the uuid-format allows more compact = conversion=20 to binary
 
Regards,
Jeroen
----- Original Message -----
From:=20 Sean Olson
Sent: Wednesday, March 14, 2007 = 6:37=20 PM
Subject: RE: [Sip] size of = temporary=20 GRUUs

See: =20 http://ms= dn2.microsoft.com/en-us/library/aa925034.aspx

The=20 algorithm used in either Triple-DES or RC4 (default) depending on = which you=20 choose

 

 

From: Jeroen = van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, March 14, 2007 = 10:31=20 AM
To: sip@ietf.org
Subject: [Sip] = size of=20 temporary GRUUs

 

All,

 

I did a = rough test=20 on generating a temporary GRUU:

 

1. = Concatenate AoR=20 "|" instance-id "|" absolute expiration time (hex) --> gives 83=20 bytes

2. = Encrypt using=20 Windows CryptProtectData API call using 128-bit salt (not sure which = algorithm=20 it uses, does perform MAC) --> gives 226 = bytes

3. apply = base64=20 encoding --> gives ~300 bytes

 

So: = following=20 appendix A in gruu-12, only the _user_ part of a temporary GRUU is = roughly 300=20 bytes in size.

 

Regards,

Jeroen

------=_NextPart_000_0167_01C76668.C6F95750-- --===============0339113483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0339113483==-- From sip-bounces@ietf.org Wed Mar 14 14:28:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRYBx-0005BA-4k; Wed, 14 Mar 2007 14:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRYBv-0005B2-W5 for sip@ietf.org; Wed, 14 Mar 2007 14:27:15 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRYBu-0007U8-MG for sip@ietf.org; Wed, 14 Mar 2007 14:27:15 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id A2EB81E8C28; Wed, 14 Mar 2007 11:26:30 -0800 (PST) To: "Jeroen van Bemmel" Subject: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> From: Eric Rescorla Date: Wed, 14 Mar 2007 11:26:30 -0800 In-Reply-To: <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> (Jeroen van Bemmel's message of "Wed, 14 Mar 2007 18:44:20 +0100") Message-ID: <86odmv7hjt.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Jeroen van Bemmel" writes: > Thanks Sean, > > I compared it myself with > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls1024.htm > The table provided there for AES with a hint (excluding MAC) shows 227 bytes > for 100 input bytes, so I was assuming that 83 to 226 bytes could be > indicative > > I should add that I concatenated the AoR, instance-id and expiration time as > ASCII strings - some bytes could be saved by using binary here. Perhaps this > could be an argument to standardize more strict on the format of the > instance-id: the uuid-format allows more compact conversion to binary So, as a practical matter the stateless token format in draft-rescorla-stateless-tokens-01 adds a minimum of 50 bytes of overhead, so you can add that to the size of the data itself and then b64 it.... -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 15:22:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZ1W-0001s6-Uw; Wed, 14 Mar 2007 15:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZ1V-0001rj-K3 for sip@ietf.org; Wed, 14 Mar 2007 15:20:33 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZ1U-0001Lb-0a for sip@ietf.org; Wed, 14 Mar 2007 15:20:33 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2007 15:20:32 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2EJKVFe023507; Wed, 14 Mar 2007 15:20:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2EJKVGd012334; Wed, 14 Mar 2007 19:20:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:20:31 -0400 Received: from [192.168.1.104] ([10.86.242.218]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:20:30 -0400 Message-ID: <45F84AFE.2040502@cisco.com> Date: Wed, 14 Mar 2007 15:20:30 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> In-Reply-To: <86odmv7hjt.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 19:20:30.0790 (UTC) FILETIME=[D49D5E60:01C7666D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1955; t=1173900031; x=1174764031; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20size=20of=20temporary=20GRUUs |Sender:=20 |To:=20EKR=20; bh=cbMbjCPsdKxvWPwDotCh/1deeCaPZfWCvMvjOWLbAV0=; b=WoRhxlfF3NYUF0vws9bG1HaMsxIKQ30Ayb2imgsmS8xzb2tgB4hVZLzzmFi3pJbBiF+xqA8U yJJJPBNRxiBalggY89b4p4t3B9llf+6GV7mHo2cseBZRCM13X4ey1BrQ; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, Jeroen, I'm unsure if this is a criticism (we need to do something different for temp gruu), or just a statement of fact you think we should mention more clearly in the document. I'm personally fine with this; if the size bothers an implementation it can use a stateful technique and the size can be shorter. -Jonathan R. Eric Rescorla wrote: > "Jeroen van Bemmel" writes: > > >>Thanks Sean, >> >>I compared it myself with >>http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls1024.htm >>The table provided there for AES with a hint (excluding MAC) shows 227 bytes >>for 100 input bytes, so I was assuming that 83 to 226 bytes could be >>indicative >> >>I should add that I concatenated the AoR, instance-id and expiration time as >>ASCII strings - some bytes could be saved by using binary here. Perhaps this >>could be an argument to standardize more strict on the format of the >>instance-id: the uuid-format allows more compact conversion to binary > > > So, as a practical matter the stateless token format in > draft-rescorla-stateless-tokens-01 adds a minimum of 50 bytes > of overhead, so you can add that to the size of the data > itself and then b64 it.... > > -Ekr > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 15:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZOD-0008Vv-7a; Wed, 14 Mar 2007 15:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZOB-0008Vp-Ry for sip@ietf.org; Wed, 14 Mar 2007 15:43:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZOA-0005DI-Fe for sip@ietf.org; Wed, 14 Mar 2007 15:43:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2007 15:43:58 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2EJhwfZ007713 for ; Wed, 14 Mar 2007 15:43:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2EJhwlK018438 for ; Wed, 14 Mar 2007 19:43:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:43:48 -0400 Received: from [192.168.1.104] ([10.86.242.218]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:43:48 -0400 Message-ID: <45F85073.7040009@cisco.com> Date: Wed, 14 Mar 2007 15:43:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 19:43:48.0524 (UTC) FILETIME=[15BAA6C0:01C76671] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2902; t=1173901438; x=1174765438; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20GRUU=20-=20what=20is=20there=20to=20talk=20about? |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=cpLtbBHTmYUum7PEF/jEepEq08NC6LtWXSv+jthmqBg=; b=WfJtlsSdK7esv1+LotvgzEbLTcokQzGJ3ECrFGazPQJ1Ak9G9PAwmSVvf1RvAT6oeZp12xCd X1qY9CLelo3dMtzkL4O2bDQrUA2KHuH89j2rWP7x3zcU1KClhQMT2x3a; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] GRUU - what is there to talk about? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks may have noticed that GRUU has time on the agenda. There has been an open issue that came up, but it was buried in an older thread that folks may not have paid attention to. To refresh everyones memory, a couple of revisions ago, we introduced the notion of a temporary GRUU to address concerns that GRUU would worsen privacy considerably compared to RFC 3261. The idea is that, when a client does a REGISTER (whether initial or refresh), the server constructs a new temporary GRUU for the UA. The userpart of the GRUU doesn't reveal the identity of the UA, and its temporary because these URI become invalid when the clients registration lapses. The problem that was raised on the list by Paul K. some time back, is that you might run into problems when the server forcefully terminates the registration. The client will re-register, but how does it synchronize its set of temporary GRUU with those the registrar has? The solution was to use reg-event (necessary anyway if the server is forcefully de-registering users). So, the client would use reg-event, and if it sees the server expire its registration in the reg-event notify, it discards its temp-gruu. However, getting into the details of this, it still doesn't quite work. If a client re-REGISTERs on the cusp of the expiration, it won't know whether its registration came before or after the expiration. The way to solve this is that the reg-event notifications contain, within them, the cseq of the registration which was the start of this sequence of valid temp-gruu. This way, the client knows that all temp-gruu it learned in REGISTER responses with a cseq equal or higher to that one, are valid. This also allows a client to use reg-event at any time to verify synchronization. Of course, since CSeq are scoped within a call-id, we neccesarily need to invalidate temp-gruu when the call-id changes. This leads to an interesting side-effect - now, a client can forcefully terminate all of its current temp-gruu, without unregistering, by sending a refresh which changes the call-id. This doesn't provide fine-grained expiration control over particular temp-gruu, but it allows you to erase them all. AFAICT, this works just fine. However, its an open issue in that this is yet-another-new-temp-gruu thing, an area which we have been struggling to stabilize to complete this draft. So I wanted to make sure the group was aware of this change, OK with it, and had time to ponder any possible implications. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 14 18:15:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbhO-00066S-KK; Wed, 14 Mar 2007 18:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbhN-00066N-5I for sip@ietf.org; Wed, 14 Mar 2007 18:11:57 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRbhL-0006yW-Mc for sip@ietf.org; Wed, 14 Mar 2007 18:11:57 -0400 Received: (qmail 26608 invoked by uid 0); 14 Mar 2007 22:11:33 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Mar 2007 22:11:33 -0000 Message-ID: <01b701c76685$b9da3f40$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "EKR" References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> Subject: Re: [Sip] size of temporary GRUUs Date: Wed, 14 Mar 2007 23:11:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, It's something I personally did not realize fully until now, and it may be something that renders stateless temporary gruus unusable in some deployments. Memory usage at the registrar is reduced, but at the cost of a significant increase of message size. One aspect of this is that the draft uses examples like 'temp-gruu="sip:8ffkas08af7fasklzi9@example.com;gr', making a temp-gruu look about the same size as its public cousin. With a fully stateless approach it will be more like temp-gruu="sip:AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAP7dBrHt14kasd9uJd8P5jQAAAAACAAAAAAADZgAAqAAAABAAAADsbbCyhVQzsxwwz/GDtAU3AAAAAASAAACgAAAAEAAAAKQHD3/mwAK81/dl7fZgynxYAAAA5q1SG7kiK57ukwHHiiErCoopbsRQzRQtZmuMiSKbbFPIK/U0jw0LQ6sdM6X2ttM/BHpeZYGD8YdVPLNqJTRtUXArUCZhmL/SRH34GFJF4MSp8m97XR0nPBQAAABO0exx6ITfWE5uKYq9VPl49/jesA==@example.com;gr" (Not that this would not make the example more clear, perhaps a notation with "..." would be better). So yes, at the very least it should be mentioned in the GRUU draft. It should probably be recommended that if message size is a problem, deployments should consider a stateful approach instead. A scenario in which this adds up would be a REFER callflow. The GRUU would appear both in the request URI and in the To URI, and if the originator is also using a temp-gruu in its own Contact... anyway, you get the idea. I am fine with just mentioning it more clearly in the document. Regards, Jeroen Jonathan Rosenberg wrote: > So, Jeroen, I'm unsure if this is a criticism (we need to do something > different for temp gruu), or just a statement of fact you think we > should mention more clearly in the document. I'm personally fine with > this; if the size bothers an implementation it can use a stateful > technique and the size can be shorter. > > -Jonathan R. > > Eric Rescorla wrote: > >> "Jeroen van Bemmel" writes: >> >> >>> Thanks Sean, >>> >>> I compared it myself with >>> http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls1024.htm >>> The table provided there for AES with a hint (excluding MAC) shows >>> 227 bytes for 100 input bytes, so I was assuming that 83 to 226 >>> bytes could be indicative >>> >>> I should add that I concatenated the AoR, instance-id and >>> expiration time as ASCII strings - some bytes could be saved by >>> using binary here. Perhaps this could be an argument to standardize >>> more strict on the format of the instance-id: the uuid-format >>> allows more compact conversion to binary >> >> >> So, as a practical matter the stateless token format in >> draft-rescorla-stateless-tokens-01 adds a minimum of 50 bytes >> of overhead, so you can add that to the size of the data >> itself and then b64 it.... >> >> -Ekr >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From jonsewellroqi@aoclimburg.nl Wed Mar 14 21:57:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRfDu-0004v7-NJ; Wed, 14 Mar 2007 21:57:46 -0400 Received: from [121.36.65.115] (helo=aoclimburg.nl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRfDo-0000E0-Cj; Wed, 14 Mar 2007 21:57:46 -0400 Message-ID: <25B6EBB7.F427B558@aoclimburg.nl> Date: Thu, 15 Mar 2007 13:42:22 +1200 From: "Alesha" X-Accept-Language: en-us MIME-Version: 1.0 To: "Caitlyn" Cc: "Carma" , "Malika Fisher" , "Tristan" , "Chester Hill" , "Ella Bishop" , "Hollie Harper" , "Bradford" , "Lavonda" , "Vanessa" , "Avery Parker" , "Antonietta" Subject: You Still Working On It Content-Type: multipart/related; boundary="------------418838546236625644614131" X-Spam-Score: 1.8 (+) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d --------------418838546236625644614131 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


really "And meddle hospital so caught he is in Paris?"  There like beyond house hurt was a cry of "Shut up!" from the audience. T    "Yes; madame lie little and cross I race were there two years ago. The d"To-day?"   
"On skirt dived my word, I think grotesque you held are right, Lucien," said request "I slippery had high-pitched speedy proofs that the turn excellent abb was e "And old then it burnt hemic was, I presume," said protest Monte Cristo "t  sink farm "To smoke be sure; hissing besides, every millionaire is as nobl    

"Yes.""Yes."dreamed push watch "Ah, yes--true, mademoiselle," respect exclaimed Monte Cri"Bless me, grubby I quite friend form ornament forgot the races. Did you bet?" 
"Do not coach terrible say that, Debray," eerie grip returned Beauchamp, lau     "It explain was, your country afford understand excellency; the benevolent abb took     "'Your edificial mode of life as a smuggler,' pass offer unpack said he to me    
picture floor "He will sully it summer then," returned enchanting Lucien; "for I a     "And what orange effect itch post tactic does he produce?"experience number wing "Oh, merely a worn paltry fifty louis.""I perfectly well jewel remember Perugia, hearing sir, language stuck and the Hdamage "And who shed cystic steel was the winner?"         
skirt "Oh, heavens," cried Beauchamp, crawl transport easy "the minister quot    "'A person, whose confessor I am,' outrageous lighted stop order replied he, 'an  rhythm forbidden "'But you must seriously slimy swear solemnly that I shall never h     
"M. development dirty de copy Chateau-Renaud--M. melt Maximilian Morrel," said       "It map is strange, within but neither do chalk treat I recollect meeting        knowledge "Why," said appear ran Albert, abecedarian "he was talked about for a wee"Nautilus. examine dive play apple I staked on him.""But I remember hate injure it perfectly," osseous set interposed the darl"But saw there were cake regret three races, outrageous were there not?"    
sold cold "Now, hidden then, whip to breakfast," said Beauchamp; "for, i   "No," replied produce the trade terrify circle count; "I take pleasure in sayin     "I, your excellency?"   
"My good competition weep step gold fellow," said Chateau-Renaud, "the count"Yes; robust peck buzz there was the prize slimy given by the Jockey Club"I will assist parcel blade your sleep memory, dust madame," continued the"What was it?"   
bled knock "Morrel," muttered Albert--"Morrel--who bid carefully is he?" Buteach bite "Have danger end you brought it?"  "Here it is."  amount cry evil "Well said," existence interrupted Chateau-Renaud; "and pray 

control "Perhaps you are right," prefer leather impulse said Morcerf; "meanwhile,"Oh, shut wing up!" say again interposed across some correct of the audienfed name spade "And statement I caught it, mamma, don't you remember?" inte"Why, it old-fashioned was won different by a cheat horse robust and rider utterly unkn   
"What appear wrestle has swollen he sometimes done?" asked Albert.    "Very well; and star transport where is this measure house breath that I purchas     wish dress suddenly detail "No," returned the count.          
"Oh, easy nothing end hurt worth speaking of," heard said Morrel; "M."Is that possible?"             
--------------418838546236625644614131 Content-Type: image/gif; name="ciwuhhiwuc.gif" Content-Transfer-Encoding: base64 Content-ID: <83B15ACB.30A82834@aoclimburg.nl> R0lGODdhkQGMAYQAAP///+jf0u+ysueUlNlOTsUAAN5aWu7u7MwzAAAAAP8AANbW1rm5uZrE4oac 20+QwyJhpWh9wY+UmGZmZs+yhdimbc6SVbWSZqV1O4BPIv/YfFpSWj0vPrY2CwAAAAAAACwAAAAA kQGMAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsAgOCgHHJbDqf0Kj0JRAMqoSC4TDt er/gsLgYUAIO2QLCikCYR4eBQcAd2+/4vJ44IAxGAwWCAgACcyQHBmpWc3V7j5CRknkHSoF/IgII ggOVAY4AgQV/mmuTp6ipqkN9dAYGI5qcrSQBm1oiWYSrvL2+vyZViYuGZraCr6O1t8qddXG7wNLT 1GFxbUiCCFdmaIIEAn4lioJanyLDBKDV7O3uR2kFdGnbJORuZXRnSfHysQhzDHR6R7CgQRkB4q0R tWjEPUvgQqlLWA6WCCShkK07yLHjQYra5JQjYEbUGlmE/nQBAIkJULk1Gz3KnDkNJLJ4mO4ZAqhE Eaxh/mKVG0WLptGjvmyuSWNxgFM6ZUYEkGNIzcBMzDqpRMq1K56pT+vY5IerRSWqteLB0tTSq9u3 UsK9PLQyDYGVeGkckPtNSRW4gAM32TnU1EpFJHHI0vamBZJoTBJInpzgxORplC+X0NyRMg3OAECD ifMnADltu/ZCrgHS8Iq9Tge0MdC4SGbRoSVLqrzitm4SuN/55g0DdPAux/5cGxnzhumyKSotl0du S+TfnlUdB/47N3HvHDlvTzE+zLFRSlrX1gENxYFKBLYtHnC+LRHx3UUYz849uO784OnX3XAj3Nbb gPn5/raZgQX+952CuCm44H7EbScahZlN2J+ADPYHYA9AmXMGOasNMRUBARVAkknPqbgeEBRu2GCG M/LnHY0czlgjjR1aliCCEt6II45CErijjUHi952GMnLYYYxODhnkD4upuIsBbhQhDEOk0LZYFeWU COOPDwKpY4BoKnlmmpqpeWCFZPJmIZBLembnh026mVuOKEQYJ59osomdmYD+wBAyVYi5gyeyaIXM GUp4o4WkFt1HZp5+LtmkoIXqWV6RUAYK6ppntvmhhOMNqimpnRIaqKeqTmkoM4MIsZMfsqkjAGpO iSDKio/aRuemT+LZqpyucipqnz0CqmSxmpqKbJmo/hor4LXkAXihq6G6OZy1O1gRnx/N2XCWFeWU 1sl5BsTn1y1VbFLpEHoWWuOx+CrrrKotpEpodqGWyq+T+1J7pArb1sntpQXby4R0PhgiEAIkkTOR GdXJtgtT3tg3JpwMK/sswSLDCjIL/p6876Z8SoupyjfuiHKy+na7MMxCPFauDGf1gYzGuy7ySiZ9 VWEJau4KKyuGTDdNZ4aVmQxuymt+y2qALh/ptMLgRplp1SHXK2sQpVh3QyKvAGTxVEncEl+WLNVF 3y1PGWEky0RG6WOmURt87KpXv+yhvgJPO2HfXOP5qcwmmCy4vXnrYMV6u2Y5A2zvxdfHHPCic0+7 /ld+s5eVBKD4omCoM+nWrrga7avZMfC1hWmMUOoSJ/mMLrQ5UaXue+M2enWoNigm8UIlt2vkFPIs XuR2Jdscs83yv1cPfNc0nTYUai6EE9EZslVUjPOc3L6Qla/oY/361idSOq3csyCpOv+Ib0+whaSL pTPs97/+J5VgRHzUsB5PlIBLscBSukgQNMPI4iSn858Eqwebq0DqROSCAz0wdgWcSMUu6RGIoiZI QgneKnzKyIQCy2KFujAGHfQYYQlnKMHTgImAIhCITkZEiLjVxQ+1kZgMaUhErggRK7jbRGJCQRu7 cEEOXJCF2c5hAkXU44hFzCJNerc2X/VFES2h/ooH2aJCj5UgIbSJw0vMqMU2tkM21kFgITaxBsTs QmIDXEQg6OcCjGRke0N0oyBTAZb8WURSWaKUSQhhCDowZA5XgIFTWvQNOO5skJiEBGGagomqBEsn 1YEPIylGnxkEglZZssIlM8lKMTCibaJbSSmdssOgjcKWAlERF6g4gyo1hG2tDKYeYqNE3RkmkpO7 xU+YAhI/0EUxMdwLNoRJzTHsai2bgGUKW6hKG/7xlqUL5PEu4rrqVPOcX/CGRRoJAIvt0ksCySNJ KieO94QLiCV4JUEUwE9+NkEBIgDoCQRaBIISwaBdeWBtFumrK8wBXYi6wip5loV6zMSgCLVB/kZN sFESdNSjp/goTeZzEW7QTYW0myNA1PcD01xBnOxAqEhhMFMAzLSmNR1DTjvCLtPI64/0a6QuVTPR GrCznRbkiExH0E+O2hSj/nxqRptq04AyNaoE3WhTs1rVqAbUqyAFKFiZSlaplrWrYg0rVwVKVa5a 1axXXasegFLHR9myE+nLYCwiaAOKmMInj1FqCdh61q++1a1TJSthq2rVxQ70rWg9bGEb+1G5Svaw Ml0sVhV71rRelrFjvQNDyJIYnZRyHWhY4qK051DayIaN1VgqY2cLWcc6drKaHSxtndrY2vpWt24F 7m8Ry1vQdra3nk3sZ/UAEliIghB7eUUE/n8FUxfEoR/fq1xReyHb4A63rMoFL2S/KlLLIrafifVu YYm73O9+N61Z9Sp6b6sHhVaOrwzMCn77uAtKNoSMBukubsW7XM8SWMAoMC+BEzxbrRr3s/Rt8G+N C1/ehvcRUiwKC2wyB3HU4BquQSGiqusLjB4XpBAer29z29vdori2LHaxgTsaXNuqWMI4znGN3RsJ 06TxBafRVUN4VgUF8vEwQ4FtTNE72NDWWL5T3WyDpfzgqx4XrFQV7o3Hm2WpRpjJXMbyerEsX4Iw hCT1KUQSiqqx6LrGV51DpwvKO9kd7DSY01nDWNqpBi+9gVHGS85eTXAJOb+AzlvOwZ1Z/qlG1FSp tCEJZyYGmMpYpgAJ2zV0gk3cg9Bq+ptdmk2kQGjFHj4vf7X6tKqnAeJuYJp8kzInn3U5R0uvZL+r znUeJoeC+SymKfE7TRjnpes9LFrVJhGJiL55R7dFamjFjrYvgAIOeTnirp6rSCG+5ztP1yDCT/D2 U5sc352Ku409regbSHqR0zzUep5W7wrA7QRxjzXLXVbBubU42jRnGzr7aFdSux1lw8450WK491bz nYJ9F1FS8sC2Q/pCQ39idb5sFWt8xVtm8na24+O28sUNC+WRj5vJYPayRzVOXhrju60sh4sAr6BM sXhwhgs3+MVj3nGe79zjcIW5yE1u/vGMk9znXQ050TWO9CbrfOMMd0tUwgEQsbyibjg3utK17mQY m7XoX2d5zq289aMbPK5Qj2zZyx71p5/d5L57NRy0uHS3hxzFaRd7hcEOX6jaHex3b7nI1Y7xv0e9 7naXtkwQj3i8o13lKF940cls+LUP/ehNX/nZ4ap5y8Nd8R1hfMaRTl/Jx5Xzpj850zG/dr4bfex1 hz3UuT77Y4P+F3AfOeBPrmIok/3uvmf77IEvdNVj9vGXVznZLf57499eMA6vt+0lEf3nX3T6Q6g+ 9Ztvfbdofwnfj0TKu0/+8pv//OhPv/rXz/72u//98I+//OdP//rb//74z7/+98///v77//8AGIAC OIAEWIDvdwALkIAJaIAMqAIIqIAQuACZ1oD7p4DvcYHvsQAMsAAUyIAaKIEPGIEKuIEkZE8deAoI 2AAiuIIJqIIT+BYmeIKPsAANoII1eIM4mIM4yIElWEIY+INAGIRC+IId0QAOoINIiIQO8AA8OEEx uD5DGIVS+IOB0QAPcIVYmIVauIVZ2IQvoC2LQw1P6DueUAZmeIZomIZqeIYQ8xZWeIUQ8AAQEIdw OId1SIdxSIdX6IUugCA1ESlmeGu8hAi41iCHIwRQMzaLsoaM2IiNuACFyDIHAjxjwABYaId5OId2 eImaKIdZyAAT6IfDci2xQjJF/hCEZmhAgRgVqBiJYIg9NeCH2CIEZciIZQiJjriGCZhpDvKFgDMG AcCJcqiJmXiHxXiFEQCKMSCKcmKIDoIsBWKIRBCFn1AGZXhrQriAviiNiAg4sGguapiAZSCO5JiK ZriL1piO5wiJxdE3ztiLpAgnJAOPS3AAlriJeqiF+ZiFEBABEiCBMgCPfzIos2iKtCiE1oiL5ghA QKiNfSiPo7gnpRgzqsMdQ1CL6wiJERgAuKiQ48iRn4CO58gAkSiR8gge/EKQKkmPRhAADBABxBiT MimT/kiSMyCQEOmOe7KT8XiKjOiRGgmSaYiAJLiNPRka74g1FcKN92KRtJiG/h1Zjh8plOf4kR45 jjb5kNJIkDvJlTjZlb8YBC4pATNZlprojxKQlQGpk17JltCILd+IA+IIlSEJiZVgl2iIgGlZkiZZ kHcCl4mzN2VykWroCVc5joe5jtV4hhroiifZloAZj3/Jk0zAkS9pljSZluwYi7K4kkq5lWHJAyGY l9b4HgyZhgygmaHolkkJmUnJLCcplrk4m7PJAGo5Mzzylq7JkmAJBQjoADCJmXM4Aap5A/jBOF/J OGTwgbTJmKm5gS+YnJ7Zm5GZLUzZUs2ZnVBpm0UFhtSZktA4nXHJAyPoABIQnDM5Af7oALsIBeN5 ihq4gbSpgZo5iO34mOGJ/jizyJXcKItimZja6YjxCZD9ojDfmZ+g6ZpMIIIMYJ4RMAGaOAHqKQEO sIEWuASxaR4D6oipWZycGZu5SZ16cziDSYsKGKCzmYDPyZcFwYK22aFoSaEWKoIYGoZPcJe2mZgd Kp9REJp34JIzyoJCOqQqKgH/SITuEIIu+qJESqBeQZQ5OoJGKp9IagMZCgmV8KJGuqVc2qVe+qVc yqNwcYFEeoEcGYJUCBeW6aXQ2aM2KgY4+qJyOqd0WqdzKo5VmqRTuKdjyBUZKYL2yT632KRziZgc eaLWmDoXyDOL+qSpCAdAyIZZlKYOKIMP06hm8aiWin95Kh15uqn516eg/jqqpFqqpnqqqJqqqrqq rNqqrvqqsBqrsjqrbYQAtKprbdAGLKCrL5CrI5CrtmoCwEoCw2oEvHqswXqrqICsK8CrLWCr0AoA zEqswTqtzroE0/oFyYpJ24oU18qszqqr4dqtIhCtwtqt1lqt6Aqt21qs0uqrvyquyeqr2eoC7poC 17qr45qv5Qqv/cqvQZCuNnCvKACw+Lqv5Pqu3+qvRCCwN7Cw//qu/SqxE3uuCZuvDoux8lqx9Rqv 7Mqx6goDHXuuvSqtJtuxGZuwQzCyvRqyKmCwJxCtH0ux8QqyFcsELBsDEEuxAguzDEuzNcuzLhu0 KRuzLuuwz9quITuu/jQLsOZaAhprs0ArsQuLsFA7s0J7szqrtBPLtEwrrCZLstQqtVGrsfP6sxtL tiorslybtVkLswobtFertnMrtMXqtEebty07tnELrmdrtBe7rnRLrTOLtITrtjmrr3xLr0v7txZr tHVruH2rt1MbsUX7sG1btHBrrgZ7uUQ7tHK7uJQLt3U7uH57sIJrsY4btYgLup87uDKws5q7tmi7 rqObup4rurA7sEOLtD9LrCc7tZdrtq2rtR5bvJV7sLpbvJv7tZF7trULsncbuKa7ts2aubebvMdr vNX7vP8Kr3jbvTlwr77bvOo6rFbrseSatt8bujX7tYkrtuLLvjEb/rad67rCS7l8673IG7vYS7eb a78qm7v9677za71FQLph+wMKfL1AkK3lS7vBy7oZ+7gEbLnZSwMQrL+/+6sTjLsZfLwXPLm72wQd jLMIrLgPzLAR/LLIir7Qq7TUW7WOO7fwi79sK7u9a77fy77k+7v0667he8PcG38KnMI10MAurAdH HLBIvMQEeMLY+sTKewdSbKxUXLBZrKxc3MVe/MVgHMZiPMZkbKqGCYGBWsa3VwkU0MZu/MYUkMZq nGts7MYV0MYWYAFwHMdzLG0I+MYWcAEUUAGEvMcU4KR9/GkHsMeFrMeG3MbKmMgwAIQz9Md7LMh6 XMiGHMmS/BpP/tg7EzTIdwzHglwBFyDIj1wBfNjJJtCn1+g/AVABFoABtHzKj3zKpzzKosyiYTyG GCip7EMBgYwBEkqcEqDLbXwBGMClunwBDMDKrQwKrWiX/yPLs5yWL2rNd6zMU/qibnwBFcDLXLwR Q2io1rMAeRzI/ziC1szNmqmAohzIq9zHT/jLp8mY1Ow7FIDLp0ygLpnHxLyXFyHMFkDIzvypsFrP ZkqlGHmocvykwszP4YwOC1ABGJABmokOBJ3OGHCbM7MgPkKZJyjNC22hi4mG4qiopszPziwVDEDM bQoA+8zSy1yS3kmJ70mYGrDTPA0APP3TGiAAhJrSUPgMv5yj/myImjEdGLHM0v08AvGZlQEQyDQt AXzpnyAtBgGgAQw5hQuAzXYqpwJNQZBqmkidi7YpzgZxACvN0hXwDCCp0U7NzVeNn+Kpm/qZ046h 1huWmvMMGEZt1vI5lBiZ1qjD1nPd0uhggjNN0xj919ZJiq2J1zlyGXqtAltd1nvanO/h178T2EQJ oBdxhoYtGIuMAU6N2icQAMqc2hlQlO1ImX+5m5S9KFzNp0c91ApopAhNEKBdmkJ4QWVQ2oKxAMpM y8hNyxMtFRad3MidARPg0QXKk70onbV92Siw1Sj61WEd1smIm8fZBdhtFouNga9B2tJ9k8Yy3lPA 2s6d3OBM/sim/N7P/Y8sat19eaDVqQNbDdT+/d8aQAExyqUR8KATsAEInuAIbtWTuN83qQPs/Rrl Xc6MSNxWqi0FOQkuSd8cntwZ8NzRjci+iJ/5/YzVGeEkAOAq/tMWgOAHjuAcEOMyPuMzPgGQvZ9v qd5YOuENzaHpvYw6KdKqYNzO/eEdngFITstIPtZrSS3VnZMn7qMwsOJUfgE0fuVYHuM2vjOdGeQU iZMTCTB5Tdl/wjPljaIW/hlu+eQJiqDI8dLPbeQd/twcEOK9/QhUvuJWnuVXvgE1zskhDZisaZKD Pp2VzeYoWduTPOGIyYJKzddHaSrUHTXv6OVRUNFzruRy/n7Rdc7kBJHnKr7nCj7qpJ7gEbCZsHmc kl7i1+3lkEnbGU7eZ2CaUW2nEojekN7lkTmQOS4Fevnemx7sHIDRsF0QAlABoO7fFhDjpd7sCX6k CLMqbTmZ027ZJXrXgv6m6DDalhmkIrhLZpjmawmauw7l/OnrqTkBF53pGRDj0J2Wdw4JsYzsyc7T y84Bzt7sId7gWX3u+i3SP1LuUW4u3M6ctijc4v6Fo6Lfr97rvlmkEjABSB7sSO7uxpzw7bDIBS3f hJznLZ7vpU6cqM4sgd7wA5/fAw/rQi4/6ICVAJqoZejp426R/BneySkFhxqfRiqhE9/zxozNKgrp Gq7N/hxf9EZ/AS5ezEq/9Acu8iJOiVA/ijU/Lb1u8iIaPNZlmi7fiLtUpIA+8+SeLIkY602AkSpq m2DKpFHJEfYYzun89nCfzqbM9HRfzDU58oJxqFr68tU4pw/dFT0+1Cgd73sApUZ/+BwPpoqP8TAY gWktoDSqqK1opl2NkEIfCVpf6929+d19444KgWpPpHL69DD4gwBUCwUUhAdhz7rd+hBI+Emq91FK qIcK+9VAyYiAqe5h+3iA26bf+mjYPrROpJV/ptBcAj1Om/6j9WsYqX+fyM6fi7wvE1KYqMd/PEMo SKZ/+dcfTKDc/dUkqpfG/eDfP20oP9Nf/mQo/sif/v7qv/7vH//yP//0X//2f//tt8XWo/+0SrCQ 27IggAAjUoojCpgnaaYvHMtz2dpzvOL3jrppTcZSrYa9I+0UDCKbzic0Kp0+l0YYsyfaEnk3q5fq BDfJybIq3bquc0a2GKuEx6n0Oj4/HoKZNT8bl9wLmZlNls7a2xZL4R0h31zXYWOgmk8WZuYkEGMn YOZf5dej0A/OJipo4ClRq97gZKoU4pxnF6AbKyRpmItjWBswp1aksGSuHB+xD7Pzr6Qs6+3wXjAv Ehf1Is8srOk1rbF0r/frZp8h+XrqsLpqZy+5uZ8reHys+y57dNm4KCZO7S7hcxMOV6RVvJK9m1JL /l46VGpm6cP2rl20asXwVfSWhlGiWOE0XqvobMdDfpSSXKE4iplJjBD71TFT7RWQjzAz8oS0TZ5P lSfPCOzZRojOgDsLBjXZ1KhHg0o73jm3T+TMRDKFRoUSUqg9looAKvrU8lbZkmhJFktp06NVX+MG 1Uq28GVDeFOhos1B8BmdUEaZ7p35TZyWwwezlVKsV6LirigbO+x305zOiIDl/lz31LBjxpQdS34c 2t/oyKmlkm51uapCaSG/rtT08m7hoad38+7t+zfw3V1XW7NDPDjy5MqXM/eNE3hpos2nU69u/Tr2 7Nq3c+/u/Tv48OLHky9v/jz69OrXs2/v/j38/vjy59Ovb/8+/vz69/Pv7/8/gAEKmMIBBS5wIIIL FDgggw36d0CCEUqooIMV+nZAAAJouGEAB1gIC4QTipighx/OEECGG3LYYYkmjuDhARRUMKMFNc54 YwUCtOgiFCP6GCGPBKo45JAo7mihADgqueSMAgQQJBIh/jglhTymuKGMFGi5JZFPIskkmEs6CeUM UlI55ZEOHqAiBTZWsOWWb1KgYocNHqCkm3kaYMCSFjSZJpRnnsnAAi4uoKGMfmooZ6I1WgCnlhrW GWCbN7ppgJ8VZMqnpZlmWoGXZErJAKmELkDqgaWaiuqppaZaqIUpJpojpJUm+aimj8I55n93/n5q I6ZKcqrpnsFamiOZALRKqgMOpNrsgc020MCpzZYKbaoMABrgAlrmmiSTWnrqJo4UhMqfAI6qa+ym nmKqgY3q1girlaRO20AEETjAQLPWOtAAtP3uy+/A9p47IISNyhhmvG+SeyMF29qX7roI8LnuxRYY u6e8Nh4cKwP3Cgxwv/wSbLLJ+057Lb0MxkjjpzjG62eNjeIJqhQJ6KwzCjzH4LPPywmAqaMEGEAA AY4ejbHGSXdswAUtI7Ez0AnMwHPQPVBt9dY783bqvWGLPbaqZYfMr9RTWz1C1ukFwACNGMCsrqYY 0Oyo3bk6ijMUQVctw9/MDV3snjMivScC/kYfnTTSFj/dgQRp7+A312v/XLnaPVve9mkLkCww6KH3 O3bYzkZBeXsHMIC33TVikHfdrOet7gUSaNu35U1wvlwAhB9e454EJI600fISfnQHEzDwMQ67T577 Ec47r1i1olvvgL7XNxuB5NFjnvoCer8+vrytd2zBBenb3v3zgK9NNdvvyz+9YwdccHyxGhOtNMf6 G9ABADOwPoldroDx+1vVpLc7+n3jbdrLl8D0lT3tMU9t0IMfALCWOwwGLjmnOh8Iy/c6CdiOUAS8 GvQ0l0EVIlB+wVlABxSHvxkWC2kBnEAJF1BBFBpwc5jTYPzc1zYGwsKBD+wXBCcougjc/i5nWfNh BoG4wiB2EDmqk8AFQtix8WGAhKjaodZSGMQDfk+DYuzNnWJIQ/wJ74ZeJNSknLDADXoNiF573hPP qBgIPVCCflSiwBgQgcidsHmcg18VOXhH3jFAAq8LIRdJmMM4OtF9VCzj/PR4mgBIAIDDIx4oAejG SVJSjmJEnR0zGUYo/uZtEtAe9rYHyAjaDoyrfEEqxxjFXepyORhqJBeDOb43HqiUlSxgC3u5SOCc agKifKYoM5ABHOZQh4VsHwwCl0vNaVKXRPzGqSQwS1hGcJCEooIUeSlFbaqyORBq5ATiKU95StJU 1zSlCneZTH26MDmujKc0pRnPN5rK/phTuOM6XbjNOeaTl795pzjH2UdzVul0rNwnO9XZTd4EoFuk qoAkSVgBUm2pmAY9KAY1Wsd+pjQ4GFqW2VylQ1taFKE+XKlK9bi1FHzzGxDNFwSvB1SgDhCdrIwi Th260ypaEUUd7ZaWJuTUqRrJTlS9Klanek8rnWqoXv1qvtZHUwE5VaplzSpVtyqfArG1rW59a1ud uqBkvaCj/CJhBOaZL72ScF8VNRGG0CpYtKoVPnA9LGLhSlcAmKlVzQppSK1lKgQVVj9sNdJgA1sg zGoVQIn97GeT1dgIlW1gPqosfkCr2rfaaa6LjcJoBTUi1FoWRqs97GtzWybZzrat/uzTLXCD24Pb Epe2wj3uYot7W+Qyt7llaitjQYsC1zq3uta9Lnazq93tcre73v0ueMMr3vGSt7zmPS9606ve9bK3 ve5Fz3HoGt/3ioc2rDnCKezrioTM1yuDqcJwUpPf53xFv6oBCn1zI53EaIMmXOkvYnRDlKhERxue AU108pAX5kD4PW5ZC4j9chUMc6MulRBMURCM33+E2C45GfGDcWObGceDIQ5GTSkyPGCMmNg5/40w KX7iYk3cN8afMPJnwMIYjpCFLCchMDeUbA+nHJnK/liMhAmRGQdbmTcbvnJugEGPKDNZxTHZR5cn U2aVjBkbPsFLlNN8Zv+WORdD/ibBX+QCmoD0OC18hjOWV7xmMcPmNoPmMk+0gma+APjQ5Si0Uixy YhTL5gdbSbOa9yJkQxMZK0g+xhciXWVGi+HDhoHLROBgZbZcmtRgJnFtkHJjFS/lwmqBdaPD3JM2 E+bTRm71no3TjcE8B88NlnSwp+zqUSdb0Cn2TLEzU2t3KMPXoJays3HtZF2IWtd6rnRD5lwT1xAb LlbQQWz8/GezdDvWbFmxqYsC6f06ucAy6fOTQ2zrbP+6L1hI9T1IwupFNxs6OW5NqTt8YJQgXNih eQtQom1hSq+6yT++9rt7E22NQzjDHFe4wysjHHJH3Ny2gAaN1R3r/bYbId5O/jDMe/3vhYs85jYX DYc7DvKb87znPv850IMu9KETvehGPzrSk670pTO96U5/OtSjLvWpU73qVr861rOu9a1zvete/zrY w/5dBZC97GI/OwrKrnYFoF3sah/B29XD9imsPQZmh8HdU0D2tocn7nDfO3ryDoW1A/7vfjd84QGQ eL57R/DscXwT7i54wOfd7IVfPOO7U/cZbF7xiZ885PV++c/vPfSeP3zn7U750c+98q1/febHQ3jV b971c0c85tPOetHPHu+dJ/ztff/620t+9Kf3fOxl33vdD9/wzH/+8WkPfedHX/i8n77wbT/9uuc+ +Y1P/QtcT/3qm1774y///u6xz3vQE5/0sK++97+/eODrHu6KZ/7yw59+8nff/OPX//ntHwCeXvfF H3aw3++xHQKC3//5H/q1X/CFXvFB4P+JnvMVoAEmh+OZH+jBn+npHwRSYAU2IOsFH/RxYO4ZH/Jl YHX4HfuR4AYK4Pa53wjCYPNJ3wpSXwpGoAJiIAsGB/C5H/gdHu71XxCuHxHiXwh+IAHOHwM6IRP+ oItEoRRCHRVWodNdIRYynRZuoRd+IRiGoRiOIRmWoRmeIRqmoRquIRu2oRu+IRzGoRzOIR3WIRZm yADkoR7uIR/2oR/+ISAGoiAOIiEWoiEeIiImoiIuIiM2oiM+IiQOgKSU/ocADMDhRCImZqImbiIn dqInfiIoNuLiDMBYTYclEgAp2uF/BIAlGoAAcIcAJM4rquKADA0BzKJ1HMCe4CItMkgsDkAuGsAA GFcvzocuEkApbhICAGMxmoglEmMd9A4vNqOFDAACQKMY3CI1BskAGAA2SsGebCOUCCNyxKI4QskB ICNw6OI0nuOHCAABAMfQuCOZaKNv2CMe9ZRivM/VTM0BFqAJmiASEF/fCeT1gaAQGiQIYsc89kZD ag1PfcNGsQ1EHsYpwQJAhl8UECR4+KAR8qBCql52qCNvkGP04BIsTOQUNc8+/gxGKiTpbWTauUf/ rWAPRl5I5oEPwkAe/vYGSVbkCt0U4DjUARVlNvkNRXJTUq6kSy6lUCIVLgFNz1DkEO1O6ZVgD1re VfKg/XWlVmblBW6lTYql9N3gBK5f/bmgTeagB14lEtIeBZbg/TnBQ4ZGOuoOSq7kKfGjUy5lRCYl X+rlFHXT5kylYDKlYR6mVPblQuZgTJ5g+3XlXI7l39UfZV7mDlamZjpmZGKmRlKeY87kWHKkZFom VmpmTuIAAXzjDtTl5ORlYWZTYsbmRcJmYlIlUNKmbO4mbjLmYVrgZj5mcBokaZIlV0peWoKm71km Z5pmZ5Ye3ung+yGfChKgSDrnAO5kDBhAMk5BN+LlX8ZmXv5mYP5l/njeJlS+pm8uUm32Jnm21HAy J1tWp96JJnXeZ1ri531C53LGp3/u4AZKZxHe5GY24QCiZkBOpxO44m70pD+ep1/OpoQiZoQOJnqW Z1P+pmG254RqaH82J+xNJ+aRpv3dZEDeH3+WqH4CZ2gy5+qJ5PwJKFv654EW6IsipBRI4m6E44Ou Z4aKJ4YyZmAWZpCOp24CZob65WJ6aHNWZoiGZWSSaJOyqBPKJ3WS5Wg6J0feqGR2JmWuHom+H5fG qBg4aGiY6SpV5RmJZ3oSpVIi6ZsCKW8i1VO6KVFukJsuE+JZp41GaUxKKX3SqKBmKQ1+5fCBKVhy XxMe6vNNoApa/p4SKmFqygCaKkal0kcKqeQT4KlvaOd1eOp85B8SXOo3kKp8ZKpFmidvgGoLTip9 nOgTmKoeyGp96KPuXFCnduF0JKF+MOAR0CoeACs9VoiwxkGxDiuDHCsVKOt4olOS6oGmbmq05kx3 TCumBgez5igzJgeHQmuq8oa1git6ske4hmuZbqtjZGtKPmsemKt67oa7hgabtke5Yiu6Wuq9guf3 HOUFcQ1P+WtQvqnA6ilV9iueZirloKpTImVfoipS1qmcGmWbBuzl8KOaTqX03OlgXqzARiWRQuwT ISaQhmyFxmq+lurJnqQ68SZttqw3dSjAUuiSjizLjqtibuhs/u4lYEYsz2JszrLkGPFskc7skE7o vCpm0a6nwkYsk5psg6ZsRR6teTJteTJtyXbo1P6ozVLszfqmkSqphPrrvFqt1vpo01It1l6tkMJs 2rqnhsasd0JtHqgrnFIonbJt3dIpHdVp1nKT1JKtz66t1/Ytp5InU9oUe77ryCKUzVJtSy0Tweqt 2UpuyULu49rtE5hkaLSjvo4r2gqu2kaowhpu5batex5p03atj4qtS3ZrzQ7u2eJtPzZrhX4u7dbt mmLugnIuLLhm59buy5pt4crp0Qpt45ou2OLu1qLu294mkSKv7KKuzpIu6RYvzk7u305u6DYBd+7G XZ4O7OrT/r/m0ZJKrMRGLnxizfKS7LNaLsPy69gO0YUmrKoirNcmbumy78RObOS2Kc2ab3vy7fYe QTqy5g78pHXFa3YocI/iBwP7Lr5mFwNfxwQDpQMbq9zqQQDEYwJXMH94sHfY6gwg8GngI7K+owH8 BjyesIuYsJfxLgsDyArL42rGsJ0gAAyfaQrb8IBo7jr6MA/3hyXyzjIGsX9YYncqBioa8X4M8XT0 jjcysX1AsQHXgTXmsBSnBzxmcHLAowtvFxdznRcnsTweTSpm8XlUotFgcXWw4uEIYyjGsRzPMR3X sR3f8R8GjzCS8XRgSCXiMSAHsiAPMiHjsaRUMRonsiIvNjIjN7IjPzIkR7IkTzIlV7IlXzImZ7Im bzInd7InfzIoh7IojzIpl7IpnzIqp7IqrzIrr0cIAAA7 --------------418838546236625644614131-- From sip-bounces@ietf.org Wed Mar 14 23:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgBI-0007ku-F6; Wed, 14 Mar 2007 22:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgBH-0007km-DH for sip@ietf.org; Wed, 14 Mar 2007 22:59:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRgBF-0006Ld-1J for sip@ietf.org; Wed, 14 Mar 2007 22:59:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2007 22:59:05 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2F2x4Jm018336; Wed, 14 Mar 2007 22:59:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2F2wwGf018836; Thu, 15 Mar 2007 02:59:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 22:58:58 -0400 Received: from [192.168.1.104] ([10.86.242.218]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 22:58:58 -0400 Message-ID: <45F8B671.3040408@cisco.com> Date: Wed, 14 Mar 2007 22:58:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erkki.Koivusalo@nokia.com Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <45EC200D.5010506@acm.org><45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org><45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com><45F737F6.5000208@acm.org> <45F7E027.9010109@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F037588FA@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F037588FA@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 02:58:58.0219 (UTC) FILETIME=[E051EFB0:01C766AD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3780; t=1173927544; x=1174791544; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-02 |Sender:=20 |To:=20Erkki.Koivusalo@nokia.com; bh=MZb9E5sRD1pswV7Om1++8ddw1D27h2Dr1hm3+wADfhY=; b=qv0V2asRppJ/PPV56iq7ffZA5uQHV7E07GTEJL+8MOvwEWAgZUrFi+hlsyqlNrhyKNom+kva nFevPDfmxbjxqNDdFtxE47byr8f4WCDaVODGFM86MXWgJ4FM5ko7a5Zj; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org, petithug@acm.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Erkki.Koivusalo@nokia.com wrote: > Hi, > > >>OK, I still think this is way too complicated. > > > I agree. > > >>My first thought is to just not solve it. We don't need to >>deprecate UDP >>because of this; we just need to have some tools to alert SIP >>administrators that this problem has happened. ....The alarm >>gives them the warning that the time has arrived to fix this >>problem. > > > Jonathan, you must be kidding. I am not. Listen, if folks are running a real SIP network and they are using outbound, and they elect to use UDP knowing that this problem can happen, then the consequence is that things won't work for large messages. Thats the consequence of making this choice, and we are providing them a way to know that it has actually happened. I expect in reality, providers will know exactly how big each message will be since their clients are controlled by them and they have tested them with exactly the messages they will emit. So, this error code is really likely to show up in pre-deployment testing, at which point you either switch to tcp, or live with the risk. > > I find this kind of approach as horrible. Let the provider buy > proxies and customers buy phones just to find out after some > time that they do not work and the customers are not able to > receive all the calls. Then start fixing it some way or another. > How many days/weeks would be needed for the customers to find > out that they have some random problems and stop using the service ? > I can not believe we in IETF would be happy to drive things like that. See above. > > >>An alternative to dynamically repair it is to use the >>reg-event package for the notification, since we already have that. >>Outbound proxy would reject the request, with this new response code. >>It would pass through the home proxy/registrar which will generate a >>notification to the client telling it to re-register over tcp. > > > The problem is that the size of the simplest reg-event notifications > I have seen are close to 1000 bytes. The ultimate size will depend > on a number of things but there is a risk for the NOTIFY to become > bigger than MTU so that it can not be delivered over UDP. There is > a potential chicken and egg problem in this proposal. Well, close to 1000 is still under the MTU by plenty, so it works fine. > > >>My rationale is that if your client can do tcp (which is required >>for the dynamic repair approach), may as well have it always connect >>via tcp. I don't buy this bit about wanting hybrid UDP TCP because of >>scale. The problem you've raised in your draft argues to me the > > opposite > >>- folks whose tcp scale is a problem need to FIX it, since there is > > this > >>issue with UDP outbound. > > > I agree. Said that, it seems to me once again that the idea to > keep UDP within the Outbound draft _is_ a bad idea. I'm trying to be pragmatic. THe *reality* is that there IS still a lot of UDP out there. And IETF producing specifications that ignore this is just ignoring reality. It'll just mean that folks ignore sip-outbound. The best we can do is clearly document the ongoing and increasing troubles of UDP, so that a provider or enterprise can make an educated choice and make the move to tcp based on the evidence we've provided. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 05:00:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlmD-0004rD-W0; Thu, 15 Mar 2007 04:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlmA-0004kA-4H; Thu, 15 Mar 2007 04:57:34 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRlm8-0006or-Q8; Thu, 15 Mar 2007 04:57:34 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1173949050!5060110!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 16153 invoked from network); 15 Mar 2007 08:57:30 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-153.messagelabs.com with SMTP; 15 Mar 2007 08:57:30 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l2F8vUTd018932; Thu, 15 Mar 2007 01:57:30 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l2F8vTnm001586; Thu, 15 Mar 2007 03:57:30 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l2F8vRRP001531; Thu, 15 Mar 2007 03:57:29 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Mar 2007 16:57:26 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03F84047@ZMY16EXM66.ds.mot.com> In-Reply-To: <45F8B7C4.7070802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link to list of event packages in SIP Thread-Index: AcdmryXa055ow17NQlmm1ZRzNQqjgwAMJuLw X-Priority: 1 Priority: Urgent Importance: high References: <45F0476B.1000503@ericsson.com><1173393469.17141.108.camel@montag.eng.level3.com> <45F8B7C4.7070802@cisco.com> From: "Avasarala Ranjit-A20990" To: , X-Vontu: Pass X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Sip] Link to list of event packages in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Is there any URL link where I can get the list of all event packages that were added to SIP events framework? Thanks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 05:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRm1H-0005v2-Vo; Thu, 15 Mar 2007 05:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRm1H-0005sQ-2N; Thu, 15 Mar 2007 05:13:11 -0400 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRm1E-0001xK-CG; Thu, 15 Mar 2007 05:13:11 -0400 Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp [129.60.39.117]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2F9BdVU009756; Thu, 15 Mar 2007 18:13:06 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA) with ESMTP id ADB99974; Thu, 15 Mar 2007 18:13:06 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 0659C20AE2B; Thu, 15 Mar 2007 18:13:06 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9BA0520AE2A; Thu, 15 Mar 2007 18:13:05 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2F9D5tC021944; Thu, 15 Mar 2007 18:13:05 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2F9D48T015206; Thu, 15 Mar 2007 18:13:04 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2F9D4uI015203; Thu, 15 Mar 2007 18:13:04 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id l2F9D4ZX028937; Thu, 15 Mar 2007 18:13:04 +0900 (JST) Message-Id: <200703150913.l2F9D4ZX028937@imf.m.ecl.ntt.co.jp> To: ranjit@motorola.com From: Mayumi Munakata Date: Thu, 15 Mar 2007 18:13:04 +0900 X-Mailer: WebMail V3.5.1 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Junkmail: UCE(10) X-Junkmail-Status: score=10/10, host=sfs2.rdh.ecl.ntt.co.jp X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.45F90E22.0037,ss=1,fgs=0, ip=129.60.5.69, so=2006-12-09 10:45:40, dmn=5.3.10/2007-02-21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: sip@ietf.org, sipping@ietf.org Subject: [Sip] Re: Link to list of event packages in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All the IANA registered event packages can be found at the following link: http://www.iana.org/assignments/sip-events Mayumi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 06:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnO3-0004Z5-Ut; Thu, 15 Mar 2007 06:40:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnO2-0004Yr-Ab for sip@ietf.org; Thu, 15 Mar 2007 06:40:46 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRnNx-0005vr-AY for sip@ietf.org; Thu, 15 Mar 2007 06:40:46 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JEX00H27XNFTY@siemenscomms.co.uk> for sip@ietf.org; Thu, 15 Mar 2007 10:40:27 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Mar 2007 10:40:29 +0000 Content-return: allowed Date: Thu, 15 Mar 2007 10:40:27 +0000 From: "Elwell, John" To: Mayumi Munakata , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B4A9ECB@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [Sip] Comments on draft-munakata-sip-privacy-clarified-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mayumi, I think the Privacy header field does need to be brought up-to-date by removing unused and badly specified values and to align with more recent SIP capabilities such as GRUU, Target-Dialog, Identity, etc., so I welcome this draft. Some comments: It needs to be clarified whether this is intended to obsolete or update RFC 3323. Section 1 says that it obsoletes RFC 3323. However, it also refers to and clarifies the extensions to the Privacy header field in RFC 3325 and RFC 4424, and these extensions refer normatively to RFC 3323. So I don't think it is possible to obsolete RFC 3323 unless RFC 3325 and RFC 4424 are updated to reference the new RFC. In section 1 it mentions the Identity header field as revealing identity information. This is not true, because it is simply irreversible cryptographic information. However, the Identity-Info header field could reveal information about the requester's domain (although this would only be included when signing a From header field URI that itself reveals information, so I don't think it needs to be considered). Impact also on 5.1. It should also be mentioned that a privacy service must come before an authentication service (RFC 4474), because the authentication service will sign the From and Contact header field URIs, for example. I see that 6.2.7 has more in-depth discussion on these header fields, but I am not sure it captures these points accurately. In section 3.2, it should be mentioned that if only network privacy is requested no network intermediary is allowed to override the user-provided privacy. In section 4.1, we should mention in the table all methods, including those defined since RFC 3323 was published (e.g., PUBISH). In section 5.1, table 1, P-Preferred-Identity is missing. Should we recommend that a UA omit it, or is it still useful between the UA and its domain proxy? Table 1 does not make a distinction between requests and responses. For example, you cannot anonymise a Call-ID or Via header field in a response (although it can restore stripped out values, as mentioned below the table for Call-ID). Section 6.1.2, last paragraph. Presumably this refers to the Contact header field URI. Section 6.2.1, add Join to the list of header fields that can contain a call-ID. There is a dependency on in-bound requests outside a dialog being routed via the same privacy service - is this an issue? I think it is captured later in 6.4.3 specifically for the Replaces header field, but does it need to be discussed earlier in general terms? Also it should be mentioned in the sections dealing specifically with Join and Target-Dialog. Section 6.2.11 recommends anonymisation of Referred-By, but is there any benefit in having an anonymous Referred-By URI as opposed to omitting this header field? Section 6.2.14. Surely it is acceptable to add a Subject header field if it doesn't reveal identity in any way? Section 6.4.4. Shouldn't this discuss the restoration of Route header field values that have been stripped out of Record-Route header fields? Section 7.1. This fails to discuss location of a privacy service for mid-dialog-requests (but I think that is covered in section 8, where use of Record-Route is discussed, so perhaps it doesn't matter). More importantly, it fails to discuss location of a privacy service for requests that contain header fields such as Replaces, Join and Target-Dialog. I may have missed it, but is it specified anywhere whether a privacy service is required to pass on the Privacy header field or strip it out? John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 06:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnRm-000689-Ud; Thu, 15 Mar 2007 06:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnRm-00067p-1o for sip@ietf.org; Thu, 15 Mar 2007 06:44:38 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRnRh-0007HE-96 for sip@ietf.org; Thu, 15 Mar 2007 06:44:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2FAi0G9009827; Thu, 15 Mar 2007 12:44:21 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 12:44:12 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 12:44:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Thu, 15 Mar 2007 12:44:09 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03759217@esebe103.NOE.Nokia.com> In-Reply-To: <45F8B671.3040408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 thread-index: AcdmrfCVts/0dMOMSLiiy0PvQAu+SQALe37A References: <45EC200D.5010506@acm.org><45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org><45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com><45F737F6.5000208@acm.org> <45F7E027.9010109@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F037588FA@esebe103.NOE.Nokia.com> <45F8B671.3040408@cisco.com> From: To: X-OriginalArrivalTime: 15 Mar 2007 10:44:12.0105 (UTC) FILETIME=[DE4AEB90:01C766EE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070315124425-24EA4BB0-45294641/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 1.3 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: sip@ietf.org, petithug@acm.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Listen, if folks are running a real SIP network and they are using=20 >outbound, and they elect to use UDP knowing that this problem can=20 >happen, then the consequence is that things won't work for large=20 >messages. Thats the consequence of making this choice, and we are=20 >providing them a way to know that it has actually happened. > >I expect in reality, providers will know exactly how big each=20 >message will be since their clients are controlled by them and=20 >they have tested them with exactly the messages they will emit.=20 >So, this error code is really likely to show up in pre-deployment=20 >testing, at which point you either switch to tcp, or live with the=20 >risk. You are making quite strict assumptions in what you are saying. In practice this model would have the following limitations: - As ICE is likely to increase the size of the SDP body of INVITE by 200-400 bytes, when applying the full set=20 of NAT traversal method the probability grows that the size of the INVITE request ultimately hits the MTU limit. - UDP would only apply to closed environments (walled gardens) where the service provider is able to certify all the=20 connected clients and control the number of proxies in=20 any possible route within the network (to limit the number of Via and Record-Route headers). Furthermore there can=20 not be any direct SIP connectivity to rest of world.=20 I admit that this may apply to how SIP is used e.g. in=20 enterprises with their IT departments testing and validating=20 all pieces of equipment or VoIP operators exclusively providing=20 the UAs for their customers and having their PSTN gateways=20 towards the rest of the world.=20 - It would preclude consumers connecting the service with=20 their favourite new softphone just installed to their PC. - Only the services certified by the service provider could ever be applied.=20 - Or in best case if the service provider is able to control the types of NATs applied within the network so that those would be able to cope with IP fragmentation, in this case UDP could be used even for messages larger than MTU. If the provider is happy with all these limitations, yes then Outbound with UDP could make sense for the deployment. I still have the feeling that there are two many 'if's=20 preventing this scheme to be robust and reliable. Too many things might simply go wrong. >>>- folks whose tcp scale is a problem need to FIX it,=20 >>> since there is this issue with UDP outbound.=20 >>=20 >> I agree. Said that, it seems to me once again that the idea to=20 >> keep UDP within the Outbound draft _is_ a bad idea. > >I'm trying to be pragmatic. > >THe *reality* is that there IS still a lot of UDP out there. And IETF=20 >producing specifications that ignore this is just ignoring reality.=20 >It'll just mean that folks ignore sip-outbound.=20 It is hard for me to understand that while all the UAs and proxies have to be modified in order to support Outbound, upgrading for TCP support would be as difficult as it appears to many. For the UA point of view, having a IP stack with TCP support integrated to SIP does not appear much more difficult than supporting STUN=20 keepalives. For the proxy point of view I am hearing evidence from multiple independent research projects that scaling TCP would not be impossible to solve (at least for Linux servers). TCP could even help some of the scalability problems since it uses even more lighweight keepalive schemes as STUN and the frequency of keepalives is lower in TCP compared to UDP. >The best we can do is clearly document the ongoing and=20 >increasing troubles of UDP, so that a provider or enterprise=20 >can make an educated choice and make=20 >the move to tcp based on the evidence we've provided. What I am worried about is that the message IETF makes in=20 SIP Outbound draft (only one paragraph in the spec giving a hint that there may be a problem) is very vague. Yes it has been discussed in the list, but still providing extensive UDP machinery in Outbound (STUN keepalives etc.) would create a mixed message and delay the whole proxy industry to face the=20 issue and start actions to fix the TCP scalability problem. Also it would call the vendors to provide more complex solutions as necessary. Here I mostly refer to STUN=20 keepalives needed for UDP vs the CRLF/TCP keepalives=20 only needed for TCP. This also can delay how soon Outbound really hits the market in large scale. About the dynamic fix with reg-event: >>>An alternative to dynamically repair it is to use the=20 >>>reg-event package for the notification, since we already have that.=20 >>>..... The home proxy/registrar would generate a=20 >>>notification to the client telling it to re-register over tcp.=20 >>=20 >> The problem is that the size of the simplest reg-event notifications=20 >> I have seen are close to 1000 bytes. The ultimate size will depend >> on a number of things but there is a risk for the NOTIFY to become >> bigger than MTU so that it can not be delivered over UDP. There is >> a potential chicken and egg problem in this proposal. > >Well, close to 1000 is still under the MTU by plenty, so it works fine. I agree that typical reg-event NOTIFYs are smaller than MTU, but there is not really any upper limit so there is a chance of fatal failure. As an example consider a case where a person=20 called Gordon had registered his wireless PDA arrives to office=20 and registers now also from his PC using Outbound and UDP: -> REGISTER <- 200 OK -> SUBSCRIBE <- 200 OK <- NOTIFY In this case the full reg-event notification could be over 1300 bytes e.g. like this one: Request-Line: NOTIFY sip:gordon@pc345.worcester.bell-telephone.com:12363 SIP/2.0 Call-ID: VZ8iKyeJoIc2TwYRTcSB5j_bBPdQ3x Contact: Content-Type: application/reginfo+xml CSeq: 1 NOTIFY From: "Gordon Maverick" ;tag=3Dpoqw089q23oijf0+as9e Max-Forwards: 69 To: "Gordon Maverick" ;tag=3Dkh0h5eib81hc7r1i1sqt Via: SIP/2.0/UDP proxy.yourserviceprovider.com:5060;branch=3Dz9hG4bK2147483647 Via: SIP/2.0/UDP registrar.yourserviceprovider.com:5060;branch=3Dz9hG4bK2134765492 Event: reg Subscription-State: active;expires=3D3600 Content-Length: 649 Message body sip:gordon@pc345.worcester.bell-telephone.com:12363 Gordon Maverick sip:gordon.maverick@192.222.67.129:14568 Gordon Maverick Do you believe we should impose some limitations about how the reg-event notifications can look like if sent for UAs using Outbound with UDP ? Or introduce some exceptional practices to send partial notification right after SUBSCRIBE asking the client to register with TCP if the full notification=20 would be bigger than MTU ? Sorry to say but to me this mechanism=20 appears as broken. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 08:08:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoiB-0007fn-L2; Thu, 15 Mar 2007 08:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoiA-0007fe-98 for sip@ietf.org; Thu, 15 Mar 2007 08:05:38 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRohu-00089E-Ia for sip@ietf.org; Thu, 15 Mar 2007 08:05:38 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEY0081S1KXXY@usaga01-in.huawei.com> for sip@ietf.org; Thu, 15 Mar 2007 05:05:21 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEY00BEG1KUTJ@usaga01-in.huawei.com> for sip@ietf.org; Thu, 15 Mar 2007 05:05:21 -0700 (PDT) Date: Thu, 15 Mar 2007 07:04:01 -0500 From: Spencer Dawkins Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 To: sip@ietf.org Message-id: <12d001c766fa$05615330$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <45EC200D.5010506@acm.org> <45F6159A.9080003@cisco.com> <45F617F0.3050709@acm.org> <45F6D198.90401@cisco.com> <45F70D70.2040007@softarmor.com> <45F737F6.5000208@acm.org> <45F7E027.9010109@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F037588FA@esebe103.NOE.Nokia.com> <45F8B671.3040408@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F03759217@esebe103.NOE.Nokia.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If I understand correctly, Erkki is saying that we're driving off a cliff, and Jonathan is saying that we haven't given anyone outside the IETF an indication that we're going to change direction, so suddenly deprecating UDP isn't realistic. I do see what both Jonathan and Erkki are saying, and I think both have valid points. Perhaps it would be worth putting together a short I-D, either as Informational or (probably better) as BCP, to say: - we know 3261 requires TCP support, - we know many SIP devices were deployed without it and work today, - we know that we are in the process of developing new standards-track specifications that will significantly increase the size of SIP messages, - we know that IP-level fragmentation will increase, and is likely to be a problem, - so if you have already deployed UDP-only SIP, this would be a good time to start planning for TCP support". I can name some specifications that qualify here (Erkki mentioned ICE, and GRUU was discussed earlier this week), but is there a complete list that could be included, just off the top of anyone's head? This is probably less than two pages of non-boilerplate text, even including the list. Could it help the current situation? Spencer ----- Original Message ----- From: To: Cc: ; ; Sent: Thursday, March 15, 2007 5:44 AM Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Hi, >Listen, if folks are running a real SIP network and they are using >outbound, and they elect to use UDP knowing that this problem can >happen, then the consequence is that things won't work for large >messages. Thats the consequence of making this choice, and we are >providing them a way to know that it has actually happened. > >I expect in reality, providers will know exactly how big each >message will be since their clients are controlled by them and >they have tested them with exactly the messages they will emit. >So, this error code is really likely to show up in pre-deployment >testing, at which point you either switch to tcp, or live with the >risk. You are making quite strict assumptions in what you are saying. In practice this model would have the following limitations: - As ICE is likely to increase the size of the SDP body of INVITE by 200-400 bytes, when applying the full set of NAT traversal method the probability grows that the size of the INVITE request ultimately hits the MTU limit. - UDP would only apply to closed environments (walled gardens) where the service provider is able to certify all the connected clients and control the number of proxies in any possible route within the network (to limit the number of Via and Record-Route headers). Furthermore there can not be any direct SIP connectivity to rest of world. I admit that this may apply to how SIP is used e.g. in enterprises with their IT departments testing and validating all pieces of equipment or VoIP operators exclusively providing the UAs for their customers and having their PSTN gateways towards the rest of the world. - It would preclude consumers connecting the service with their favourite new softphone just installed to their PC. - Only the services certified by the service provider could ever be applied. - Or in best case if the service provider is able to control the types of NATs applied within the network so that those would be able to cope with IP fragmentation, in this case UDP could be used even for messages larger than MTU. If the provider is happy with all these limitations, yes then Outbound with UDP could make sense for the deployment. I still have the feeling that there are two many 'if's preventing this scheme to be robust and reliable. Too many things might simply go wrong. >>>- folks whose tcp scale is a problem need to FIX it, >>> since there is this issue with UDP outbound. >> >> I agree. Said that, it seems to me once again that the idea to >> keep UDP within the Outbound draft _is_ a bad idea. > >I'm trying to be pragmatic. > >THe *reality* is that there IS still a lot of UDP out there. And IETF >producing specifications that ignore this is just ignoring reality. >It'll just mean that folks ignore sip-outbound. It is hard for me to understand that while all the UAs and proxies have to be modified in order to support Outbound, upgrading for TCP support would be as difficult as it appears to many. For the UA point of view, having a IP stack with TCP support integrated to SIP does not appear much more difficult than supporting STUN keepalives. For the proxy point of view I am hearing evidence from multiple independent research projects that scaling TCP would not be impossible to solve (at least for Linux servers). TCP could even help some of the scalability problems since it uses even more lighweight keepalive schemes as STUN and the frequency of keepalives is lower in TCP compared to UDP. >The best we can do is clearly document the ongoing and >increasing troubles of UDP, so that a provider or enterprise >can make an educated choice and make >the move to tcp based on the evidence we've provided. What I am worried about is that the message IETF makes in SIP Outbound draft (only one paragraph in the spec giving a hint that there may be a problem) is very vague. Yes it has been discussed in the list, but still providing extensive UDP machinery in Outbound (STUN keepalives etc.) would create a mixed message and delay the whole proxy industry to face the issue and start actions to fix the TCP scalability problem. Also it would call the vendors to provide more complex solutions as necessary. Here I mostly refer to STUN keepalives needed for UDP vs the CRLF/TCP keepalives only needed for TCP. This also can delay how soon Outbound really hits the market in large scale. About the dynamic fix with reg-event: >>>An alternative to dynamically repair it is to use the >>>reg-event package for the notification, since we already have that. >>>..... The home proxy/registrar would generate a >>>notification to the client telling it to re-register over tcp. >> >> The problem is that the size of the simplest reg-event notifications >> I have seen are close to 1000 bytes. The ultimate size will depend >> on a number of things but there is a risk for the NOTIFY to become >> bigger than MTU so that it can not be delivered over UDP. There is >> a potential chicken and egg problem in this proposal. > >Well, close to 1000 is still under the MTU by plenty, so it works fine. I agree that typical reg-event NOTIFYs are smaller than MTU, but there is not really any upper limit so there is a chance of fatal failure. As an example consider a case where a person called Gordon had registered his wireless PDA arrives to office and registers now also from his PC using Outbound and UDP: -> REGISTER <- 200 OK -> SUBSCRIBE <- 200 OK <- NOTIFY In this case the full reg-event notification could be over 1300 bytes e.g. like this one: Request-Line: NOTIFY sip:gordon@pc345.worcester.bell-telephone.com:12363 SIP/2.0 Call-ID: VZ8iKyeJoIc2TwYRTcSB5j_bBPdQ3x Contact: Content-Type: application/reginfo+xml CSeq: 1 NOTIFY From: "Gordon Maverick" ;tag=poqw089q23oijf0+as9e Max-Forwards: 69 To: "Gordon Maverick" ;tag=kh0h5eib81hc7r1i1sqt Via: SIP/2.0/UDP proxy.yourserviceprovider.com:5060;branch=z9hG4bK2147483647 Via: SIP/2.0/UDP registrar.yourserviceprovider.com:5060;branch=z9hG4bK2134765492 Event: reg Subscription-State: active;expires=3600 Content-Length: 649 Message body sip:gordon@pc345.worcester.bell-telephone.com:12363 Gordon Maverick sip:gordon.maverick@192.222.67.129:14568 Gordon Maverick Do you believe we should impose some limitations about how the reg-event notifications can look like if sent for UAs using Outbound with UDP ? Or introduce some exceptional practices to send partial notification right after SUBSCRIBE asking the client to register with TCP if the full notification would be bigger than MTU ? Sorry to say but to me this mechanism appears as broken. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 08:10:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRomU-0002UH-Fz; Thu, 15 Mar 2007 08:10:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRomT-0002U4-IK for sip@ietf.org; Thu, 15 Mar 2007 08:10:05 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRomN-0000o0-U8 for sip@ietf.org; Thu, 15 Mar 2007 08:10:05 -0400 Received: by an-out-0708.google.com with SMTP id d30so145882and for ; Thu, 15 Mar 2007 05:09:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=rAgfqsMHEFEZRwiKnMY3eBqEDhXnSvsH/13rvb8UvvZH4UHITBeSYG4EH+KQG1tDPdxtqsspQooUQ/gKU1s2q2VScdHM2q8oRNn4a/Zdsy0PUk5c+dvXrbZkaTgVlLLenLtowKBKSqKsdUZ1KtNwbwPU5DTmKpsq5Vhy8HrqHMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=k1Rp3JGGq9ySOilhNmpMm/QCJRh4v+8v31JOsy60evwzp5mGSzN/+adFHlEdAMdi7ogUDyRRiaOBWWJhc/RAjVjchzhVlzuPbneM0Ei1ESZMxh9ApzyUCKX/ri3YwhvKr/RgUc0nXvTMSKA5sjMoHVqEYNS3heV3XjDwtCEVT0k= Received: by 10.100.133.9 with SMTP id g9mr338949and.1173960599550; Thu, 15 Mar 2007 05:09:59 -0700 (PDT) Received: by 10.100.109.3 with HTTP; Thu, 15 Mar 2007 05:09:59 -0700 (PDT) Message-ID: <1bf2eff0703150509u3936243dy61512ffd9b79dc69@mail.gmail.com> Date: Thu, 15 Mar 2007 20:09:59 +0800 From: "Xu Chunrong" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] useage of DNS in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1490008112==" Errors-To: sip-bounces@ietf.org --===============1490008112== Content-Type: multipart/alternative; boundary="----=_Part_53805_12337746.1173960599483" ------=_Part_53805_12337746.1173960599483 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksYWxsLi4KIFBsZWFzZSBoZWxwIG1lICEgcXVlc3Rpb24gYWJvdXQgRE5TIGNvbmZpZ3VyYXRp b24gZm9yIFNJUC4KClN1cHBvc2UgdGhlcmUgaXMgYSBTSVAgdHJhcGV6b2lkOgoKICAgICAgICBQ cm94eTEtLS0tLS0tLS1wcm94eTIKICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXAogICAgICAvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXApVQTEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVUEyCgpwcm94eTEgYW5kIHVhMSBpcyBpbiBkb21h aW4gQS5jb20sIHByb3h5MiBhbmQgdWEyIGlzIGluIGRvbWFpbiBCLmNvbSxhbmQKYm90aCBkb21h aW4KaGF2ZSB0aGVpciBvd24gRE5TIHNlcnZlcnMuLi5Ib3cgc2hvdWxkIEkgY29uZmlndXJlIHRo ZSB0d28gRE5TPyAuLkkgbWVhbgpob3cgdG8gc2V0CkROUyBTUlYgYW5kL29yIE5BUFRSIHJlY29y ZHMuLgoKVGhhbmtzLi4uCgotLSAK4pWU4pWQ4pWQ4pWXICDilIsgIOS9lSAg5peiCuKVkeeXtOiv tOKVkSAg4pSLICDlirMgIOinowrilZHkurrmoqbilZEgIOKUiyAg5bymICDnkLQK4pWa4pWQ4pWQ 4pWdICDilIsgIOS4iiAg5LitCuKVkFNFVeKVkCDilpMgIOmfsyAg5ZGzCuKVkFh1IENodW5yb25n 4pWQ4pWQ4pekCg== ------=_Part_53805_12337746.1173960599483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksYWxsLi48YnI+Jm5ic3A7UGxlYXNlIGhlbHAgbWUgISBxdWVzdGlvbiBhYm91dCBETlMgY29u ZmlndXJhdGlvbiBmb3IgU0lQLjxicj48YnI+U3VwcG9zZSB0aGVyZSBpcyBhIFNJUCB0cmFwZXpv aWQ6PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3h5MS0tLS0tLS0tLXBy b3h5Mjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBc PGJyIGNsZWFyPSJhbGwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFwKPGJyPlVBMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVQTI8YnI+ PGJyPnByb3h5MSBhbmQgdWExIGlzIGluIGRvbWFpbiA8YSBocmVmPSJodHRwOi8vQS5jb20iPkEu Y29tPC9hPiwgcHJveHkyIGFuZCB1YTIgaXMgaW4gZG9tYWluIDxhIGhyZWY9Imh0dHA6Ly9CLmNv bSI+Qi5jb208L2E+LGFuZCBib3RoIGRvbWFpbjxicj5oYXZlIHRoZWlyIG93biBETlMgc2VydmVy cy4uLkhvdyBzaG91bGQgSSBjb25maWd1cmUgdGhlIHR3byBETlM/IC4uSSBtZWFuIGhvdyB0byBz ZXQKPGJyPkROUyBTUlYgYW5kL29yIE5BUFRSIHJlY29yZHMuLjxicj48YnI+VGhhbmtzLi4uPGJy Pjxicj4tLSA8YnI+4pWU4pWQ4pWQ4pWXJm5ic3A7Jm5ic3A74pSLJm5ic3A7Jm5ic3A75L2VJm5i c3A7Jm5ic3A75peiPGJyPuKVkeeXtOivtOKVkSZuYnNwOyZuYnNwO+KUiyZuYnNwOyZuYnNwO+WK syZuYnNwOyZuYnNwO+inozxicj7ilZHkurrmoqbilZEmbmJzcDsmbmJzcDvilIsmbmJzcDsmbmJz cDvlvKYmbmJzcDsmbmJzcDvnkLQ8YnI+4pWa4pWQ4pWQ4pWdJm5ic3A7Jm5ic3A74pSLJm5ic3A7 Jm5ic3A75LiKJm5ic3A7Jm5ic3A75LitPGJyPiDilZBTRVXilZAg4paTJm5ic3A7Jm5ic3A76Z+z Jm5ic3A7Jm5ic3A75ZGzPGJyPiDilZBYdSBDaHVucm9uZ+KVkOKVkOKXpAo= ------=_Part_53805_12337746.1173960599483-- --===============1490008112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1490008112==-- From sip-bounces@ietf.org Thu Mar 15 08:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpQw-00060G-FP; Thu, 15 Mar 2007 08:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpQv-0005uT-6u for sip@ietf.org; Thu, 15 Mar 2007 08:51:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRpQn-0000br-6s for sip@ietf.org; Thu, 15 Mar 2007 08:51:53 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 51D4620951; Thu, 15 Mar 2007 13:50:57 +0100 (CET) X-AuditID: c1b4fb3c-aacefbb0000073d5-01-45f94131971c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3C2E4204C5; Thu, 15 Mar 2007 13:50:57 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 13:50:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Thu, 15 Mar 2007 13:50:55 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702AC27AE@esealmw113.eemea.ericsson.se> In-Reply-To: <12d001c766fa$05615330$6401a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Thread-Index: Acdm+0GIBkPH4AYPQCSdkSuPVccclgAAHKwg From: "Christer Holmberg \(JO/LMF\)" To: "Spencer Dawkins" , X-OriginalArrivalTime: 15 Mar 2007 12:50:56.0552 (UTC) FILETIME=[92E57280:01C76700] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, What I am worried about is the assumption that the size of SIP messages will keep on growing, growing and growing, and nobody seems to care. Maybe THAT is something we should look at also, and not only focus on the transport protocol. And, just because we define hundreds of new message increasing extensions, it doesn't mean that people are going to implement them - at least not in the near future. I am pretty sure there are lots of deployments out there, for which UDP works just fine. When people start to implement/deploy new message-increasing features, they are probably going to look into the transport issues also. Also, even if we remove UDP from outbound, what will prevent people from implement it anyway - either using STUN keep-alive, or some other mechanism for the keep-alive??? Isn't it better to have a standardized way of doing it?=20 Remember that STUN keep-alive is not part of outbound as such - it's a STUN usage defined in 3489bis. The outbound spec defines how to use the STUN keep-alive in SIP environments, no matter if you implement the rest of outbound or not, so that should be there (or somewhere else) even if outbound support for UDP is removed. Regards, Christer=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: 15. maaliskuuta 2007 14:04 > To: sip@ietf.org > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 >=20 > If I understand correctly, Erkki is saying that we're driving=20 > off a cliff, and Jonathan is saying that we haven't given=20 > anyone outside the IETF an indication that we're going to=20 > change direction, so suddenly deprecating UDP isn't realistic. >=20 > I do see what both Jonathan and Erkki are saying, and I think=20 > both have valid points. >=20 > Perhaps it would be worth putting together a short I-D,=20 > either as Informational or (probably better) as BCP, to say: >=20 > - we know 3261 requires TCP support, >=20 > - we know many SIP devices were deployed without it and work today, >=20 > - we know that we are in the process of developing new=20 > standards-track specifications that will significantly=20 > increase the size of SIP messages, >=20 > - we know that IP-level fragmentation will increase, and is=20 > likely to be a problem, >=20 > - so if you have already deployed UDP-only SIP, this would be=20 > a good time to start planning for TCP support". >=20 > I can name some specifications that qualify here (Erkki=20 > mentioned ICE, and GRUU was discussed earlier this week), but=20 > is there a complete list that could be included, just off the=20 > top of anyone's head? >=20 > This is probably less than two pages of non-boilerplate text,=20 > even including the list. Could it help the current situation? >=20 > Spencer >=20 > ----- Original Message ----- > From: > To: > Cc: ; ; > Sent: Thursday, March 15, 2007 5:44 AM > Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 >=20 >=20 >=20 > Hi, >=20 > >Listen, if folks are running a real SIP network and they are using > >outbound, and they elect to use UDP knowing that this problem can > >happen, then the consequence is that things won't work for large > >messages. Thats the consequence of making this choice, and we are > >providing them a way to know that it has actually happened. > > > >I expect in reality, providers will know exactly how big each > >message will be since their clients are controlled by them and > >they have tested them with exactly the messages they will emit. > >So, this error code is really likely to show up in pre-deployment > >testing, at which point you either switch to tcp, or live with the > >risk. >=20 > You are making quite strict assumptions in what you are saying. > In practice this model would have the following limitations: >=20 > - As ICE is likely to increase the size of the SDP body > of INVITE by 200-400 bytes, when applying the full set > of NAT traversal method the probability grows that the > size of the INVITE request ultimately hits the MTU limit. >=20 > - UDP would only apply to closed environments (walled gardens) > where the service provider is able to certify all the > connected clients and control the number of proxies in > any possible route within the network (to limit the number > of Via and Record-Route headers). Furthermore there can > not be any direct SIP connectivity to rest of world. > I admit that this may apply to how SIP is used e.g. in > enterprises with their IT departments testing and validating > all pieces of equipment or VoIP operators exclusively providing > the UAs for their customers and having their PSTN gateways > towards the rest of the world. >=20 > - It would preclude consumers connecting the service with > their favourite new softphone just installed to their PC. >=20 > - Only the services certified by the service provider could > ever be applied. >=20 > - Or in best case if the service provider is able to control > the types of NATs applied within the network so that those > would be able to cope with IP fragmentation, in this case > UDP could be used even for messages larger than MTU. >=20 > If the provider is happy with all these limitations, yes > then Outbound with UDP could make sense for the deployment. > I still have the feeling that there are two many 'if's > preventing this scheme to be robust and reliable. Too > many things might simply go wrong. >=20 > >>>- folks whose tcp scale is a problem need to FIX it, > >>> since there is this issue with UDP outbound. > >> > >> I agree. Said that, it seems to me once again that the idea to > >> keep UDP within the Outbound draft _is_ a bad idea. > > > >I'm trying to be pragmatic. > > > >THe *reality* is that there IS still a lot of UDP out there. And IETF > >producing specifications that ignore this is just ignoring reality. > >It'll just mean that folks ignore sip-outbound. >=20 > It is hard for me to understand that while all the UAs and proxies > have to be modified in order to support Outbound, upgrading for > TCP support would be as difficult as it appears to many. For the > UA point of view, having a IP stack with TCP support integrated > to SIP does not appear much more difficult than supporting STUN > keepalives. For the proxy point of view I am hearing evidence > from multiple independent research projects that scaling TCP > would not be impossible to solve (at least for Linux servers). > TCP could even help some of the scalability problems since it > uses even more lighweight keepalive schemes as STUN and the > frequency of keepalives is lower in TCP compared to UDP. >=20 > >The best we can do is clearly document the ongoing and > >increasing troubles of UDP, so that a provider or enterprise > >can make an educated choice and make > >the move to tcp based on the evidence we've provided. >=20 > What I am worried about is that the message IETF makes in > SIP Outbound draft (only one paragraph in the spec giving > a hint that there may be a problem) is very vague. Yes it > has been discussed in the list, but still providing extensive > UDP machinery in Outbound (STUN keepalives etc.) would create a > mixed message and delay the whole proxy industry to face the > issue and start actions to fix the TCP scalability problem. >=20 > Also it would call the vendors to provide more complex > solutions as necessary. Here I mostly refer to STUN > keepalives needed for UDP vs the CRLF/TCP keepalives > only needed for TCP. This also can delay how soon > Outbound really hits the market in large scale. >=20 >=20 > About the dynamic fix with reg-event: >=20 > >>>An alternative to dynamically repair it is to use the > >>>reg-event package for the notification, since we already have that. > >>>..... The home proxy/registrar would generate a > >>>notification to the client telling it to re-register over tcp. > >> > >> The problem is that the size of the simplest reg-event=20 > notifications > >> I have seen are close to 1000 bytes. The ultimate size will depend > >> on a number of things but there is a risk for the NOTIFY to become > >> bigger than MTU so that it can not be delivered over UDP. There is > >> a potential chicken and egg problem in this proposal. > > > >Well, close to 1000 is still under the MTU by plenty, so it=20 > works fine. >=20 > I agree that typical reg-event NOTIFYs are smaller than MTU, > but there is not really any upper limit so there is a chance > of fatal failure. As an example consider a case where a person > called Gordon had registered his wireless PDA arrives to office > and registers now also from his PC using Outbound and UDP: >=20 > -> REGISTER > <- 200 OK > -> SUBSCRIBE > <- 200 OK > <- NOTIFY >=20 > In this case the full reg-event notification could be over > 1300 bytes e.g. like this one: >=20 > Request-Line: NOTIFY=20 > sip:gordon@pc345.worcester.bell-telephone.com:12363 > SIP/2.0 > Call-ID: VZ8iKyeJoIc2TwYRTcSB5j_bBPdQ3x > Contact: > Content-Type: application/reginfo+xml > CSeq: 1 NOTIFY > From: "Gordon Maverick" > = ;tag=3Dpoqw089q23oijf0+as9e > Max-Forwards: 69 > To: "Gordon Maverick" > = ;tag=3Dkh0h5eib81hc7r1i1sqt > Via: SIP/2.0/UDP > proxy.yourserviceprovider.com:5060;branch=3Dz9hG4bK2147483647 > Via: SIP/2.0/UDP > registrar.yourserviceprovider.com:5060;branch=3Dz9hG4bK2134765492 > Event: reg > Subscription-State: active;expires=3D3600 > Content-Length: 649 > Message body > > state=3D"full"> > id=3D"a100" state=3D"active"> > duration-registered=3D"0"> > sip:gordon@pc345.worcester.bell-telephone.com:12363 > Gordon Maverick > > duration-registered=3D"1204" call-id=3D"Vqpwoidf034i0_jv0wj090vasdfj"> > sip:gordon.maverick@192.222.67.129:14568 > Gordon Maverick > > > >=20 > Do you believe we should impose some limitations about how > the reg-event notifications can look like if sent for UAs > using Outbound with UDP ? Or introduce some exceptional > practices to send partial notification right after SUBSCRIBE > asking the client to register with TCP if the full notification > would be bigger than MTU ? Sorry to say but to me this mechanism > appears as broken. >=20 > Regards, >=20 > Erkki >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 09:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqI8-0004Rl-3e; Thu, 15 Mar 2007 09:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqI7-0004RY-6i for sip@ietf.org; Thu, 15 Mar 2007 09:46:51 -0400 Received: from web31513.mail.mud.yahoo.com ([68.142.198.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRqI5-0002EV-JQ for sip@ietf.org; Thu, 15 Mar 2007 09:46:51 -0400 Received: (qmail 16566 invoked by uid 60001); 15 Mar 2007 13:46:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=N62k2WRvWpSy2mA8NARQyPuf3aGGdTcnUbEMSQGjdPEoNlrgNpFMgS3rAMKe1tPa1LS5tkk0PPNYkf9Ms8nf235y5279VVH82RAl1dKgmw0g47dkym3IOOWNrES0Zl4AmLVfaocwd7Gxebum1vU3IDtEhnvQB4tvWbgZrvI6XiY=; X-YMail-OSG: MBhDxwAVM1lrBVym2qgF6M_dOkIRTmZb3qVJDvBASE8dl7L6lbop81RmikHLI51wV6iugM7C1rlIYqLxzbHmrs1obI4B5bi7B6UrTmN3Q.4epH46y03uGCIyhFbQxblOqQ6kFMzJ.C4- Received: from [198.152.12.67] by web31513.mail.mud.yahoo.com via HTTP; Thu, 15 Mar 2007 13:46:46 GMT Date: Thu, 15 Mar 2007 13:46:46 +0000 (GMT) From: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) To: Paul Kyzivat In-Reply-To: <45F7FCEA.4030201@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <421934.16161.qm@web31513.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul Yes, I am refering to similar cases - the offer2 in subsequent 100Rel/ 200OK after the first o/a exchange. You are indicating that RFC3261 still holds good and UAC should reject the 2nd100Rel/ 200OK. Note, that offer2 is invalid (protocol violation) and UAC may have to cancel(reject) the transaction(dialog) in this case since there is no clear way of indicating protocol violation rejection in PRACK/ ACK. However, going by Takuya's proposal in the draft -the UAC would assume the o/a completed based upon offer1/answer1 and ignore the SDP in 2nd100Rel/ 200OK(irrespective of if it is answer1 or offer2). The onus now is on the UAS(violating UAS) to interpret no answer2 in PRACK/ ACK. Ignoring is perfect for SDP-answer1 in the 2nd100Rel/ 200OK. In case of SDP-offer2 it seems your suggestion is correct, unless Takuya has some clarification. thanks, Kapil --- Paul Kyzivat wrote: > > > Kapil Nayar wrote: > > Hi Takuya > > > > Thanks for the reply. > > I would agree with you - since RFC 3261 does not > > clearly restrict the "SDP" (but only offer) in 1xx > and > > 200OK AFTER the completion of the first o/a > exchange. > > What do you think should be the behavior of the > UAC if > > the UAS sends an SDP-offer (a new session ID - new > > media) in 100Rel/ 200OK in the above case? > > I don't understand exactly what case you are > describing. > > Do you mean: > > UAC UAS > | INVITE w/Offer1 | > |----------------->| > | 1xxRel w/Answer1 | > |<-----------------| > | PRACK | > |----------------->| > | 1xxRel w/Offer2 | > |<-----------------| > | ?????? | > |----------------->| > > If so, I can see little to do other than send some > error response to the > PRACK. I think ignoring in that case would be a > mistake. Its not nice to > reject a PRACK, but it seems the only option. > > Paul > > > Would > > ignoring suffice or you would like to recommend > UAC to > > cancel the call since UAS violated RFC 3261. > > > > Also, you might want to take note of the > corrections > > indicated inline KN>>. > > > > Thanks, > > Kapil > > > > --- Takuya Sawada wrote: > > > >> Hi, > >> > >> I just catched up the discussion... > >> > >> Comments inline with [TS]. > >> > >>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE > BELOW > >> AND COMMENT *** > >>> (References are to figures in > >> draft-ietf-sipping-sip-offeranswer-00.) > >>> Comments inline. > >>> > >>> Paul > >>> > >>> Kapil Nayar wrote: > >>>> Thanks Paul for the clarifications. > >>>> Replies inline. > >>>>> If you were to allow a second o/a exchange via > >>>>> reliable 1xx, then it would have the potential > >> for a race with a > >>>>> concurrent UPDATE in the other direction. And > >> that would result in a > >>>>> need to > >>>>> send an error response. But PRACK isn't > prepared > >> for carrying an > >>>>> error response. Forcing subsequent o/a to use > >> UPDATE avoids this. > >>>> KN>> Perfect. So UPDATE (with SDP) support is > >> sort of > >>>> mandatory for implementations which want to > >> enable > >>>> changing early-media. > >>> Yeah. It would be quite unwise to support 100rel > >> and not UPDATE. > >>>>>> 2. Just to clarify, in Figure1 "After F6 UAC > >> and > >>>>> UAS > >>>>>> can send a new offer in an UPDATE request", I > >>>>> guess > >>>>>> the authors meant F7. > >>>>> Debatable. I think the UAS can send an UPDATE > >> after > >>>>> sending F6, without waiting to receive F7. > (With > >> the understanding that > >>>>> the UPDATE could fail if received before F6.) > >>>>> > >>>>> The UAC should probably wait until it sends > F7. > >>>> KN>> I would agree with mandating UAC to wait > >> until it > >>>> sends F7. > >>> I don't feel too strongly about this. I think it > >> would probably be wise to > >>> wait until after F7, but if somebody wants to > jump > >> the gun and is prepared > >>> for the potential error if F7 was lost then I > >> guess that is their > >>> business. > >>> > >> [TS] > >> I did not care so much on F6 or F7. > >> Now I agree with that waiting unil F7 is better > and > >> safe. > >> Probably we can modify the figure in a later > >> version. > >> > >>>>>> 3. In the description for Figure1 it is > >> indicated > >>>>> that > >>>>>> F12 (final response) should not contain an > SDP, > >>>>> and if > >>>>>> it does and is different than F6, the UAC > >> should > >>>>>> discard it. (Similar description is present > in > >>>>>> Figure2.) > >>>>>> > >>>>>> a).Does this mean that a UAS cannot change > the > >>>>> early > >>>>>> media to a final media in final response? > >>>>> It means that each offer has been answered, > and > >> that > >>>>> once an answer has been sent, it can't be > >> changed without another > >>>>> offer/answer cycle. And that another > >> offer/answer cycle may not be > >>>>> initiated > >>>>> in the 2xx if one has already been completed. > >>>>> > >>>>> This last is part of a principle that was > >> discovered > >>>>> during the evolution of this work: At most one > >> offer and one > >>>>> answer per transaction. > >>>>> > >>>>> At the time of F12, if the UAS wants to change > >> the > >>>>> SDP, it can send an UPDATE before sending the > >> 2xx for the INVITE. Or it > >>>>> can send the 2xx and send an UPDATE or > reINVITE > >> after the ACK. > >>>>>> b).If F12 carries SDP, it should be > designated > >> as > >>>>> a > >>>>>> new offer-SDP, right? If UAC discards the > >>>>> offer-SDP in > >>>>>> F12, is it still obligated to send an > >> answer-SDP > >>>>> in > >>>>>> ACK? > >>>>> No. This is all as specified in 3261. Having > >> sent an > >>>>> unreliable provisional with an answer in F2, > if > >> there is any > >>>>> SDP in the 2xx it must be identical to what > was > >> sent in F2. It is *not* > >>>>> another offer, and so it there must not be an > >> answer to it in F13. > >>>>>> c).If UAC accepts the offer-SDP in F12, can > the > >>>>>> answer-SDP in ACK be different than the one > >>>>> originally > >>>>>> offered in F1? What is the behavior expected > at > >>>>> the > >>>>>> UAS upon receiving this different media? > >>>>> See above. > >>>> KN>> Actually, there is some confusion here. In > >>>> Figure1 and Figure2 call flows there is a > >> successful > >>>> completion of the o/a through reliable 1xx. As > >> per RFC > >>>> 3261..."Once the UAS has sent or received an > >> answer to > >>>> the initial offer, it MUST NOT generate > >> subsequent > >>>> offers in any responses to the initial INVITE." > >> However, if you read the > >>>> description in line with the > >>>> figures it seems we have relaxed the MUST NOT > to > >>>> SHOULD NOT. > >>>> Figure1 - UAS should not include an SDP in the > >>>> responses F9 and F12. Figure2 - UAS should not > >> include > >>>> an SDP in the responses F6 and F9. > >>> It has been a long time, and I no longer > remember > >> the rationale that led > >>> to the SHOULD here. Note that in these figures > the > >> SDP in the 2xx is not > >>> to be considered an offer. It is just a piece of > >> redundant data. > >>> Personally I would be happy to say that the UAS > >> MUST NOT include SDP in > >>> the 2xx in these examples. But I would also like > >> to say (this is a best > >>> practice) that the UAC SHOULD/MUST ignore any > SDP > >> that arrives in the 2xx > >>> in these cases. This happens a lot in the wild, > so > >> one ought not break in > >>> these cases. > >>> > >>> But I would like to hear from Takuya (who is the > >> primary author) and > >>> others on this. > >>> > >> [TS] > >> RFC 3261 says "UAS MUST NOT generate offer", not > >> "UAS MUST NOT include > >> SDP". I guess some may interpret this as follows; > >> > >> UAS can include the same SDP both 1xx and 2xx. > >> It does not care whether 1xx is reliable or > not. > >> If 1xx is reliable, SDP in 1xx is the answer > and > >> if not, SDP in 2xx is the > >> answer. > >> Some SDPs may be neither an offer nor an > answer, > >> just a hint or nothing. > >> > >> I would be also happy to say "UAS MUST NOT" but I > >> could not conclude to > >> say that. Clearly some implementation would > violate > >> "MUST NOT" rule. > >> That is why I put the following description in > the > >> draft. > >> > >> UAS should not include an SDP in the > >> responses F9 and F12. However, > >> UAC should prepare to receive an SDP in F9 > >> and/or F12, and just > >> ignore them for the case that the peer > does > >> not conform to the > >> recommended implementation. > > KN>> > > This is a bit confusing on the first read. > Actually, > > it seems you are trying to refer to the generic > cases > > in table1 in the description for Figure1(2)- with > > reference to the Figures 1(2), SDP in F9(F6) and > > F12(F9) will always be ignored. Isn't it? The case > > w.r.t. the Figure is always non-conformant. > > > > Further, the conformant case is when the o/a > exchange > > has not already taken place in the transaction. > > > > You may want to disassociate (correct) these text > > description. > > > > > >> Regards, > >> Takuya > >> > >> > >>>> And, it sort of opens the discussion to > possible > >>>> scenarios where another o/a can be initiated. > Is > >> this > >>>> intentional? > >>> Definitely not. > >>> > >>> 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 > >> > >> > > > > > > > > > > > > > ___________________________________________________________ > > > The all-new Yahoo! Mail goes wherever you go - > free your email address from your Internet provider. > http://uk.docs.yahoo.com/nowyoucan.html > > > ___________________________________________________________ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 10:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqgc-00072F-MP; Thu, 15 Mar 2007 10:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqgb-000729-C7 for sip@ietf.org; Thu, 15 Mar 2007 10:12:09 -0400 Received: from bay0-omc3-s31.bay0.hotmail.com ([65.54.246.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqgZ-0005sI-Lq for sip@ietf.org; Thu, 15 Mar 2007 10:12:09 -0400 Received: from hotmail.com ([65.55.133.93]) by bay0-omc3-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 15 Mar 2007 07:12:07 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Mar 2007 07:12:07 -0700 Message-ID: Received: from 65.55.133.123 by by128fd.bay128.hotmail.msn.com with HTTP; Thu, 15 Mar 2007 14:12:04 GMT X-Originating-IP: [65.93.173.80] X-Originating-Email: [asburr@hotmail.com] X-Sender: asburr@hotmail.com From: "Andrew Burr" To: sip@ietf.org Bcc: Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Thu, 15 Mar 2007 14:12:04 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Mar 2007 14:12:07.0022 (UTC) FILETIME=[E9EC30E0:01C7670B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The original SIP would have sufficed to say that SIP runs on a reliable transport. Another specification titled "SIP UDP adaptation layer" could have specified retransmission and backing off retransmit timers and fragmentation. SIP message size may be bloated by tunneling session related information thru SIP using the attachment mechanism. Controlling SIP header size with an arbitrary limit is perhaps an ideal way to control header fields and prevent bloating of the SIP core which should never exceed 65K; but it's unfeasible to limit the size of what is tunneled in attachments. "SIP UDP adaptation layer" needs to handle the UDP limitations with a fragmentation and reassembly mechanism. Perhaps it is short sighted to tie-up SIP with a specific transport/security/media protocol, if SIP has to head off a ledge then why not disentangle it from transport/security/media issues and reduce SIP to the responsibilities of session offering whatever that session may be and make SIP generic enough to work for both SIP and TCP transports. Andrew ----Original Message Follows---- From: Spencer Dawkins To: sip@ietf.org Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Thu, 15 Mar 2007 07:04:01 -0500 If I understand correctly, Erkki is saying that we're driving off a cliff, and Jonathan is saying that we haven't given anyone outside the IETF an indication that we're going to change direction, so suddenly deprecating UDP isn't realistic. I do see what both Jonathan and Erkki are saying, and I think both have valid points. Perhaps it would be worth putting together a short I-D, either as Informational or (probably better) as BCP, to say: - we know 3261 requires TCP support, - we know many SIP devices were deployed without it and work today, - we know that we are in the process of developing new standards-track specifications that will significantly increase the size of SIP messages, - we know that IP-level fragmentation will increase, and is likely to be a problem, - so if you have already deployed UDP-only SIP, this would be a good time to start planning for TCP support". I can name some specifications that qualify here (Erkki mentioned ICE, and GRUU was discussed earlier this week), but is there a complete list that could be included, just off the top of anyone's head? This is probably less than two pages of non-boilerplate text, even including the list. Could it help the current situation? Spencer ----- Original Message ----- From: To: Cc: ; ; Sent: Thursday, March 15, 2007 5:44 AM Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Hi, >Listen, if folks are running a real SIP network and they are using >outbound, and they elect to use UDP knowing that this problem can >happen, then the consequence is that things won't work for large >messages. Thats the consequence of making this choice, and we are >providing them a way to know that it has actually happened. > >I expect in reality, providers will know exactly how big each >message will be since their clients are controlled by them and >they have tested them with exactly the messages they will emit. >So, this error code is really likely to show up in pre-deployment >testing, at which point you either switch to tcp, or live with the >risk. You are making quite strict assumptions in what you are saying. In practice this model would have the following limitations: - As ICE is likely to increase the size of the SDP body of INVITE by 200-400 bytes, when applying the full set of NAT traversal method the probability grows that the size of the INVITE request ultimately hits the MTU limit. - UDP would only apply to closed environments (walled gardens) where the service provider is able to certify all the connected clients and control the number of proxies in any possible route within the network (to limit the number of Via and Record-Route headers). Furthermore there can not be any direct SIP connectivity to rest of world. I admit that this may apply to how SIP is used e.g. in enterprises with their IT departments testing and validating all pieces of equipment or VoIP operators exclusively providing the UAs for their customers and having their PSTN gateways towards the rest of the world. - It would preclude consumers connecting the service with their favourite new softphone just installed to their PC. - Only the services certified by the service provider could ever be applied. - Or in best case if the service provider is able to control the types of NATs applied within the network so that those would be able to cope with IP fragmentation, in this case UDP could be used even for messages larger than MTU. If the provider is happy with all these limitations, yes then Outbound with UDP could make sense for the deployment. I still have the feeling that there are two many 'if's preventing this scheme to be robust and reliable. Too many things might simply go wrong. >>>- folks whose tcp scale is a problem need to FIX it, >>>since there is this issue with UDP outbound. >> >>I agree. Said that, it seems to me once again that the idea to >>keep UDP within the Outbound draft _is_ a bad idea. > >I'm trying to be pragmatic. > >THe *reality* is that there IS still a lot of UDP out there. And IETF >producing specifications that ignore this is just ignoring reality. >It'll just mean that folks ignore sip-outbound. It is hard for me to understand that while all the UAs and proxies have to be modified in order to support Outbound, upgrading for TCP support would be as difficult as it appears to many. For the UA point of view, having a IP stack with TCP support integrated to SIP does not appear much more difficult than supporting STUN keepalives. For the proxy point of view I am hearing evidence from multiple independent research projects that scaling TCP would not be impossible to solve (at least for Linux servers). TCP could even help some of the scalability problems since it uses even more lighweight keepalive schemes as STUN and the frequency of keepalives is lower in TCP compared to UDP. >The best we can do is clearly document the ongoing and >increasing troubles of UDP, so that a provider or enterprise >can make an educated choice and make >the move to tcp based on the evidence we've provided. What I am worried about is that the message IETF makes in SIP Outbound draft (only one paragraph in the spec giving a hint that there may be a problem) is very vague. Yes it has been discussed in the list, but still providing extensive UDP machinery in Outbound (STUN keepalives etc.) would create a mixed message and delay the whole proxy industry to face the issue and start actions to fix the TCP scalability problem. Also it would call the vendors to provide more complex solutions as necessary. Here I mostly refer to STUN keepalives needed for UDP vs the CRLF/TCP keepalives only needed for TCP. This also can delay how soon Outbound really hits the market in large scale. About the dynamic fix with reg-event: >>>An alternative to dynamically repair it is to use the >>>reg-event package for the notification, since we already have that. >>>..... The home proxy/registrar would generate a >>>notification to the client telling it to re-register over tcp. >> >>The problem is that the size of the simplest reg-event notifications >>I have seen are close to 1000 bytes. The ultimate size will depend >>on a number of things but there is a risk for the NOTIFY to become >>bigger than MTU so that it can not be delivered over UDP. There is >>a potential chicken and egg problem in this proposal. > >Well, close to 1000 is still under the MTU by plenty, so it works fine. I agree that typical reg-event NOTIFYs are smaller than MTU, but there is not really any upper limit so there is a chance of fatal failure. As an example consider a case where a person called Gordon had registered his wireless PDA arrives to office and registers now also from his PC using Outbound and UDP: -> REGISTER <- 200 OK -> SUBSCRIBE <- 200 OK <- NOTIFY In this case the full reg-event notification could be over 1300 bytes e.g. like this one: Request-Line: NOTIFY sip:gordon@pc345.worcester.bell-telephone.com:12363 SIP/2.0 Call-ID: VZ8iKyeJoIc2TwYRTcSB5j_bBPdQ3x Contact: Content-Type: application/reginfo+xml CSeq: 1 NOTIFY From: "Gordon Maverick" ;tag=poqw089q23oijf0+as9e Max-Forwards: 69 To: "Gordon Maverick" ;tag=kh0h5eib81hc7r1i1sqt Via: SIP/2.0/UDP proxy.yourserviceprovider.com:5060;branch=z9hG4bK2147483647 Via: SIP/2.0/UDP registrar.yourserviceprovider.com:5060;branch=z9hG4bK2134765492 Event: reg Subscription-State: active;expires=3600 Content-Length: 649 Message body sip:gordon@pc345.worcester.bell-telephone.com:12363 Gordon Maverick sip:gordon.maverick@192.222.67.129:14568 Gordon Maverick Do you believe we should impose some limitations about how the reg-event notifications can look like if sent for UAs using Outbound with UDP ? Or introduce some exceptional practices to send partial notification right after SUBSCRIBE asking the client to register with TCP if the full notification would be bigger than MTU ? Sorry to say but to me this mechanism appears as broken. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Have Some Fun Out Of The Sun This March Break http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!142 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 10:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqqC-0001sw-B7; Thu, 15 Mar 2007 10:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqqB-0001sp-7I for sip@ietf.org; Thu, 15 Mar 2007 10:22:03 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqq9-0007Aa-Dl for sip@ietf.org; Thu, 15 Mar 2007 10:22:03 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070315142200b14006vqsae>; Thu, 15 Mar 2007 14:22:00 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2FEM0GJ010264 for ; Thu, 15 Mar 2007 09:22:00 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2FEM0qX010260; Thu, 15 Mar 2007 09:22:00 -0500 Date: Thu, 15 Mar 2007 09:22:00 -0500 Message-Id: <200703151422.l2FEM0qX010260@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <7374777208BDC7449D5620EF9423256702AC27AE@esealmw113.eemea.ericsson.se> (christer.holmberg@ericsson.com) Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <7374777208BDC7449D5620EF9423256702AC27AE@esealmw113.eemea.ericsson.se> X-Spam-Score: 1.4 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Christer Holmberg \(JO/LMF\)" What I am worried about is the assumption that the size of SIP messages will keep on growing, growing and growing, It seems a safe assumption. and nobody seems to care. What do you propose to do about it? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 10:37:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRr4a-00062x-8e; Thu, 15 Mar 2007 10:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRr4Y-00062k-HF for sip@ietf.org; Thu, 15 Mar 2007 10:36:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRr4X-0000ux-BT for sip@ietf.org; Thu, 15 Mar 2007 10:36:54 -0400 Received: by wr-out-0506.google.com with SMTP id 37so208169wra for ; Thu, 15 Mar 2007 07:36:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=kZRS2f+RSU2pkhN2niRXs8+PeLjN+KtjdpBD8HeFAH+qJS3PiSUXnd9W0Z1Vv1qYuin7rlLRRBaJYXUsQZ+dUkCCpjzzk1XHzEQ43YSzGh3wbDsh0quER2LG/KkqnrHJqIlo/VNDr/EiQc+PXT8qyQEbSiM6qwKkVEEWpI1Dt9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=el+RpNigxu/HMsQ3J9G6FqBJldF2sx1RLyyEZrQBq5XkbswW2nWhiwItwy5igHI1tHNkpep0tlMDNMrbkdou9p0NcTPgzylp7Rpq4ILiwzTF6BQU/eQOMQRrHKA3S0dfL2NaD2EbMhYMqLrsebi2mTktURzwg6oGu5wrLpQgXcQ= Received: by 10.115.54.1 with SMTP id g1mr255339wak.1173969399390; Thu, 15 Mar 2007 07:36:39 -0700 (PDT) Received: by 10.114.200.6 with HTTP; Thu, 15 Mar 2007 07:36:39 -0700 (PDT) Message-ID: <4ebec9460703150736l7365e2b1m143721490ba8bb54@mail.gmail.com> Date: Thu, 15 Mar 2007 09:36:39 -0500 From: "guiovanna sabogal" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] Hi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942366956==" Errors-To: sip-bounces@ietf.org --===============0942366956== Content-Type: multipart/alternative; boundary="----=_Part_75117_19547566.1173969399249" ------=_Part_75117_19547566.1173969399249 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi im newbie on SIP. I dont understand very well if SIP is already using for video tranmision, if its tru, what codec uses sip for video??? thanks- Guiovanna Sabogal ------=_Part_75117_19547566.1173969399249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi im newbie on SIP. I dont understand very well if SIP is already using for video tranmision, if its tru, what codec uses sip for video???

thanks-


Guiovanna Sabogal ------=_Part_75117_19547566.1173969399249-- --===============0942366956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0942366956==-- From sip-bounces@ietf.org Thu Mar 15 11:22:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrjS-00088B-St; Thu, 15 Mar 2007 11:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrjR-000884-IH for sip@ietf.org; Thu, 15 Mar 2007 11:19:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrjP-0007tL-St for sip@ietf.org; Thu, 15 Mar 2007 11:19:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2007 11:19:09 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2FFJ7ab001034; Thu, 15 Mar 2007 11:19:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2FFIvlm000575; Thu, 15 Mar 2007 15:19:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:18:59 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:18:58 -0400 Message-ID: <45F963E2.7060601@cisco.com> Date: Thu, 15 Mar 2007 11:18:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <421934.16161.qm@web31513.mail.mud.yahoo.com> In-Reply-To: <421934.16161.qm@web31513.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 15:18:58.0908 (UTC) FILETIME=[413169C0:01C76715] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11402; t=1173971947; x=1174835947; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20Kapil=20Nayar=20; bh=fqI1+ayg9RYEGHkYDXPcG/tBsj9cy6BjwjDyjpYUSzg=; b=ghCPHowGCztwWDY4njRvmkUaQq5FyhSbTGzTyjsGbqa6X+4x9/1G88ZmrQfoqr4Z1B2pjB8p Xb+4YkaUX3e8zHzwuzULYQIqe+sAKthULMQka+Ad2XqgHyV+KbczCmMW; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We are quibbling over how the UAC should respond to a UAS that is in violation of the specs. We don't normally specify this normatively - it is up to implementors to cope as best they can. Perhaps the same can be said for SDP in the 200 when a reliable provisional has already completed the o/a. The difference is that we know some implementations do this, and don't consider it to be an offer, so ignoring it will most likely work. In your example, its hard to imagine that the UAS doesn't think it is making a new offer, so ignoring it is much less likely to work. The only reason I can see for recommending this is to sneak in another optional way to do o/a. Paul Kapil Nayar wrote: > Hi Paul > > Yes, I am refering to similar cases - the offer2 in > subsequent 100Rel/ 200OK after the first o/a exchange. > > You are indicating that RFC3261 still holds good and > UAC should reject the 2nd100Rel/ 200OK. Note, that > offer2 is invalid (protocol violation) and UAC may > have to cancel(reject) the transaction(dialog) in this > case since there is no clear way of indicating > protocol violation rejection in PRACK/ ACK. > > However, going by Takuya's proposal in the draft -the > UAC would assume the o/a completed based upon > offer1/answer1 and ignore the SDP in 2nd100Rel/ > 200OK(irrespective of if it is answer1 or offer2). The > onus now is on the UAS(violating UAS) to interpret no > answer2 in PRACK/ ACK. > Ignoring is perfect for SDP-answer1 in the 2nd100Rel/ > 200OK. In case of SDP-offer2 it seems your suggestion > is correct, unless Takuya has some clarification. > > thanks, > Kapil > > --- Paul Kyzivat wrote: > >> >> Kapil Nayar wrote: >>> Hi Takuya >>> >>> Thanks for the reply. >>> I would agree with you - since RFC 3261 does not >>> clearly restrict the "SDP" (but only offer) in 1xx >> and >>> 200OK AFTER the completion of the first o/a >> exchange. >>> What do you think should be the behavior of the >> UAC if >>> the UAS sends an SDP-offer (a new session ID - new >>> media) in 100Rel/ 200OK in the above case? >> I don't understand exactly what case you are >> describing. >> >> Do you mean: >> >> UAC UAS >> | INVITE w/Offer1 | >> |----------------->| >> | 1xxRel w/Answer1 | >> |<-----------------| >> | PRACK | >> |----------------->| >> | 1xxRel w/Offer2 | >> |<-----------------| >> | ?????? | >> |----------------->| >> >> If so, I can see little to do other than send some >> error response to the >> PRACK. I think ignoring in that case would be a >> mistake. Its not nice to >> reject a PRACK, but it seems the only option. >> >> Paul >> >>> Would >>> ignoring suffice or you would like to recommend >> UAC to >>> cancel the call since UAS violated RFC 3261. >>> >>> Also, you might want to take note of the >> corrections >>> indicated inline KN>>. >>> >>> Thanks, >>> Kapil >>> >>> --- Takuya Sawada wrote: >>> >>>> Hi, >>>> >>>> I just catched up the discussion... >>>> >>>> Comments inline with [TS]. >>>> >>>>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE >> BELOW >>>> AND COMMENT *** >>>>> (References are to figures in >>>> draft-ietf-sipping-sip-offeranswer-00.) >>>>> Comments inline. >>>>> >>>>> Paul >>>>> >>>>> Kapil Nayar wrote: >>>>>> Thanks Paul for the clarifications. >>>>>> Replies inline. >>>>>>> If you were to allow a second o/a exchange via >>>>>>> reliable 1xx, then it would have the potential >>>> for a race with a >>>>>>> concurrent UPDATE in the other direction. And >>>> that would result in a >>>>>>> need to >>>>>>> send an error response. But PRACK isn't >> prepared >>>> for carrying an >>>>>>> error response. Forcing subsequent o/a to use >>>> UPDATE avoids this. >>>>>> KN>> Perfect. So UPDATE (with SDP) support is >>>> sort of >>>>>> mandatory for implementations which want to >>>> enable >>>>>> changing early-media. >>>>> Yeah. It would be quite unwise to support 100rel >>>> and not UPDATE. >>>>>>>> 2. Just to clarify, in Figure1 "After F6 UAC >>>> and >>>>>>> UAS >>>>>>>> can send a new offer in an UPDATE request", I >>>>>>> guess >>>>>>>> the authors meant F7. >>>>>>> Debatable. I think the UAS can send an UPDATE >>>> after >>>>>>> sending F6, without waiting to receive F7. >> (With >>>> the understanding that >>>>>>> the UPDATE could fail if received before F6.) >>>>>>> >>>>>>> The UAC should probably wait until it sends >> F7. >>>>>> KN>> I would agree with mandating UAC to wait >>>> until it >>>>>> sends F7. >>>>> I don't feel too strongly about this. I think it >>>> would probably be wise to >>>>> wait until after F7, but if somebody wants to >> jump >>>> the gun and is prepared >>>>> for the potential error if F7 was lost then I >>>> guess that is their >>>>> business. >>>>> >>>> [TS] >>>> I did not care so much on F6 or F7. >>>> Now I agree with that waiting unil F7 is better >> and >>>> safe. >>>> Probably we can modify the figure in a later >>>> version. >>>> >>>>>>>> 3. In the description for Figure1 it is >>>> indicated >>>>>>> that >>>>>>>> F12 (final response) should not contain an >> SDP, >>>>>>> and if >>>>>>>> it does and is different than F6, the UAC >>>> should >>>>>>>> discard it. (Similar description is present >> in >>>>>>>> Figure2.) >>>>>>>> >>>>>>>> a).Does this mean that a UAS cannot change >> the >>>>>>> early >>>>>>>> media to a final media in final response? >>>>>>> It means that each offer has been answered, >> and >>>> that >>>>>>> once an answer has been sent, it can't be >>>> changed without another >>>>>>> offer/answer cycle. And that another >>>> offer/answer cycle may not be >>>>>>> initiated >>>>>>> in the 2xx if one has already been completed. >>>>>>> >>>>>>> This last is part of a principle that was >>>> discovered >>>>>>> during the evolution of this work: At most one >>>> offer and one >>>>>>> answer per transaction. >>>>>>> >>>>>>> At the time of F12, if the UAS wants to change >>>> the >>>>>>> SDP, it can send an UPDATE before sending the >>>> 2xx for the INVITE. Or it >>>>>>> can send the 2xx and send an UPDATE or >> reINVITE >>>> after the ACK. >>>>>>>> b).If F12 carries SDP, it should be >> designated >>>> as >>>>>>> a >>>>>>>> new offer-SDP, right? If UAC discards the >>>>>>> offer-SDP in >>>>>>>> F12, is it still obligated to send an >>>> answer-SDP >>>>>>> in >>>>>>>> ACK? >>>>>>> No. This is all as specified in 3261. Having >>>> sent an >>>>>>> unreliable provisional with an answer in F2, >> if >>>> there is any >>>>>>> SDP in the 2xx it must be identical to what >> was >>>> sent in F2. It is *not* >>>>>>> another offer, and so it there must not be an >>>> answer to it in F13. >>>>>>>> c).If UAC accepts the offer-SDP in F12, can >> the >>>>>>>> answer-SDP in ACK be different than the one >>>>>>> originally >>>>>>>> offered in F1? What is the behavior expected >> at >>>>>>> the >>>>>>>> UAS upon receiving this different media? >>>>>>> See above. >>>>>> KN>> Actually, there is some confusion here. In >>>>>> Figure1 and Figure2 call flows there is a >>>> successful >>>>>> completion of the o/a through reliable 1xx. As >>>> per RFC >>>>>> 3261..."Once the UAS has sent or received an >>>> answer to >>>>>> the initial offer, it MUST NOT generate >>>> subsequent >>>>>> offers in any responses to the initial INVITE." >>>> However, if you read the >>>>>> description in line with the >>>>>> figures it seems we have relaxed the MUST NOT >> to >>>>>> SHOULD NOT. >>>>>> Figure1 - UAS should not include an SDP in the >>>>>> responses F9 and F12. Figure2 - UAS should not >>>> include >>>>>> an SDP in the responses F6 and F9. >>>>> It has been a long time, and I no longer >> remember >>>> the rationale that led >>>>> to the SHOULD here. Note that in these figures >> the >>>> SDP in the 2xx is not >>>>> to be considered an offer. It is just a piece of >>>> redundant data. >>>>> Personally I would be happy to say that the UAS >>>> MUST NOT include SDP in >>>>> the 2xx in these examples. But I would also like >>>> to say (this is a best >>>>> practice) that the UAC SHOULD/MUST ignore any >> SDP >>>> that arrives in the 2xx >>>>> in these cases. This happens a lot in the wild, >> so >>>> one ought not break in >>>>> these cases. >>>>> >>>>> But I would like to hear from Takuya (who is the >>>> primary author) and >>>>> others on this. >>>>> >>>> [TS] >>>> RFC 3261 says "UAS MUST NOT generate offer", not >>>> "UAS MUST NOT include >>>> SDP". I guess some may interpret this as follows; >>>> >>>> UAS can include the same SDP both 1xx and 2xx. >>>> It does not care whether 1xx is reliable or >> not. >>>> If 1xx is reliable, SDP in 1xx is the answer >> and >>>> if not, SDP in 2xx is the >>>> answer. >>>> Some SDPs may be neither an offer nor an >> answer, >>>> just a hint or nothing. >>>> >>>> I would be also happy to say "UAS MUST NOT" but I >>>> could not conclude to >>>> say that. Clearly some implementation would >> violate >>>> "MUST NOT" rule. >>>> That is why I put the following description in >> the >>>> draft. >>>> >>>> UAS should not include an SDP in the >>>> responses F9 and F12. However, >>>> UAC should prepare to receive an SDP in F9 >>>> and/or F12, and just >>>> ignore them for the case that the peer >> does >>>> not conform to the >>>> recommended implementation. >>> KN>> >>> This is a bit confusing on the first read. >> Actually, >>> it seems you are trying to refer to the generic >> cases >>> in table1 in the description for Figure1(2)- with >>> reference to the Figures 1(2), SDP in F9(F6) and >>> F12(F9) will always be ignored. Isn't it? The case >>> w.r.t. the Figure is always non-conformant. >>> >>> Further, the conformant case is when the o/a >> exchange >>> has not already taken place in the transaction. >>> >>> You may want to disassociate (correct) these text >>> description. >>> >>> >>>> Regards, >>>> Takuya >>>> >>>> >>>>>> And, it sort of opens the discussion to >> possible >>>>>> scenarios where another o/a can be initiated. >> Is >>>> this >>>>>> intentional? >>>>> Definitely not. >>>>> >>>>> 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 >>>> >>>> >>> >>> >>> >>> >>> > ___________________________________________________________ >>> The all-new Yahoo! Mail goes wherever you go - >> free your email address from your Internet provider. >> http://uk.docs.yahoo.com/nowyoucan.html > > > > > ___________________________________________________________ > What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. > http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 11:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrqz-000627-Sw; Thu, 15 Mar 2007 11:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrqy-00061u-6p for sip@ietf.org; Thu, 15 Mar 2007 11:26:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrqw-0000VI-U6 for sip@ietf.org; Thu, 15 Mar 2007 11:26:56 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2007 11:26:56 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FFQsns000496; Thu, 15 Mar 2007 11:26:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2FFQalY002960; Thu, 15 Mar 2007 15:26:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:26:50 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:26:50 -0400 Message-ID: <45F965BA.1020100@cisco.com> Date: Thu, 15 Mar 2007 11:26:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <7374777208BDC7449D5620EF9423256702AC27AE@esealmw113.eemea.ericsson.se> <200703151422.l2FEM0qX010260@dragon.ariadne.com> In-Reply-To: <200703151422.l2FEM0qX010260@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 15:26:50.0642 (UTC) FILETIME=[5A5E4F20:01C76716] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1114; t=1173972414; x=1174836414; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-02 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=heZ61L+mZWwHS0VIpt23POEdW4TVQmLxtopYkazGoR4=; b=A6C6q7ACSAl+te3VDWNdRaLae2eeC1fw0mDVaVQ1obUILQL1nCVi02VvYj1yJEOlG7va6I9C l9mp9XYZNZqKeTVU7l/QAO7oYfCiJrEqTut5+tWkX29oQo3DrJlUEEJq; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In case you hadn't noticed, the amount of memory and cpu required to run applications keeps growing and nobody seems to care. And the amount of network bandwidth needed to successfully browse on the web also keeps growing and nobody seems to care. The main reason nobody seems to care is probably that the amount of cpu, memory, and bandwidth available, and the unit price of it, also keeps growing. Paul Dale.Worley@comcast.net wrote: > From: "Christer Holmberg \(JO/LMF\)" > > What I am worried about is the assumption that the size of SIP > messages will keep on growing, growing and growing, > > It seems a safe assumption. > > and nobody seems to care. > > What do you propose to do about it? > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 12:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsTb-00084M-6T; Thu, 15 Mar 2007 12:06:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsTZ-00082I-QX for sip@ietf.org; Thu, 15 Mar 2007 12:06:49 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRsTY-0005L4-JD for sip@ietf.org; Thu, 15 Mar 2007 12:06:49 -0400 Received: (qmail 16720 invoked from network); 15 Mar 2007 16:06:36 -0000 Received: from host168.sub9.rev.sunrocket.com (HELO [172.16.9.168]) (gkulshreshtha@[172.16.9.168]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 15 Mar 2007 16:06:36 -0000 Message-ID: <45F96F08.4000609@sunrocket.com> Date: Thu, 15 Mar 2007 12:06:32 -0400 From: Gaurav Kulshreshtha User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Simple SIP UA source code References: <45DE80FB.3030507@gmail.com> <45DEABCE.5050301@opensipstack.org> In-Reply-To: <45DEABCE.5050301@opensipstack.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You might also want to check out sipp http://sipp.sourceforge.net Cheers Gaurav Joegen E. Baclor wrote: > http://www.opensipstack.org has a softphone implementation > > > Prithvi wrote: >> Hi all >> Can any one tell me the where i can get simple SIP UA through >> which can make simple voice call. >> >> INVITE ---> >> <----200 OK >> ACK -----> >> voice media >> >> BYE----> >> <-----200OK >> >> regards >> Prithvi >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 12:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsct-0000CS-Eg; Thu, 15 Mar 2007 12:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRscs-0000CD-Kj for sip@ietf.org; Thu, 15 Mar 2007 12:16:26 -0400 Received: from web31513.mail.mud.yahoo.com ([68.142.198.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRscq-0006gy-Cj for sip@ietf.org; Thu, 15 Mar 2007 12:16:26 -0400 Received: (qmail 77419 invoked by uid 60001); 15 Mar 2007 16:16:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ldV7ZdV2gsf5knE03NAyLZ/qoVWuB+4Cji8dJX0NKFWqnYzc34byyXwEUGzrEu+gwW0mCiD1FlIc3a0fPwJ8EBiwh0KneN/hIm7ZqolAOlzuk75GQl2LNOxkTer51pZ3B+fm6sVa4X6q39bXInawXbuRtBXAzvf9APAtDCXn3II=; X-YMail-OSG: N7ehBmUVM1kE18QB9N6IxaQd8oEwYqwc.DIvncTVPtwsCxJoQam.YzyuBr_1P5I2Nx.zf97mzvvx9MwAg3GoDm0IQTOEHM8ChvNeNnc.tNU5NDY7T422SkkvEEEXD2PV14h10ryly74- Received: from [198.152.12.67] by web31513.mail.mud.yahoo.com via HTTP; Thu, 15 Mar 2007 16:16:07 GMT Date: Thu, 15 Mar 2007 16:16:07 +0000 (GMT) From: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) To: Paul Kyzivat In-Reply-To: <45F963E2.7060601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <757872.76090.qm@web31513.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, the SDP that your refer to in the figures/ description in draft is (answer1) always and nothing else. Correct? --- Paul Kyzivat wrote: > We are quibbling over how the UAC should respond to > a UAS that is in > violation of the specs. We don't normally specify > this normatively - it > is up to implementors to cope as best they can. > > Perhaps the same can be said for SDP in the 200 when > a reliable > provisional has already completed the o/a. The > difference is that we > know some implementations do this, and don't > consider it to be an offer, > so ignoring it will most likely work. In your > example, its hard to > imagine that the UAS doesn't think it is making a > new offer, so ignoring > it is much less likely to work. The only reason I > can see for > recommending this is to sneak in another optional > way to do o/a. > > Paul > > Kapil Nayar wrote: > > Hi Paul > > > > Yes, I am refering to similar cases - the offer2 > in > > subsequent 100Rel/ 200OK after the first o/a > exchange. > > > > You are indicating that RFC3261 still holds good > and > > UAC should reject the 2nd100Rel/ 200OK. Note, that > > offer2 is invalid (protocol violation) and UAC may > > have to cancel(reject) the transaction(dialog) in > this > > case since there is no clear way of indicating > > protocol violation rejection in PRACK/ ACK. > > > > However, going by Takuya's proposal in the draft > -the > > UAC would assume the o/a completed based upon > > offer1/answer1 and ignore the SDP in 2nd100Rel/ > > 200OK(irrespective of if it is answer1 or offer2). > The > > onus now is on the UAS(violating UAS) to interpret > no > > answer2 in PRACK/ ACK. > > Ignoring is perfect for SDP-answer1 in the > 2nd100Rel/ > > 200OK. In case of SDP-offer2 it seems your > suggestion > > is correct, unless Takuya has some clarification. > > > > thanks, > > Kapil > > > > --- Paul Kyzivat wrote: > > > >> > >> Kapil Nayar wrote: > >>> Hi Takuya > >>> > >>> Thanks for the reply. > >>> I would agree with you - since RFC 3261 does not > >>> clearly restrict the "SDP" (but only offer) in > 1xx > >> and > >>> 200OK AFTER the completion of the first o/a > >> exchange. > >>> What do you think should be the behavior of the > >> UAC if > >>> the UAS sends an SDP-offer (a new session ID - > new > >>> media) in 100Rel/ 200OK in the above case? > >> I don't understand exactly what case you are > >> describing. > >> > >> Do you mean: > >> > >> UAC UAS > >> | INVITE w/Offer1 | > >> |----------------->| > >> | 1xxRel w/Answer1 | > >> |<-----------------| > >> | PRACK | > >> |----------------->| > >> | 1xxRel w/Offer2 | > >> |<-----------------| > >> | ?????? | > >> |----------------->| > >> > >> If so, I can see little to do other than send > some > >> error response to the > >> PRACK. I think ignoring in that case would be a > >> mistake. Its not nice to > >> reject a PRACK, but it seems the only option. > >> > >> Paul > >> > >>> Would > >>> ignoring suffice or you would like to recommend > >> UAC to > >>> cancel the call since UAS violated RFC 3261. > >>> > >>> Also, you might want to take note of the > >> corrections > >>> indicated inline KN>>. > >>> > >>> Thanks, > >>> Kapil > >>> > >>> --- Takuya Sawada wrote: > >>> > >>>> Hi, > >>>> > >>>> I just catched up the discussion... > >>>> > >>>> Comments inline with [TS]. > >>>> > >>>>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE > >> BELOW > >>>> AND COMMENT *** > >>>>> (References are to figures in > >>>> draft-ietf-sipping-sip-offeranswer-00.) > >>>>> Comments inline. > >>>>> > >>>>> Paul > >>>>> > >>>>> Kapil Nayar wrote: > >>>>>> Thanks Paul for the clarifications. > >>>>>> Replies inline. > >>>>>>> If you were to allow a second o/a exchange > via > >>>>>>> reliable 1xx, then it would have the > potential > >>>> for a race with a > >>>>>>> concurrent UPDATE in the other direction. > And > >>>> that would result in a > >>>>>>> need to > >>>>>>> send an error response. But PRACK isn't > >> prepared > >>>> for carrying an > >>>>>>> error response. Forcing subsequent o/a to > use > >>>> UPDATE avoids this. > >>>>>> KN>> Perfect. So UPDATE (with SDP) support is > >>>> sort of > >>>>>> mandatory for implementations which want to > >>>> enable > >>>>>> changing early-media. > >>>>> Yeah. It would be quite unwise to support > 100rel > >>>> and not UPDATE. > >>>>>>>> 2. Just to clarify, in Figure1 "After F6 > UAC > >>>> and > >>>>>>> UAS > >>>>>>>> can send a new offer in an UPDATE request", > I > >>>>>>> guess > >>>>>>>> the authors meant F7. > >>>>>>> Debatable. I think the UAS can send an > UPDATE > >>>> after > >>>>>>> sending F6, without waiting to receive F7. > >> (With > >>>> the understanding that > >>>>>>> the UPDATE could fail if received before > F6.) > >>>>>>> > >>>>>>> The UAC should probably wait until it sends > >> F7. > >>>>>> KN>> I would agree with mandating UAC to wait > >>>> until it > >>>>>> sends F7. > >>>>> I don't feel too strongly about this. I think > it > >>>> would probably be wise to > >>>>> wait until after F7, but if somebody wants to > >> jump > >>>> the gun and is prepared > >>>>> for the potential error if F7 was lost then I > >>>> guess that is their > >>>>> business. > >>>>> > >>>> [TS] > >>>> I did not care so much on F6 or F7. > >>>> Now I agree with that waiting unil F7 is better > >> and > >>>> safe. > >>>> Probably we can modify the figure in a later > >>>> version. > >>>> > >>>>>>>> 3. In the description for Figure1 it is > >>>> indicated > >>>>>>> that > >>>>>>>> F12 (final response) should not contain an > >> SDP, > >>>>>>> and if > >>>>>>>> it does and is different than F6, the UAC > >>>> should > >>>>>>>> discard it. (Similar description is present > >> in > >>>>>>>> Figure2.) > >>>>>>>> > >>>>>>>> a).Does this mean that a UAS cannot change > >> the > >>>>>>> early > >>>>>>>> media to a final media in final response? > >>>>>>> It means that each offer has been answered, > >> and > >>>> that > >>>>>>> once an answer has been sent, it can't be > >>>> changed without another > >>>>>>> offer/answer cycle. And that another > >>>> offer/answer cycle may not be > >>>>>>> initiated > >>>>>>> in the 2xx if one has already been > completed. > >>>>>>> > >>>>>>> This last is part of a principle that was > >>>> discovered > >>>>>>> during the evolution of this work: At most > one > >>>> offer and one > >>>>>>> answer per transaction. > >>>>>>> > >>>>>>> At the time of F12, if the UAS wants to > change > >>>> the > >>>>>>> SDP, it can send an UPDATE before sending > the > >>>> 2xx for the INVITE. Or it > >>>>>>> can send the 2xx and send an UPDATE or > >> reINVITE > >>>> after the ACK. > >>>>>>>> b).If F12 carries SDP, it should be > >> designated > >>>> as > >>>>>>> a > >>>>>>>> new offer-SDP, right? If UAC discards the > >>>>>>> offer-SDP in > >>>>>>>> F12, is it still obligated to send an > >>>> answer-SDP > >>>>>>> in > >>>>>>>> ACK? > >>>>>>> No. This is all as specified in 3261. Having > >>>> sent an > >>>>>>> unreliable provisional with an answer in F2, > >> if > >>>> there is any > >>>>>>> SDP in the 2xx it must be identical to what > >> was > >>>> sent in F2. It is *not* > >>>>>>> another offer, and so it there must not be > an > >>>> answer to it in F13. > >>>>>>>> c).If UAC accepts the offer-SDP in F12, can > >> the > >>>>>>>> answer-SDP in ACK be different than the one > >>>>>>> originally > >>>>>>>> offered in F1? What is the behavior > expected > >> at > >>>>>>> the > >>>>>>>> UAS upon receiving this different media? > >>>>>>> See above. > >>>>>> KN>> Actually, there is some confusion here. > In > >>>>>> Figure1 and Figure2 call flows there is a > >>>> successful > >>>>>> completion of the o/a through reliable 1xx. > As > >>>> per RFC > >>>>>> 3261..."Once the UAS has sent or received an > >>>> answer to > >>>>>> the initial offer, it MUST NOT generate > >>>> subsequent > >>>>>> offers in any responses to the initial > INVITE." > >>>> However, if you read the > >>>>>> description in line with the > >>>>>> figures it seems we have relaxed the MUST NOT > >> to > >>>>>> SHOULD NOT. > >>>>>> Figure1 - UAS should not include an SDP in > the > >>>>>> responses F9 and F12. Figure2 - UAS should > not > >>>> include > >>>>>> an SDP in the responses F6 and F9. > >>>>> It has been a long time, and I no longer > >> remember > >>>> the rationale that led > >>>>> to the SHOULD here. Note that in these figures > >> the > >>>> SDP in the 2xx is not > >>>>> to be considered an offer. It is just a piece > of > >>>> redundant data. > >>>>> Personally I would be happy to say that the > UAS > >>>> MUST NOT include SDP in > >>>>> the 2xx in these examples. But I would also > like > >>>> to say (this is a best > >>>>> practice) that the UAC SHOULD/MUST ignore any > >> SDP > >>>> that arrives in the 2xx > >>>>> in these cases. This happens a lot in the > wild, > >> so > >>>> one ought not break in > >>>>> these cases. > >>>>> > >>>>> But I would like to hear from Takuya (who is > the > >>>> primary author) and > >>>>> others on this. > >>>>> > >>>> [TS] > >>>> RFC 3261 says "UAS MUST NOT generate offer", > not > >>>> "UAS MUST NOT include > >>>> SDP". I guess some may interpret this as > follows; > >>>> > >>>> UAS can include the same SDP both 1xx and > 2xx. > >>>> It does not care whether 1xx is reliable or > >> not. > >>>> If 1xx is reliable, SDP in 1xx is the answer > >> and > >>>> if not, SDP in 2xx is the > >>>> answer. > >>>> Some SDPs may be neither an offer nor an > >> answer, > >>>> just a hint or nothing. > >>>> > >>>> I would be also happy to say "UAS MUST NOT" but > I > >>>> could not conclude to > >>>> say that. Clearly some implementation would > >> violate > >>>> "MUST NOT" rule. > >>>> That is why I put the following description in > >> the > >>>> draft. > >>>> > >>>> UAS should not include an SDP in the > >>>> responses F9 and F12. However, > >>>> UAC should prepare to receive an SDP in > F9 > >>>> and/or F12, and just > >>>> ignore them for the case that the peer > >> does > >>>> not conform to the > >>>> recommended implementation. > >>> KN>> > >>> This is a bit confusing on the first read. > >> Actually, > >>> it seems you are trying to refer to the generic > >> cases > >>> in table1 in the description for Figure1(2)- > with > >>> reference to the Figures 1(2), SDP in F9(F6) and > >>> F12(F9) will always be ignored. Isn't it? The > case > >>> w.r.t. the Figure is always non-conformant. > >>> > >>> Further, the conformant case is when the o/a > >> exchange > >>> has not already taken place in the transaction. > >>> > >>> You may want to disassociate (correct) these > text > >>> description. > >>> > >>> > >>>> Regards, > >>>> Takuya > >>>> > >>>> > >>>>>> And, it sort of opens the discussion to > >> possible > >>>>>> scenarios where another o/a can be initiated. > >> Is > >>>> this > >>>>>> intentional? > >>>>> Definitely not. > >>>>> > >>>>> 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 > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > > > ___________________________________________________________ > >>> The all-new Yahoo! Mail goes wherever you go - > >> free your email address from your Internet > provider. > >> http://uk.docs.yahoo.com/nowyoucan.html > > > > > > > > > > > ___________________________________________________________ > > > What kind of emailer are you? Find out today - get > a free analysis of your email personality. Take the > quiz at the Yahoo! Mail Championship. > > > http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk > > > > ___________________________________________________________ Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 12:18:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsel-0000vn-Gr; Thu, 15 Mar 2007 12:18:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsek-0000vh-V8 for sip@ietf.org; Thu, 15 Mar 2007 12:18:22 -0400 Received: from web31502.mail.mud.yahoo.com ([68.142.198.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRsek-0006wj-9T for sip@ietf.org; Thu, 15 Mar 2007 12:18:22 -0400 Received: (qmail 84359 invoked by uid 60001); 15 Mar 2007 16:18:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=On2F4fvn2Ei7HgIceZhF4CsXc+QIXWjdu+DTpp2BmcMUNh0DmTnQyiURyS/TSo6yeO702mrvi+VAbw/QUTueAgCUJjVF6V5yZH/3jH6WYRrqAi5/xb/KqDUuq2FN/yQ7ihfoQKrk2dIZskxWLyG4xeMWU48AusEjOILj0o/7oEU=; X-YMail-OSG: ZV_R1AoVM1miZ7IOvnplq3ir7mG8bMIcSh0pvC5iw0Bxi1xZ4HumDUKYL00jIcv8xXsGRAlJO.F3P.X4LqasFF1nAnkWpWEpPnEacA8545Sr0QCerBu0NzGIBcUsOpph9gVn_hFt_hI- Received: from [198.152.12.67] by web31502.mail.mud.yahoo.com via HTTP; Thu, 15 Mar 2007 16:18:21 GMT Date: Thu, 15 Mar 2007 16:18:21 +0000 (GMT) From: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) To: Paul Kyzivat In-Reply-To: <45F963E2.7060601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <603393.83028.qm@web31502.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, the SDP that your refer to in the figures1(2)/ description for F9,F12(F6,F9) in draft is (answer1) always and nothing else. Correct? --- Paul Kyzivat wrote: > We are quibbling over how the UAC should respond to > a UAS that is in > violation of the specs. We don't normally specify > this normatively - it > is up to implementors to cope as best they can. > > Perhaps the same can be said for SDP in the 200 when > a reliable > provisional has already completed the o/a. The > difference is that we > know some implementations do this, and don't > consider it to be an offer, > so ignoring it will most likely work. In your > example, its hard to > imagine that the UAS doesn't think it is making a > new offer, so ignoring > it is much less likely to work. The only reason I > can see for > recommending this is to sneak in another optional > way to do o/a. > > Paul > > Kapil Nayar wrote: > > Hi Paul > > > > Yes, I am refering to similar cases - the offer2 > in > > subsequent 100Rel/ 200OK after the first o/a > exchange. > > > > You are indicating that RFC3261 still holds good > and > > UAC should reject the 2nd100Rel/ 200OK. Note, that > > offer2 is invalid (protocol violation) and UAC may > > have to cancel(reject) the transaction(dialog) in > this > > case since there is no clear way of indicating > > protocol violation rejection in PRACK/ ACK. > > > > However, going by Takuya's proposal in the draft > -the > > UAC would assume the o/a completed based upon > > offer1/answer1 and ignore the SDP in 2nd100Rel/ > > 200OK(irrespective of if it is answer1 or offer2). > The > > onus now is on the UAS(violating UAS) to interpret > no > > answer2 in PRACK/ ACK. > > Ignoring is perfect for SDP-answer1 in the > 2nd100Rel/ > > 200OK. In case of SDP-offer2 it seems your > suggestion > > is correct, unless Takuya has some clarification. > > > > thanks, > > Kapil > > > > --- Paul Kyzivat wrote: > > > >> > >> Kapil Nayar wrote: > >>> Hi Takuya > >>> > >>> Thanks for the reply. > >>> I would agree with you - since RFC 3261 does not > >>> clearly restrict the "SDP" (but only offer) in > 1xx > >> and > >>> 200OK AFTER the completion of the first o/a > >> exchange. > >>> What do you think should be the behavior of the > >> UAC if > >>> the UAS sends an SDP-offer (a new session ID - > new > >>> media) in 100Rel/ 200OK in the above case? > >> I don't understand exactly what case you are > >> describing. > >> > >> Do you mean: > >> > >> UAC UAS > >> | INVITE w/Offer1 | > >> |----------------->| > >> | 1xxRel w/Answer1 | > >> |<-----------------| > >> | PRACK | > >> |----------------->| > >> | 1xxRel w/Offer2 | > >> |<-----------------| > >> | ?????? | > >> |----------------->| > >> > >> If so, I can see little to do other than send > some > >> error response to the > >> PRACK. I think ignoring in that case would be a > >> mistake. Its not nice to > >> reject a PRACK, but it seems the only option. > >> > >> Paul > >> > >>> Would > >>> ignoring suffice or you would like to recommend > >> UAC to > >>> cancel the call since UAS violated RFC 3261. > >>> > >>> Also, you might want to take note of the > >> corrections > >>> indicated inline KN>>. > >>> > >>> Thanks, > >>> Kapil > >>> > >>> --- Takuya Sawada wrote: > >>> > >>>> Hi, > >>>> > >>>> I just catched up the discussion... > >>>> > >>>> Comments inline with [TS]. > >>>> > >>>>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE > >> BELOW > >>>> AND COMMENT *** > >>>>> (References are to figures in > >>>> draft-ietf-sipping-sip-offeranswer-00.) > >>>>> Comments inline. > >>>>> > >>>>> Paul > >>>>> > >>>>> Kapil Nayar wrote: > >>>>>> Thanks Paul for the clarifications. > >>>>>> Replies inline. > >>>>>>> If you were to allow a second o/a exchange > via > >>>>>>> reliable 1xx, then it would have the > potential > >>>> for a race with a > >>>>>>> concurrent UPDATE in the other direction. > And > >>>> that would result in a > >>>>>>> need to > >>>>>>> send an error response. But PRACK isn't > >> prepared > >>>> for carrying an > >>>>>>> error response. Forcing subsequent o/a to > use > >>>> UPDATE avoids this. > >>>>>> KN>> Perfect. So UPDATE (with SDP) support is > >>>> sort of > >>>>>> mandatory for implementations which want to > >>>> enable > >>>>>> changing early-media. > >>>>> Yeah. It would be quite unwise to support > 100rel > >>>> and not UPDATE. > >>>>>>>> 2. Just to clarify, in Figure1 "After F6 > UAC > >>>> and > >>>>>>> UAS > >>>>>>>> can send a new offer in an UPDATE request", > I > >>>>>>> guess > >>>>>>>> the authors meant F7. > >>>>>>> Debatable. I think the UAS can send an > UPDATE > >>>> after > >>>>>>> sending F6, without waiting to receive F7. > >> (With > >>>> the understanding that > >>>>>>> the UPDATE could fail if received before > F6.) > >>>>>>> > >>>>>>> The UAC should probably wait until it sends > >> F7. > >>>>>> KN>> I would agree with mandating UAC to wait > >>>> until it > >>>>>> sends F7. > >>>>> I don't feel too strongly about this. I think > it > >>>> would probably be wise to > >>>>> wait until after F7, but if somebody wants to > >> jump > >>>> the gun and is prepared > >>>>> for the potential error if F7 was lost then I > >>>> guess that is their > >>>>> business. > >>>>> > >>>> [TS] > >>>> I did not care so much on F6 or F7. > >>>> Now I agree with that waiting unil F7 is better > >> and > >>>> safe. > >>>> Probably we can modify the figure in a later > >>>> version. > >>>> > >>>>>>>> 3. In the description for Figure1 it is > >>>> indicated > >>>>>>> that > >>>>>>>> F12 (final response) should not contain an > >> SDP, > >>>>>>> and if > >>>>>>>> it does and is different than F6, the UAC > >>>> should > >>>>>>>> discard it. (Similar description is present > >> in > >>>>>>>> Figure2.) > >>>>>>>> > >>>>>>>> a).Does this mean that a UAS cannot change > >> the > >>>>>>> early > >>>>>>>> media to a final media in final response? > >>>>>>> It means that each offer has been answered, > >> and > >>>> that > >>>>>>> once an answer has been sent, it can't be > >>>> changed without another > >>>>>>> offer/answer cycle. And that another > >>>> offer/answer cycle may not be > >>>>>>> initiated > >>>>>>> in the 2xx if one has already been > completed. > >>>>>>> > >>>>>>> This last is part of a principle that was > >>>> discovered > >>>>>>> during the evolution of this work: At most > one > >>>> offer and one > >>>>>>> answer per transaction. > >>>>>>> > >>>>>>> At the time of F12, if the UAS wants to > change > >>>> the > >>>>>>> SDP, it can send an UPDATE before sending > the > >>>> 2xx for the INVITE. Or it > >>>>>>> can send the 2xx and send an UPDATE or > >> reINVITE > >>>> after the ACK. > >>>>>>>> b).If F12 carries SDP, it should be > >> designated > >>>> as > >>>>>>> a > >>>>>>>> new offer-SDP, right? If UAC discards the > >>>>>>> offer-SDP in > >>>>>>>> F12, is it still obligated to send an > >>>> answer-SDP > >>>>>>> in > >>>>>>>> ACK? > >>>>>>> No. This is all as specified in 3261. Having > >>>> sent an > >>>>>>> unreliable provisional with an answer in F2, > >> if > >>>> there is any > >>>>>>> SDP in the 2xx it must be identical to what > >> was > >>>> sent in F2. It is *not* > >>>>>>> another offer, and so it there must not be > an > >>>> answer to it in F13. > >>>>>>>> c).If UAC accepts the offer-SDP in F12, can > >> the > >>>>>>>> answer-SDP in ACK be different than the one > >>>>>>> originally > >>>>>>>> offered in F1? What is the behavior > expected > >> at > >>>>>>> the > >>>>>>>> UAS upon receiving this different media? > >>>>>>> See above. > >>>>>> KN>> Actually, there is some confusion here. > In > >>>>>> Figure1 and Figure2 call flows there is a > >>>> successful > >>>>>> completion of the o/a through reliable 1xx. > As > >>>> per RFC > >>>>>> 3261..."Once the UAS has sent or received an > >>>> answer to > >>>>>> the initial offer, it MUST NOT generate > >>>> subsequent > >>>>>> offers in any responses to the initial > INVITE." > >>>> However, if you read the > >>>>>> description in line with the > >>>>>> figures it seems we have relaxed the MUST NOT > >> to > >>>>>> SHOULD NOT. > >>>>>> Figure1 - UAS should not include an SDP in > the > >>>>>> responses F9 and F12. Figure2 - UAS should > not > >>>> include > >>>>>> an SDP in the responses F6 and F9. > >>>>> It has been a long time, and I no longer > >> remember > >>>> the rationale that led > >>>>> to the SHOULD here. Note that in these figures > >> the > >>>> SDP in the 2xx is not > >>>>> to be considered an offer. It is just a piece > of > >>>> redundant data. > >>>>> Personally I would be happy to say that the > UAS > >>>> MUST NOT include SDP in > >>>>> the 2xx in these examples. But I would also > like > >>>> to say (this is a best > >>>>> practice) that the UAC SHOULD/MUST ignore any > >> SDP > >>>> that arrives in the 2xx > >>>>> in these cases. This happens a lot in the > wild, > >> so > >>>> one ought not break in > >>>>> these cases. > >>>>> > >>>>> But I would like to hear from Takuya (who is > the > >>>> primary author) and > >>>>> others on this. > >>>>> > >>>> [TS] > >>>> RFC 3261 says "UAS MUST NOT generate offer", > not > >>>> "UAS MUST NOT include > >>>> SDP". I guess some may interpret this as > follows; > >>>> > >>>> UAS can include the same SDP both 1xx and > 2xx. > >>>> It does not care whether 1xx is reliable or > >> not. > >>>> If 1xx is reliable, SDP in 1xx is the answer > >> and > >>>> if not, SDP in 2xx is the > >>>> answer. > >>>> Some SDPs may be neither an offer nor an > >> answer, > >>>> just a hint or nothing. > >>>> > >>>> I would be also happy to say "UAS MUST NOT" but > I > >>>> could not conclude to > >>>> say that. Clearly some implementation would > >> violate > >>>> "MUST NOT" rule. > >>>> That is why I put the following description in > >> the > >>>> draft. > >>>> > >>>> UAS should not include an SDP in the > >>>> responses F9 and F12. However, > >>>> UAC should prepare to receive an SDP in > F9 > >>>> and/or F12, and just > >>>> ignore them for the case that the peer > >> does > >>>> not conform to the > >>>> recommended implementation. > >>> KN>> > >>> This is a bit confusing on the first read. > >> Actually, > >>> it seems you are trying to refer to the generic > >> cases > >>> in table1 in the description for Figure1(2)- > with > >>> reference to the Figures 1(2), SDP in F9(F6) and > >>> F12(F9) will always be ignored. Isn't it? The > case > >>> w.r.t. the Figure is always non-conformant. > >>> > >>> Further, the conformant case is when the o/a > >> exchange > >>> has not already taken place in the transaction. > >>> > >>> You may want to disassociate (correct) these > text > >>> description. > >>> > >>> > >>>> Regards, > >>>> Takuya > >>>> > >>>> > >>>>>> And, it sort of opens the discussion to > >> possible > >>>>>> scenarios where another o/a can be initiated. > >> Is > >>>> this > >>>>>> intentional? > >>>>> Definitely not. > >>>>> > >>>>> 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 > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > > > ___________________________________________________________ > >>> The all-new Yahoo! Mail goes wherever you go - > >> free your email address from your Internet > provider. > >> http://uk.docs.yahoo.com/nowyoucan.html > > > > > > > > > > > ___________________________________________________________ > > > What kind of emailer are you? Find out today - get > a free analysis of your email personality. Take the > quiz at the Yahoo! Mail Championship. > > > http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk > > > > ___________________________________________________________ All New Yahoo! Mail Tired of unwanted email come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 13:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtj6-0003Zs-Og; Thu, 15 Mar 2007 13:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtj6-0003Zk-27 for sip@ietf.org; Thu, 15 Mar 2007 13:26:56 -0400 Received: from smtp-1.hut.fi ([130.233.228.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRtj4-0008Je-Hf for sip@ietf.org; Thu, 15 Mar 2007 13:26:56 -0400 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l2FHPev7004727; Thu, 15 Mar 2007 19:25:40 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 22354-02-4; Thu, 15 Mar 2007 19:25:40 +0200 (EET) Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l2FHPYZ8004697; Thu, 15 Mar 2007 19:25:34 +0200 Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id 9D1B43A2CD7; Thu, 15 Mar 2007 19:25:34 +0200 (EET) Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28969-08; Thu, 15 Mar 2007 19:25:33 +0200 (EET) Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32]) by mail.tml.hut.fi (Postfix) with ESMTP id DC3BB3A2CCC; Thu, 15 Mar 2007 19:25:33 +0200 (EET) Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Thu, 15 Mar 2007 19:25:33 +0200 Message-ID: <20070315192533.23n2ti5qo8ss8oww@horde-intra.tml.hut.fi> Date: Thu, 15 Mar 2007 19:25:33 +0200 From: sergiole@tml.hut.fi To: sip@ietf.org References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> <5741BEAE-07B2-43AB-A89A-34D4617B916F@ekabal.com> <20070313142802.lzjkmze0go8owgw0@horde-intra.tml.hut.fi> <0F7C061D-871B-453D-847B-C3D0BB35FAC1@ekabal.com> In-Reply-To: <0F7C061D-871B-453D-847B-C3D0BB35FAC1@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >> 2) Where " the remote IP address and port." I understand that >> these are the destination for the REGISTER (e.g Registrar). >> True? > No, this is the address and port of the UA. In my opinion it could be easy to understand something like Original text { the remote IP address and port. } Suggestion { remote IP address and port of the user agent that is sending the REGISTER (or creating the flow) } Also it could be good if you mention that these (IP address and port ) are the "public" IP address and port (i.e. the IP address and port after a possible NAT). Sergio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 13:46:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRu0G-0002LW-51; Thu, 15 Mar 2007 13:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRu0E-0002LP-K4 for sip@ietf.org; Thu, 15 Mar 2007 13:44:38 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRu0D-0003jC-CK for sip@ietf.org; Thu, 15 Mar 2007 13:44:38 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070315174436m1300e3cske>; Thu, 15 Mar 2007 17:44:36 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2FHiZGJ025062 for ; Thu, 15 Mar 2007 12:44:35 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2FHiZGL025058; Thu, 15 Mar 2007 12:44:35 -0500 Date: Thu, 15 Mar 2007 12:44:35 -0500 Message-Id: <200703151744.l2FHiZGL025058@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45F965BA.1020100@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <7374777208BDC7449D5620EF9423256702AC27AE@esealmw113.eemea.ericsson.se> <200703151422.l2FEM0qX010260@dragon.ariadne.com> <45F965BA.1020100@cisco.com> X-Spam-Score: 1.4 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat The main reason nobody seems to care is probably that the amount of cpu, memory, and bandwidth available, and the [amount of it per dollar], also keeps growing. And perversely, despite that SIP is hardly designed to be efficient with each bit it sends over the wire, a SIP-based phone system is cheaper than a TDM-based phone system. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 13:46:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRu2N-0003Ks-8g; Thu, 15 Mar 2007 13:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRu2M-0003Kc-IH for sip@ietf.org; Thu, 15 Mar 2007 13:46:50 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRu2K-00044x-AP for sip@ietf.org; Thu, 15 Mar 2007 13:46:50 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20070315174647m1500el52fe>; Thu, 15 Mar 2007 17:46:47 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2FHkkGJ025219 for ; Thu, 15 Mar 2007 12:46:46 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2FHkk9L025215; Thu, 15 Mar 2007 12:46:46 -0500 Date: Thu, 15 Mar 2007 12:46:46 -0500 Message-Id: <200703151746.l2FHkk9L025215@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4ebec9460703150736l7365e2b1m143721490ba8bb54@mail.gmail.com> (guiovannasabogal@gmail.com) Subject: Re: [Sip] Hi References: <4ebec9460703150736l7365e2b1m143721490ba8bb54@mail.gmail.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "guiovanna sabogal" Hi im newbie on SIP. I dont understand very well if SIP is already using for video tranmision, if its tru, what codec uses sip for video??? If you ask this question at , they will probably have better information for you. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 14:55:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRv3z-0003rV-4k; Thu, 15 Mar 2007 14:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRv3y-0003qd-Bn for sip@ietf.org; Thu, 15 Mar 2007 14:52:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRv3w-0007Ps-Sd for sip@ietf.org; Thu, 15 Mar 2007 14:52:34 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4BB5C203AF; Thu, 15 Mar 2007 19:52:30 +0100 (CET) X-AuditID: c1b4fb3e-af1edbb0000061ca-54-45f995ee98ca Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 26C3F200E4; Thu, 15 Mar 2007 19:52:30 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 19:52:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Thu, 15 Mar 2007 19:52:28 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702AF7A28@esealmw113.eemea.ericsson.se> In-Reply-To: <45F965BA.1020100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Thread-Index: AcdnFpVBasw0mlkJT3adVu0n9DOGNwAGyibw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 15 Mar 2007 18:52:29.0645 (UTC) FILETIME=[14FCBFD0:01C76733] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >In case you hadn't noticed, the amount of memory and cpu required to run applications keeps growing and nobody seems=20 >to care.=20 Memory and cpu is probably not a problem for a SIP client running on a PC. But, there are other types of nodes where memory is not "freely available" in the same sense. Also, what is my grand mother supposed to do when she is trying to make an important phone call, and her SIP phone crashes, and all she sees on the "screen" is a core dump or a message saying "Out of memory"... >And the amount of network bandwidth needed to successfully browse on the web also keeps growing and nobody=20 >seems to care. Web browsing is not as real-time sensitive, and does not have the same setup restrictions, as phone calls. Also, I believe we are expected to design something which is more effective and efficient than the protocols used today. >The main reason nobody seems to care is probably that the amount of cpu, memory, and bandwidth available, and the unit=20 >price of it, also keeps growing. That is probably why we have sigcomp, why people are working on more and more efficient codecs etc etc... Regards, Christer > Dale.Worley@comcast.net wrote: > > From: "Christer Holmberg \(JO/LMF\)"=20 > > > >=20 > > What I am worried about is the assumption that the size of SIP > > messages will keep on growing, growing and growing, > >=20 > > It seems a safe assumption. > >=20 > > and nobody seems to care. > >=20 > > What do you propose to do about it? > >=20 > > Dale > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 15:17:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvR9-0005qI-98; Thu, 15 Mar 2007 15:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvR7-0005pf-Nf for sip@ietf.org; Thu, 15 Mar 2007 15:16:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRvQo-0003Ta-8r for sip@ietf.org; Thu, 15 Mar 2007 15:16:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B76F0216CC; Thu, 15 Mar 2007 20:16:07 +0100 (CET) X-AuditID: c1b4fb3e-af9eebb0000061ca-63-45f99b779ef1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3378213C9; Thu, 15 Mar 2007 20:16:07 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 20:16:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Thu, 15 Mar 2007 20:16:06 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702AF7A5C@esealmw113.eemea.ericsson.se> In-Reply-To: <200703151744.l2FHiZGL025058@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Thread-Index: AcdnKl4TiTFBqOn5SBCGLsrbIpo7lgACLsKQ From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 15 Mar 2007 19:16:07.0162 (UTC) FILETIME=[61E4ADA0:01C76736] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>The main reason nobody seems to care is probably that the amount of >>cpu, memory, and bandwidth available, and the [amount of it per >>dollar], also keeps growing. >=20 >And perversely, despite that SIP is hardly designed to be=20 >efficient with each bit it sends over the wire, a SIP-based=20 >phone system is cheaper than a TDM-based phone system. So, our aim is only to make something which is cheaper (SIP phones I've seen aren't that cheap, though...), it doesn't have to be better? :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 15:49:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvwg-0003UN-17; Thu, 15 Mar 2007 15:49:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvwe-0003St-KH for sip@ietf.org; Thu, 15 Mar 2007 15:49:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRvwb-0001QC-8r for sip@ietf.org; Thu, 15 Mar 2007 15:49:04 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2007 15:49:01 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FJn0CJ002279; Thu, 15 Mar 2007 15:49:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2FJn0lG018603; Thu, 15 Mar 2007 19:49:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 15:49:00 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 15:49:00 -0400 Message-ID: <45F9A32C.1050403@cisco.com> Date: Thu, 15 Mar 2007 15:49:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 References: <7374777208BDC7449D5620EF9423256702AF7A28@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256702AF7A28@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 19:49:00.0425 (UTC) FILETIME=[FA0CB790:01C7673A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2520; t=1173988141; x=1174852141; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-02 |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=cJy9hHvAyUAyswlhLHqpnT0IjDp5qYveVhDfUHdyELg=; b=GMVeUXPZYiF/iXoaXWeHdEFGkOU7K5AoeY7dp5Tiwcr5+84/4EyYV7sjEK4fajJpGfgMUl6b C5yVc+9BlUL5Vwnnx5HY30xXB7ZB4LrJ6cEZUU12BiWyh3LVT+r7pJwy; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Everything is relative. But I'm not seeing anyone screaming to make sip work over 300 baud modems on a .5mhz device with 700kb of memory. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > >> In case you hadn't noticed, the amount of memory and cpu required to > run applications keeps growing and nobody seems >> to care. > > Memory and cpu is probably not a problem for a SIP client running on a > PC. But, there are other types of nodes where memory is not "freely > available" in the same sense. > > Also, what is my grand mother supposed to do when she is trying to make > an important phone call, and her SIP phone crashes, and all she sees on > the "screen" is a core dump or a message saying "Out of memory"... > >> And the amount of network bandwidth needed to successfully browse on > the web also keeps growing and nobody >> seems to care. > > Web browsing is not as real-time sensitive, and does not have the same > setup restrictions, as phone calls. Also, I believe we are expected to > design something which is more effective and efficient than the > protocols used today. > >> The main reason nobody seems to care is probably that the amount of > cpu, memory, and bandwidth available, and the unit >> price of it, also keeps growing. > > That is probably why we have sigcomp, why people are working on more and > more efficient codecs etc etc... > > Regards, > > Christer > > > > >> Dale.Worley@comcast.net wrote: >>> From: "Christer Holmberg \(JO/LMF\)" >>> >>> >>> What I am worried about is the assumption that the size of SIP >>> messages will keep on growing, growing and growing, >>> >>> It seems a safe assumption. >>> >>> and nobody seems to care. >>> >>> What do you propose to do about it? >>> >>> Dale >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 16:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwAo-00055c-DB; Thu, 15 Mar 2007 16:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwAm-00052f-5s for sip@ietf.org; Thu, 15 Mar 2007 16:03:40 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRwAi-0004as-TT for sip@ietf.org; Thu, 15 Mar 2007 16:03:40 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id l2FK3Rx21113; Thu, 15 Mar 2007 14:03:27 -0600 Date: Thu, 15 Mar 2007 14:03:27 -0600 Message-Id: <200703152003.l2FK3Rx21113@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Paul Kyzivat" , "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 X-Spam-Score: 1.3 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, funny you should mention that... My day job is for a defense contractor that builds military radios. I've been lobbying to turn them from push-to-talk broadcast devices into VoIP terminals. These devices are based on 25 KHz channels and the very best you can do at a range of a quarter mile on a clear day with the planets aligned right is 80 Kbps; 9600 bps is much more typical. Can you guess what kinds of questions people ask me about things like SIP and RTP? FM ------------------------------------------------ On Thu, 15 Mar 2007 15:49:00 -0400, Paul Kyzivat wrote: > Everything is relative. But I'm not seeing anyone screaming to make sip > work over 300 baud modems on a .5mhz device with 700kb of memory. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 17:07:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRx7h-0001wR-0b; Thu, 15 Mar 2007 17:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRx7f-0001wC-FE for sip@ietf.org; Thu, 15 Mar 2007 17:04:31 -0400 Received: from m70095e42.tmodns.net ([66.94.9.112] helo=svcstsnq08.hotspot.t-mobile.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRx7e-0006Cw-2X for sip@ietf.org; Thu, 15 Mar 2007 17:04:31 -0400 Received: from [10.242.56.238] (238.56.242.10.in-addr.arpa [10.242.56.238]) by svcstsnq08.hotspot.t-mobile.com (8.13.7+Sun/8.12.10) with ESMTP id l2FL3DPH008766; Thu, 15 Mar 2007 14:03:13 -0700 (PDT) In-Reply-To: <7374777208BDC7449D5620EF9423256702A4D6AA@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF9423256702A4D6AA@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 15 Mar 2007 21:43:28 +0100 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-0701160000 definitions=main-0702270060 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: Outbound-08: usage of keep-xxx parameter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is so that the administrative domain that runs the server can pick what type of keep alive it wants to use (even though they are all supported). I think this is all too much complexity but it seemed that some people wanted this so that's what we wrote up. Cullen On Mar 14, 2007, at 2:25 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > If all outbound compliant edge proxies MUST implement all keep- > alive mechanisms, why do we need to list the different keep-alive > mechanisms (keep-stun, keep-crlf etc) in the outbound-proxy-set > URIs? Isn't it enough to simply include the 'ob' URI parameter? > > If all oubound compliant edge proxies MUST implement all keep-alive > mechanisms, do we need to keep-xxx parameters in the first place? > > Regards, > > Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 17:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxCG-0006RP-MW; Thu, 15 Mar 2007 17:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxCF-0006Na-G8 for sip@ietf.org; Thu, 15 Mar 2007 17:09:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRxCA-0007Mh-7v for sip@ietf.org; Thu, 15 Mar 2007 17:09:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2007 17:09:11 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FL9AYr009607; Thu, 15 Mar 2007 17:09:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2FL8rGd013356; Thu, 15 Mar 2007 21:08:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 17:08:52 -0400 Received: from [10.242.56.238] ([10.82.210.208]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 17:08:52 -0400 In-Reply-To: <7374777208BDC7449D5620EF9423256702A4D5AD@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF9423256702A4D5AD@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62571863-2986-4A54-8999-392E7753D4A9@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 15 Mar 2007 21:44:11 +0100 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Mar 2007 21:08:52.0285 (UTC) FILETIME=[223886D0:01C76746] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=354; t=1173992950; x=1174856950; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Outbound-08=3A=20Editorial=20comment=20on=20chapter=2 03.5.1 |Sender:=20 |To:=20Christer=20Holmberg=20((JO/LMF))=20; bh=yj9DAYQq/oyufg6Z6qNFtsoxi70RBY9V5Uc4qfj4YBA=; b=F/uDA3dzSiYb9IgPth1HwfWjIYw0/y3r4czlk7A1vr0AYpDZ+t7F6B8soHxUEO/ZdOnFBfXw sMoOt43Iao40kPziIbUCm4kP5n9bPUEXkcfuvxU16OD4GW3+LEuNhxOO; Authentication-Results: rtp-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: Outbound-08: Editorial comment on chapter 3.5.1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org oops - thanks for catching. On Mar 14, 2007, at 2:10 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > Chapter 3.5.1 says: > > "If the server does not receive a "pong" within an appropriate > amount of > time, it considers the flow failed." > > Should it be: > > "If the CLIENT does not receive..."? > > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 18:00:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxyk-0002Ql-F7; Thu, 15 Mar 2007 17:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxyi-0002Qc-Rj for sip@ietf.org; Thu, 15 Mar 2007 17:59:20 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRxyh-0008WV-Il for sip@ietf.org; Thu, 15 Mar 2007 17:59:20 -0400 Received: from dragon.ariadne.com (failure[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <20070315215914014002peiee>; Thu, 15 Mar 2007 21:59:14 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2FLVVGJ009233 for ; Thu, 15 Mar 2007 16:31:31 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2FLVVdx009229; Thu, 15 Mar 2007 16:31:31 -0500 Date: Thu, 15 Mar 2007 16:31:31 -0500 Message-Id: <200703152131.l2FLVVdx009229@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] Erratum for RFC 4235 (dialog event package) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just ran into this error. As listed in the RFC errata: ---------------------------------------------------------------------- RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005 Reported By: "Michael Procter" Date: Tue, 24 Oct 2006 04:40:09 -0700 UNVERIFIED Section 4.1 says: It should say: Rationale: The proposed version of text is consistent with the rest of the document, including the schema in section 4.4. ---------------------------------------------------------------------- It's clear to me that this erratum is correct. What is needed to advance this erratum to "verified"? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 18:27:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyFy-0001iu-Fw; Thu, 15 Mar 2007 18:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyF5-0001F6-3u for sip@ietf.org; Thu, 15 Mar 2007 18:16:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRy68-0001Qf-5z for sip@ietf.org; Thu, 15 Mar 2007 18:07:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 94E9E20522 for ; Thu, 15 Mar 2007 23:06:55 +0100 (CET) X-AuditID: c1b4fb3c-a84eabb0000073d5-58-45f9c37f2c4e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81D3420018 for ; Thu, 15 Mar 2007 23:06:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 23:06:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Mar 2007 23:06:54 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702AF7BDE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: To tag in final error responses Thread-Index: AcdnTj29HxNw2AVTQp60HsTfDe2KeA== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 15 Mar 2007 22:06:54.0835 (UTC) FILETIME=[3DFB7C30:01C7674E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] To tag in final error responses X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Chapter of 3261 says: "However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID." My question is: is there a reason why a final error response to an initial INVITE, for which NO provisional responses have been sent (ie no dialog has been established), must contain a To tag? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 15 18:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyqp-0002C2-3y; Thu, 15 Mar 2007 18:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyqn-0002Bi-BN for sip@ietf.org; Thu, 15 Mar 2007 18:55:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRyql-0002zN-Mg for sip@ietf.org; Thu, 15 Mar 2007 18:55:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2007 18:55:12 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2FMtBTZ017127; Thu, 15 Mar 2007 18:55:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2FMsrGv005344; Thu, 15 Mar 2007 22:55:10 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 18:55:07 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 18:55:06 -0400 Message-ID: <45F9CECA.9070006@cisco.com> Date: Thu, 15 Mar 2007 18:55:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kapil Nayar Subject: Re: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE) References: <603393.83028.qm@web31502.mail.mud.yahoo.com> In-Reply-To: <603393.83028.qm@web31502.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Mar 2007 22:55:06.0936 (UTC) FILETIME=[F9CF1380:01C76754] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13106; t=1173999311; x=1174863311; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Can=20a=20UA=20initiate=20a=20late=20offer=20 (in=20UPDATE=20instead=20of=20INVITE) |Sender:=20 |To:=20Kapil=20Nayar=20; bh=egRW2fsk5jth0pqQe8RuIvC7zTkgCrihNxWamr6YNZk=; b=KcfANwF8qsrpud+4z9E2fPt4y8Z02oJL7fZqw7f15y9ssV11ZZ+jHzGC9++9MMa9xwt64MTt bAaZUc+NGwBT1+iXyWZArw0hkCRjtiC2/efpnU2tE/jRAVWuWFvhm6N2; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: sip@ietf.org, Takuya Sawada , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Kapil Nayar wrote: > So, the SDP that your refer to in the figures1(2)/ > description for F9,F12(F6,F9) in draft is (answer1) > always and nothing else. Correct? Neither of these examples are suggesting that there is a second offer hiding in here. If SDP is included where it should not be by the UAS, and is ignored by the UAC, things will still work *if* the UAS had not intended the SDP as a new offer. If it did intend it as a new offer, then things are not going to work. Paul > --- Paul Kyzivat wrote: > >> We are quibbling over how the UAC should respond to >> a UAS that is in >> violation of the specs. We don't normally specify >> this normatively - it >> is up to implementors to cope as best they can. >> >> Perhaps the same can be said for SDP in the 200 when >> a reliable >> provisional has already completed the o/a. The >> difference is that we >> know some implementations do this, and don't >> consider it to be an offer, >> so ignoring it will most likely work. In your >> example, its hard to >> imagine that the UAS doesn't think it is making a >> new offer, so ignoring >> it is much less likely to work. The only reason I >> can see for >> recommending this is to sneak in another optional >> way to do o/a. >> >> Paul >> >> Kapil Nayar wrote: >>> Hi Paul >>> >>> Yes, I am refering to similar cases - the offer2 >> in >>> subsequent 100Rel/ 200OK after the first o/a >> exchange. >>> You are indicating that RFC3261 still holds good >> and >>> UAC should reject the 2nd100Rel/ 200OK. Note, that >>> offer2 is invalid (protocol violation) and UAC may >>> have to cancel(reject) the transaction(dialog) in >> this >>> case since there is no clear way of indicating >>> protocol violation rejection in PRACK/ ACK. >>> >>> However, going by Takuya's proposal in the draft >> -the >>> UAC would assume the o/a completed based upon >>> offer1/answer1 and ignore the SDP in 2nd100Rel/ >>> 200OK(irrespective of if it is answer1 or offer2). >> The >>> onus now is on the UAS(violating UAS) to interpret >> no >>> answer2 in PRACK/ ACK. >>> Ignoring is perfect for SDP-answer1 in the >> 2nd100Rel/ >>> 200OK. In case of SDP-offer2 it seems your >> suggestion >>> is correct, unless Takuya has some clarification. >>> >>> thanks, >>> Kapil >>> >>> --- Paul Kyzivat wrote: >>> >>>> Kapil Nayar wrote: >>>>> Hi Takuya >>>>> >>>>> Thanks for the reply. >>>>> I would agree with you - since RFC 3261 does not >>>>> clearly restrict the "SDP" (but only offer) in >> 1xx >>>> and >>>>> 200OK AFTER the completion of the first o/a >>>> exchange. >>>>> What do you think should be the behavior of the >>>> UAC if >>>>> the UAS sends an SDP-offer (a new session ID - >> new >>>>> media) in 100Rel/ 200OK in the above case? >>>> I don't understand exactly what case you are >>>> describing. >>>> >>>> Do you mean: >>>> >>>> UAC UAS >>>> | INVITE w/Offer1 | >>>> |----------------->| >>>> | 1xxRel w/Answer1 | >>>> |<-----------------| >>>> | PRACK | >>>> |----------------->| >>>> | 1xxRel w/Offer2 | >>>> |<-----------------| >>>> | ?????? | >>>> |----------------->| >>>> >>>> If so, I can see little to do other than send >> some >>>> error response to the >>>> PRACK. I think ignoring in that case would be a >>>> mistake. Its not nice to >>>> reject a PRACK, but it seems the only option. >>>> >>>> Paul >>>> >>>>> Would >>>>> ignoring suffice or you would like to recommend >>>> UAC to >>>>> cancel the call since UAS violated RFC 3261. >>>>> >>>>> Also, you might want to take note of the >>>> corrections >>>>> indicated inline KN>>. >>>>> >>>>> Thanks, >>>>> Kapil >>>>> >>>>> --- Takuya Sawada wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I just catched up the discussion... >>>>>> >>>>>> Comments inline with [TS]. >>>>>> >>>>>>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE >>>> BELOW >>>>>> AND COMMENT *** >>>>>>> (References are to figures in >>>>>> draft-ietf-sipping-sip-offeranswer-00.) >>>>>>> Comments inline. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Kapil Nayar wrote: >>>>>>>> Thanks Paul for the clarifications. >>>>>>>> Replies inline. >>>>>>>>> If you were to allow a second o/a exchange >> via >>>>>>>>> reliable 1xx, then it would have the >> potential >>>>>> for a race with a >>>>>>>>> concurrent UPDATE in the other direction. >> And >>>>>> that would result in a >>>>>>>>> need to >>>>>>>>> send an error response. But PRACK isn't >>>> prepared >>>>>> for carrying an >>>>>>>>> error response. Forcing subsequent o/a to >> use >>>>>> UPDATE avoids this. >>>>>>>> KN>> Perfect. So UPDATE (with SDP) support is >>>>>> sort of >>>>>>>> mandatory for implementations which want to >>>>>> enable >>>>>>>> changing early-media. >>>>>>> Yeah. It would be quite unwise to support >> 100rel >>>>>> and not UPDATE. >>>>>>>>>> 2. Just to clarify, in Figure1 "After F6 >> UAC >>>>>> and >>>>>>>>> UAS >>>>>>>>>> can send a new offer in an UPDATE request", >> I >>>>>>>>> guess >>>>>>>>>> the authors meant F7. >>>>>>>>> Debatable. I think the UAS can send an >> UPDATE >>>>>> after >>>>>>>>> sending F6, without waiting to receive F7. >>>> (With >>>>>> the understanding that >>>>>>>>> the UPDATE could fail if received before >> F6.) >>>>>>>>> The UAC should probably wait until it sends >>>> F7. >>>>>>>> KN>> I would agree with mandating UAC to wait >>>>>> until it >>>>>>>> sends F7. >>>>>>> I don't feel too strongly about this. I think >> it >>>>>> would probably be wise to >>>>>>> wait until after F7, but if somebody wants to >>>> jump >>>>>> the gun and is prepared >>>>>>> for the potential error if F7 was lost then I >>>>>> guess that is their >>>>>>> business. >>>>>>> >>>>>> [TS] >>>>>> I did not care so much on F6 or F7. >>>>>> Now I agree with that waiting unil F7 is better >>>> and >>>>>> safe. >>>>>> Probably we can modify the figure in a later >>>>>> version. >>>>>> >>>>>>>>>> 3. In the description for Figure1 it is >>>>>> indicated >>>>>>>>> that >>>>>>>>>> F12 (final response) should not contain an >>>> SDP, >>>>>>>>> and if >>>>>>>>>> it does and is different than F6, the UAC >>>>>> should >>>>>>>>>> discard it. (Similar description is present >>>> in >>>>>>>>>> Figure2.) >>>>>>>>>> >>>>>>>>>> a).Does this mean that a UAS cannot change >>>> the >>>>>>>>> early >>>>>>>>>> media to a final media in final response? >>>>>>>>> It means that each offer has been answered, >>>> and >>>>>> that >>>>>>>>> once an answer has been sent, it can't be >>>>>> changed without another >>>>>>>>> offer/answer cycle. And that another >>>>>> offer/answer cycle may not be >>>>>>>>> initiated >>>>>>>>> in the 2xx if one has already been >> completed. >>>>>>>>> This last is part of a principle that was >>>>>> discovered >>>>>>>>> during the evolution of this work: At most >> one >>>>>> offer and one >>>>>>>>> answer per transaction. >>>>>>>>> >>>>>>>>> At the time of F12, if the UAS wants to >> change >>>>>> the >>>>>>>>> SDP, it can send an UPDATE before sending >> the >>>>>> 2xx for the INVITE. Or it >>>>>>>>> can send the 2xx and send an UPDATE or >>>> reINVITE >>>>>> after the ACK. >>>>>>>>>> b).If F12 carries SDP, it should be >>>> designated >>>>>> as >>>>>>>>> a >>>>>>>>>> new offer-SDP, right? If UAC discards the >>>>>>>>> offer-SDP in >>>>>>>>>> F12, is it still obligated to send an >>>>>> answer-SDP >>>>>>>>> in >>>>>>>>>> ACK? >>>>>>>>> No. This is all as specified in 3261. Having >>>>>> sent an >>>>>>>>> unreliable provisional with an answer in F2, >>>> if >>>>>> there is any >>>>>>>>> SDP in the 2xx it must be identical to what >>>> was >>>>>> sent in F2. It is *not* >>>>>>>>> another offer, and so it there must not be >> an >>>>>> answer to it in F13. >>>>>>>>>> c).If UAC accepts the offer-SDP in F12, can >>>> the >>>>>>>>>> answer-SDP in ACK be different than the one >>>>>>>>> originally >>>>>>>>>> offered in F1? What is the behavior >> expected >>>> at >>>>>>>>> the >>>>>>>>>> UAS upon receiving this different media? >>>>>>>>> See above. >>>>>>>> KN>> Actually, there is some confusion here. >> In >>>>>>>> Figure1 and Figure2 call flows there is a >>>>>> successful >>>>>>>> completion of the o/a through reliable 1xx. >> As >>>>>> per RFC >>>>>>>> 3261..."Once the UAS has sent or received an >>>>>> answer to >>>>>>>> the initial offer, it MUST NOT generate >>>>>> subsequent >>>>>>>> offers in any responses to the initial >> INVITE." >>>>>> However, if you read the >>>>>>>> description in line with the >>>>>>>> figures it seems we have relaxed the MUST NOT >>>> to >>>>>>>> SHOULD NOT. >>>>>>>> Figure1 - UAS should not include an SDP in >> the >>>>>>>> responses F9 and F12. Figure2 - UAS should >> not >>>>>> include >>>>>>>> an SDP in the responses F6 and F9. >>>>>>> It has been a long time, and I no longer >>>> remember >>>>>> the rationale that led >>>>>>> to the SHOULD here. Note that in these figures >>>> the >>>>>> SDP in the 2xx is not >>>>>>> to be considered an offer. It is just a piece >> of >>>>>> redundant data. >>>>>>> Personally I would be happy to say that the >> UAS >>>>>> MUST NOT include SDP in >>>>>>> the 2xx in these examples. But I would also >> like >>>>>> to say (this is a best >>>>>>> practice) that the UAC SHOULD/MUST ignore any >>>> SDP >>>>>> that arrives in the 2xx >>>>>>> in these cases. This happens a lot in the >> wild, >>>> so >>>>>> one ought not break in >>>>>>> these cases. >>>>>>> >>>>>>> But I would like to hear from Takuya (who is >> the >>>>>> primary author) and >>>>>>> others on this. >>>>>>> >>>>>> [TS] >>>>>> RFC 3261 says "UAS MUST NOT generate offer", >> not >>>>>> "UAS MUST NOT include >>>>>> SDP". I guess some may interpret this as >> follows; >>>>>> UAS can include the same SDP both 1xx and >> 2xx. >>>>>> It does not care whether 1xx is reliable or >>>> not. >>>>>> If 1xx is reliable, SDP in 1xx is the answer >>>> and >>>>>> if not, SDP in 2xx is the >>>>>> answer. >>>>>> Some SDPs may be neither an offer nor an >>>> answer, >>>>>> just a hint or nothing. >>>>>> >>>>>> I would be also happy to say "UAS MUST NOT" but >> I >>>>>> could not conclude to >>>>>> say that. Clearly some implementation would >>>> violate >>>>>> "MUST NOT" rule. >>>>>> That is why I put the following description in >>>> the >>>>>> draft. >>>>>> >>>>>> UAS should not include an SDP in the >>>>>> responses F9 and F12. However, >>>>>> UAC should prepare to receive an SDP in >> F9 >>>>>> and/or F12, and just >>>>>> ignore them for the case that the peer >>>> does >>>>>> not conform to the >>>>>> recommended implementation. >>>>> KN>> >>>>> This is a bit confusing on the first read. >>>> Actually, >>>>> it seems you are trying to refer to the generic >>>> cases >>>>> in table1 in the description for Figure1(2)- >> with >>>>> reference to the Figures 1(2), SDP in F9(F6) and >>>>> F12(F9) will always be ignored. Isn't it? The >> case >>>>> w.r.t. the Figure is always non-conformant. >>>>> >>>>> Further, the conformant case is when the o/a >>>> exchange >>>>> has not already taken place in the transaction. >>>>> >>>>> You may want to disassociate (correct) these >> text >>>>> description. >>>>> >>>>> >>>>>> Regards, >>>>>> Takuya >>>>>> >>>>>> >>>>>>>> And, it sort of opens the discussion to >>>> possible >>>>>>>> scenarios where another o/a can be initiated. >>>> Is >>>>>> this >>>>>>>> intentional? >>>>>>> Definitely not. >>>>>>> >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> > ___________________________________________________________ >>>>> The all-new Yahoo! Mail goes wherever you go - >>>> free your email address from your Internet >> provider. >>>> http://uk.docs.yahoo.com/nowyoucan.html >>> >>> >>> >>> > ___________________________________________________________ >>> What kind of emailer are you? Find out today - get >> a free analysis of your email personality. Take the >> quiz at the Yahoo! Mail Championship. > http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk > > > > > ___________________________________________________________ > All New Yahoo! Mail Tired of unwanted email come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From maxintjukye@painvincompany.com Thu Mar 15 21:20:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS17b-00055v-VQ; Thu, 15 Mar 2007 21:20:44 -0400 Received: from [124.147.195.195] (helo=painvincompany.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HS17Z-0003AA-3W; Thu, 15 Mar 2007 21:20:43 -0400 Message-ID: <97090A31.E1A92C6C@painvincompany.com> Date: Thu, 15 Mar 2007 23:01:49 -0200 Reply-To: "Adella" From: "Adella" MIME-Version: 1.0 To: "Ozell" Cc: "Roselyn" , "Brittny Warren" , "Deandra" , "Christi" , "Alexis" , "Tinisha Gonzalez" , "Verda Johnston" , "Moses Martinez" , "Melvin" , "Jolanda Flores" , "Lissa" Subject: How Is Your Day Going Content-Type: multipart/related; boundary="------------442484868850284036088813" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb --------------442484868850284036088813 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit


"Oh, it is comfortable well double week taught enough as the production of a huma within dust impulse "Be assured," replied Albert, sought "that if I had been  "Ah, Maximilian, horn that is quality the very not spill thing that makes"So easy cerebric you were divide at the races, baron?" friendly inquired the co  
question lend "Well," finger said Morcerf, "for three hurt days I believed m  relation color balance "Philosophy, fast M. Bertuccio," interrupted the Count; "Oh, excellency,"   clever "Nothing more simple," street returned the connection puzzled count. "I had  "From which it would open seem, robust corporeal my dear name count, that you"Yes, madame."regularly attempt thick "I will not admit that word," sped returned the young m"Well, man tell then," into pursued parcel Madame G----with considerabl   "With the authority condition band that overcame they instrument should sin no more,"    force gracefully "No, aerial sit no; but philosophy at half-past ten at night   "My decay tight journeys became more excited and more sold extensive and mo    
"No, monsieur," back belong point returned Monte successfully Cristo "upon the si 

pipe "You hammer are right, in some degree; drain when string I wish to lis"I am wooly ice sorry horse to say I cannot," replied bumpy the baron; ""It is true," said Valentine, as she theory search thumb gone passed the enlock "Are you very settle anxious whistle to hourly know, countess?" asked Al       
attempt "Bravo," drove cried pipe judge Chateau-Renaud; "you are the first   knee "This," kneel wake said Monte Cristo, "is less irritably correct than y  cloth sent "Alas, your blew excellency detail is right," replied Bertucci          
"It collect level is trouble groan frank, at least," said Morrel. "But I am su        "Valentine," buy put replied the young cloud miss man, deeply affecte         

example "Then became sleep here, beneath my dear sharply count. The conditions ar"To know what?"iron "No, Maximilian, occipital I am hilly agreeable not offended," answered she,"The name of present the owner existence word sense of the winning horse?" 
"How joyously have I deviated follow advertisement grip from those principles, monsie    "We never knew band lick who industry had revealed pop this fatal secret,  run seen "'Are entertain you mad, instrument uncle?' (he called me by this name  
"No, thank belief request you. Your orchestra shone baby is too noisy. To sliron chase forsake "Excessively; only wipe imagine--but do tell me, viscou"Hate you, feeling orange sweet voice Valentine," exclaimed song the young mbeset "I beg hair your kiss pardon, madame, but art you were about to       
"Why, it seems to butter me," hospital replied Morrel, drunk astragatar "that in desold "Sweet meant calm vessel child," murmured Monte Cristo.  "Oh, roof had whip he been my surprise own drawer son," replied Bertuccio, "     
"Of lighten which muscle berry he is the ran brightest ornament," said Beau   

correctly "I drown mysteriously death know--the famous hashish!""Well, then, listen. You must know tore breed hug change I felt so inter"Alas," meal replied the request weeping girl, trouble join "I am obliged to"Precisely; fry I was off sure powerfully house of it," said Morcerf.   
"My divide dear count," fasten shut sow cried Morcerf, "you are at fault-  "Our apple expedition over light made a favorable shine beginning. We anc    "Yes," said selfishly prison accidentally drunk Monte Cristo "I perfectly recollect hi          
"My leather dear prefer vicomte," went returned Monte produce Cristo, "I do no"Sure of what?"              
--------------442484868850284036088813 Content-Type: image/gif; name="uyclquaeibijim.gif" Content-Transfer-Encoding: base64 Content-ID: <2BA358C6.C0654EA4@painvincompany.com> R0lGODdhjQGRAYQAAP///+jf0u+ysueUlNlOTsUAAN5aWu7u7MwzAAAAAP8AANbW1rm5uZrE4oac 20+QwyJhpWh9wY+UmGZmZs+yhdimbc6SVbWSZqV1O4BPIv/YfFpSWj0vPrY2CwAAAAAAACwAAAAA jQGRAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqZAUHgSa1ar9jsUSAY cAkFw0FLLpvPaOgUcAAXEF0EYj06DAyCcXrP7/vRAwADBIEiAwWIAgACeCQHBm9deHp/lZaXmD0H U4eFiwiIAwGjlIKhn3CZqqusrSaDeQYGIwKgBQOwJAG2swBgiq7BwsNlXI+RjGu7iLK3urbOd3p2 wMTW19hAdnJRiAhea22IBAKEJZCIYQHTkASl2fDx8iwBbgV5bt8k6HOjeWxS7N2jhQCPgQHv5ilc mK1eOjiHvFXjx4mcIHcOmY2IYipMQoYgQ7LK+OZOOgJr/iLCqTXwF4CMngw9/Ceypk1MJMPYK8SP UcEpkGYdG0gr3a1cN5MqzRJTBEk4bnrh8rKJToA7jEpSYhlKXLWlYMMquYqLJsmAYVxswqrL3qxa TcXKnfuj3MNGL90QeCmlxgG746ZwoUu4MA+fRlO9bEenBtc3jekNRpKgsuUEJywLu6y5RGeFl2l8 BjDaip1AAdBJFPH3a42Milf8nSrHQGQhnEuTruwH84rcvEnoxgbcN4zRw58sC7Tt5McbqdOq2NT8 HjoxRjqHxpRcePDdxsHP+zw8vOfuWJY5y+vtdg5qKA5sIvCNqyhbcYGQ/y4C+Xbv5f3X33f75TaC gSoU/giggMABuNuCmunW4Hn+GdddaRVyRqGD4GkIoTZsqGZbiIkgcRUBBhWAkkrRqeheDxVyOKCH MzI44YwHElhcjfyZECOP2xVnoY1C8ickhDoOaZ6MOOZ4448d0nhjXdBYBIABcxRhTETOJMMVF+m4 9gOU4jVZpoIDyohmh2ai16aR2vXopJPmhWannGommaOZPsqZ4ZvhFejbfnMGwSUzXIjJQ1UsIRQV G1OI49GjQ5ApaJ9LFgoon2u6GSWRmn6qJKZNSoggesFd6Ceco3KqZ6k7CjEANCUG4RMhs7ojgES4 yORiRL3glmSgrK5JaqHGoumpqMeeGWuZHMZJ7ISo/g6aaajQbupqq85OCUQX9BHynA1rdZEOagip ZwB9gtnCBSjBBmFstnRuay+0UErbQrWjBsnqsfrWqC2g/G6YJ7f4voqnEdT5wMhBCKCEDkZrXDcr MFGJkx8Pl2qq7LACJ2ztqyKzUDCs3Jo6KGn3lhxylCaTPHC+JMscRBQ0vUdWVBfvGoksIviMEhec SMRupc9uSySNoiqJoMswp3Byt0+rjDKSGQrI5m/eQk0zwk8PUUtB477wiCwFTXyVFLbQlyVMed0X ihdEJM1n1B9iuipv/7aMwtSXztvt3XfWqfXdCR7udd9Q432YKCbsmuUMs8lH3yB4uMsaP+sCM/Ff /iqWg+KLhs21rEK74kq0IdjJAJgYqUkiabBcihIF6D+rM0rpvDOt1KHeoNiXWnQcKgYum3Q0uXoY fbPMN8jzLv3WYalm1GotiA5MdWEk4xR+I6hkLjmy5Dz9+XI9QgB910fSgqTuEJQOXiJcV1QoWCJU Nvr837TOJpJg3+QcsTsS1I4WWDoXCXymGJashHT9i2D6uoCQOoxiEOKqQz4q5oWdbEQvU0gN3SRI wgjealanCFoCpdMF9kCGNflQVAlnOD3VgOmFVzKJ+x6hCLjlhRCReZgMaUhEkQgxaPhZBkoMgRYV jUEan/CIUz4CCX0csYhYnEcB1eYria1HEHjw/iBcVLixD9rGDg8pYxbXyIpZYeeAUYRDO4DxMPZF 4hDxcwFHOmKUIbLxj34gyyKkI6kszU58i5gEl/AwQhfgokXjcOP+AElJMiBGKoXIikauJJHrzEcR tQDiDA5Bqyx1YZKVTKUTJMG2cYzhKpzQYSp8dgtaHsSJL0ElCh7jvrWp8pdMwQUodIU9unVBXWyI SkYIQb8bAAYOf+EGMKdJhV29BRStXE8LT2lDPnbQSu9xyursR81yLkEcvWCEIj63mCgcxI5De4M5 5LODckBugWy5hgL2uc8kKEAE/zxBQIkwUIKGxYGRQaQgvIAHcyGKKj4Qhz4YUtCC3sCiAl0B/kZN sNEzdNSI4HsJOEKajEaMbRI3O8hkFmLRj8bApQDVKAtg+gKa6sCmClFXauDVEXcwNHXyMYYQ1Fm/ CiqkpSPgJ0cB0M+kNlWpJYBqQAcq1aQKtJ9UZapWnbrRf3q1q1ZlalO3ulWvkuCrVp3qU8Na1rGK Nas4ZcJQ5KgRWiKkfBmkBQRfA4ZUBAVn8kAqWVs61ZgaFqNwPWxaDZvRwYq1rGxNa2GjuljFHpaw l2WsWTXr2M66tQxcQssSewK5d7RhiYuyHkNtMys1ukKwWT1rWGOLWMpCVrYuTextY4vbyFaWtrNd qmU9q9XN1na4Z8jILCKiiL/IgnQRAed7/gZhFCtJTpeZgK1vgYtcxlqWsLn97WWh2lvvine4k5Ut eoNrVqqOlZ9r3QNCJbdX+YWivi3YIyTdN0Z4aNe83L2teoNL1u4O2LgGLm+Bzyvg9LI1vcBtr3CP K194IYUebrEnuWYVGxTOb6XZqOiDbdtg8zp2smoVsHA1i2ATb3bBI14vjAPM2xoTWMVpSM0ZX6Aa YsYGBq1JYB4XYxTXBgO+4F2xe93L0fgumbMLfm9lAfrZmPKWxG89a1WjSt6KuvXK5M2yiYXBJZSo JxBE0+XFnPtjQWjOnDJNwZV3ENdKVgcOZ+HkT4YHKZyFEBSe4HP4vghnOatgzjcttCO4/rSSKgHF GxikowAF40oV3E7RM/hyD6pc6AP65CfJDEwVe9i2MdDSj5hONR+2MTkA6kFdQ+kFO7ky5AKq+tZ8 OOYu8cMVqWBPNZ64A64tUWdgqkSHI+IjHdsWKaAN+9mWGAo54LUVBZKortKdS7FnOmZ/fvSzXeb0 VVWp077SwT4bERGI6cJpRB+620gQ92O1/OQWyBuLoT1zHcjJGkbk1TBVfmpcHVwGcCsVvi64NxEl dQ+77iMwJMSqWpGM1vdGuMZSpjLGcZvix1pc4FR+61c/7uV5I/yqXga5wkESQC/wQg/rs3YED95x gaN13pC1ucZ3LmapwhXkHq95xVPc/l6hh5zmIedy0i0uZrnsrhxkc4osyhJxo5u84+plMtIlPvQs a/rqR8e6xrVeXKurXN5AZzrOCXPpOhAx7WY/Ltm7XnSPlz3rRgc6V+d+9ZPDvd1WBzu0jxr3pct9 7yJPPMIXH+bC6z3sYb95wMUeZsMnXfCDD2zhvU50AHOdq02need9znnLSzzygj+75LUe+M9nXvOX PzvOsep5p9o+9kw2+ey7PnbTo3jJJbd5yRN/+aC/Xiwr9zY2kn98wmeB+X7IffOVAn0jVL8PJ5++ 9rfP/e57//vgD7/4x0/+8pv//OhPv/rXz/72u//98I+//OdP//rb//74z7/+96+K/gMs4P//x38C 6AgAWID/h10DyH4AKB8MKB8LwAALkID394AL4IAGWIAQGEH0JIGrtgANcIEg+H8fiIBhsYEcaAYe +IENsIIs2IIuyIIRqIES1IA0WIM2eIMkqBAN4AAv2IM96AAPEIP9Y4LSg4NGeIQ0KBYN8ABM2IRO +IRQ6IRC+AI9ojjZQISFURWjsIVc2IVe+IVc2DBLsQBPCAFmeIZm2IQQ8ABouIZNiF/eQSHXcgbY 9RxYOBdaCIZ6uIdfmIOnkybngQVLyIRrmIaEaIhnSIhsKIUyoCPBsDta+BKkcALJQ4WGszA6oCF2 swN5yIeeuIcLAIdMEjN9ggUM/qCGhciGaIiKieiGTMgAJOiIIJMmqSItc6gJNbiFVSGJIRQpuSiK VfiHjTgkeyIEndiHWxiKn+iFB3gcmIGJpYgGB4CKqtiKbriKhvgAEQCLMSCLK0OLz1iLB1KMxoiD 60AKWyiJNxiAlkiO8nIt0IgDxxgA/zcK9XiPupiMFYiO56iPovgg3hiOe+KIW8M3t6gJp4iIUbiI UGiGESABFTiMDzKRAiOOFPkyQWCO66CM+fg/NciOLuCN9QKOIXM4AWKMXwiA9FiA9GiPXRiKoeh/ +5iMDPCPBjknETIyE3mTAMmTRRAADBABbTiUQykBZ/iQNTkDPCmSFgknF6kN/noYky4Jk31Igc44 kN/Yk84yjoC4IIGYkcxoj/joki3JhcpIlS+ZlCFJjDtpLYAojnDplkcAlEZJlHbpkBIgAWopkU3p ln1ZjPGoA/UYljJ5jlIZhgugl/+olRd5J295iZliIyjphVXBkWZpmS95mDQJjGz5l20Jjo75lERA j0F5l0OJlKFoA4TymQYpl59JBDKJmVXBgB7phQyglxF5lRaplZ5Jkn9DkECwjMK5hwywlzHjIZ75 l8HYlUfgfw4glKZphhOAmzloMBSJnALZmFboA6SJmZ/4gNTJl3IZl48JmLcInD8wnOqZlty4L4bz mrWYnUspnwcZUf/HAA4g/gHQSZQT8JAO0IxLEJhI4H/F6Z1gCJ4QuA6iQZDkGSfm+ZXXWZ82UJbr KZwPCIG6tJzJmZ1t2ZtFcIH4qZ8TcIYT0J8S4AAQuIBHwJbpcaEGyoW3GZ41sJpRM595c6OiuSgq WaF8eJ+KCRYhWJz5qZ95eaIpeoErKowDSpoJapt5maBNIKDpUaAhWKVWioF5mZtJEZtBWpxHWqXV eQ0ESqUA+KQxqQQsumpAWZxF2qZu+qZw+qZQChYMeKW0WYEL2IBiQZpyqqVoqqSmwaReOqiEWqiG Oqj1GKZiioSMeoc2oY8gqKBDCKlXapn3uKOSmj6OKhsMuBRaSAk2GIYL/qensnGCsNmpxDOJpop+ igopm7qq9/eqsDqrtFqrtnqruJqrurqrvNqrvvqrwBqswjqslYAAxFpociAHLKCsL5CsI5CsxmoC 0EoC02oEzHqt0XqsfICtK8CsLWCs4AoA3Eqt0Tqu3noE4xoD2coD68pG7SoS58qt3qqs8/qu4nqv 0tqu5lqu+gqu61qt4uqs5Bqwz8qvInCuyyqwKoCw3VqvDBuw8aqwRLCvNQCwKfCwF+uw9mqxFjsE FFux/8qv/nqwI0uyJyCxBVsCH4uwzkqxKEuyJfux32qwC2uvKBCuMduvJkuwPIsE6aquNJuxzfqs PMuyNPuz1hq0MxCx/jvrsjYLsSr7riurs0V7tBtrtU37tFE7sARbrz37sOGar1tbtTubshGrsVvr tWQrA0zbtdlKr2+7sfg6tim7tkbbsxAbt3ertkgLtFw7tXibr3F7slgbuPtarWBbuH17syELs2Sr tlF7tWMrs44LuIJrt0rbrI0LtfI6uJcrtn9buAWbs1lLuKS7tjTQtoCLsQeLrxhruXXbt4lbuqjb sKFLu3CbsVQbuZ57t5hbtrf7u2y7uav7tCjLsLCLu6IbvL2rtTNbtjL7skSLs1SbvJyruFd7uotL uMyLtawLtcAbu3rru9iKuJIrvN8rtOKrvIEbuXU7ucuLuebLvejr/rwzq7pBK72jC7MtS65nK7Ul y7/vO7B8m7nqy76Pq7Vh+7oGTL4NfL7W6wL4y77fu8A2a72UG74IvL1FkL5z6wMebLsgnL+iq7/3 Sr3wi7uXG8HXi8DDC70lzLo4a7jYG74tW8MrjMNJYMJJewMhvLQSG70VXL43PLohK7n/O8Bm27wa rLkT/LVDLLJFLMBGLLZJ3MS568Lm58H2C7I+3MVNwMVB8MMHTH883MFgXMZYcMYTm8aMq61wHMdy PMd0XMd2fMd4TH+VyZKtmsd2FgAUEMiCPMgUkKl+nGqbMMgVEMgWYAGEXMiHjMgLMMgWcAEUUAGY /MgU4KeRPE0H/vDImezImhzI7dnJLFCDMzjJj2zJjpzJmlzKpkyJRKiq6HPJi0zIllwBF2DJo1wB UxjLjpAQkXg+AVABFoAByLzLo7zLu3zLtryYc4yFDSiq0kMBlYwBJTqdEuDMgXwBGNCmznwBDADM dVAKodqSfaxFxnzMeuml67zI3vykXirIF1AB0Hys0nyDYnnPDLEAjVzJEAmADLDO8YybAGjLlfzL fkyE01ybl2nIckEBzLzLuQmUjYzNP/oS1mwBmCzO6cyrDE2bCSofzHimeGjNE23PrLEAFYABGYCb rLHR/4wBxkmKcViKUqrHwUzSVNqPmcnP8XAAujzR4rwRDIDN/hgqAhJN1N9sk++J0xLKMAGgAVRd 1VZ91QJQqSo5PRtIg2tqmcdIgR9NDMVM1BQ9AheqlgFQyUwtAYuJnjd9BVPtkUiYmIdaqBltGKAq 0k3Kh8UJ1Fc41ERdAdPQkjFt1vH81p3poBsqHjn9ArZmAn1MlwqdPqzB1wZK0jBa054q2EQ9zpet B0vN1C9d2YkzkFgJnzqZkzww1eXcqMIpH7dp2nQa2gT6ok6x2YCNDZ+MAWbt27cRAN782xmQgd3I oWxio6rNnDdwABpA17D9pVqdl2MtprZNCjjYZ6Pw13SxAN6MzOCNzCq9ES0d3uCdARPA2aTIlPRZ nq+ZA3O9/p52fdeHuo3HSaNO8NgxMA1JOB26nQPJod9WINzmHd71jMm6XODnDZHQrNw32djvjQNT fdUUXuEaQAEP+aYREAElugEe/uEe7tZc86AzmolRTTm2rc96yN04gCHMzQdAqeAyHt4ZcN7pzclr udiM2ZruLeApYOFAbtUW4OET8OEccORInuRJPgG03ZW7KZFpwN+0OZwsrpoc6uNZ4N3mXeMzngFe jsxentfHPS0PTowQngNBnuYXoORs3uZHzuRlw6DI7S8dOjJ2DprLzThAFtoVWuUzSp9lbp7k6QQx ft5cPuPnzQE3Xt1nkOZBvuZuHulvDsvR2KF57uB+OS2O/g3o8CkDUr7HIWib6n3cEeqbAImVyL0E LI3oYH7oLq3oYo4Njg7kkA7itn7rHx4BqSk1UjKeFrLcrEks5QnhJ+52bEDSaX2oM7ndL3EDcj7s ZB7h55SYBe7q1s4BL23c8SAAFTDrFG4BR47r4v7hEBnnkenrodmXodnj7V3nxc4auc2kVvpKW+jn SqnjwZ7aT35OtzkBLs3qGXDk6K2XjI4Gxdzt3l7V4M4B4y7uNz7i0bjvZ86cyunrL2428U6BezgG Wmjvw4id0B7yOdqcPioBE+Dl1u7lAq/NHi+m1ozgCO7oQ97wuD6du87rmWHxO67zPnnp7N4fns4a 9tjX/n2o3bFO6nG4m6up3FAg0DFaoigf9drczve524H0zjCf9Vp/AUSezV7/9UVu8zgOoTc9i0p/ 59op8mf/7nw+9C86iSt5m5SO9A8qM5romkrQiffJpnDqpYMJkvBwAAP9z4Rf+ISvy2Cf+NmMmlYP D3HPpm9/joQK0XSaklr9kgVvBmOq9ZwP83H6+S1fggb41z2KpHSh4lOOhJHN25VJ367/+gWq1yu5 99LdpQWa+a6Qi7N8GzcoDw2t1cAfgrg/DJtA+8G/ksPfCqi80/sjq8HQqLkY/JjJO3d6pdBNj8mP q/O4jOij2WD4i9mv/V79ieHv+0ZIy+Q8HdmdReOf/v7Ht/ruT0nOXwLwH/+AJIanXP72T6fzf+z7 78kgcAAjWZonmqor27ovHMszXds3nus73/s/MCgcEovGIzKpXDKbzic0Kp1Sq9YrNqvdcrveLzhc RYi/5DI6DUSwzyt2rE1qu0t0u/wIB+z3rzuLn0veXJ2JH53gUN+ZotpjC2Og4RufpSTeCKZjEeZg I+VhaApZaeEoYaaS59Qo5I2gJGKpG6fpieImqChfHWBvLm2h5u6nKtxs7zCuJV7o73JmLCG0crIy dlwqqSsK9TbxNHiQrs50ODZy7bOtYXk2+nu7cHpxpC8ovXq0sx383L+AcuSx01eM0xt73GCYMsgr /htCI6xsnKtH7GLEbY4IPuSI6yDIP/guWrTmilpAfik9tiP5TuQxeiZVamr20JtCXuLWBYMYMkdF jhGB0SzJKg8jQC2N5lQR9Oc+p8hI4rwZMxxSdi4bFZUa0+A3nO6GJt0Y9WU/jziebsXY7RZCtW0F amVKddJVu2QvJVrYFe3dZXLv5S2X0azfkoKh1h1M0d7LcTUbjp07cSBjsXZT+r3mSfIlm4rvxj37 U5TD0YQXW5apWZVV2K2VNs68A1pksmWjAsOHeGdR3oAnsfX5tue/ih/h/WrpuWnCwiH3Vo4te/P1 1nOfDK1JrpuxMeBF++i+eg3k06AbWpyoGrP2/o+p3ScBrWc83lbmieyPLgS3errxBFJz4PDWW3Ay DfcKgw06uFwg/+Hn34MVWnghNxNKuJaGGHr4IYghijgiiSWaeCKKKaq4IostuvgijDHKOCONNdp4 I4456rgjjz36+GOJBwi5AJFFLiAkkEkqOcQBRjr55JFLSnlAABYIcOWVAYgg5QpNQvmlkVvqGEAA WJpJJpI5HkBBBW1a8GabcVYggJhcjgAmnk6qaSaffKJpowByCjpomwIEwKWXeSoaZY1lmskmBZFK 2uehMgZKKKaCGppkoosqWieMBzwKZwWSSloqBWeCquIBgpL6qgEGDGpBoavi6KmRDICpK40L/lzJ Jq1XogrsmxaYGmmWtpZIAa1uNmtAs8/K+WqclapZJAPZ6rpAtkRqu2233Grr7QIyOgrsnMcyO2cF xrZrrKmbpthqs+9WAK2gsroZK75xBqujuNk64IC3AxM5cAMNcDuwtgZ7y4CyKS4Q6buXDhpptKTK SYG1JgpQLMj9PhsttBrACfKb5d4YQLYJNxBBBA4wMDDDDjRgMM0yz6xzyx2z2CSxbGZ6cqkax0lB xB9+HDICsobstAX9xooynD6by4DLOd9M88w7d921zAk3rLKLazpL6Mm0vkmsqxVY/UICccdNwtwo 1F23EwJAWywBBhBAQLF+Px014FQbcAHZ/jDIfXcCKsyNdwuLNy653EVw6zLmmWv+Ledj04A35Gqw 7CYGzoLcLgZqF5v6u8W6/XnjIzCewuxP6M1vrG3+HSsCffsN+N9NG96BBIm7APrksdudPNzKI4/E AlvnPD31NGuOOcGw0638IwcwsHrqb2LAOurgsw7yBRJAPEPox3MPRQC47/5mrAT0/nffKOPudwcT MPC2497nPhm0T3YCFMLCqqdAB8RsgQOLgPEUxzwGNal147sgysJHNQtcoIPqi+AAl2fA2jGugEy6 wP74FbW9BW5qKzRAB2KYgQ8m7QQFRN7sSnhAAFTOhjsEAsscCLOcxayBDgSg+963OAPy/pB7S2wi E5nArQ1SMYPjk4D6dFVD2u3wcduDIhRrB70O+C6FZuTX32Q4gSwuAIlcFCEPv/i4CZrwiV88QhCF SLMhGrF6EVhfDXooOznOcZBMFKMSvCeBC1SRahfEABa75UYW1NF5lcuhCYvQKjKeMYX2U2MkdaUl 9h0QcksspCADaMof/qBJQiwiLPs4vQgUb4uq9GEhwTjC2NmRCSyTwPiq+EgssnGUN6jkIenIy1Qi IQASiOH98CfNGIKymMYkJRzDyDwdRu55zWSABBzIwAfKkojqmyQlQ4fKZRLyjk6gEjgfKc8LhpJI 1zxmF5UJxlWyEoEMmAA1A0rNDGRg/o1sbKMtV3BDdmpTl03spy4zGQRuSaCc4iQiLXllg1zuU58d 3SUUmgTOCZC0pCUl5rYSKsE75rKlHl3CL0lKUIKSNJTbuicOnkfCbb60BN50qBFEWlGLvjKjjNJe FDGZVHYiEqYTy1YFiInFCmRLUvbEaU7tqEOP9jIJVApY58bVRnSSsoc4XCdIuZhKiQZBqDAb4gLf +lYa4tOdkvvoLnuaSDIFgEhWfRJfA/unsgm2sIYNrEobxS25MraxMPsgWVXEVygFdqyH5WtiLSSk zXK2s57lLGYz+6K+zgyLETApzFCLRZkddUZUuixsLytaB322trb9LI86Ja6BSVWq/gzbVpFmG6LN oim2rxVScRHLqtsy97Y60q2TOKczPAn3Q829rmdftFk7sQC6uAJTdYcrAuzalrs98u53idRZEJq3 vbklL3zdK98fwTe+873veTkLgOuSIE34/S+AAyzgARO4wAY+MIITrOAFM7jBDn4whCMs4QlTuMIW vvBt8NshDHehGlVhyCzm4ZsNw+I0IDZPf9CBFbGMGAkLgjB9suOU0FzGNvWBjn+6k2L21Dg+Nw6M FEiMIbYk4xqHIE9gBnOgAvXkOUCmUHvW4RNvIDk5NnaLMwakEymrRiQo7tA3RJxlF5t4Bk9xiJH7 ASHWvMc020nLlc9TDzRzGTUf/mZzjecDHfhgB8RPljEpaJwTx3QCxzDB83ROghzpJNk2SyG0VxDd lsNUBzVcRg6hWbJhIks5zQCpi6StzJwwV8bJnDl0fGRxnDozWtRzzsqHIZ2Yzag6Iaxmc2+qs5s9 O3rTIyFKrZ88DkyXmc8LMnaZZVAcwyi6GaXxMbSF3WtttDrYgcaxe4gN5EfHWc6aPrVGKKHkaUNI 1oc2dYhnTJmOxBnZbz4FrX1NldycRNDstox84q0Zc99Z3zORyq1Tret8wLrc3TZzKuhta6wIJ+EG ck2BqoJuEgNo0kQBOMMV5HCtAEfaU+5yfgSOZXX/edzvXgm5mYDiDZUYCyv//g6HFpGe7azH3tUe tJtB7m6QF1rIPUjxrIMMdPTEXObL5snCc63xjkujxR6fOIcn/HKitzzqVlezE4a+5qtzvete/zrY wy72sZO97GY/O9rTrva1s73tbn873OMu97nTve52vzve8673vfO9737/O+DFroDBEz7wfSc84hVg eL0jfgSNf4XibZB4FBT+BJUnweAX34XLA4DzaPB8DBKfecxPvgSl73zkNb8F0EN+9DOoPOdHf/nC yz71qtfC6Sn/eNTbPvasJ33qfa/434ve9LvXfeRnX/vgJ3/4tr897nMP/Mcrv/fSNz7zrV98y59e 9M/HvuNdD3vxO//30LeC/vdNMP7mZx/44f/++90vf+K7nvfyR3717z95+J8/C9tHPunFnwDaHwAO YP4VIAEOoPrl3gEKIPv1HxccH+/t3vJN3/UZIPm1HwIKXwpUIAbyH/vVHwRegfB1X/lh3/+Bn/5l YAey4P2p4AHSn/2J4Ag6gQhW3wkGIAe2AA6uIPzt4AQWYAzSIOqFnxHWYBQ0IAGW4PMpoQ/CIBEm YBBKIRRqIBGSHxUiYRN4n/ZJnwROIP2lnwWGYQZ+IQre4PXV3wVq4RKkoPt5Hhny3/vl4Aya3xTO oRxOHwIu4ALmIRvKiB3+IdoFoiCaHSEWItkdIiIuIiM2oiM+IiRGoiRO/iIlVqIlXiImZqImbiIn dqInfiIohqIoNsqVDIApniIqpqIqriIrtqIrviIsxqIsziIt1qIt3iIu5qIu7iIv7mKWiIEADMDu qCIA9KIxHiMyJqMyLiMzNqMz7uLvDEBkPYEwEoA0jqKJBIAwGoAAZIEA9E43YqOK6A0BhOMUHIAB AIA5iuOKfOMAnKMBDEB4seODoCMBTGMQBAACvCM9xogwzuMNxM869uOLDAACAGQNlCNB0sgAGABC ykCsLGSNxKMSfKNE1sgB3CMSoONAXiSMCAABIIHeeKSNKKQRmGQ6MZMS8JLjwA36RWHnqR8NBN8X wGQWMqAZ9uEVjGQR/vBk5PjUD0CUISlUEAiQUIaeHDbhTGJeTfphFAIhD/phE2gkEVDk8ZjAUSqO S1JSUdqQDzyl9S2l4znIUxZhTNokHxIBWp6AKRYBVf4kUI4Q7QCVWS2U8wzlQw0lK92lXjaVWdHN IKlTAWUeDpYfYR5mWMbkWNZhDtIeYjJmFsZf8zmgGirfHTrfWFam9pklHuLfG2bf8MmAT7ZVSG4l YMYRXrJUFKFmKZ0mS+ola3IlbKJmbGLlabLma9KmAI1fAPYmZfYmTR5h7QHnZJrlcHLfESomZ2Kh cSafTMrecjJlcwbnYhpfcpYedNIAATxkCoymbLrmbcalboKnV9rm/ngCJUTxZW2KZ3hOzm2q524y n29y5nL+oHQWIexZZ34a4X6mZXReZ3E2p3JKJ2/Wp4HOoe5ZJ30K6AwYAD7OQENqZVyqp3jCZ2pe aG4qEVudp26CTnkG5ntuj0oyJ31W5nzep3xiZliqqA7iZ4Jep28eZx/e4G+C4WHOpxcmJhomZwxw 4xC0pWkaEoXGkYUKqd2U55Dm5lzO5oR+KJGG6IUqqIFOZoDSIHVmpoua3lmGJlOyKHLCKIDyqA4q 5RIGaIz+YBPq6PflZAsMQEf2QEQGaZGaJ4cqKZRmKGDa6YfyJZ86KW3uE5RKKRZSqWQO6n2GqX/u qJg+5uxhoAEK/mfvoah84ucDVqdiHieJWmoNAGkQcGo3MZNKMmlerqZPeeif/qWo4qVWmWqpsucE iSj3IeakhqnvKWeanuiBnmlaOqZ+ympnBqFj0p6NImihhuCkmmBhSiUKeOoPMOuHGGVQsmcRrCUJ KquHuKELOGsPaCuGQKsPOFESUOtLqgiZxgC37sC5gsiGEpASIQGbYsG7gsgaskC65kC9kqSL3OsN 6Cu+rgi/bio/so8OtCYQZGUMrGtOcYHBPusS/CsNOGy0+ikPLOxVGgHFWmx4NsjFXiwOQKwMeGwP EGzEhuwRcCwRDCmDbGzDBiwQgGxsVpKGnqp7PqlclqoltaZg/oKrUd7snsIqk84seiYpq8InDqGn WgWmht4lzBrtqPpszeJSnvLs09JsoK5VxkIoyzZr1kro3fSskPIpQ9Vpnl5t1/6st6LsefZpX8JR 2Kpt2o7t2rZkUt2pnq5n2Yoth9Ltz77n2Vbt1X7s1m5r4FYs2vrtbIJrqu7l36Itnh5pkc4pnSqp hbpnkgbqkuKt3R4p5qKs4hrp3qYqiFou0NqAy76AyzYuVgrSnEpuL6nuDbWn6mpu4QKt284uee4t 5dpsXv1thfItqv7p7d4sP+kuLt0t0cYu1IqoKQEvDVhlEHgn15Kt4b4t72ast26u7PIu7Qav9t6u 2OauV4rs/uVCLuhmbpRKK/NeL/lGKerapsmSgI8KAfRuJeeu5uqqqt/W7+Eybvnir+fmbe+eansO cOgCsNfiLf9i7+FK7//eL/t+bvX26IPKQEYGUvl6kfLarJ2CatEWb+oaMKn+UNJqsPYir9MmrhMt L9m2rwmXkgpPbdPGMPHWqdQ+cF9erw1kJHemwFu21/tiwQ8HaYgE8fz6QOneSBBbQRLD5YgE8RG/ QACUpnkh7IwscRdQ8Qr0sBCgZL9+ZDoaAUh2sYxwMX+8qRijSBiL5Hae8c8ggBkLQYSysYo470bS sRyTiDA2gT4O7h1jiDBOcA9YYx+LSB7DT6zs8CBXQfw4jeQUGOQbJ3IagCQfNwFIkjEko0ElAzIY +801XjK6gvE2PvIUaOPuxOMzomIxnrIqq3Iqr7Irv3IttrIy1k88avI7lQks57Iu96Is77Iv//Iy JosnDzMxF7MxHzMyJ7MyLzMzN7MzPzM0R7M0TzM1V7M1XzM2Z7M2bzM3d7M3fzM4h7M4jzM5l7M5 T3MIAAA7 --------------442484868850284036088813-- From sip-bounces@ietf.org Thu Mar 15 22:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS2Z7-0004U4-86; Thu, 15 Mar 2007 22:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS2Z5-0004Ta-Lr for sip@ietf.org; Thu, 15 Mar 2007 22:53:11 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS2Z2-0004Us-TN for sip@ietf.org; Thu, 15 Mar 2007 22:53:11 -0400 Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp [129.60.39.117]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2G2oXCa007306; Fri, 16 Mar 2007 11:53:05 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA) with ESMTP id ADE65128; Fri, 16 Mar 2007 11:53:04 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 800A320AE28; Fri, 16 Mar 2007 11:53:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 3855E20AE29; Fri, 16 Mar 2007 11:53:04 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2G2r3rr010357; Fri, 16 Mar 2007 11:53:03 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2G2r3cO013284; Fri, 16 Mar 2007 11:53:03 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2G2r3cs013281; Fri, 16 Mar 2007 11:53:03 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id l2G2r2FQ018782; Fri, 16 Mar 2007 11:53:02 +0900 (JST) Message-Id: <200703160253.l2G2r2FQ018782@imf.m.ecl.ntt.co.jp> To: john.elwell@siemens.com Subject: Re: [Sip] Comments on draft-munakata-sip-privacy-clarified-00 From: Mayumi Munakata Date: Fri, 16 Mar 2007 11:53:02 +0900 X-Mailer: WebMail V3.5.1 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Junkmail: UCE(10) X-Junkmail-Status: score=10/10, host=sfs2.rdh.ecl.ntt.co.jp X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090204.45FA0690.00B9,ss=1,fgs=0, ip=129.60.5.69, so=2006-12-09 10:45:40, dmn=5.3.10/2007-02-21 X-Spam-Score: 1.1 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John, Thank you for the detail comments to my privacy-clarified draft. See inline. Elwell, John wrote: > Mayumi, > > I think the Privacy header field does need to be brought up-to-date by > removing unused and badly specified values and to align with more recent SIP > capabilities such as GRUU, Target-Dialog, Identity, etc., so I welcome this > draft. Some comments: > > It needs to be clarified whether this is intended to obsolete or update RFC > 3323. Section 1 says that it obsoletes RFC 3323. However, it also refers to > and clarifies the extensions to the Privacy header field in RFC 3325 and RFC > 4424, and these extensions refer normatively to RFC 3323. So I don't think > it is possible to obsolete RFC 3323 unless RFC 3325 and RFC 4424 are updated > to reference the new RFC. I am unfamiliar with the process, but we will change the text to say that it updates RFCs 3325 and 4244 to reference the new RFC, if necessary. > > In section 1 it mentions the Identity header field as revealing identity > information. This is not true, because it is simply irreversible > cryptographic information. However, the Identity-Info header field could > reveal information about the requester's domain (although this would only be > included when signing a From header field URI that itself reveals > information, so I don't think it needs to be considered). Impact also on You're right. The Identity header doesn't reveal user's information. But the Identity-Info header may reveal the information about the administrative domain of the user. I believe that the Identity/Identity-Info headers could sign functional anonymous From/Contact headers, and in this case, the domain name in the Identity-Info header is the only part that could reveal user privacy related information. > 5.1. It should also be mentioned that a privacy service must come before an > authentication service (RFC 4474), because the authentication service will > sign the From and Contact header field URIs, for example. I see that 6.2.7 > has more in-depth discussion on these header fields, but I am not sure it > captures these points accurately. A privacy service doesn't always have to come before an authentication service. As mentioned in section 6.2.7, if an authentication service comes before, a privacy service will compute and replace the Identity/Identity-Info header when it anonymizes From/Contact headers. > > In section 3.2, it should be mentioned that if only network privacy is > requested no network intermediary is allowed to override the user-provided > privacy. Agree. We will add text. > > In section 4.1, we should mention in the table all methods, including those > defined since RFC 3323 was published (e.g., PUBISH). Agree. We will add PUBLISH and REFER(oops!) in the table. > > In section 5.1, table 1, P-Preferred-Identity is missing. Should we > recommend that a UA omit it, or is it still useful between the UA and its > domain proxy? The P-Preferred-Identity header must be removed by proxy in a trust domain so you don't have to worry about the privacy. We can add a text in section 6.4 (Considerations for Non-Target SIP Headers). > > Table 1 does not make a distinction between requests and responses. For > example, you cannot anonymise a Call-ID or Via header field in a response > (although it can restore stripped out values, as mentioned below the table > for Call-ID). How to handle Call-ID and Via headers in a response is mentioned in section 6.2.1 and 6.2.16, respectively. However, I agree that it is more easily understandable if the table is separated into requests and responses. > > Section 6.1.2, last paragraph. Presumably this refers to the Contact header > field URI. Right. > > Section 6.2.1, add Join to the list of header fields that can contain a > call-ID. There is a dependency on in-bound requests outside a dialog being > routed via the same privacy service - is this an issue? I think it is > captured later in 6.4.3 specifically for the Replaces header field, but does > it need to be discussed earlier in general terms? Also it should be > mentioned in the sections dealing specifically with Join and Target-Dialog. We might have make an oversight about the Join header. Yes, a dependency on in-bound requests outside a dialog being routed via the same privacy service is the issue. > > Section 6.2.11 recommends anonymisation of Referred-By, but is there any > benefit in having an anonymous Referred-By URI as opposed to omitting this > header field? This is another issue we would like to discuss in Prague. > > Section 6.2.14. Surely it is acceptable to add a Subject header field if it > doesn't reveal identity in any way? That's right. This behavior traces back to RFC 3323. We will change the text. > > Section 6.4.4. Shouldn't this discuss the restoration of Route header field > values that have been stripped out of Record-Route header fields? This is complex so we need to show some examples to explain. When UAC (Alice) requires privacy for a request, a privacy service doesn't have to handle Route header. Alice > INV(Privacy:all) > P1 > INV(Record-Route:P1, Privacy:all) > PS > INV(Record-Route:PS) > P2 > INV(Record-Route:P2,PS) > Bob Bob > 200(Record-Route:P2,PS) > P2 > PS > 200(Record-Route:P2,PS,P1) > P1 > Alice Alice > re-INV(Route:P2,PS,P1, Privacy:all) > P1 > re-INV(Route:P2,PS, Privacy:all) > PS > re-INV(Route:P2) > P2 > re-INV > Bob When UAS (Bob) requires privacy for a response, that's another story. Alice > INV > P1 > INV(Record-Route:P1) > P2 > INV(Record-Route:P2,P1) > Bob Bob > 200(Record-Route:P2,P1, Privacy:all) > P2 > PS' > 200(Record-Route:PS',P1) > P1 > Alice Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' > re-INV(Route:P2) > P2 > Bob Yes, I agree that the Route header should be restored by the stripped value out of Record-Route, in this case. Again, we need to distinct the behaviors for requests and responses... > > Section 7.1. This fails to discuss location of a privacy service for > mid-dialog-requests (but I think that is covered in section 8, where use of > Record-Route is discussed, so perhaps it doesn't matter). More importantly, > it fails to discuss location of a privacy service for requests that contain > header fields such as Replaces, Join and Target-Dialog. That is an issue, too, unless we don't have to make the replacement work using Replaces with anonymous call-ID. > > I may have missed it, but is it specified anywhere whether a privacy service > is required to pass on the Privacy header field or strip it out? As mentioned in the 6th paragraph in section 8, a privacy service should remove the corresponding priv-value and must remove the entire Privacy header when all the priv-value has been removed. Thanks, Mayumi > > John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 04:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS7Nw-0000Kz-Gm; Fri, 16 Mar 2007 04:02:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS7Nv-0000Kt-JU for sip@ietf.org; Fri, 16 Mar 2007 04:01:59 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS7Ns-00023s-VR for sip@ietf.org; Fri, 16 Mar 2007 04:01:59 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JEZ004C8KZ6H2@siemenscomms.co.uk> for sip@ietf.org; Fri, 16 Mar 2007 08:01:54 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 16 Mar 2007 08:01:55 +0000 Content-return: allowed Date: Fri, 16 Mar 2007 08:01:54 +0000 From: "Elwell, John" Subject: RE: [Sip] Comments on draft-munakata-sip-privacy-clarified-00 To: Mayumi Munakata Message-id: <50B1CBA96870A34799A506B2313F26670B4F550C@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mayumi, Just a few points. John > -----Original Message----- > From: Mayumi Munakata [mailto:munakata.mayumi@lab.ntt.co.jp] > Sent: 16 March 2007 02:53 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Comments on draft-munakata-sip-privacy-clarified-00 > > Hi John, > > Thank you for the detail comments to my privacy-clarified draft. > > See inline. > > Elwell, John wrote: > > Mayumi, > > > > I think the Privacy header field does need to be brought > up-to-date by > > removing unused and badly specified values and to align > with more recent SIP > > capabilities such as GRUU, Target-Dialog, Identity, etc., > so I welcome this > > draft. Some comments: > > > > It needs to be clarified whether this is intended to > obsolete or update RFC > > 3323. Section 1 says that it obsoletes RFC 3323. However, > it also refers to > > and clarifies the extensions to the Privacy header field in > RFC 3325 and RFC > > 4424, and these extensions refer normatively to RFC 3323. > So I don't think > > it is possible to obsolete RFC 3323 unless RFC 3325 and RFC > 4424 are updated > > to reference the new RFC. > > I am unfamiliar with the process, but we will change the text > to say that it updates RFCs 3325 and 4244 to reference the new RFC, > if necessary. [JRE] OK, but I think this needs group discussion before making the change. > > > > > In section 1 it mentions the Identity header field as > revealing identity > > information. This is not true, because it is simply irreversible > > cryptographic information. However, the Identity-Info > header field could > > reveal information about the requester's domain (although > this would only be > > included when signing a From header field URI that itself reveals > > information, so I don't think it needs to be considered). > Impact also on > > You're right. The Identity header doesn't reveal user's > information. But the Identity-Info header may reveal the > information about the administrative domain of the user. > I believe that the Identity/Identity-Info headers could > sign functional anonymous From/Contact headers, and in this > case, the domain name in the Identity-Info header is the > only part that could reveal user privacy related information. > > > 5.1. It should also be mentioned that a privacy service > must come before an > > authentication service (RFC 4474), because the > authentication service will > > sign the From and Contact header field URIs, for example. I > see that 6.2.7 > > has more in-depth discussion on these header fields, but I > am not sure it > > captures these points accurately. > > A privacy service doesn't always have to come before an > authentication service. As mentioned in section 6.2.7, > if an authentication service comes before, a privacy service > will compute and replace the Identity/Identity-Info header > when it anonymizes From/Contact headers. [JRE] Then the privacy service is forced to become an authentication service too. I don't think we should mix the two concepts. If we assume that a privacy service will always remove the domain from the From header field URI (replacing it with anonymous.invalid), then in fact an authentication service coming after the privacy service will be unable to add an Identity header field, so no problem. If the authentication service comes first, the privacy service must simply remove the Identity and Identity-Info header fields. Perhaps that is all we need to say. However, if the privacy service were to retain the domain in the From header field URI, an authentication service that comes after the privacy service would be able to add an Identity header field to authenticate the caller as an anonymous user in the domain concerned. This too would be harmless. Because this option is not recommended, I guess we don't need to say anything. [JRE] We seem to be missing a statement that we MUST or SHOULD use sip:anonymous@anonymous.invalid when anonymising a From header field URI. This recommendation was given in RFC 3323 and must not be lost. > > > > > In section 3.2, it should be mentioned that if only network > privacy is > > requested no network intermediary is allowed to override > the user-provided > > privacy. > > Agree. We will add text. > > > > > In section 4.1, we should mention in the table all methods, > including those > > defined since RFC 3323 was published (e.g., PUBISH). > > Agree. We will add PUBLISH and REFER(oops!) in the table. > > > > > In section 5.1, table 1, P-Preferred-Identity is missing. Should we > > recommend that a UA omit it, or is it still useful between > the UA and its > > domain proxy? > > The P-Preferred-Identity header must be removed by proxy in > a trust domain so you don't have to worry about the privacy. > We can add a text in section 6.4 (Considerations for > Non-Target SIP Headers). > > > > > Table 1 does not make a distinction between requests and > responses. For > > example, you cannot anonymise a Call-ID or Via header field > in a response > > (although it can restore stripped out values, as mentioned > below the table > > for Call-ID). > > How to handle Call-ID and Via headers in a response is > mentioned in section 6.2.1 and 6.2.16, respectively. > However, I agree that it is more easily understandable > if the table is separated into requests and responses. > > > > > Section 6.1.2, last paragraph. Presumably this refers to > the Contact header > > field URI. > > Right. > > > > > Section 6.2.1, add Join to the list of header fields that > can contain a > > call-ID. There is a dependency on in-bound requests outside > a dialog being > > routed via the same privacy service - is this an issue? I > think it is > > captured later in 6.4.3 specifically for the Replaces > header field, but does > > it need to be discussed earlier in general terms? Also it should be > > mentioned in the sections dealing specifically with Join > and Target-Dialog. > > We might have make an oversight about the Join header. > Yes, a dependency on in-bound requests outside a dialog > being routed via the same privacy service is the issue. > > > > > Section 6.2.11 recommends anonymisation of Referred-By, but > is there any > > benefit in having an anonymous Referred-By URI as opposed > to omitting this > > header field? > > This is another issue we would like to discuss in Prague. > > > > > Section 6.2.14. Surely it is acceptable to add a Subject > header field if it > > doesn't reveal identity in any way? > > That's right. This behavior traces back to RFC 3323. > We will change the text. > > > > > Section 6.4.4. Shouldn't this discuss the restoration of > Route header field > > values that have been stripped out of Record-Route header fields? > > This is complex so we need to show some examples to explain. > When UAC (Alice) requires privacy for a request, > a privacy service doesn't have to handle Route header. > > Alice > INV(Privacy:all) > P1 > INV(Record-Route:P1, Privacy:all) > > PS > INV(Record-Route:PS) > > P2 > INV(Record-Route:P2,PS) > Bob > Bob > 200(Record-Route:P2,PS) > P2 > > PS > 200(Record-Route:P2,PS,P1) > P1 > Alice > Alice > re-INV(Route:P2,PS,P1, Privacy:all) > > P1 > re-INV(Route:P2,PS, Privacy:all) > > PS > re-INV(Route:P2) > P2 > re-INV > Bob > > When UAS (Bob) requires privacy for a response, > that's another story. > > Alice > INV > P1 > INV(Record-Route:P1) > > P2 > INV(Record-Route:P2,P1) > Bob > Bob > 200(Record-Route:P2,P1, Privacy:all) > P2 > > PS' > 200(Record-Route:PS',P1) > P1 > Alice > Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > > PS' > re-INV(Route:P2) > P2 > Bob > > Yes, I agree that the Route header should be restored > by the stripped value out of Record-Route, in this case. > > Again, we need to distinct the behaviors for > requests and responses... > > > > > Section 7.1. This fails to discuss location of a privacy service for > > mid-dialog-requests (but I think that is covered in section > 8, where use of > > Record-Route is discussed, so perhaps it doesn't matter). > More importantly, > > it fails to discuss location of a privacy service for > requests that contain > > header fields such as Replaces, Join and Target-Dialog. > > That is an issue, too, unless we don't have to make the > replacement work using Replaces with anonymous call-ID. > > > > > I may have missed it, but is it specified anywhere whether > a privacy service > > is required to pass on the Privacy header field or strip it out? > > As mentioned in the 6th paragraph in section 8, a privacy service > should remove the corresponding priv-value and must remove the > entire Privacy header when all the priv-value has been removed. [JRE] Another point. The recommendation for the UA to include a Proxy-Require header field if it "believes that it is sending a request directly to a privacy service". Is this a reasonable recommendation? In general, a privacy service is likely to be realised at the domain proxy, and there would be no need to provide a privacy service at edge proxies. Is it reasonable for the UA to have to take this into account? Perhaps a solution is to specify procedures for edge proxies that are aware that there is a downstream privacy service to pass on the Privacy header field along with the Proxy-Require header field. Furthermore Proxy-Require is not appropriate in responses. [JRE] Yet another point. This document contains a very large number of SHOULD statements and relatively few MUST statements. As a consequence, there is very little a UA or proxy needs to do to conform to this, if it ignores all the SHOULD statements. I think this largely reflects the style of RFC 3323. However, recent thinking is to use SHOULD conservatively, and when it is used provide discussion concerning circumstances where the recommendation need not be followed. > > Thanks, > Mayumi > > > > > John > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From jeffreybobstsacko@globalcu.org Fri Mar 16 05:24:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS8fi-0007RW-SA; Fri, 16 Mar 2007 05:24:26 -0400 Received: from [59.21.245.118] (helo=globalcu.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HS8fg-0004QY-VQ; Fri, 16 Mar 2007 05:24:26 -0400 Message-ID: <3ead01c767db$3aab6bc0$4893d044@jeffreybobstsacko> Reply-To: "Oralee" From: "Oralee" To: "Romana Flores" Cc: "Teena Lawson" , "Kyung Greene" , "Julianna Mccoy" , "Babara" , "Jodie" , "Walter" , "Perla" , "Allena" , "Kathrin" , "Hui Webb" , "Kristi Hicks" Subject: Waiitng For This Date: Fri, 16 Mar 2007 14:56:08 +0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_EB4_C4D8_878C587E.69D8E159" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 0.7 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 This is a multi-part message in MIME format. ------=_NextPart_EB4_C4D8_878C587E.69D8E159 Content-Type: multipart/alternative; boundary="----=_NextPart_3DB_56C8_95BE7FD3.22250378" ------=_NextPart_3DB_56C8_95BE7FD3.22250378 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "See flow how the order silk hum artist peeps out!" exclaimed Madame D = deserve receipt grass "Be assured," replied Albert, sought "that if I had= been fake "'Ah,' instrument continued false my use father, still fro= wning, 'their"So osseous mark you were wait at the races, baron?" hurt in= quired the co grip shoe "Precisely, monsieur," replied hearing drunk Monte Cristo with = o "'There,' said La Carconte, irritate stroke jump as she story place= d a bottle "From time split given to language time Caderousse swollen d= arted on his wife k brake "If discovery I did not man challenge fear to fatigue you," said th= e gener "I admire all that leaf obey is last beautiful," meat returned the you"Ye= s, madame.""Brutal politics, bid crack amount I must tasteless confess." = said Maximilian"Well, fasten hammer then," put pursued long Madame G----w= ith considerabl balance wait "I shall jump be most slept grateful, monsieur, if you will,= "The jeweller bewildered abecedarian began eating colourful his supper, = night and the wom "Joannes noisy pig stayed for back a while gold to see = whether the sto   impulse eye "Ah, here is my mother," mark cried into the viscount. Monte "What do you think of win twist sugar noise the count?" inquired Debray;"= I am feather drab sorry light to say I cannot," replied building the baro= n; "library "Oh, homely he condition laughed, upset and in that singular = manner so pefrantically "Are you very detail anxious apologise to protest= know, countess?" asked Al tin "Are wooly swung you box ill, mother?" cried the viscount, springi "A= ll these circumstances did building not upset chop strike straight me as = pain "Caderousse shuddered. The woman's pull bit carry quit lips seemed = to grin She bump lock thanked son them both with a smile. "No," returned = decision "The knowledge name rot fought of M. Noirtier," interposed Maxim= ilian, plough handle influence "The count," repeated Eugnie, damaged as though i= t had no"To know what?"short "Oh, I have often heard mass whispers cinera= ry pig of things that se"The name of shakily the owner balance list imagi= ne of the winning horse?" "Go, then, and monsieur salt and I eventually will tail word strive our b= est "To the fearful noises that bump had sown employ awakened kick me had= su shade street "Then all became clear neck and manifest to relieved me= , and I r "I quite crept flag agree with low you," said Morcerf; nail "and the swok= en play steep "Excessively; only prepare imagine--but do tell me, viscou"= How jewel dust singular," murmured mute regularly Maximilian; "your fathe= rswept "I beg bulb your advise pardon, madame, but reason you were about = to sanguineous "Believe early me, madame, I feel attention most arrest grate= ful for yourheart dry "I stumbled over some concentrate gather object; I = stooped to examine stick "As fly I noticed arch violently the significan= t manner in which the turn dealt stick "We warm shall have the pleasure another time," said th = "Then the Countess rhythm G----has healthy returned buzz father to Paris,= has"Well, then, listen. You must know tore false nerve long I felt so in= ter"Hush," map cried wobble Valentine, mist suddenly; worry "some one is = co"Precisely; desire I was news sure flow almost of it," said Morcerf. produce "My dear Count," said Albert, "I innocent shop almost will endeav= or to "Then bottle I hang produce almost saw that they took me for th= e assassin. I "I slay army had been sip sound tracked by a customs-offi= cer, who had   nest "A match thousand jealous thanks for loudly your kindness, viscount,= " r"Sure of what?" ------=_NextPart_3DB_56C8_95BE7FD3.22250378 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"See flow how the order silk hum artist peeps out!" exclaimed Madame = D   deserve receipt grass "Be assured," replied Albert, so= ught "that if I had been     fake "'Ah,' instrum= ent continued false my use father, still frowning, 'their"So osseous mark= you were wait at the races, baron?" hurt inquired the co  &nbs= p; 
grip shoe "Precisely, monsieur," replied hearing drunk Monte Cristo with = o     "'There,' said La Carconte, irritate strok= e jump as she story placed a bottle   "From time split giv= en to language time Caderousse swollen darted on his wife k  &n= bsp;  brake "If discovery I did not man challenge fear to fatigue you," said th= e gener     

"I admire all that leaf obey is last beautiful," meat returned the yo= u"Yes, madame.""Brutal politics, bid crack amount I must tasteless confes= s." said Maximilian"Well, fasten hammer then," put pursued long Madame G-= ---with considerabl  
balance wait "I shall jump be most slept grateful, monsieur, if you will,=  "The jeweller bewildered abecedarian began eating colourful his sup= per, night and the wom "Joannes noisy pig stayed for back a while go= ld to see whether the sto    
impulse eye "Ah, here is my mother," mark cried into the viscount. Monte&= nbsp;
"What do you think of win twist sugar noise the count?" inquired Debray;"= I am feather drab sorry light to say I cannot," replied building the baro= n; "library "Oh, homely he condition laughed, upset and in that singular = manner so pefrantically "Are you very detail anxious apologise to protest= know, countess?" asked Al      
tin "Are wooly swung you box ill, mother?" cried the viscount, springi&nb= sp;"All these circumstances did building not upset chop strike straight m= e as pain  "Caderousse shuddered. The woman's pull bit carry qu= it lips seemed to        
grin She bump lock thanked son them both with a smile. "No," returned&nbs= p;   decision "The knowledge name rot fought of M. Noirtie= r," interposed Maximilian,   
plough handle influence "The count," repeated Eugnie, damaged as thou= gh it had no"To know what?"short "Oh, I have often heard mass whispers ci= nerary pig of things that se"The name of shakily the owner balance list i= magine of the winning horse?" 
"Go, then, and monsieur salt and I eventually will tail word strive our b= est "To the fearful noises that bump had sown employ awakened kick m= e had su  shade street "Then all became clear neck and manifest= to relieved me, and I r   
"I quite crept flag agree with low you," said Morcerf; nail "and the swok= en play steep "Excessively; only prepare imagine--but do tell me, viscou"= How jewel dust singular," murmured mute regularly Maximilian; "your fathe= rswept "I beg bulb your advise pardon, madame, but reason you were about = to      
sanguineous "Believe early me, madame, I feel attention most arrest grate= ful for yourheart dry "I stumbled over some concentrate gather object; I = stooped to examine  stick "As fly I noticed arch violently the = significant manner in which the     turn dealt stick "We warm shall have the pleasure another time," said th&= nbsp; 
"Then the Countess rhythm G----has healthy returned buzz father to Pa= ris, has"Well, then, listen. You must know tore false nerve long I felt s= o inter"Hush," map cried wobble Valentine, mist suddenly; worry "some one= is co"Precisely; desire I was news sure flow almost of it," said Morcerf=   produce "My dear Count," said Albert, "I innocent shop almost will endeav= or to     "Then bottle I hang produce almost saw= that they took me for the assassin. I   "I slay army had = been sip sound tracked by a customs-officer, who had   &nb= sp;      
nest "A match thousand jealous thanks for loudly your kindness, viscount,= " r"Sure of what?"         
------=_NextPart_3DB_56C8_95BE7FD3.22250378-- ------=_NextPart_EB4_C4D8_878C587E.69D8E159 Content-Type: image/gif; name="majpuyfzyqucoy.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhdQGuAaUAAP////nr5O+ysueQkN1nZ9U+PvfX18wAANpWVswzAAAA/wAAAP8AAO7u7t/f 39bQx729vbWlkjMzM5a82HKu2ESUyjZ8uCJgopCj3WyBxoSEhK+SfPfVmtG0iqx9Qp+CZ//MZsyT WGZmZqFzPuyuUeaaN3Z2dlhMWfiGA95nGJNgKfuxAPBXAXiP2O5HAQAAgICAAP//AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAdQGuAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhodJAQGI jI2OjAECAwIEBYtEl4+am5xskQYABgcHBAIIAkMGCAMGmZ2vsLFYAQYJqAEFpLSgALgHBgO2dArE xQpHxZrGyUbMskXGVM5C03oCBZIDQgQHCAQEQwOjrcK9ccvVAOl6x0voxM3wz0Pv7VDV63QB36IH k9sHChBAkGqULV4DCvBywyxaoXxEnOGTN08ixScQ8/j6xe0AKgDifhm4BWyUpVAEBqR8Y9EetYvL 4q2LGZFiS5rqcCJpCQ1d/k+dyWD6TPdOplB7ECe6rPezaU6fPy+G2Wcy2IEEoASMkpRgH8GQC0Nq YzOt7FGHL4EWpWez7VqoO4/WXPsUrtp6ZunW5Zk2idK5dqXexMm0TMgEHcFpxfYNJNbFl7R2U+nq TN65bJHK4/s0s+e+adtx9us2Kmhkbl3WXZ2Rs8XTMmNnFl0ac+jTo7uMRDgqZbdeBlpdikQJAa9+ ChEQXHP582qnqJfWbt4Zdly91bOHzl29odS9m7/XtG67fPbcrsMX9iIZ8SKwAj4mGnJtKwABlS2n Nh9YNX/1zp0HIBPY4ZYaYd95R5t0b4nH1ktK/FUeerV1h9cXI3UU0HvG/kGx0VhH0EKJfF9Q6N9z zaVYoYALNpERi7dpR9SANxnI4GwOWichjBNOl2MXyoWCQG9VCJDAckXsMmQl/oBRo3N8PelQlOlp diJ00VkJ5YqgKdijljHuRSCXVUJXJnlaDInAItycREVwmAhQ0gBLSrYQFxf+d9eeaOXJo5ikXRnm YH0mSONZfColKI4zgqndn3mhxZ5BqFSS3xT4iYPNJJKZQkqJBSrqn044GpXTl4BF+GOhDB7DnZeP RiNqdBhJuqWjNgYIaBghTXbnFCNdc8pWivgygDhIzqOsfosuq4QpCZQzBXG5EAAMVcppw82wbjrr rRekfutEsdOaMpBK/htmFVBj/Qgr7rtb2ArvEqqAOK4k31x1rGQIWBJAAh4FwEq11s5r8MFhxEcE N78iQVwA3qySyy25CAQKN9YmoNIpCHfssRa5KFdKfJcmOaQ/wMi5LUBYjSSOxqeU/PHMNCtRyyg4 e5TIN4vU588APY8TyigqYbOKzDUnrXQqx1YCcJNI9DOWkUQLYWwvBAO99NZcK6EIJbyIuMoQ3GB1 H532AVD2xQQg3fXbcBtQQAFWaSMwwIrhp6YQmsoHJ9yAx/2P1OKAY4BvOrftCygjZVLLmpI0HPjk Bo8E0lWgIKuV3ceaBDFBwEgOdq8kGrLA6aensYAQqx/RuhmvkxE7/teNB9mP4URHi8qxIaVk7xFy ShZQt6YTMbsVxxuRvPFMpB7I8h8r4pglwAgpNMEBHa53wUwQ8HSTrDAyO/RLjN98+c2Tj4f6BtMS TOe/3BcJ2l8FRHW2Udysy7GNmM+688wDIABQ97/jEXCArBvCAV+XPNStjoEIFOABi/DAATZQgQXE YAIjGEAItm6BGkSgBWM3wQqyTw4DUYVCcqGN+MQnJHIiGp3wE4VFpAxiOhMfBTcoQgV+kIc/3GEC g+hBHioviBEkYggx6DwDMlGDELQgBYmIxAoCsYdV/B8gRFGAXlTqNwLLRsXMVbonyA0c9KGhDpmH RSGK8INIXOIb/o3IwSQA0IpRjGIA5TjEK7axhyHM4gZNOEc3xrEPnQrFSITWtEgcqRVWoITWOOE/ Pfoxj8oT4iEn6Loi/tGBTrTkEz8JxUwOMpB9tOIIfQjCLQKsc2taksASgh/JRYFOtIiZ2wRRSTli 8pRuBGYvkXDHQhrTdX/coSB/yUZjYpKQmjQlINRkpK5IZhLBucThbMkEydAtJabg5iBIiMpmLlOa eLziIY1HTi06M5OiLOc7AXlJeeqRmevkg524gYrIGWFtwNIQ0ETxu0OAcopOBOIdDdhEhZ6TnfeU IiuRGU8jctKBdByhJS+6xIsWM6N5QBYuk8Cvf4xrID3LRTdI/ka5LKivoi5taRT8mYSbJSd+3fTU WA43imTJtAov5aMWTvhTJ8jtKpLYiilYkYldDK2f9uJnUcMgQS8IcKpVOKotQlI/f3DsGoi5HBqT VEasmnVZVFFMSthkv3H861Ngsdouz0pXWZh0CL4ohX2WNLTfgKSsdQ2suG7HQiEM6SQdQQXHBMtY eMEwF7zpivU0psaZMYABXMAsADQbhst6VrOXFUJoN8vZLYy2rjhUyCuFYCer0bRmpyUCZ0vLBNCO 4bShHa1uaZuF2J5VYMqhGhqvCTffkla0vE2CbW87W9ru1gvGpevXxna28L0tt6D9rGePi9vZiva4 30Wud4ew/t3wgve82EWuernr3PKSNrbpLcJnyVve+DYWYdt9Lnjzm13yfne32e1vgMW7XvRiVr8A NrB6EXxg3zKYvu+9b8cevN/+yte82G0we9Ob4fO+t74WpnCFR0xiCJdYvxI2GIVF7N/NQvjA7HUx h2GsYRPLNsQ4pu98tZvjG6+3uwVOMbxW3GPZYpi/GW4wkpVcWuMSucAO5i2Kf2zhEgv5XU+O8HOX q+MIE3i+X46vk3uM4i3nGMQkBrJ7ryyuMgu4xtw1L5Sb6+M5W5nKePYwmD/sYwYD+cXJZTPNoks5 Qgv6Y4buGp0PvbREK3rNjI60pCdN6Upb+tKYzrSmN83p/k57+tOgDrWoR03qUpv61KhOtarz0IBW N2DVsA5Dq4fQAAe8Ota41sKshdBqB/h6cq6+da4NsWsABNvXD3AA3BrwgGY7W9jDFkSwaw0BBwTA 1w5oNrRrxuxkB/vZgZv2tpd97AhUG9vIfsC4PfYACDj73c2GQLWdIAEJFKHeAMD3M4ptbH4/Qd9D wDfAvVDvgguh4AYvw6t7bW50Y/sBEVj3vQee74DbWxMNmIDGN87xjkNA4hO3+LJcfQSSRwHgFP8C yi+eb5Yr3NXtRvcikB0BZS8h4Qd3+SYcQIGe+/znQO/5BEAu8pwbveUrb3nO9Y1wVov76UQ/QtKV jnSW/gv84k2vuhFSfnQzHPsINLd5Eq6+dKzjnOkJJ/sdGkCBCljA7RaIe9wpIPe4V6DtEGDC1Ctu dXtf3ewBL3odnm7rWosbClMXuMj/3vW+TzzlXJd1rX1drGI9vOY397vjy774xat98BVw+wXkfoHR i94Co397BTCwy8+vXO1of7zO4zBth/t62upGvOYF3/TYU93ikM96119ue9tDXOxIcL3jP69139th AnG/QAVKL3e4j970Foi43nd/dLL7fuDMl4Phe1382zvg47r/fexhD3jPJ//ssxfDq5Et7/qfO9uY V4Ly3Z909uPBARmQenU3gHWnAeiXeerHff6XgMMn/n7NVn7YVmvmdnLcp3Tr136JF3+8p4Fg0GrX FgHvdnu1dnz6h3DO530YqIAcCAcOEAGoV3owGIPUZ4BRB3xE4H+Mx4C/RwcNIG8QeH4bcIC653I4 qHntR3UUt3eR14GTV3MOx3DaN3abl4FTqIJ6EAAQoAEyKIMaAII1aINFZ4JG53xVt4JuwGzuZnwR 4IVTgHNImHULWHazJ4aCVwbZ1m5OKHMQB4II2HgpSIS9d4Rr124a8IIxaAFdmHtgsHmFcH7u5mxr KIRjwIiDgIbyBm/OVn9f+C3xhoeFKHddeInJFgbCR2x4GAEbkH9nUIqVOHmPCG8Pt4nOcofwBgHm /iaK7yaL4lJ7T6iLHzN56PZtvjgPwFh8xRhsSvN0tDZtbwN1hJc0/pYEJkczzoiM04hVhgeN10gE zBhtgVCN0eiN4qgE/raN46gJCXCOsBYt6agE7bgE7EgE8WgE8ygE9QgG7ZiPffCOcMOP7/KO/lgE AUmPAJCO+WiQ/hgtBXmQC1kG+vgF93gEA0mPCjkEEWmPFYmRGQmR9tiRUnCRAtkE9wiSI7mRHFmQ HrkFCamRAJmSKzmQJqmQFSmTAYmQFpmRBhmSOOmRE3kFLZkEPWmRKMmQMWmTGHkGDwkFP4kEQdmR OdmQRdmQUNmUWpCUVRmSKMmTLimQF2mSCwmQ/kYpj/r4k145k1qZlVywkl9JlkIpj2gplkzJkEwp lV8plC/Jlm8pkljJjniZl0/JlYA5k2Fpl2DZknfZllaZBWrZl38plhtZlmHJlwTplJKZl1uZlYmp mHuJmJd5k1EZlywpkWOJmDX5kKYZBYvJmWiZkF3JmlJJkxTplKQZm5h5liq5mbbZmG4JlqJJl0eJ lUM5mcB5mpaJBamZm8VZmTfZmzxZk4Q5jzCpmpkJj7hZm7JJkY9Zmq85mFvJl9OJl9Ppk225mimZ nDL5m8sJm1NJm3/5ncQZnlZwnNYZnBLpl9pJm255nfk5nGdJlcCJnOQ5ke0Jk0apnvupm8kp/p3l qZKPqZoL6pmeKZga6Zj1iZM7SZAXCp/xOZ59maBPqZ4GepSQqZ/u2Z8PygRL2aHR+aHOCaLc+Zrk aZ4mWpxr0JP+OQU3KpxqMJIOSqMlyZveCaEYWpjjuZvgiaMNaps+aqHQeZD8SJJ0WY8reqRwkKNp SQVWWqVAiY9YOgc2yqU4qo5OkKVXGaZxQKaaaaZiuqZs2qZu+qZwGqdyOqd0Wqd2eqd4mqd6uqd8 Gj0G4Gxz1adjUHmVN4zvYgAc0AGKuqgcYACGKqizEAAcMKmU2qiP6iwGoKhruKmaqoiQagaSWqmi ygHIRzOJuqmcqqlsCGzKCDehOqqV2gGl/uoxBhABHvABqbioqJiKa/gASUOohMoB9jess1ozrwqr lAoCHZA0EBACH6ABvLqGz5qra1is7cMBMgOBfNgEItCt3ioE3UoFIpAF4UoGHAAC6Jqu6CqqIBAC 1gqu4zoF5QoA8foHLRgCQZhtHRACI6AByfYA+7qtUhhyWyeIgoCtwFosBjCs9UeI70oE8xqu8woF E7sHkkoCGJux6qquJZB3SVCx8lqvfvAAIVCyHfBqD/ABH/BxAbCvJRsB21eHN2iGf4CslNoBJqAB GmACJiACJ/CzPwuzTBCx4yqx9eqt8Wq09PqtS1uuSLu0TQu1UKu08AqyNQQCGZu1Wouu/iUQhUdg tU9LtFPLtE+bByRbsiHwcT2Ifi77sjHbfWkHeN9nhDv4Bg2wsXhbAia4txpQg2L7rVRrtEU7uPBa uEQ7uIQruGNbuFUQAFr7uFmLAl5rBCDrtEy7uFJ7tCJbByTrAZ4bAr7qas3qASHguUJbgp03hnL7 h0hXt21wt3jLsRIAtLQLtH07tJqbuYSLuYGbtLuru4a7u71rBY4LuZCbApNbBJXru7zLvENQtnfQ giPguR7Ah5Jaup47AipwuqgLfn73huAbvkuoBh1AArHLtbWbvpKIBEhrucEbtsxrufD7vM6rtO7b vpsbBQ5AAiXQv/5bAhjrv/yLvCC3/rzz675Si7lr1wEj0MANHAJryK8OrAIf4Ksx239WOLdwOwck a7wkEALpS7sa8LD0S7nxu7n367wlzLgpDLxWOwUN0AH/O8P/mwIj4LHsm78VO7zAm8B3kLIq0MAq MMREXMQb8IULWIQbHL60Z4uoiqobwLNSPMX++oXLG7xY3LxZ3MP2e8KMWwUPQMM0jAIpMMJKcMW6 m7tcnL88CAHaW8RwrAL++m8ZCL45qMFyQAvtxrDy9sSbeolWrMP1S7aDXLUqjMBdzMKXWwUNEAFi 7L9kvLJEh7/0e7grnMYvzMEfEMdFLALJW4KAaHAajMfjmwYJS6iYCG+XuiwOsAEo/iDGKZAAkvyr 7bYBmxzHH9BwlPODttY1rTwCKRDMwjzEqkgztOjEG5DMvepslAOOq4xWEPcBE4yr5hao4lJ5hSeC DVB5n1oGCrvHoqgI2PqrxfLM3Rypp1x54nTOl5bOCcvOn+bOwArP9FzPY2rPZICmnQCS++mOI4qf QRoGxLkH+hwI/FykQJmdBPqkXtkFA32lJ4rQFfqWrXmfY6Ch8dnQ/ZzQFg2XQirQSqqXET3SdomZ 3OmivgnSNLqh+amcSfmSOsmanxnTH62bkRnSZbrSOi2bDF2aQFrQSknSOmrSGYrQCJrSKF2WUbqT hzmjEO2gAy3TT4rUSE2gJIqe/stpnRitps1Z1Atq01VtoVvKpCVtpAr6BPIZ1Vz5z+lJlPfZnlj9 m+/pBWndnaJplimN1RptmJUZnTMK1HPZ0mdtnw0ak0vd0GZJlm/t1CIN1XaNnQwdmxKq1JQJnfX5 13RdnS/to0Tdmh4tnAjq11ot1Fw9n5u90KZp1SLqnJWN1/w52mit2Y+NoVkdmG4N2pYp2nOd2Z1p lStqn+iZnaBJn/Pp0bv91ABqmHPppJ692rjN2q/90I2douX523LZ1tuZ14ndo1l93A6dpMUtoP8s 1rVN0xN6ojdd3LfZ29U90a651NgNmMRdorBNpjyqpOJdmBJalx8t2OftoVR6/qZbepIf2Qb3Hd5x +da82d+EWdMVGuBi8KUEjpp/ANhdWtoEPeC8XeBauqMXbqcWjuH3jM8kXuImfuIonuIqvuIs3uIu /uIwHuMy7giH91OOiwI4jgIkYM0Hg6iiCknhRn5PSDkBAAIlsAJInuQrAAI8/i6JuqhQ3gGN2uTv 0mupnIvmjFYkgAJK3uU7vjQAu69RHgJQPs7J2G1XHoJZPg9bjuQ5nuNuTgJrzgkxLOZR3rZQHqjC F3lk+AcjiIup3LBzDgsc8OZcnuSGvqw14wAue+doa7JiXoN9LnU0uwc92HGYznE+SMcyCwtbbuig juMl8K6Xu8hnLMg+/MOP/r7qrP6yUcd1aIfHWqcHzDYBGHDruI7rmT4BFtwEexcLAZACLCDMxJ4C OG7sON7rJqy5RSuubKzqpbvqpMvqs4y6BVtxqrvEpWy3EJDr3q7rHIcBOOzrFQiHFTjrkz4HHCDs LDDsxf7u4668gFvqhEy1i3u4z84Grdzq0v6s89aHBNt8rMsHPfjtud4CBr++oMx0nqeA7ue66t7u Ej/xFN/uiv61847Iv5vCwnvJcQABHzDtj+65KpuvSBx/F8jErPjD394CCO/yCI/rCK/s5K5zgTh8 5r7tbsABFd/zEn/xJkyvQq/xCUz0Ewu9TSzNDtzAuOpuugjrGWywbhi9/hCQATB/9Vjv8hlQzNsH fxZ4hPt3hSngAj7PAmTf7ikQ7xDb7MLbvkVfyH+b72wAcclc95H4AFQ+yqur7ZV+hhCXAVaf9TAP +AJLb1b49XzPeaxWAmdv9i7w+I8v8S7gAWpfwvP+xV9s9IU8Bz4urBCArHhvzXtudqIM9lOPB8wW ARoA+Kzf+oRPwtee7YgvvoePBzwP+bif+y6wAaSOuGv89u/7+5zfbMFR/MZ//FQ+chCns8zf/Abo qYYfhjefgKXfgHYQArqv+5RfwEmb+YR8yYlsyHKvBvL8ztxGf06MqqLYy76M/dn/+NUL+1WeJKe8 NSOYbOkWgg/H/lzT/oJjn/tAkPpAHADjEZlULplN5xMalU6pVesVe21suV2vNxsWj8MNyCbkUW8i kAYZHpfP6XW78btN5u99vzMg4OEBonAw4C9RcZGx0fEREiBwkrIy8hIzU3OTM6zy07JTdJS01PQU tTQhlbUVctWVM2H2CbaW9mjWFkmXF/cONrh1NxaVuFjK9pgXatXZiPYX2jmYOlHYrtdpWUl7etkb ILwOm1tsvDsqHF1cml2unIq4+hdbPOm5e966vR/fv52ye8zqQTNILte2ZveqAZzmL5o5eAcnUlwi 0WC+iPj4bfxjT92/gQPt7ZP20BdEfikZJnSIMt7Iii51CRw5T2au/n0qXzJUVhBnQZJzcAa0aTMh uJ24PBL8KTDoUYsLmd2kmI+ju2Mem7r0qQ0czYMYsRSVatXXyZdcV+rMSHNrTJBkzIpFq1Nt3npt YaLVOxbwlLqBW168qZRn3qTpGA91TFTk2cJZd/1lytdqzblXA5OtMvgx1rSV4wKs2ZgaWMOdp1K9 CzKsxqVYu/aVzFIuwqqSRRN0qy/x1sUiieeeSbhkzuE9+51U/JZ4Vcebm7mz2/ob3svZ8Rrei9Sp Xc9XkN6OTXJ2cOCTqTNlDZkzYeUtG6Zk29P97d/G/Zgbb+W/6BxZ57r5AtKuvnXU8qk77FaKiSjr 5OPGG81g0iq2/qe8Cu+9PgKM48MNWfEvm7JcIVE3AJFZ8ZIQ6TJxxEdcNJDFGm28EcccddyRxx59 /BHIIIUcksgijTwSySSVXJLJJp18EsoopZySyiqtfISSK7XckhQOSCgBzBJIAIEDRLg88w4u0ESC gzDdDJOEMtecs4w83jjTgDfDRAFMPsXkQAoJBJXgCEGZMBQARKEYFFFGFaUzlS0cmJRSSu/U8ss+ 9USBUzjNbKJRQp94NApFTRXVETtVVXPOBip9ddIHuCyBzxRS6JPPTm/tEwInSDUi1FCBRZVRJX4d NtUuYF3W0ktHPfZQVJFd0VVmKX2giCdE2HbbIxsowdYUUAiX/lxxObU1Al+lLZRQYtsVVdhE1y02 CWj7qNbafB1wFlR7jV23Rkn1JYTfJLo14uAiOwj3XIYbTkEFDWTtd4lTDY130H4zZrcRgfVlFttF 3+U4Y2HjlddkgDFxdZCWB3mVkGyZSBgJbkU4oltuAUjY5lYc8CCBcsOdRYWIiSgYiWNTlndalFUe 9tSOK8XWgZcthXWLQURmGmqUmS55ZK4vHruTBggpBG20CRkkgoln1hnnm3eWW+e6b5Z77lYeGEEz oiNue9+t/xU7bFI3jpZjRvC99lqqQXab4qgJnxzjwp+GpOq0z0a77Qfa1rbnvEU/mHS8Q2flAQ2K LvoDDSDA/hZpiimH1/JpDXc38UUW/xjW17eWfOmvaS/2ZE0yTxt5tCWOoufSEaYb+udFTyUQA1we xIBJqqCXcLCb5j5p8P2to2rel/Uc8oodpd322oufnBMH1DZEbbaXlyLn6EeP3nnqQfk/EFYym9XM V7UIRCB2uascsry3wPetLHkR1MAGZLYEnt1Nf/3Ln/T8B0BQJLBJ8oPAAUlYQhOSkA3pU1/iHFg7 qLGPa5swQwTTtgHXgXBucMuh6TIIPR1CikXHo2EEYbcmEdJwAyagIBCZiIdVqWpOnmtD2iKgARPc r4lZ1OITUqcBL3rRBCIwQa+2WEYzHoFlVfyiBtrwABye/hGOXIJZy671xjjecUpPFBgescPHKOlR UnYk0jtExAQFKYU0MxKMfPxoB0CyykngaUwTntEQ53QEM7pRZCM26aNH6iGSkalQfJbDErdsRzHf KSWDOkQHQvYxK2m5CIb6w0hVCAk0EDJJaWL5kL+wByW4aeVMJEKWSvoyPc1x0YeoQ5cFSWcbtDTk ToBhS0pG5jq9+QZpgPMd4WTkNPM5SzPPIUqhSFKba8EkfkwDlH+cE5ZhkKSAvIMe5hzyGvEUUHIy Y8jDzFKdqFFOWN7TSX/uRjwiCqcpkdlQjkDHng+djj7JY07evBOg74SKcFQJUXAmdJGkhE0963PK df6S/jYOMo5BV5NNziCSmw9F5Te/4h6BThQ+Lg0NZdbDIVYK8yi85E8yJPQYA1UonJdJpHc05CDT WHMMuXypP38C0JkKlKbSGSocpNpPfWiFMZfEalJbutUUTfI48ohEeQp0npI29KoSTak4V+pKbCLn qP/8ai/6VpyBlnWYdh0QjF5R1JHO8inbOVCDNMrYDIE0p2yViVuDWVmxytUvGTVrI0t0UMGqqLCV aes0E/vWy/p0lOmAJ404CyIZETZGns3pZ1pb2xa9tqK21e1uedtb3/4WuMEV7nCJW1zjHhe5yVXu cpnbXOc+F7rRle50qVtd614Xu9nV7napywDvevdI/t9lgBLEe4TvLmG83CWSeM8bi/RWgb3vBQB7 zTtf8NZXvUO6rxHaiwX5/mG/U9jvgO8LXgMPOL/r/W+Ay2te+RI4wElgcHoP/F8k0NfBEb7wewns YPval8MJ1q+GM9zfDoO4weR9MIXjywQMx9fC/GUxh2n84QeLWMH9lbGHd9zjE6t4wz3+sItXnGEi m7jIIMYvjnMcYyEXmMVBRm+RkdyEHwt5wzqeMHpl7GQm7wjJGB4ylFsMZB5vmcg8VrORh9xmDSOY xF9mUYShvOb5utnLUvZxkqds5zfX+MkLDnKc5YwMLUcZy0pmc5v13F5He3nCgJbwjM/M4EkzutA2 /oJxiXWsaE47GcYzTrGKITzqT0+60wseb54zXQwxdxnTJDY1qlcd5U7TOst5nrWpY3zrVpuR0L8W tp2HXWxiGxvZyVb2spndbGc/G9rRlva0qV1ta18b27oN9ba53W1vfxvc4Rb3uMldbnOfG93pVne6 eRTsbCs4R6x+t5HcfYp6zzu8K5I3vpN0707sm9/9boW/A44kgGPi4AXvd8IfwXA8Ehy+S/ZDmceM aDlAPA4OXwTDF9Dxjs9hAVEIOQBGroSSP+HkKF9CyrMQ5xtHnL+KOHGdMU0GjMNB44lw+MlZHoae m1zlIF85znstaSmEWOZG3zMdbo5zUuw8CSX3/vjQP36EqZO86kjIOsmNIHWpW90JI/961z9+daub /etbN7uHS43iHV85xAjuMtI9TWNVV3rpNlZ1pGvs8jD33eE5F0XKxQ72qBee611XfNQXn3jEPz7o Y0871Q2P9cWP3cg/hnDFL1xfMs8d1op+9N3zTvPzzhzRB/a0lGn+9psL3g4aJ3zjWS55w9ce6I5n /M+1TvvG//72ife98FPees1bvPMxd32tl693Jd+a4qZPPaClz3kzt976MNdEzmdP/Nzr/vLfD77w yc778RO/6j0vPM9v7/HiW/z4iVb+nd9+5zqv2vn4h37RSw//F9MX+/CO0QLw6DiB+xjP+xAQ/vwW sPLGr/vMbwFxT/0Uj/3CL83wTM0IkP42sLwarANPDwT3r8+sz/gsjM6QL/mwTwOhAPbm4AArD/Ng cPhwLwEhjwGHrgbBbgKBL/2GTwAxENZMT+KeL9LqrsJYj/9I0P/6T++ob/oGrela8OKwwP0Ib+tk sPzOzuQq0Otk8Oe8Luuu7gotj/y4Tu3GUAWdEAjpLtAaTdLQTNaeMPvcrsTY7g2rDAqvQAozzki+ MA667w6aDoii0AD7EAfJgAYDcQ+vROkKcBMWEbgEcU1mzRG3T+EgBRLHIBMvUb8KkRMn0RM/8Uw2 MQz2DQJFTvwQsQ7GEA5OcRFi0EZcUQFt/i4U/SARW5EOZJEKOQEWa0QXG1ATa7EJ1u8LzxD9dE/s zhAMgU4Ze68MsS4ZKxD9MG/9do/9otEHsTELKXDlerAZKdAPw9DxvnEbDy/ttBEadVABtbEXyUsY mSAZgS8HyTAe6fH8Qg4WezAB03EdefAeZ7D2EM8eudH3Ju/yeK8LI5DsFvLwDnIG/9EZx9ECa5AG BRIfgdEd/w0KLDLsHnIibS8ivy8R/XAi1dEjbzAbsfAiL7IMQRIeVfIeRzIlnxEhIZIa5dEMYfIU SVEM5I0jt1AfFXIaw5AoZbL82nEee+8mkzIilxIZc3IbqxAnsXAcxVAL+3Eol/HsAtIq/j/S/XAS 7b4SKq3s6SIPI13yJ5HSH5tyJkVyGPcxLQ/RKauRJZUyFbESJROSLffxEIHRKHtxBwXSJMmyLN+S Lx0yKX9SIfPRBsVRLsFyL11S6xRzLhlyLAXTLT+S9gJSMzszH20SJnOPMp+AJ53OMNux7LYSDAVz 7cJSAnmuLhHSMWeRH48SMtVuMqURNrXyMAdyGmHwNRuwNckxN1WSN3ewKkMyI01BEpHkF0nhOa8g Ol3B/ErTBc9kOgfvD7IzFXivORnBOkVx4FwtPMXT3vTNPA2uPPvgO9OTFdZT5+DTPR2hPf/t1eZz 4O7zR9aNP/vTP/8TQANUQAcU3fBz/k7k00CbCEETdBAZlLkW1EEPNEKVC0IndBQtFLkqFEO1REM3 1Eo61EOpBERDVEpGlEShxERP1ElSVEWZhEVbVEleFEYNbkZ9S0ZrtEhuFEc7EU2ux0d/FEiDVEiH lEiL1EiPFEmTVEmXlEmb1EmZlAGeVEqR9BKm1EqvFEuzVEu3lEu7dBCi1EuxtEof4AXK1EzPFE3T VE3XlE3b1E3fFE7jVE7nlE7r1E7vFE/zdE0ZQE/7dE7HFE3XSFA1wE8L1VAPFVETVVEXtU75lFER FVDPVAOYAAII9VEvFVMzVVM31U8dlVPxNFLNdFKXoFcs9VNPFVVTVVUN1VNXNU5D/rVMRxUAFEAB VPNOjcBVXxUAXgBX/bRXczVVf/VQWzVRhVVPYbVMaVUBeLVWjwACFqBMe1Vad1VNqfVRjfVPdxVX sfVWrVVRk8BMudVQuRVcedVbWbVbj4BNt/Vc7RRZYSAGlNVcnRVazTVaqVVcxXVc27VO2bVQ9dVX 8ZVfv5Vfp9VeE5VYdTVcBxZg6RRW4bVZX2BZkeBZ79ViDxYJLjZj51Vg1VVd79VYN3ZjF/Zj7dVf y5VjSdZaURZkBZZXW3Zgz/RX/TVla1ZkXbZcR1ZjtXVkb/ZlwbVkY05lMdZbZ5ZnP/Zke7Zk1zRU IVZZaZVjK9ZiadZgaXZniXZq/l12Ybf2YHeWZ032a8E2a8e2a7E2Yw3WTY1WbLn2aqsWZwv2bS92 a89Wa4U1vcoWbeWWar92b7F2XSNhEMoUBiBAYjk2CaTWcJEWaMO2bev2aJdWbfG2Y8W2b5Ugcf22 cblWWHVWbdk1b802btcWTXPWcT12ZR33Xu82ZJe2ayuXb99WZ9M0UmEABiRWAQqhcCm2XucVZOWW bDMXdJn2dH13Wl93ba3WdzE3eK82bYe3eBl3eV23Ws/VbX8Xbf1VdamXdTs3bqUXTmdXAaD1aQ0X cTF3dSWXbKt3ejW3aCc3aZeXbTNXfZVXeJn3d6M3bJE3fvG3dVEXV7NXdtuV/nvH1nvn9nUhIXCT 9QXcT1bpVWa1FmaJ9nmZ93m1t2MteID71nAjeIMnWHJZd3qD9nGHtmY7uHRHV3u91mqvV2DvtoTJ 1WcpN38v2Hg99xESOFkbWAnKF1jdNWZ7eH+BGFgT9oGBGFl1+HB3V4gd9oeBNXaXOFeJOIhV9YiH qBCUGIqzWIu3mE6lOIuRtQrDuOO4mIzL2IzR1IuhGFnPmI3b2I3LNI2XeEzDlI7r2I7vGI/pGEzz mEnHdFD/GJABuYsCmZAL2ZAPGZEHdZATmZEb2ZEfGZIjWZK9iAEm2ZIZ2Y93tBTXZBAmlY8/GZRD WZTveI9HuUgz2ZRTWZVX/pmVg7SUW9lHURmWZ5mWa1mPbfl6ZBmXd5mXe/lIX9mWddmXh5mYhxmY a1mYiXQBunSZi9mZf7SZvTSarfSYaTmZW6YKH2CZp3lJs9lHt7mbsVmbudSbmxScs7SchZSbk5Sb 13mcsbSaZ/maB8Gd3RlJ7fmd8/mexZmZ0ZmcjxSfi7SdoTlL4xmW51mfx7mZPU5J19n9FLrj2Fmc Fzqi3zmaA5qgr4eh85miF1qhtbmiNxqkMRpIp1mkN7qjJdplUhqiK9pJDZqVMaGTAaCkHxqcL5qd UXqiExqgLZqjfZqec1qkgxqni9qjcZqonRSpPzqpSbqms7mof/qlfRmh/gd6mx96n1d6p52aoI/a ppmaq/l5pXXao5ParEc6ol26ocX6nD9arXtaq6FaqpsUpmMacFOHpjN6q81Zo/c6nI+6r885rINa qwlbsHf6rOt5sNkasZkapFW6sRP7Set6le8ar0s6sOfaSAe6qflasjl6sRN6qUf7p0lbrLO6tCN7 sa3ar3k6SSlblas6s0e6obH6qx97rQ3bpS86tB36pMe6rC2apYcatWmbnkPauItbuL36rZcUtlMZ oZ9Zuqdbuae6l6s6nZU6u580jO+4u035u5lZjDGbmqn6rj2ZutNbvfn4uU05utcbvuN7Stt7lN9b vu8bv3/ZvBH4svPb/r//W7+v+7zzGsAL3MCvh75F2b4PnMHhO8FDOZMvWcInnMIr3MIvHMMvvJIz vMIzWZP9i5P7O5Q5nMRL3MRPHMM33JEJ/I4XPEw1QIxjXMZnnMZr3MZvHMdzXMd3nMd73McXgAF4 XFb42MW9FMY58b16msXtuMi79MiPIJCrLcmjAMaHHEkl5kmbnEuf3AiQGAAqldqmnEirfMnHPLRz ecBHmcsBwMtLddrEfEjJPEkn9cxbpsk5+0nXXFZp1TajDc6FVM6N9Iu+vM5ViBFm+pvrua+ldM1t d2KbldBpMwvUUg7qchdd9AisHNCXucx/1Iuc9Yo1mrhjOc1FXa8J/jvPS+4FnHZi6ZU2KT0z72Al xYA7ceTPgzTQAd0IkqfKUZ1Ikzm4bZuhBXu3Q/qtn3zV4xVXWz3SlRPW8bIPLF06cyQADMAABEAA BsAAogDOx7uTOT3Ov7xSXacQet21Rx3YDbuxrxrV29q1U2fkWF1eXT03sXHqxJL8QLIan/IGxXLW 8d01VRMoCRLfE6Harz3bB4AAFh4BGv4AHh7iB4DbM53A0znXgZTc3a9STfqbT9vQFwHRCzvYU/u4 h523PT3kBjd3SRUQYzM0PXLfY34tc3LWCfIyD/McfVAOrJ0AGt7nCwDig17oh/4ACqAAfB7pk/7W ifvifXRSnxWb/s1dt9uam4W5u6P6s039uK/nyGnXdnGX2Z+1HyszM/+d5s9e2iev5s3wK6XyM23+ 2a+A53/e6Ine7oM+6fPe52+dp5ue66Eemx06rj3e6gdfsk3b17m568PX0Zm92b2QKpGTLtGe8lue 8m1+5i3fKQ3e2rF9ABS+5xse6IVe4lmQ4s1c0z0d8H29sB276ks98Uu+o90dpY19nZ+8Vhk4icc+ 8n+P7OHy5c3eIG9e3wcz7hnh4D1/26kg9TEe3HF99YdU2NdZy7eUyxXAy3fd8ukRH9GOKoG/LaNx 8iWvKAX+N/N97XKk+VF+/V3GiwodSO07vK9Uz614Os3v+Kug/tZXsUfan+ufHwgewuFwoVkQk8ql EuB8QqPSKbUKEGquzC23yzxCF+IxWWytLqxp5/rslrbf8nl0TL/j89SHlnvke415DQrpGUZh9REu LoIdPkJGSk5SVlY9aGRqbhplIikyhiZZ0iWKnvrFka6ytrq+opXJkgGi2sJeYoLa2mrw/gIHCw8T FxPvGjfhTpkmLy5DR0tPVzpzUTthbW5zd3t/g4eLj5OXm5+jp4MDqLe7v8OnY2vN19vf4+frU2rH +/8DDChwIMGCBgHuS6hwIcOGDh9CjChxIsWKFi9izKhxI8eOHj+CDClyJMmSJk+iTKlyJcuWLl/C jClzJs2aMDZv4sypcyfPnj5/Ag0qdCjRokaPIk2qdCnTpk6fQo0qdSrVqlavYs2qdSvXrm+CAAA7 ------=_NextPart_EB4_C4D8_878C587E.69D8E159-- From sip-bounces@ietf.org Fri Mar 16 06:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS9MV-0003zE-PH; Fri, 16 Mar 2007 06:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS9MV-0003z4-8A for sip@ietf.org; Fri, 16 Mar 2007 06:08:39 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS9MT-0000nN-RJ for sip@ietf.org; Fri, 16 Mar 2007 06:08:39 -0400 Received: (qmail 30245 invoked by uid 0); 16 Mar 2007 10:09:47 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Mar 2007 10:09:47 -0000 Message-ID: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Fri, 16 Mar 2007 11:07:56 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Sip] ambiguity regarding lifetime of temp-GRUU X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1962568390==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1962568390== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C767BB.59F65690" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C767BB.59F65690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In gruu-12 section 4.2 it is stated: "The temporary GRUU will be valid for the duration of the registration" There may be ambiguity in interpretation, as a registration refresh can be considered to extend the duration of the registration. Propose to change the text to reflect that a temporary GRUU will be valid for the expiration time provided in the REGISTER 200-OK response (either as an 'expires' parameter on the same Contact header, or an Expires header) Consequently, a UA cannot construct a temporary GRUU by itself, there are no "self-made temporary GRUUs". This should be made explicit in section 4.3 Regards, Jeroen ------=_NextPart_000_001B_01C767BB.59F65690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In gruu-12 section 4.2 it is stated: = "The temporary=20 GRUU will be valid for the duration of the registration"
 
There may be ambiguity = in interpretation, as a=20 registration refresh can be considered to extend the duration of the=20 registration.
 
Propose to change the text to reflect = that a=20 temporary GRUU will be valid for the expiration time provided in the = REGISTER=20 200-OK response (either as an 'expires' parameter on the same Contact = header, or=20 an Expires header)
 
Consequently, a UA cannot construct a = temporary=20 GRUU by itself, there are no "self-made temporary GRUUs". This should be = made=20 explicit in section 4.3
 
Regards,
Jeroen
------=_NextPart_000_001B_01C767BB.59F65690-- --===============1962568390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1962568390==-- From sip-bounces@ietf.org Fri Mar 16 06:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSA3F-0000Ku-Dl; Fri, 16 Mar 2007 06:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSA3D-0000Kp-Oz for sip@ietf.org; Fri, 16 Mar 2007 06:52:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSA3C-0005fF-F1 for sip@ietf.org; Fri, 16 Mar 2007 06:52:47 -0400 Received: from [144.254.34.230] (dhcp-144-254-34-230.cisco.com [144.254.34.230]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2G9wUQw021153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2007 03:58:31 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 16 Mar 2007 05:52:21 -0500 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , Keith Drage Subject: [Sip] Current status of WG slides posted for review with IETF 68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There are some status slides posted at: http://www.softarmor.com/sipwg/meets/ietf68/slides/index.html Please check them out and make sure they look reasonable to you. We won't have a lot of time to discuss them in Prague. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 08:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBMf-0000C0-2x; Fri, 16 Mar 2007 08:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBMd-0000Bk-SR for sip@ietf.org; Fri, 16 Mar 2007 08:16:55 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSBMc-0005Si-Gd for sip@ietf.org; Fri, 16 Mar 2007 08:16:55 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l2GCG9vb026473 for ; Fri, 16 Mar 2007 07:16:32 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 07:16:16 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 13:16:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 13:16:12 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E9788A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP WG presentations Thread-Index: Acdnw4nA8e4QCVx8T9Cz38cHCPbVZQ== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 16 Mar 2007 12:16:12.0873 (UTC) FILETIME=[E3570390:01C767C4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] SIP WG presentations X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) If you have an agenda slot at Prague in the SIP WG, please make sure you get your presentation to the SIP WG chairs at least 24 hours before presentation. And while we will attempt to manage revisions, if you produce your revision even 20 minutes before the start of the session, it is not going to happen!!! - and a bit of warning would probably help as well. There are at least a couple of agenda slots where Dean and I want to go through the slides with the author before presentation to make sure we have covered the right issues. I will be contacting you directly on this. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 10:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSD7p-0001E0-SC; Fri, 16 Mar 2007 10:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSD7n-00019t-NH for sip@ietf.org; Fri, 16 Mar 2007 10:09:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSD7m-0003j7-EU for sip@ietf.org; Fri, 16 Mar 2007 10:09:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2007 10:09:43 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2GE9g3Y027674; Fri, 16 Mar 2007 10:09:42 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2GE9blO010912; Fri, 16 Mar 2007 14:09:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 10:09:26 -0400 Received: from [10.86.242.243] ([10.86.242.243]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 10:09:26 -0400 Message-ID: <45FAA515.8070404@cisco.com> Date: Fri, 16 Mar 2007 10:09:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] ambiguity regarding lifetime of temp-GRUU References: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> In-Reply-To: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2007 14:09:26.0471 (UTC) FILETIME=[B4A3CD70:01C767D4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1310; t=1174054182; x=1174918182; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20ambiguity=20regarding=20lifetime=20of=20temp- GRUU |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=uOJrkIzKzjQzie0h1o4K83+yjJmyaSxvSQDhelfym3c=; b=OBPxfAvttldmzeLaxEpuGMloNpFWqAH9h4ODDqFkqmmLiZg73BTCFF69Qu+AYFSbay05IkeA wSOeZQFx7+0Rgx8JCa4OkGrKZe+KL6Nu/sLPcNrTqlmHVdRSBqaDFsK6; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > In gruu-12 section 4.2 it is stated: "The temporary GRUU will be valid > for the duration of the registration" > > There may be ambiguity in interpretation, as a registration refresh can > be considered to extend the duration of the registration. > > Propose to change the text to reflect that a temporary GRUU will be > valid for the expiration time provided in the REGISTER 200-OK response > (either as an 'expires' parameter on the same Contact header, or an > Expires header) The intent is that the temp gruu will remain valid for as long as the registration continues to be refreshed. I don't think that is what you are implying in your proposal above. > Consequently, a UA cannot construct a temporary GRUU by itself, there > are no "self-made temporary GRUUs". This should be made explicit in > section 4.3 > > Regards, > Jeroen > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 10:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDWm-0002CC-Rg; Fri, 16 Mar 2007 10:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDWl-0002Bt-D0 for sip@ietf.org; Fri, 16 Mar 2007 10:35:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDWf-0006dF-RY for sip@ietf.org; Fri, 16 Mar 2007 10:35:31 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4071620E35; Fri, 16 Mar 2007 15:35:21 +0100 (CET) X-AuditID: c1b4fb3c-aa4eebb0000073d5-76-45faab29f548 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2CEA520B0C; Fri, 16 Mar 2007 15:35:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 15:35:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 15:35:19 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702B41261@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-08: usage of keep-xxx parameter Thread-Index: AcdnRYIgRy+uYzIRSIOj7NpsfrCxAgAkjuQA From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 16 Mar 2007 14:35:21.0080 (UTC) FILETIME=[53424F80:01C767D8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] RE: Outbound-08: usage of keep-xxx parameter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >This is so that the administrative domain that runs the=20 >server can pick what type of keep alive it wants to use (even=20 >though they are all supported). I think this is all too much=20 >complexity but it seemed that some people wanted this so=20 >that's what we wrote up. I don't remember any recent discussion regarding this, but I may of course have missed it. But, if we can have multiple keep-alive mechanisms for a single transport protocol I guess it's ok to have that possibility. BUT, I still think that it should also be possible to only include the 'ob' URI parameter, and let the UA choose whatever outbound keep-alive mechanism he wants, and that we should describe that. Also, when discussing outbound with Rohan in San Diego I believe we agreed some text saying that the edge proxy can also insert the keep-xxx parameters in the Path header. But, I don't find any text regarding that. Regards, Christer >=20 > Cullen >=20 > On Mar 14, 2007, at 2:25 PM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > > > Hi, > > > > If all outbound compliant edge proxies MUST implement all=20 > keep- alive=20 > > mechanisms, why do we need to list the different keep-alive=20 > mechanisms=20 > > (keep-stun, keep-crlf etc) in the outbound-proxy-set URIs? Isn't it=20 > > enough to simply include the 'ob' URI parameter? > > > > If all oubound compliant edge proxies MUST implement all keep-alive=20 > > mechanisms, do we need to keep-xxx parameters in the first place? > > > > Regards, > > > > Christer > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 10:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDgP-0003Iq-Pi; Fri, 16 Mar 2007 10:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDgN-0003DS-HN for sip@ietf.org; Fri, 16 Mar 2007 10:45:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDgK-00081F-2A for sip@ietf.org; Fri, 16 Mar 2007 10:45:27 -0400 Received: from [144.254.34.230] (dhcp-144-254-34-230.cisco.com [144.254.34.230]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2GDpScJ022808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2007 07:51:29 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 16 Mar 2007 09:45:18 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: SIP IETF Subject: [Sip] notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I did a full read through, not counting the examples that I never get right anyhow. general note: Keith tells me the standard is to write '200 (OK) response' instead of '200 "Ok" response'. Specific points of consideration: abstract: > "This document providing clarifications" The above doesn't parse. Maybe "This document clarifies" or "attempts to clarify", depending on what you believe about declaring victory. Section 3 paragraph 3 says: > "Contrary to what many believe erroneously, the last-hop exception > was not created to allow for using a SIPS URI to address a UAS that > does not support TLS : the last-hop exception was an attempt to > allow for incoming requests TLS when a SIPS URI is used, and it > does not apply to outgoing requests. Given that the last-hop-exception was to a great extent my fault, I have to say that the specific use case I argued for was so that I could advertise a SIPS: URI that would be terminated on a record- routing proxy at my desk and translate to a SIP: URI that would end up on an experimental 3Com SIP phone that did not support SIPS:. I might have been wrong, but that's what I wanted to do. And given the fundamental design flaw of SIPS: (you can't tell when somebody's cheating), it works just fine if the proxy is smart enough to "upgrade" outbound requests. Next paragraph says: > It is therefore RECOMMENDED that implementations do not use the > last hop exception rule and use TLS all the way up to the remote > target." Since we've already said that outbound provides a superior solution, why don't we just say something like "Note: outbound [xxxx] provides a solution that works better than the last hop exception. Use it when possible." Next para includes: > "The SIPS scheme implies transitive trust. Obviously, there is > nothing that prevents a proxy to cheat" Classic SIP error. We have our To: and From: reversed. Perhaps "from cheating" instead of "to cheat". First para of section 3.1. Scope of SIPS says: > "SIPS means that the SIP resource designated by the target SIPS URI > be contacted securily, using TLS, on each SIP hop (last-hop > exception nothwistanding)." This doesn't quite pass my in-head English parser. Perhaps: SIPS means that the SIP resource designated by the target SIPS URI is to be contacted securely, using TLS on each hop between the UAC and the proxy responsible for the request URI, and using TLS between the proxy responsible for the request URI and the UAS if possible. Just before Section 4, we have ' > "Some proxies may have local policies that enforces TLS on all" There's a pluralization mismatch in there. Perhaps "local policy that enforces" or "local policies that enforce". The last para in "Section 4: Routing" before 4.1 says" " o Reject the call with a 403 "Forbidden"." I'm not sure I believe that. It seems much more like a 404 case. Since there's no sips: URI available, the contact was not found. If we use 403, then we need to give a reason phrase that might help the caller figure out what went wrong. Section 5 Registration, Para 2 says: > "The USC registers either a SIPS or a SIP AOR" We probably mean UAC instead of USC in the preceding. On the other hand, you can never tell about those guys at the University of Southern California. Maybe they speak SIP now. The following 3rd paragraph says: > "Those are mechanical rules with no influence on routing." The "Those" should perhaps be "These". The 6th or so paragraph of section 5 says: > "A registrar MUST only accept a binding to a SIPS Contact if all > the appropriate URIs are of the SIPS scheme: i.e., the Request-URI, > the AOR (i.e., To header), the From header, the Contacts and all > the Path headers. If the URIs are not of the proper SIPS scheme, > it must reject the REGISTER with a 403 "Forbidden"." The MUST here needs some backing. Where does the authority for it come from? The same caveat applies to the last statement of Section 5: > "However, a registrar MUST record the scheme of the Contact." Why? Is that in an RFC somewhere explicitly or implicitly? What happens if it doesn't? A similar question applies to the first para in "Section 6; SIPS in a Dialog": > "There MUST be only one Contact in any request resulting in the > establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." Section 6 Para 3 says: > "If a UAS (or proxy acting on behalf of a UAS) does not support > SIPS, it MUST reject a request to a SIPS Request-URI with response > code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC > SHOULD NOT re-attempt the request by automatically replacing the > SIPS scheme with a SIP scheme. If the UAC does re-attempt the call > with a SIP URI, it SHOULD inform to the user that the security > level is downgraded." The first MUST of the above is, I believe, a restatement of some part of 3261, which could be called out as the source of authority. The rationale for the SHOULD might need support. I seem to recall discussing this or something like it on-list. Section 7, first para, says: > "Sessions, dialogs and transactions may be "derived" from existings > ones." The "existings" might be better as "existing". The "Must be rejected" in para 3 of section 7 requires some support. Keith would suggest indenting the Note: paragraph (4) of section 8. The following discussion of RFC326`/16.7: > "will be in the path of subsequent supports this transport" is probably missing the word "requests" between "subsequent" and "support". Section 9, discussion of GRUU, p 2 says: > "If the wrong scheme is received in the GRUU (which would be an > error in the registrar), the UAC MUST treat it as if the proper > scheme was used (i.e., it MUST replace the scheme with the proper > scheme before using the GRUU)." I'm not currently sure this is supportable in this document. I don't suppose we could move this text into GRUU? Jonathan? In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: > "... how SIPS may be used. "server-side authentication" (where the > server" The following "it's" should probably be the possessive, "its". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 11:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSE38-0003e6-Gf; Fri, 16 Mar 2007 11:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSE37-0003cf-BW for sip@ietf.org; Fri, 16 Mar 2007 11:08:57 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSE33-0003Xv-VK for sip@ietf.org; Fri, 16 Mar 2007 11:08:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2GF8nl15813; Fri, 16 Mar 2007 15:08:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 10:08:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FA06E0F@zrc2hxm0.corp.nortel.com> In-Reply-To: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes on draft-ietf-sip-sips-02 Thread-Index: Acdn2cAKgjBS6qJ/R9ycLHl3knh2agAAwUqA References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: SIP IETF Subject: [Sip] RE: notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK. I'll integrate all of those comments.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, March 16, 2007 07:45 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF > Subject: notes on draft-ietf-sip-sips-02 >=20 > I did a full read through, not counting the examples that I=20 > never get right anyhow. >=20 >=20 > general note: Keith tells me the standard is to write '200=20 > (OK) response' instead of '200 "Ok" response'. >=20 > Specific points of consideration: >=20 > abstract: > > "This document providing clarifications" >=20 > The above doesn't parse. Maybe "This document clarifies" or=20 > "attempts to clarify", depending on what you believe about=20 > declaring victory. >=20 >=20 >=20 > Section 3 paragraph 3 says: >=20 > > "Contrary to what many believe erroneously, the last-hop=20 > exception was=20 > > not created to allow for using a SIPS URI to address a UAS=20 > that does=20 > > not support TLS : the last-hop exception was an attempt to=20 > allow for=20 > > incoming requests TLS when a SIPS URI is used, and it does=20 > not apply=20 > > to outgoing requests. >=20 > Given that the last-hop-exception was to a great extent my=20 > fault, I have to say that the specific use case I argued for=20 > was so that I could advertise a SIPS: URI that would be=20 > terminated on a record- routing proxy at my desk and=20 > translate to a SIP: URI that would end up on an experimental=20 > 3Com SIP phone that did not support SIPS:. I might have been=20 > wrong, but that's what I wanted to do. And given the=20 > fundamental design flaw of SIPS: (you can't tell when=20 > somebody's cheating), it works just fine if the proxy is=20 > smart enough to "upgrade" outbound requests. >=20 > Next paragraph says: >=20 > > It is therefore RECOMMENDED that implementations do not use=20 > the last=20 > > hop exception rule and use TLS all the way up to the remote target." >=20 > Since we've already said that outbound provides a superior=20 > solution, why don't we just say something like "Note:=20 > outbound [xxxx] provides a solution that works better than=20 > the last hop exception. Use it when possible." >=20 >=20 > Next para includes: >=20 > > "The SIPS scheme implies transitive trust. Obviously, there is=20 > > nothing that prevents a proxy to cheat" >=20 > Classic SIP error. We have our To: and From: reversed.=20 > Perhaps "from cheating" instead of "to cheat". >=20 >=20 > First para of section 3.1. Scope of SIPS says: >=20 > > "SIPS means that the SIP resource designated by the target=20 > SIPS URI be=20 > > contacted securily, using TLS, on each SIP hop (last-hop exception=20 > > nothwistanding)." >=20 >=20 > This doesn't quite pass my in-head English parser. Perhaps: >=20 > SIPS means that the SIP resource designated by the target=20 > SIPS URI is to be contacted securely, using TLS on each hop=20 > between the UAC and the proxy responsible for the request=20 > URI, and using TLS between the proxy responsible for the=20 > request URI and the UAS if possible. >=20 >=20 > Just before Section 4, we have ' >=20 > > "Some proxies may have local policies that enforces TLS on all" >=20 > There's a pluralization mismatch in there. Perhaps "local=20 > policy that enforces" or "local policies that enforce". >=20 >=20 > The last para in "Section 4: Routing" before 4.1 says" >=20 > " o Reject the call with a 403 "Forbidden"." >=20 > I'm not sure I believe that. It seems much more like a 404 case. =20 > Since there's no sips: URI available, the contact was not=20 > found. If we use 403, then we need to give a reason phrase=20 > that might help the caller figure out what went wrong. >=20 > Section 5 Registration, Para 2 says: >=20 > > "The USC registers either a SIPS or a SIP AOR" >=20 > We probably mean UAC instead of USC in the preceding. On the=20 > other hand, you can never tell about those guys at the=20 > University of Southern California. Maybe they speak SIP now. >=20 > The following 3rd paragraph says: >=20 > > "Those are mechanical rules with no influence on routing." >=20 > The "Those" should perhaps be "These". >=20 > The 6th or so paragraph of section 5 says: >=20 > > "A registrar MUST only accept a binding to a SIPS Contact=20 > if all the=20 > > appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the=20 > > AOR (i.e., To header), the From header, the Contacts and=20 > all the Path=20 > > headers. If the URIs are not of the proper SIPS scheme, it must=20 > > reject the REGISTER with a 403 "Forbidden"." >=20 >=20 > The MUST here needs some backing. Where does the authority=20 > for it come from? The same caveat applies to the last=20 > statement of Section 5: >=20 > > "However, a registrar MUST record the scheme of the Contact." >=20 > Why? Is that in an RFC somewhere explicitly or implicitly?=20 > What happens if it doesn't? >=20 >=20 > A similar question applies to the first para in "Section 6; SIPS in a > Dialog": >=20 > > "There MUST be only one Contact in any request resulting in the=20 > > establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." >=20 >=20 > Section 6 Para 3 says: >=20 > > "If a UAS (or proxy acting on behalf of a UAS) does not support =20 > > SIPS, it MUST reject a request to a SIPS Request-URI with response =20 > > code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC =20 > > SHOULD NOT re-attempt the request by automatically replacing the =20 > > SIPS scheme with a SIP scheme. If the UAC does re-attempt=20 > the call =20 > > with a SIP URI, it SHOULD inform to the user that the security =20 > > level is downgraded." >=20 > The first MUST of the above is, I believe, a restatement of=20 > some part =20 > of 3261, which could be called out as the source of authority. The =20 > rationale for the SHOULD might need support. I seem to recall =20 > discussing this or something like it on-list. >=20 > Section 7, first para, says: >=20 > > "Sessions, dialogs and transactions may be "derived" from=20 > existings =20 > > ones." >=20 > The "existings" might be better as "existing". >=20 >=20 > The "Must be rejected" in para 3 of section 7 requires some support. >=20 >=20 > Keith would suggest indenting the Note: paragraph (4) of section 8. >=20 >=20 > The following discussion of RFC326`/16.7: >=20 > > "will be in the path of subsequent supports this transport" >=20 > is probably missing the word "requests" between "subsequent" and =20 > "support". >=20 > Section 9, discussion of GRUU, p 2 says: >=20 > > "If the wrong scheme is received in the GRUU (which would be an =20 > > error in the registrar), the UAC MUST treat it as if the proper =20 > > scheme was used (i.e., it MUST replace the scheme with the proper =20 > > scheme before using the GRUU)." >=20 > I'm not currently sure this is supportable in this document. I don't =20 > suppose we could move this text into GRUU? Jonathan? >=20 > In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: >=20 > > "... how SIPS may be used. "server-side authentication" (where the =20 > > server" >=20 > The following "it's" should probably be the possessive, "its". >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 12:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSFS4-00089i-2y; Fri, 16 Mar 2007 12:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSFS2-000872-4H for sip@ietf.org; Fri, 16 Mar 2007 12:38:46 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSFS0-0005qx-HN for sip@ietf.org; Fri, 16 Mar 2007 12:38:46 -0400 Received: (qmail 10124 invoked by uid 0); 16 Mar 2007 16:39:44 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Mar 2007 16:39:44 -0000 Message-ID: <006401c767e9$7be589f0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" References: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> <45FAA515.8070404@cisco.com> Subject: Re: [Sip] ambiguity regarding lifetime of temp-GRUU Date: Fri, 16 Mar 2007 17:38:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, Paul Kyzivat wrote: > Jeroen van Bemmel wrote: >> In gruu-12 section 4.2 it is stated: "The temporary GRUU will be >> valid for the duration of the registration" >> >> There may be ambiguity in interpretation, as a registration refresh >> can be considered to extend the duration of the registration. >> >> Propose to change the text to reflect that a temporary GRUU will be >> valid for the expiration time provided in the REGISTER 200-OK >> response (either as an 'expires' parameter on the same Contact >> header, or an Expires header) > > The intent is that the temp gruu will remain valid for as long as the > registration continues to be refreshed. I don't think that is what you > are implying in your proposal above. > And this is precisely the ambiguity I was pointing out: the algorithm in the annex includes the absolute expiration time of the temporary GRUU in string S, so it is easy to jump to a wrong conclusion. Suggest to add some text about the intent that temporary GRUUs remain valid across refreshes in section 4.2 Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From byersraxh@rdsnet.ro Fri Mar 16 13:42:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSGRc-0004a3-HW; Fri, 16 Mar 2007 13:42:24 -0400 Received: from [82.78.141.217] (helo=rdsnet.ro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSGRX-0005qv-W6; Fri, 16 Mar 2007 13:42:24 -0400 Message-ID: <47af01c767a2$e66eea60$7b67c98e@byersraxh> Reply-To: "Nicol Clark" From: "Nicol Clark" To: "Roberta" Cc: "Aileen" , "Minh" , "Lashawn" , "Jamey Wheeler" , "Flossie" , "Daphine Berry" , "Dara" , "Donnie" , "Delilah" , "Georgann" Subject: Thanks Date: Fri, 16 Mar 2007 08:12:55 -0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_7B0_AEEC_3E90788A.A9DC0F94" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 This is a multi-part message in MIME format. ------=_NextPart_7B0_AEEC_3E90788A.A9DC0F94 Content-Type: multipart/alternative; boundary="----=_NextPart_0EB_A7E6_355B6D28.A68C2352" ------=_NextPart_0EB_A7E6_355B6D28.A68C2352 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "A Greek?" hair volucrine journey murmured the copper Count of Morcerf. = "True deceive as day. steel The deal fact shed was, nobody had observed= a see "Yes; we call have never broken had the beset happiness of press= ingevent "And was it not burn found out at turn last fought to whom the h= ors chain spell "Undeceive yourself, monsieur," committee unripe replied Mont= e Cris "And cry lead this king's drain attorney was comfort named Vil= lefort?" as "Yes, your excellency; serpentine he came medium jog kiss f= rom Marseilles, wh broadcast noise "And spin brought very princely," added Chateau-Renaud. = "Yes, indeed, escape count," gentle said water print Madame Danglars; "an= d t"No."cast "Oh," cried Julie, "I station squeeze have not lost all hema= tic hope of soanswer "You develop say coal that the horse myrmecological = was entered under the name "What, do smitten you not know your ant boy plough house?" asked Debray. = "Then," said Monte speed mountain bow hematic Cristo "you went to him?" = hilarious "'Monsieur,' I said, 'my open pump book brother was assassinate= d   "No," awful said Monte Cristo; "I told canvas shave you I bless did not w= is amused "Did I hear rightly, hastily monsieur," house built said Monte Cri= stodecay spark "Exactly; paper mistake that was the title.""An Englishman= ," said pump war was Monte guarantee Cristo, who grew uneasdestroy "Then,= " sponge answered Albert, "I lend am shame better informed tha "Thanks, bit monsieur," tumble victoriously returned Monte breathe Cristo= , "my ste range "'Every mend blot prevent revolution has its catastrop= hes,' returned "I looked coal at merrily him an were instant to strange = see if there was an development "Is your steward religion stuck also cute a Nubian?" asked De= bray. slit addition trick "Yes," replied deceive Maximilian, "an En= glishman, who rep seldom structure "I low was inspector-general of fistic the pasha's troop= s," r"Shut up, there!" cried ripe the pit company in finger crooked choru= s. And thi"But you tell bone father me, also, energetic that feed the hou= se of Thomson"Ha, ha," gleaming observation broken said Chateau-Renaud, c= ommittee "here comes some fr payment "No, he is a countryman drain of print yours, attention if a Cors= ican is "Well, cruel fish well," wall coloem said Monte Cristo, "such an= innocent "He stolen knew so well, that from suddenly hair that protect= moment he shut hi "But film stunk chain look!" religion exclaimed Madame Danglars."Handsome= , thumb overcame peace certainly," vinic replied Albert, "but not to"Yes.= "silky invite "Ah, well," exclaimed bath pen Chateau-Renaud, who because = "Is clung it delightful war safe that excellent M. Bertuccio, who underst= andknew "One evening, seat as I was comfort looking grip over the wall, I= sa "And," asked industry the punctually count, "did cut you ever cloth = know the nam forsaken "Yes, you saw shrunk him the day begun I had blot the honor of r= ecei "Where?" stammered Morcerf."No, memory for lip that whip very resemblance= affrights view me; I sho"Then awoken is sister it not support probable t= hat fierce this Englishman mayAnd, indeed, it required whirl but value on= e seek pot glance at Mademoi "And you have down along base chosen wall this honest citizen for your = "No, copy excellency," belong returned Bertuccio; summer malic "you will= se "Go on."   table "On my word," super replied the dust count, support "not more than = anstrap The curtain irritate fell almost squash elegantly immediately aft= er the entr ------=_NextPart_0EB_A7E6_355B6D28.A68C2352 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"A Greek?" hair volucrine journey murmured the copper Count of Morcer= f.    "True deceive as day. steel The deal fact shed = was, nobody had observed a   see "Yes; we call have never = broken had the beset happiness of pressingevent "And was it not burn foun= d out at turn last fought to whom the hors  
chain spell "Undeceive yourself, monsieur," committee unripe replied Mont= e Cris     "And cry lead this king's drain attor= ney was comfort named Villefort?" as   "Yes, your excellen= cy; serpentine he came medium jog kiss from Marseilles, wh   broadcast noise "And spin brought very princely," added Chateau-Renaud.&n= bsp;     "Yes, indeed, escape count," gentle said water print Madame Danglars; "an= d t"No."cast "Oh," cried Julie, "I station squeeze have not lost all hema= tic hope of soanswer "You develop say coal that the horse myrmecological = was entered under the name     "What, do smitten you not know your ant boy plough house?" asked Debray.&= nbsp; "Then," said Monte speed mountain bow hematic Cristo "you went= to him?" hilarious "'Monsieur,' I said, 'my open pump book brother = was assassinated    
"No," awful said Monte Cristo; "I told canvas shave you I bless did not w= is   amused "Did I hear rightly, hastily monsieur," house built said Monte Cri= stodecay spark "Exactly; paper mistake that was the title.""An Englishman= ," said pump war was Monte guarantee Cristo, who grew uneasdestroy "Then,= " sponge answered Albert, "I lend am shame better informed tha  = ;      
"Thanks, bit monsieur," tumble victoriously returned Monte breathe Cristo= , "my ste    range "'Every mend blot prevent revoluti= on has its catastrophes,' returned  "I looked coal at merrily h= im an were instant to strange see if there was an    =    
development "Is your steward religion stuck also cute a Nubian?" asked De= bray.       slit addition trick "Yes,"= replied deceive Maximilian, "an Englishman, who rep   &nb= sp;      

seldom structure "I low was inspector-general of fistic the pasha's t= roops," r"Shut up, there!" cried ripe the pit company in finger crooked c= horus. And thi"But you tell bone father me, also, energetic that feed the= house of Thomson"Ha, ha," gleaming observation broken said Chateau-Renau= d, committee "here comes some fr 
payment "No, he is a countryman drain of print yours, attention if a Cors= ican is  "Well, cruel fish well," wall coloem said Monte Cristo= , "such an innocent   "He stolen knew so well, that from s= uddenly hair that protect moment he shut hi  
"But film stunk chain look!" religion exclaimed Madame Danglars."Handsome= , thumb overcame peace certainly," vinic replied Albert, "but not to"Yes.= "silky invite "Ah, well," exclaimed bath pen Chateau-Renaud, who because&= nbsp;        
"Is clung it delightful war safe that excellent M. Bertuccio, who underst= andknew "One evening, seat as I was comfort looking grip over the wall, I= sa  "And," asked industry the punctually count, "did cut you e= ver cloth know the nam     
forsaken "Yes, you saw shrunk him the day begun I had blot the honor of r= ecei    
"Where?" stammered Morcerf."No, memory for lip that whip very resembl= ance affrights view me; I sho"Then awoken is sister it not support probab= le that fierce this Englishman mayAnd, indeed, it required whirl but valu= e one seek pot glance at Mademoi     
"And you have down along base chosen wall this honest citizen for your&nb= sp;   "No, copy excellency," belong returned Bertuccio; su= mmer malic "you will se  "Go on."     =      
table "On my word," super replied the dust count, support "not more than = anstrap The curtain irritate fell almost squash elegantly immediately aft= er the entr             
------=_NextPart_0EB_A7E6_355B6D28.A68C2352-- ------=_NextPart_7B0_AEEC_3E90788A.A9DC0F94 Content-Type: image/gif; name="dloitiezb.gif" Content-Transfer-Encoding: base64 Content-ID: <3339d01c767a2ee6713450f9bb94af@byersraxh> R0lGODdhbgGxAaUAAP////jv3++ysueQkN5ra9U+PvfX1+uhocwAANhLS8wzAAAA/wAAAP8AAN/f 3+bm5tbQx729vbOuqTMzM5Gj3XKu2DqFwjl4tBpgqXuS2oSEhJGPknRxdPfVmtG0irqcgal7QaCL c//MZmZmZuyuUceKU1hMWeSUKN5nGJlmM4xbJ/+ZAPuxAPBXAe5HAQAAgICAAP//AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAbgGxAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhmABAYeL jI2GAQIDAgQFBkWKjpmam2oBB5YGCAgEAgkCQwYJAwaWnK6vsFcBBgqnAQWjs60GuAYHtXILwsML R8OZxMdFyrHLzFHPz3kCBQIHA0IECAkEBEMHoqzAAJhtydIA6HnFS+fCzuzNQu7xT9HveQbdoQiS 2QgFCCRAJUrBJyEDKrlRRqyQOnhD7tWLxeyhEot3eIXThuAAwnAGBOgaIKqAIn0DCGBjg29eS5f1 khmRObMhkYot6cHEmC7n/kt38GzC7HnzXM+JR4XujOkTacSXR4salUo1qdKlZAJwLDBAAQIFlsAh sAZWIACSCFoFQOtRjcSqS39OjSs3Hs6pc43VfQqUbtO/9OrO7Rt1KBJpEgfv9WuXsBi0Cjh6Axey 21mwAgBiEquKQDkzb/mKNnx3dOHTd9k1ZVKar2qocK82nA27amuip2siTWw4d+ret7uEbIWWALiB rAwkEgJpUoJdJVN5SxMaODqL1Rkuxp37sE7TiBXvxqd9PM3aT3vrXg9+dfvGr793yfzV89lwAk4p aQXgAK6x/X0G2l9wWQVfEqEFh5N6COZlHXzisVeeVHg5lR53ek0U3oHq/t1WnmNaVCYKQJYM8BwU GnWUxCyT6OdFcN3t1CF5iynoE4PeWfigjL7BNiFqP2KYGnoMbvhebO7xpEUCCcySgCjTTSGAAgMZ ocuTCfXzIoFHksalTa0JFSaRpmXYJZDmeckUh9yJeZWZRbrXI5seklnFkyeSZFIVrBCRnwEkmTiK WPxpERhErkEln4GAuckhTTleJOehOP6YGKSLJsUaiGiWWeeab2ohFjCUCEiFAIACFMkB9JUySheZ dgdpohn6eMx2vzWoY6eu8WobjRreKphTStJaE5JrnolVGGhtc5AVIVFDiiioKofLNdvIo+0ZxW5r xAEJKGBQFc3hQgCg/vpsowoA2piimbfwwhpqvEvoMgUk3HRGYlgAWcYPNVXSK7AV8w58BEpReJKS NgZJIkoCJgXgFaqfmHuuwRhn3AWrRGhTaBK+oJqvfypqFJAl2pyrwAAmuqjxyzBPgQuTxlljqpVP dhRyulUyzMoB4Kxsys0xF230wV6NKEpbB3ejCDWisPx0OADwk1I1qnx89NZco8IyJUmvdHDUQkxJ NjleYXPLKCoR3fXbXc9ywMXk+LLuP2D1JyiA9+WdktZwBy44KgVw5ZVHgHrlTX4B4PlRNagAPvjk RQN6itUkeQMoWqessjYoIqFCZUirUG66xiH1XaKzKq6FViVmoXvE/iSpUrsIA7jjjgYDQvB+hO9l AD+G8G+H1DhyUFYdtbidswwly0t8IhZAChkiPPFWYF+E9kRw330g3r+cyFoKmARo1TlbYq6evhzQ ON1LEJC0iqVbv70W4QOQf/76g8/1LF0ZAKH6ExJwvUpPZmOS2p5ACyht7nb3653u7jdBCfoud9ub 4AWHgMH+9e53ugMe70Z4vQp+j4S/46AFVfhBD6qwgiNcoQtFKMMaxpB/cBBIKiqBC2zkxxqcw9zQ ogAKSaRCRYcg3gZbyMEl0tCFRoihB2m4xBTOUH9OZOEJq6hFKU6RhSbUoASZ6EUqghGMOIxDKApA jlO0q2qSYBku/rBGCirwIkoAYBwEv3dFPn6xhfsDJAWVYMY+PvGEWkSkIc/oxyo+8YZ/bCQT+dCq qoWEagI81y+e47YmTKJ+mVAiGSMYSS5a0ZQdREIhH5k77JUxhY4cJRQXKUtIihCGrZzkHhrovCY9 yTNyFInkoGAiVgytk/7j4yFrycgkZFGZznwhM6O5TGnSMpLTXCQkI+hKQOBpSphZ2ieUIwR9DHMJ 9CnA3CRxIkZcr4ukjOUsFRlLU/pxhs+c5yuteE1UNvOQAP2nLvdAn3SdIhJa89kU0hW1WSDxdrns ngllicVbZjCfHXxkBuEZxol+sJqJTGVFUZnKEr5zkiItaSLz/kASVTQpCZwR4BO08lKSbcNmp7tC +ECKv5w+AaH78UolnnTOIVgDS+XkSMB8SoWdrnQLaWTqEjRSC86VwnNDsFcoPGKNjj1UqlA9KRc8 ClYi4qKqD7tPPxLA1QJE5j54zKrLykpXeWjlVZ9EmapAoji1qgWZdQ2sK/xBhLUZx3a/VF62zsI0 wTqWXvygBBKftCeOnIKtj81svMQCNeJ8BRRPMoj7YtaABmzBtABALRhKy1rUllYIr02tajW7hcaR 6HBloxo5rlFUesW2CKqd7RJcK4bfvja2yBUubbGwFiaZbTpiERvXfjuE5DqBuMUNrnCtu9wuzMIT d1tVbzN2/lzXtpa1sk2velML2/VqN7jVRS97Yavd+KqXu+U1LXVbS4Ty0pe68TWufP3bXXihF7/m 1S99q9ve5Cb4vxCWrXntu2AEQ/jAE76vfo9LYQpzN73yLfC2LKzh9gLXxCD2b35TLOH1SnjAGSax jDP8YuDGuL4uFnEzZrzg+fYXxRzeMIjZq2IizxbAJU4ygvmrZCH398YeVq6OX8Hj+xoBuzXmr5Yx nN8jK7fKJH5yhWnc4w9/eMqxADOHh+zjCwt4w+9tMYttXGYoN3nMTrZumFeM5h3TWM95VnCb3Ytj Qkc5x3dOdI3t6+AlF3rOfX4ZkkcsZStMOtICuzSVO2xp/k5j2mCapnKIscDkT5v61KhOtapXzepW u/rVsI61rGdN61rb+ta4zrWud83rXvuaXuMD7K+H3YRgA8ABwia2sq2EiUQ4wAEPoFwAHvCAZC+7 DuMjx/ge4AAIIDtwD4CAuMdt7WvHIdjTjgC0uS3ucscrAOJeN7XJPTl0u1t8wX6ABNT97Ge3e2sQ iMC4By7uCKjbCROYQBESDgCGx2I5WYV4FBw+BIZTvAsJz7gQMq7xrGhb3/zud7clANiOV7ziCnfE AyJAAYO7nOUUaLnBWy5sil8cFtlm9r1tnvIw8BzlZwh2wPvt7JFHewkmb3jPNeGACjj96VC/ANSd ToGS/vfc4Vg3ucVTzvGNJ30O9g67xBF+da4rvOteV7rXs35ztR+h7WEI9rflbnSkn93sbC/72s3u djoEwOkWqMAFBk94wRP+AoGvQASY8HO1633rfN840P1u72pP295QaLzW7670yDd88ihvO9wRMW1q o7vfEJDA0ZOwddCj3fFA1/jo2/B3C1wAA4THAO4Fj3vcS90CVWc859O+d7dnfeFffwO6qU3tdaMb AuVuPfG7fvy+Fx/5SZ+9FxLBfJGLPPWrR4L0+976i1Pf83OgwOAxYAHdI/79t7+9BWxPcuGTn+/S r37atd8Jy0/b+/IWAA4QAdE3fI7HedVnfgaIfXpn/gbcF24vF3LgZ3f3F3sGWH7oJwcPkAGHN38e iHgeaHsaQID293PHl4ANyH9pAG8QwHzN54LV5gD7NnEX2HH553n693YNWAbjI4MDh2wCOIGsx3H6 h4HTN3wquAYyeHu653uH534bQIJNkH1IiIBFmIFwEAAGJ28wuHJRuHMKeIJ3h4MZ2HjWNwZFJwHe 52wSUH9DOHmaF4fGt3R+FwEc0IR42IQaIAHQ9wRUuHf4h35EaAfwJnBcGG5t2IdS8IeDeIDEB4hG 0IiPSAbhlnpqKHLwlogU+IgouHSDmIN0gIgawIR4eAF7qIhfsIOCsHICN25tKIVjoIqBUIgGR3AF /mdw99YM8RZwEjCK7reHtehtPpd8s2iJErABaogGrzcIRdeKP+hvuQgL3WaLbfiKthh+RXN6z8Z8 Yzc4pceN44OKL8NtANhv5LiNprc1YRdxxgY36HYJPRiNOJdsOZeNYmds9Sg43bht8jiP3ciO/2hu d3CPASmQBqlthVWQB1kICrCQtyYuDakEEbkEEEkEDTmRFomRFSkGEdmRe4CRgQOS8TKRImmRTHCR ANCRFwmSKykE4pKSJekFHimTL5kEMVkEG+mSNYmTOwmTPSmTLhmUUJCTSHCTGamRP6mTSGmUWDCT TBkFLKmUJCmUKYmTVWkEP9mSMLmVVrmTOYmS/ibplUL5lFIwlUV5klWpklw5BC/plWRplVMwk05g lmdJkWmpk2uJlzXZlm9pBXKZBVF5lVcplyxJlHjJk2yplRkZlGaZlHs5llSpBYH5lVQZlSWZlIeJ mYxJkmJpmY0ZmXZpkj75maAJloi5mHupmGy5lpSpkawJmVswmaspmKZ5lEiJlaxpmLQ5mn85m4MJ m7EJl05ZmTyZlTeZmpj5mI0pko/5m4KJlqJJmnQplVhZmFzJl9XJmLNpnLDZm1cgm8BZm2GZmEeg mnlJnMxZntsJnJIpnOH5nInJndk5lum5mRt5mevpnE0AnvopntRJnoiZmue5mxDZnKLpnN75/p2+ SZqgqZ1qiZrXaZ7XuZvwmZnd2QXgSZgVqp2LeZoeuqAVip8XuqF1mZ/9SaKmmZxaiZ1weZctCqII SpOuyZ4x+ZUFmplLqZ5uOZ2rKZb6GZzE+aP4CZYsyqLk6ZgeyaAdOpwkWqJ0+ZdDOpjWWaQSqpwm CqBM2pccaZNfoKUHmgZEyaQNqpRHeaQ3Sqa4uaO+GZ356aVheqU12pNnipxlmqacyaNpKZ1w4KWA SQV8ygbHCQZ/2qRoEKhdGpcOyaVqMKiDygWN6peImqiSOqmUWqmWeqmYmqmauqmc2qme+qmgGqqi OqrFpgusoJCkGnfrCDcG0AEe8Kqw2gHk/pSqPBgAHXCruDqrXGMAr/oBvuqrsCqOtLp9toqrxnqr DqCOrvqrvwqrviqs9kiQ7Rg4xXqsxuoB2PgyBvABIBACIfABzsqsHwABR0OQHRCBL5esb1Ot1oqr IuABRqOFINCtG8Cs3tqGHgCu2Yoxtko03wiDPugEIzCwBCsEAzsFIxAFCWsEBzsGHSACEBuxEGus IkAC6noEBYuwCwsAG8sHDvABJRAC6gYBHjCvIeBtJPusmwh6RACKf9ABBGkA6FqLEbABF6sEDcux CZuzT8CzemCrJBC0QiuxEQsAi5cEPquxfwABIFsCHqAIEDCvBBgA+eqrEmB/k9iydKgE/lsrB+16 rRygAWLLASNgAmZrtlfLBDl7sGw7BAS7sA27sxn7tgZbsGx7t3Wrs3pbt0kLBQFQsUIbuENbsU+L tB3rtna7sXhLtzrbt3HAtPNaAlPbhongASVQAvP6AVg7hyg4h/s3fm7wt0RLtCRAhKarAYC1tnKb uHnLunELt3KLuKurt3cbu69LLoKbu0J7Ah/gNkn7uqq7t3GLuHcAuZlLruMTAZg7ryCwAZtrcRb4 uUc4hme4BqI7uhFbume7vWe7AamruLYbu7QLu8JLvsFbvuPbuuRLBQGgu7qLAr1ruAxrvuJ7u7J7 uHLwscwLAh8AhB3ArfOaAimQthQY/oZV6LkInIRk4AEkgL0QSwLcG8FuiLNvS7+Ny7rpe8F4m7fo u8G1m7FT8ADuK7gngAITPL/zS7cevL4ZjG0lmwLM+6sBDMMqAALkWoKPd8Cdi8BvwLQjDMER3L03 K79FsLiHe7v2S7wcjMT1K76y4AEn8MMkgAIgcLRI8LtH3MRLzMJ1ELUqIMBgHMYpoAIqcMJv2Lli eIRqnIURIK7iygFwHMdxvAHQirH4a8Tqm8cdDL5bnMErbAUQcAKCPMiETAIlHAJDXMR3vL4gbL9J jG0SMMZfLMBkLMkqoAE3PIVymMY2GHkKjIYGEHAzGwHVWMrVWMcorMjl68iMPLd8/rzH6HvBT0zI J1AChEzFsGjHjCvLfKvEq+y4jxsClkzGxKwCI2DGXGvAB+yICdy1nSCttkhw/SgPH0vLgowCCgAC yKwxhRgCIDDMXxwC+5bI69qFMDjN1OzNKLDO6/zFqleu3RbKpGzKfBhv6Awv0nrPD8e0wizA3bpv +qwJy1d0YjesXzA+8hyMiQCz5dqOEjetBs0F+TwL6piPEZ0VE42qF41mGR3QG01XEP3RcvCoIq2o GKObL2qTSDqfvLmlP3oHJM0HKP2lKp2j1WnTgsqe7Tmma3qWtambK00GCdqUmsnTxcnSHYqmYSCm 0EmoT4mSasmdAlrUQBrTKa2S/j7Ko+JpnoaZnLk5lZ7ZpkBp1E/tokodn2ZaBkONm9FJmRTao+U5 pVGdnmrKoZsp1o7qniMKn2d613UKoKeZooe5pHu909uZ1T291efZ10WtmK3ZlXq6n8Lp1lq9oVI9 13aK1nadp3gNpCYqpoUpp4stn4FNoUGdpRg62QxqmZBdnJzJpXVt1n4do5LNpnsd2swp13qZ23b9 oFha2H1q2yd6mfc52IA9oOg5p+o5olZN06j91v8527Pd14S9nPP53E39ngQa13LK21Ndn3la3C2K 3Yat3WDt01JJ2si93SkdpEwd3HgdmK5Nn3Gd1uPd0pYd33Op18ON3sZt30YK/qLgDaPvDd9PGplR ap0RmtSlraS/TduezdxwraPpzdu7zdayPaaR3ZciKqQU7tsX/t3XbdojDuGOKto0WpSnDeKa6dg+ 2trAbeCdnd9b7dtuOaBWqtMWauInieIezt3xKaA++ddheac9zdkxDqgmndeRuqgoDqUqbuE3rtkw PuQa/povPdbLreVD6QfN3eVN/pFLzuRl+QZfDuZQqaln/gSMWtJu/uZwHudyPud0Xud2fud4nud6 vufUqtF9HtLSRgIrMOgk4NGw0KrHqqv62HwAuK/rKgInwAKSPukiYOgC7aqwmukeIKuWvgn/F80D V236KOiTXuosQALjJTAk/puvmq7pDK2OlQjqP9jpm0DqLDDouC7pK1Do5dqrre6smZ5srzd6LrsH QRiMoO5yqAwzHYDrgz7pzr4C8Go0DlC1rS6ur0oChbuJKvjJdsCKozzK5Cx+sugKgh7t6L4CJ+Do jSu7ArvIe1u8luu0JPCrJWDvHxC0945McJd3a9x5znxuARdzBF/wo5zJzxvwjhAAKNAC7Pzwg44C uI7wigy++AsFwDwHTIu5l8u/3NrxJUACHZ/LOljyObzG3o4GWljwLE/wEdhymVeDgai1O2wHHdDw LeDwD7/zKGDFKby6Fg+7G5y+qpvxaPAATQsCl7v0TG+y77yyWht6y0yM/nXY8gWfAVZP8slsg5+L hNFbvV6b82I/9mTfAtOuy0Dfx+dbu8Lry28QASHA9EvPvOKsbjXXtZxMhimv8hBAAVgfcxkQ+IL/ 94CfARQvfHQoe4LYyXt/Bh1Q9pCf82ePwjsby0PPyvHOy2z8zczrz8i47CUfiTpcho1vBjI4+Kif +hnw9GSndcxsguXudyjgApFP+znf8/Jb+cCLwZbvxEMPB6nnrcL/AfsGfe6GxjPfzHmQiaqv+nxI g557gyhP9edGArbfAi6Q/dkv9i4gubn/x0Sw9hYcy3CA6OcaAV97qn64eZB4haUfdKmnARyg+nC8 h+P+htIr/dGPhXPw/vja//9A4BIKPw7AEYkcjQBL5vIIbT6Z0SrUObVGk13vFxwWAwIGCMSQVq/X gfEbHpfP6d4ARKLh7Pl7jQTCbW5iAonwiPDwEGCRMbFwsbFuss5j6PISJELwS+qqasoTVEoLa9QJ lFK1K6DV9RX2dXWWtjYswMEBIkKi17c34syB07bYuPbhAzNT4uH4GRoudjo22voaCVc496wbIpd7 GHucHMABBQUTJaS53P0dPr424KHe/h7/Xn5/9iHiowQIEOw28TN4EOE7aqyqJXQopsyZCMEMEHt4 EWNGjRufUYPFEWRIkSM5emxIEmVKlSuPmfzIEqQCmDNp1oypQKaY/pxjcO4E0PMLUCRCo+U0OtKn TYRJlSbZydTpG5lTj+D8mdSq1atbsR2FRhQMVC9gwVbValZsMa9pVZXtwnbo2atQycr9WhUvHKxo n+b9+fbvWKxTjRIey3Xu0MB4z6696zeo1L+FETOmbLco5Fp9w0qmutVu1stwbXmVHHWxY809mYY2 DLr1Uc6u86o2tnfubMVR6e7VKvpw48aLLe82vRlw4tq7Ffd++xo4YOF9fesmrjO59clB6wrmGh31 ZNaaUy+/jhy1dc5xMYf+/tqpbOOxzR+nhVv1er7enz+FH5ex+fjLLw78jGuuM/+4e68yvz4LjzkC jzHQvO0Ek6s9/gYztEwoug4MjLQ5KDTtwfgwpG+61pob77zyQCQvjPW0a5EqyuKDzawGv3ORvhd9 vC27Dy0MDsDgRjsswOSUlLC0IH8skbcin2twwyGZC49JvTAUskXlcrOxLg+nu7K4+h5z8UcaLaQN uv9yHNK+N7NEj0fIxARxMBz1vBFOGH8z85q0QpxkUCXjIYtLsYhibTSf3BKPPTLL9LFQORBNU9EU wTxRTP/0W/HDSusQtclRUxL0TDpIlQfVVEVsCtZS31m1y4tonYXWW2Pdlddeff0V2GCFHZbYYo09 FtlklV2W2WadfRbaaKWdltpqrb0W22wneUnbbr19pgMSSDjh/gRxRejAom/VlaMVbzsgF954y0V3 3XohmgZbA+TdF14SOojjEUMK+SKSgd94BBKE7d2olXweEKfacfmdmIR0DXEEEYPDkASORgzmuByX POqWHocfhsBaidGZGIV4IxADZIwdKThjgUGOOeZrYDHZ5HY7ztkLjoEGiR5wjM7lgW/eQCWVXwMo AZ2Wo566ZXLRkQBmjQVmZGuaZRY6kS6GhqZkns1+wOKgx946Ca1JauXouHdJe4u6g/Ugaqvz1hsF FTRAeWO3ZZ454ZpnDjxsw0Mu2wF8kL7n8aSNGEORjwOm2WvCa15bIV28+cZoPJwJg5QkUFGCCipQ L32jB1JQ/oDqqHFSIYUNJIAYDJwHrvxry4FOfHByypbcc6NxObqVMw4ufHPew+YdkeaZT+gOXia6 Pphg8AAcjNNRrzuL8J/4PiQIXmdUAdr/gADt5QlmHnqwBb9YceHtAQf04h822h7lKZ8+fvATYPPq d5CkYQ8PwADE9sbANPB94oGra9pGIBCCFFwwBSCwHfvo9j7DBbB3H9Sax9gWssY9bH/1AIfjTugP 7gVucCDE3O4UljmEHFACE8lhDrG3gReSTnwR1MIQTSGSVpjhcxWRBcCAV7Dn0dBmglNYAbGRtLPx jIFZm6IMoWjDEFLPAdfbRfa0hwcfyqGIRIRgKdZYEpFx/utZd9hG3OjIjV50MIZd1GPhvAZChwQA e4G83gY2MLrunUKNQkwj6zLyxpM8yx+/kOQkfbFB94kwhH7U3BepJ8hAbuAPeHSgFUghigdmYWEk OaAnWRmM9mHrATwU5AY4sIHJpRJbjnyktRKIPQnQ8oy4FGYqIQBKQuphBBp42TCZuS5t/FIDGrBd MPDYTGtCC3LdUGEgrtnNaomscd3UlTd59cZXLutREIoRp7jjKMwAKU3kbIkjmfUpQyUIT1Rqk46e ESeNjBNWukRndhblIOks6Ea/cROk0IIgUAGqn+9UZ1jY2R8TdaVCGwGoRp1EKTKxiE8XzVF75FOb PHm0/larsOdEiXQk3rgUoylti0RhdCGRIlRKj/EnkoREIhp1Z0op4ilhOjRUiKqFoMNBU5Km9NKR qmhMTJ2UbZBaU5luB6Y39VKgrKpOn5ZHUalxDm2WdB4VAWqj9/zqV9nTo4eCp0gPshGf5nSfpPb0 oPxx6qQe6iUowYeq2DFoRu8016dqqEdyJc+fUApPvIK1ne4MalYNyig/haqrhHKSbQZDUiP1Na48 SuxRebIlwlLUUwptaKQ+u1qzIiawdKqQT8OqoNbCtbI8xRJp7Zqe2f70REhibJWIytiyNtZVLJWt pfYho0RF5jNsQuyA6kRd5C6XSVByKD/R9yXcWOmy/mi1RlpVpdnmmhZTqG1ro7Ta14K29rp0Ug9L a/SmnJKVrtVtal3l6VjdVtVUrDLtcTKVWsPi171Klc58+5vcceSKJK3qJyXI22ALnwYeEL7whjnc YQ9/GMQhFvGISVxiE58YxSlW8YpZ3GIXvxjGMZbxjGlcYxvfGMc51vGOecyRBvz4x8QCcgO8MGQk ALnIPfbVkJGMEiLXgclPPgKTjwyAIFdZyby68pS3HJIux2HLYb5ykMksZSlnOVZf7rKRj3xmMX85 CWsmcpnP3AUqtxnObdYzl/VcZiyjOc155jKbrWzmJ0e5znvmM6LBcGdGf2HMYu7znP8M6EA3WdGS /uZzoRVtZzfP2dBhkDOeG03oURf60Jb+FaGLHGpOv3rTrY6zqROd6Trn+c6xhjWWMa1qWGH60a+O dJQh/eldCxrWak50kzW96ylXGdm+HomyY63mZNda1pOetahd3elqd9vai8a2tKd96mYPetbd3ja6 mT1uOat7z8A+9Jq3HW1ye5nYg2Y1qj29bzxTOditfrO/Ud3rgt+63vemSa7ZfetaE/zfnKazGFgN cX0LHOH9Vjgzx73xe3fc49IGechJXnKTnxzlKVf5ylnecpe/HOYxl/nMaf4sRN8c5znX+c553nOf /xzoQRf60IledKMfXedNsXfNlzxyLzOdWUvX/ojUoR4sp1/k6lUXFtUTknWtb10kXP862EHi9bEP S+zwMHsz0w4HM5Mj38Ked5qnLgcG3P3ux2DAG/YOgL574e9iCPwYBn+EwqvC3mt/+zg0HWld22Tt jJ9D4A+vison4fKG1/sXMk8HOMP7DYtnPOgdT3esT74Lf8c75/1O+by3vvCU17zhVY+Ey/e99rTf ++oxz3u/2771vT+8n/nNZuIfG9qiN3XEn63rxs9d7hJ3uKTfjW1aU9/rkY+G2QePe+Cn3vu/n33s xS/+8J9f8LM3P/APv/vvB3/96if1mG0NaucnH90Fz7/xS//tTZceychs3fwM2Lwt+o4N1LLv/iG4 L/XUj/zG7/seMALl7/c6L/zi7/0wT/NkDwIp8ADBDfrs7M8mzvECcO5MsN/k7f+gLwRLMAQvztNW cADNTvuegQE1sPwk8AIvMAPjr/vKDwx2kALbbwNxEAMLDwBt7fGaz8omzf6k7wlJcPpU8ANT7drE 7fH8DQCNzdlCr+vq4AdzEPAmsAONsAO77/XCQAh1zwPXjwPND++QkAWVsAubkAkFMAopLQ+b8AkN sAr/79uMrP+kL9sGcRDd7gvpIAxzzwjXUALPsAGBcAzFsAGJsAIbsQ3jzQqvsA6VzwSHLQHnjc4c rthkUNj8bwY1UeAO0BTloAaNYe3ekBHf/s8RxzD30A8DWY8Sa88SJfH11jAV7fDa9lAYp4/f5u/d jvEQTTEJOZEAn48ZX3Di5uAViyEW4xD8elH10jANM3AHGZEHHdD3eK8baW8I4Y8NC9ETsRAQmRAV 39EZX1AVP9D5VLD6WpAKtY0aExFYHnEWwnD7qjHQrCHtBLIWDDIkAJIW/PEY2m5XQG8WIJLi+HHG HPIhDc4WLE7UKPLsrgUhI7IjteUjV2EkQ7JXSpISUNIkTe8gnK7z4IAhV+ElwXAmJ6Emx2EWYeIm exAkEUIlddEMF3LzrGEnryEnWaIoJbEnWxImN7DyfC/4ttEN09EcqZL9XE/2Yu8XuxEc/rlxAn+Q K+HQASOQG72y/X4RHWHvKlnPLK1yHMuRKncP98qSFyMRDoFxI32yKeFPB8fv/OZyLKdyCHExB/vS F8nwCKuy98QRAsFRDG/x9myPMAFTKdGSLxHT/c7RL8sQMidRCI9SBB1i5PDSMzEzMHMxMj0QNG/R FmkxMLXRNacyMwEyHO2SNTlzEhOzDDNxF01zN9kvNjNzIkWT705T+GqRM7FRMaHyNJVTKXuzEoMT MTHxNYtQOMlROTPPMWHPMisTM53zLbWSHL9zPAGPLtGy834S8QjPOKsTNykRKDVTN5/zNjVwO+uT OqHT/YQTOO0SKPGzPaHzOXtQId3T/jtL8xL7My9PTw0DlDLrExjRLyctkzLpczq90TfPsjk3dCwB FPwMlDQvEz4/k0AzVDoRdDsXlEGDMECjUjLPU/6gki5t0fXgMxt50he5sjwr8Q3TchbDMzZftDm9 UjXRESuFT0jN8z63cTXJskeTbCMssliS8iKoFPV6JfPUMyOvxUofokvj4Es54vKk1B20dCXLzsnM 9EwzQk0bck3Rrk1tME7fVB7mNCDpdCCVIu7wNOwYTsuQDlADVegOTlALdRQNFVGRjlCBjk89slFV zE4fNVsiVVIdtVJNjFIvlVoyVVOlhVM7FVo+FVSdRVRHNepMNcRKFVWTRVVX9Vha/tVViwVWYxXt aJXDZtVWgQVXc3XJeNXCdtVXH1KYXgBaiPXEgJWCPkdZl5VZm9VZnxVao1Vap5Vaq9VarxVbs1Vb n7UBttVbr3UfzuAFxpVcy9VczxVd01Vd15Vd29Vd3xVe41Ve55Ve69Ve77UB7lVf7TVcIcBcowlg A1YD9pVgC9ZgDxZhE1Zh5zVfF9Zh+/VfwSACBtZhK9ZiLxZjM1ZfG1ZjCRZiy1UDJBYAKLZjS9Zk TxZl95VjU3ZeP5ZcQ/YIFmABXpQB6vUIWNZdb/ZmcZZnD3Zn7XVlMfZnbVYexNVcZXYBiHVmkSAC atZYx3Vnh7ZcpRZhqfZddRYA/p62Z+G1C8jVag2WartWa4EWbJNAXbGWaOPBaMkVBmIAaY2VaZ02 arN2bM31awv2bq82a/N2a+2Wbvm2bM91buuWXoOWX+mWcL0WcdMWHtb2Bdp2aV8gaZOgaaH2by/X cgcXbi93bpFgbM12aj13c/1WdNEWaz1XdEc3czt3cVfXconVddn1Z9FWdUHXdjFXbEH3dZ9WbGv3 dHWWyBR3dlEXcxXXeHN3b5M3dWW3aP11XCEXaWV2cyv3dWl3cGl3d603ebV2aId3d7N3e023eLWX e1u3e3EXdb/3bBFXfEPXfXkXfau3dcuXft2XeF/3yfy2bjX3e8m3fRMXXT8W/gYiQHI3twuo14BL t2uxl36vV3mX13v3N37/14HNVnN7t4HZV31193PDV4Hf13/jl3QvmHPJ92nz14AJl4M7OIPhV33X V22dFwZgQHIXYCIKmHKdFm4z94UZ2IHlF4BZWIKBmIJF2HhdeIiRGHaD+H2R2IIX94edeHv1F4Sn 2IRvNn+jWHjNl32t2IPrl3lj+HkXoGaj14ARGIyl1odF+H8Ft4s3eIK/uIWruIW1uHjXlYTtF4o1 OIoZuIfZ2IvxN4TdmJCB2IUHeY3FeFyTNg5hNofpeIu9mHXBt3yXd4dVN5KJOJArmXVLWJLvGJNh 2Ht193aH934ruYkpOYXz/hiFkTeCR3h8v/iHE7lxnXeRHfkL0Lhv4xVw97WXc3Z+dzljDZd5cdZl xxWXvUCXhRmYH9aS05aZT5aY8TiYO/aYX0CZWmmZo5mbu9mbyXWavfma45Cc4/Cbzxmdozmcu/ma 09md37lvSbZc15mb+/Vb7xmf81mf95mf+/lbu9Wf+7lfBZagC9qgDxqhE1qhF5qhG9qhHxqiA3Zk I5qiK9qiA7YBLlqjI3qgcemHWOKj2dRbziBkA9qkTxqlU1ql+xmgV9pbO9qlY1qmZ5qmT7qla7pa YRqnd5qne9qnP+emf9pZdVqoi9qoj5qfgxqpvYGol9qpnxqqnVWpn7qp/qGVAfz5qqNaq63apLN6 W6faqau6G8gZAq7aq7GVrL3BrMvaWr16rfc5rbP1rfE5rp31rNtarZf1rrEVrJdarM9gr9laWwMb sMcarwu7nwlbrvlZsZW1sbnasB37n7faf2K4pPX6c94a7w5brTfbrO+OWt1asDd7tBF7WveatEW7 rEGbrdc6tVmbtKv1rGM7tQGbtU87r1c7qz/7tqu1r5H6r3UbtF07sk+7tgt7rkO7tEV7t01bWuu6 tQ2buZtbtQV7sU17ron7WsvZurXbuqn1t486uO/ateNQtjNbur8bt6nbvIn7sSU7s2O7tJE7vW3b s6+7u/P7s7c7r8k6/ruvNbyNerzRO7nPO7ej+70xm7oJPLqV+8AXXL/rW71Xm7+xO8Jt28Dpu7+L G7wpO6TJgaQBgFnJu8En/FlJnL4THLM1fL5N/MTR28ItnLmLu7od/MJL3MWbdbYjvManNcCLesA3 XLfb2ryFe7RV/MHtm8Y5e6xpu7ObG7FhW8rR+smbnL2RnMN3G7aNHMA9PLg9HMzDnMm7nLLHG7rl +szRvMhPmrtxus2x+s1hPFt/XKi/XMzvHM9Z2sub97Lz3M//fJ/p/KftHNAL3dCjVdB9mtAPndEb vRsSvacX3dEnvdAhnaclndIzHc8tfac7eqM/HdRDXdRHndQTeqJL/v2gM5qgTx3VLbqjg9UVRxoC +nymW93Wbx3Xc12jVb2iRdylMd2fNaCch53Yi93Yjx3Zk13Zl53Zm93Znx3aib0Bov2qfX2l7dna az1MNy7RcDvbUxrY+1nYk8CgWa7b4UDYUaZa/2Zbw52fxx0JkhkAJnblzh1a0/3b7x3Ll9Xd9xne j0DeX0beSc7enxXf193vtBXYUXxb/31kkUBmuTPlCt5ZD15aAXbe952p+Tzfe5vDc5xaHb6GJzdu /dPycPQZ+HNSvUDdDb7aozWamHYiyFu++Z3jHTuwGV5b//1x3VZ6Sz4oQZNFedMW9vNbKL5ZLb7i j0CQ0t25n7Wq/qGcy9v7yN1ayu8a3ns+cpc2401e6P+THFS+WMrAAATgAAbAALywC1p+2LtB6Zk1 ZCcimq7H6U285j98HEIcxqX+v7ecxV0c3qE3eoGeZtlw9cDzRL1PQn8zOy/x8KVS9+byLBU/8nUm Dcx+AAaAADY/ATofAT4f9AdA7ZOg5YX7rN9+WbM5Did2x+X8rqM+yiU8u9vb6lN/7wYYh1OvaW1z RH3TB4tQMMOxLo0++G30MJ2yRSfBAAig85u/AEAf+qNf+hGgAAqg+a//+pG+5lH/c+Leres+yof7 45uau2ecxXO+9r1h3Ge4hm+Y63cfE1NUO63T8euf+F3T6CX0/vCdlDZ7vxaWHwgSwgIRYTwik0gh s9lsAKJSCABitTKuV022qv1qItkrY6w1Q7JmNFXqfsPj8rlX48We0+Sveo/3/20xAMAsMLwsJC68 SIm9DUYNQgJMVsJZUmZKanJubrpZemaOfkZKlU6ammKO0rm6BhgYCBwMDBAQMBUoDbxCvVF9CUNw BQ9bhaGxAfYFWr1CRwMT3+n5lZVhYVtrj22nZYNBLlBi2zWmtqKesqu3u6vCw4d2qn6uY0LSx6dL +8PKojXAwL8oxo4h64KQmJiFZ75901JwYhxk1RxizDiMi5QF5+A4AtWuTCRJ2Ea+k8dqZUmS9fTZ q3SynEuZ/jBPzaSoc6ecgwiLXQRTTKNGnjotOsQWkShGjlLCRIgqNWo/aFX5GY1zleJWf12zgn3l 8xjQpEOZLgz7Dynatg6dtlSqdOJWVmq/RsvJ1WUAtX6jjd2oMGk4t8L+AqZmeLEwuIgfQ44seTIw DZYvY8Y8mHFbyhUVc+bs2DPp0qZPP5KrWmng0BhR1wnqmqmG2bZv486te3do2byfoWb72yHs4saP Hx8+DDayzM6fQ48ufTr16tavY8+ufTv37toBeA8vXjry8ubPo0+vfj379u7fw48vfz79+vbv48+v fz///v7/AxiggAMSWKCBByKYoIILMtiggw9CGKGEE1JYPKGFF2KYoYYbctihhx+CGKKII5JYookn opiiiiuy2KKLL8IYo4wz0lijjTfimKOOO/LYo48/AhmkkEEGAQA7 ------=_NextPart_7B0_AEEC_3E90788A.A9DC0F94-- From sip-bounces@ietf.org Fri Mar 16 13:48:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSGUU-000838-Fy; Fri, 16 Mar 2007 13:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSGUS-00082q-ND for sip@ietf.org; Fri, 16 Mar 2007 13:45:20 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSGUR-0006OS-0r for sip@ietf.org; Fri, 16 Mar 2007 13:45:20 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2GHivN20081; Fri, 16 Mar 2007 17:44:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 12:44:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> In-Reply-To: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes on draft-ietf-sip-sips-02 Thread-Index: Acdn2cAKgjBS6qJ/R9ycLHl3knh2agAFxlnw References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: SIP IETF Subject: [Sip] RE: notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, I have done all these changes (plus a whole bunch of editorial ones). I am keeping=20 a "draft" draft-ietf-sip-sips-03 at the following location: https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip-sips-03 .txt On the GRUU comment however: Jonathan has expressed his preference for having the SIPS-related discussion be included in the sips draft as opposed to the GRUU draft. That's why it's here. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, March 16, 2007 07:45 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF > Subject: notes on draft-ietf-sip-sips-02 >=20 > I did a full read through, not counting the examples that I=20 > never get right anyhow. >=20 >=20 > general note: Keith tells me the standard is to write '200=20 > (OK) response' instead of '200 "Ok" response'. >=20 > Specific points of consideration: >=20 > abstract: > > "This document providing clarifications" >=20 > The above doesn't parse. Maybe "This document clarifies" or=20 > "attempts to clarify", depending on what you believe about=20 > declaring victory. >=20 >=20 >=20 > Section 3 paragraph 3 says: >=20 > > "Contrary to what many believe erroneously, the last-hop=20 > exception was=20 > > not created to allow for using a SIPS URI to address a UAS=20 > that does=20 > > not support TLS : the last-hop exception was an attempt to=20 > allow for=20 > > incoming requests TLS when a SIPS URI is used, and it does=20 > not apply=20 > > to outgoing requests. >=20 > Given that the last-hop-exception was to a great extent my=20 > fault, I have to say that the specific use case I argued for=20 > was so that I could advertise a SIPS: URI that would be=20 > terminated on a record- routing proxy at my desk and=20 > translate to a SIP: URI that would end up on an experimental=20 > 3Com SIP phone that did not support SIPS:. I might have been=20 > wrong, but that's what I wanted to do. And given the=20 > fundamental design flaw of SIPS: (you can't tell when=20 > somebody's cheating), it works just fine if the proxy is=20 > smart enough to "upgrade" outbound requests. >=20 > Next paragraph says: >=20 > > It is therefore RECOMMENDED that implementations do not use=20 > the last=20 > > hop exception rule and use TLS all the way up to the remote target." >=20 > Since we've already said that outbound provides a superior=20 > solution, why don't we just say something like "Note:=20 > outbound [xxxx] provides a solution that works better than=20 > the last hop exception. Use it when possible." >=20 >=20 > Next para includes: >=20 > > "The SIPS scheme implies transitive trust. Obviously, there is=20 > > nothing that prevents a proxy to cheat" >=20 > Classic SIP error. We have our To: and From: reversed.=20 > Perhaps "from cheating" instead of "to cheat". >=20 >=20 > First para of section 3.1. Scope of SIPS says: >=20 > > "SIPS means that the SIP resource designated by the target=20 > SIPS URI be=20 > > contacted securily, using TLS, on each SIP hop (last-hop exception=20 > > nothwistanding)." >=20 >=20 > This doesn't quite pass my in-head English parser. Perhaps: >=20 > SIPS means that the SIP resource designated by the target=20 > SIPS URI is to be contacted securely, using TLS on each hop=20 > between the UAC and the proxy responsible for the request=20 > URI, and using TLS between the proxy responsible for the=20 > request URI and the UAS if possible. >=20 >=20 > Just before Section 4, we have ' >=20 > > "Some proxies may have local policies that enforces TLS on all" >=20 > There's a pluralization mismatch in there. Perhaps "local=20 > policy that enforces" or "local policies that enforce". >=20 >=20 > The last para in "Section 4: Routing" before 4.1 says" >=20 > " o Reject the call with a 403 "Forbidden"." >=20 > I'm not sure I believe that. It seems much more like a 404 case. =20 > Since there's no sips: URI available, the contact was not=20 > found. If we use 403, then we need to give a reason phrase=20 > that might help the caller figure out what went wrong. >=20 > Section 5 Registration, Para 2 says: >=20 > > "The USC registers either a SIPS or a SIP AOR" >=20 > We probably mean UAC instead of USC in the preceding. On the=20 > other hand, you can never tell about those guys at the=20 > University of Southern California. Maybe they speak SIP now. >=20 > The following 3rd paragraph says: >=20 > > "Those are mechanical rules with no influence on routing." >=20 > The "Those" should perhaps be "These". >=20 > The 6th or so paragraph of section 5 says: >=20 > > "A registrar MUST only accept a binding to a SIPS Contact=20 > if all the=20 > > appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the=20 > > AOR (i.e., To header), the From header, the Contacts and=20 > all the Path=20 > > headers. If the URIs are not of the proper SIPS scheme, it must=20 > > reject the REGISTER with a 403 "Forbidden"." >=20 >=20 > The MUST here needs some backing. Where does the authority=20 > for it come from? The same caveat applies to the last=20 > statement of Section 5: >=20 > > "However, a registrar MUST record the scheme of the Contact." >=20 > Why? Is that in an RFC somewhere explicitly or implicitly?=20 > What happens if it doesn't? >=20 >=20 > A similar question applies to the first para in "Section 6; SIPS in a > Dialog": >=20 > > "There MUST be only one Contact in any request resulting in the=20 > > establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." >=20 >=20 > Section 6 Para 3 says: >=20 > > "If a UAS (or proxy acting on behalf of a UAS) does not support =20 > > SIPS, it MUST reject a request to a SIPS Request-URI with response =20 > > code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC =20 > > SHOULD NOT re-attempt the request by automatically replacing the =20 > > SIPS scheme with a SIP scheme. If the UAC does re-attempt=20 > the call =20 > > with a SIP URI, it SHOULD inform to the user that the security =20 > > level is downgraded." >=20 > The first MUST of the above is, I believe, a restatement of=20 > some part =20 > of 3261, which could be called out as the source of authority. The =20 > rationale for the SHOULD might need support. I seem to recall =20 > discussing this or something like it on-list. >=20 > Section 7, first para, says: >=20 > > "Sessions, dialogs and transactions may be "derived" from=20 > existings =20 > > ones." >=20 > The "existings" might be better as "existing". >=20 >=20 > The "Must be rejected" in para 3 of section 7 requires some support. >=20 >=20 > Keith would suggest indenting the Note: paragraph (4) of section 8. >=20 >=20 > The following discussion of RFC326`/16.7: >=20 > > "will be in the path of subsequent supports this transport" >=20 > is probably missing the word "requests" between "subsequent" and =20 > "support". >=20 > Section 9, discussion of GRUU, p 2 says: >=20 > > "If the wrong scheme is received in the GRUU (which would be an =20 > > error in the registrar), the UAC MUST treat it as if the proper =20 > > scheme was used (i.e., it MUST replace the scheme with the proper =20 > > scheme before using the GRUU)." >=20 > I'm not currently sure this is supportable in this document. I don't =20 > suppose we could move this text into GRUU? Jonathan? >=20 > In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: >=20 > > "... how SIPS may be used. "server-side authentication" (where the =20 > > server" >=20 > The following "it's" should probably be the possessive, "its". >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 16 15:06:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHhL-0006MK-CG; Fri, 16 Mar 2007 15:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHhK-0006Ld-3q for sip@ietf.org; Fri, 16 Mar 2007 15:02:42 -0400 Received: from empbedex1.empirix.com ([12.38.203.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSHfJ-0003df-TP for sip@ietf.org; Fri, 16 Mar 2007 15:00:41 -0400 Received: from EMPBEDEX.empirix.com ([10.16.0.91]) by empbedex1.empirix.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 15:00:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Mar 2007 15:00:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP v3.0? Thread-Index: Acdn/VbKknz0xYdnTLGfvZ3ES0iwVQ== From: "Beith, Gordon" To: X-OriginalArrivalTime: 16 Mar 2007 19:00:21.0122 (UTC) FILETIME=[586C2E20:01C767FD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Sip] SIP v3.0? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0242929034==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0242929034== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C767FD.557257CB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C767FD.557257CB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello. I was interested to find out whether a draft exists or not for SIP version 3.0. I have seen a lot of discussion on the topic, but have been unable to find a draft. Or am I too premature on this topic? Regards, Gordon Beith=20 =20 ------_=_NextPart_001_01C767FD.557257CB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello.

I was interested to find out whether a draft exists = or not for SIP version 3.0.

I have seen a lot of discussion on the topic, but = have been unable to find a draft.

Or am I too premature on this = topic?

Regards,

Gordon Beith 

 

------_=_NextPart_001_01C767FD.557257CB-- --===============0242929034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0242929034==-- From sip-bounces@ietf.org Fri Mar 16 18:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSKZ5-0007m4-7h; Fri, 16 Mar 2007 18:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSKZ3-0007ht-1u for sip@ietf.org; Fri, 16 Mar 2007 18:06:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSKZ0-0006e4-OC for sip@ietf.org; Fri, 16 Mar 2007 18:06:21 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2007 23:06:16 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2GM6F7V020531; Fri, 16 Mar 2007 23:06:15 +0100 Received: from [10.0.0.38] (ams3-vpn-dhcp4452.cisco.com [10.61.81.99]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2GM6DlZ016200; Fri, 16 Mar 2007 22:06:13 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 16 Mar 2007 23:06:06 +0100 To: Dean Willis X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=869; t=1174082775; x=1174946775; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Current=20status=20of=20WG=20slides=20posted=20for=20 review=20with=20IETF=2068 |Sender:=20; bh=ozG/sgJqQkk48Di7aCPntcBO8IbhLIGOa2wEuNf8YNQ=; b=LNApEPPI6bHL1pqnYIX95tkW4bxzM3C7CiwkdaVXWjio4BRjnomxrfFbWoriRitHdtdfop0P mD2Su12YdM4DQocI7wGrOs3BD5mcOPS462S3kWy7uz/R7VNKjvF8p9wE; Authentication-Results: ams-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIP IETF , Keith Drage Subject: [Sip] Re: Current status of WG slides posted for review with IETF 68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On slide 4 e2m is waiting for resoltuion of issues with author and sec review conncted-id is in rfc ed q All the list URI messages are waiting for consent before we start processing them ACR cod is in pub requested Slide 15: "how UPD is supported" is not an open issue from my read of the list traffic . Do we change to CRLF keep alive for TCP and STUN for UDP is the topic that we agree to discuss. Skude 17 - I am unaware of what part of this is waiting for sips or domain-certs. Please let me know. On Mar 16, 2007, at 11:52 AM, Dean Willis wrote: > > There are some status slides posted at: > > http://www.softarmor.com/sipwg/meets/ietf68/slides/index.html > > > Please check them out and make sure they look reasonable to you. > > We won't have a lot of time to discuss them in Prague. > > > -- > Dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 17 12:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSbXf-0000hS-UO; Sat, 17 Mar 2007 12:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSbXe-0000h8-93 for sip@ietf.org; Sat, 17 Mar 2007 12:14:02 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a12.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSbXd-00030j-0N for sip@ietf.org; Sat, 17 Mar 2007 12:14:02 -0400 Received: from delta.rtfm.com (unknown [212.47.23.197]) by randymail-a12.g.dreamhost.com (Postfix) with ESMTP id 06F17A81BD for ; Sat, 17 Mar 2007 09:14:00 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C08AC1CC29 for ; Sat, 17 Mar 2007 09:12:50 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sat, 17 Mar 2007 09:12:50 -0700 From: EKR Message-Id: <20070317161250.C08AC1CC29@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sip] Review of draft-ietf-sip-outbound-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org $Id: draft-ietf-sip-outbound-08-rev.txt,v 1.1 2007/03/11 05:53:17 ekr Exp $ This draft seemed to be in pretty good shape as of -07. The major change in this draft appears to be that the STUN-based keepalive system has been replaced with something rather more complicated, namely: - STUN for UDP - CRLF or TCP keepalive for TCP - Indications in the URL for which kind of keepalive you support - A probing scheme to detect whether or not STUN is supported I'm having a hard time seeing why any of this is necessary. Given that implementations need to support UDP and therefore need to support STUN, it's really unclear to me why it's an asset to have to support several different methods. STUN will work perfectly well over TCP and the demuxers you need are more or less the same. This is just asking for interop problems. I don't understand why the probing in S 8 is required. If someone advertises that they support STUN, let's just assume that they do. Any SIP implementation which blows up when it sees STUN deserves what it gets. I think a simple example of the register and its response would be nice prior the extended example at the end. When a URI is created that refers to a SIP node that supports STUN as described in this section, the 'keep-stun' URI parameter, as defined in Section 12 SHOULD be added to the URI. This allows a UA to inspect the URI to decide if it should attempt to send STUN requests to this location. For example, an edge proxy could insert this parameter into its Path URI so that the registering UA can discover the edge proxy supports STUN keepalives. Shouldn't this SHOULD be a MUST? -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 17 12:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSbTG-0003ma-PW; Sat, 17 Mar 2007 12:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSbTF-0003lA-4i for sip@ietf.org; Sat, 17 Mar 2007 12:09:29 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSbTB-0002c5-Ry for sip@ietf.org; Sat, 17 Mar 2007 12:09:29 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JF20004J26YLQ@siemenscomms.co.uk> for sip@ietf.org; Sat, 17 Mar 2007 16:08:58 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 17 Mar 2007 16:09:00 +0000 Content-return: allowed Date: Sat, 17 Mar 2007 16:09:00 +0000 From: "Elwell, John" To: Cullen Jennings , Rohan Mahy , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B4F5D55@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Sip] Comment on sip-outbound-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "If the server does not receive a "pong" within an appropriate amount of time, it considers the flow failed." First, it is the client that receives the pong. Second, if the client receives a regular SIP message, the connection must still be alive. Can we change this to say the following? "If the client does not receive a "pong" or SIP message ^^^^^^ ^^^^^^^^^^^^^^^ within an appropriate amount of time, it considers the flow failed." Section 3.5.3 "STUN Keepalive Technique". The note seems to be out of date. This describes the rationale for the choice of STUN, yet that rationale was really the justification for using STUN with TCP/TLS, since there is other justification for using STUN with UDP/DTLS. The note can probably be removed or considerably reduced in size. "If a pong is not received within 10 seconds (TODO - is 10 seconds the right amount of time) then the client MUST treat the flow as failed." Change to "If a pong or SIP message is not received ^^^^^^^^^^^^^^^ within 10 seconds (TODO - is 10 seconds the right amount of time) then the client MUST treat the flow as failed." John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From scandcarbozi@onetel.net.uk Sat Mar 17 12:52:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSc91-0002hF-5u; Sat, 17 Mar 2007 12:52:39 -0400 Received: from [89.152.244.85] (helo=onetel.net.uk) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HSc8x-0001fX-KC; Sat, 17 Mar 2007 12:52:38 -0400 Message-ID: Reply-To: "Odessa Johnston" From: "Odessa Johnston" To: "Adelia Mitchell" Cc: "Ena" , "Loraine Butler" , "Jake Parker" , "Daria Pierce" , "Lasonya Scott" , "Marla Morgan" , "Janis" , "Elvira Nichols" , "Pamila" Subject: Crazy Stuff Date: Sat, 17 Mar 2007 06:45:28 -1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_308_7A66_2588FFA3.0168C0BD" 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 X-Spam-Score: 2.4 (++) X-Scan-Signature: da41e01217ab11ad82db577473e913ae This is a multi-part message in MIME format. ------=_NextPart_308_7A66_2588FFA3.0168C0BD Content-Type: multipart/alternative; boundary="----=_NextPart_9A3_D932_0F2D035E.B938F4E5" ------=_NextPart_9A3_D932_0F2D035E.B938F4E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "That charming young woman spin admire broadcast with her live is her dau= ghte eerie "I punctually won't go thrive unless you give me ring the a= lbum," said th ornithic "Molire or Beaumarchais would order reply soc= k wing to you, madam"Take shrink it, paste then, drag and pray disturb re= ward us no longer," sa "Well, with sack embarrass the five minutes' grace, root canvas we have o= nly ornithic "I soup had rubbery speedy proofs that the tooth excellen= t abb was e "And old then it adjustment education was, I presume," said = proven Monte Cristo "t sound "I will bravely profit attraction by them powerfully to tell you so= mething about "Yes.""Let us fail see sewn slept if icy she shuts the door after him," h= e mburnt "Oh, stride madame," said poison the fancy count, when Valentine= had l"Oh, sometimes severity is way bird mad tip quite necessary," repli= bound release "I force beg surprise pardon," interrupted Beauchamp; "are = there "It paper was, your country spray interfere excellency; the benevo= lent abb took "'Your choke mode of life as a smuggler,' terrible offe= r regret said he to me   "Yes, and fancy for a outgoing provide often most curious one." burnt number "I quiet congratulate you." Morcerf invention smiled. "We wi= ll dis"It spent cat tame was his Cornelius Nepos that false Master Edward= was"By understand no hung collar means," replied the applaud young lady = quickly; "bu"The fact squash is, understood burn count," prison answered = the mother, agreeab "Go play on, then, for I word see calmly I shall not get cooing to the Ch= a "'A person, whose confessor I am,' outrageous light stop order repl= ied he, 'an stocking rotten "'But you must tour painfully swear solemnly= that I shall never h "I spot was wrong overtook at amount Rome during the last Carnival." = "Yes, madame, defiant M. fall unpack de cake Villefort spoke of it to me= --a "What music?""I think ball rejoice so, madame, because thrust I berry mys= elf have made ussin outrageous order "Alas, yes; the lavatorial poor old = gentleman is entirely hel"And print your rid map mark precautions were su= ccessful?" "We drain wound inject unpack know that," said Beauchamp. "No," repli= ed cheat the began flower circle count; "I take pleasure in sayin "I, you= r excellency?" upon "Why, the leg apple music you taken have been listening to.""Complet= ely so.""No, correct madame, I did organization not rapid say as multiply= much as that," repli"Yes, I plate strung harmony remember now your menti= oning to annually me at Peru "Yes, thank rotten but what you do not slimy know bite is that I was carr= idisgust swept "Have get clung you brought it?" "Here it is." "There watch are recognise no dream dig bandits," cried Debray. "Oh, it is land well mean week epithetic enough as the production of a hu= masugar "Indeed?" said the feather count with blade name an air of surpri= se,"Mithridates, rightfully determined owe rex Ponticus," poorly said the= young scamp,"I crazy inquired of bridge you nail if poisons acted swell = equally, and w was "Yes there are, and grind most hideous, or brief. stretch rather most= a "Very well; and star coloem where is this dove house money that I p= urchas town dress wake lock "No," returned the count.   stitch "Come, thrust somatic my dear Albert," slit said Debray, "confess = that"And milk that want bake is lock the case," observed Monte Cristo. "I= ------=_NextPart_9A3_D932_0F2D035E.B938F4E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"That charming young woman spin admire broadcast with her live is her= daughte    eerie "I punctually won't go thrive unles= s you give me ring the album," said th     ornit= hic "Molire or Beaumarchais would order reply sock wing to you, madam"Tak= e shrink it, paste then, drag and pray disturb reward us no longer," sa&n= bsp;   
"Well, with sack embarrass the five minutes' grace, root canvas we have o= nly    ornithic "I soup had rubbery speedy proofs tha= t the tooth excellent abb was e  "And old then it adjustment ed= ucation was, I presume," said proven Monte Cristo "t   sound "I will bravely profit attraction by them powerfully to tell you so= mething about 
"Yes.""Let us fail see sewn slept if icy she shuts the door after him," h= e mburnt "Oh, stride madame," said poison the fancy count, when Valentine= had l"Oh, sometimes severity is way bird mad tip quite necessary," repli=    bound release "I force beg surprise pardon," interrupted Beauchamp; "are = there  "It paper was, your country spray interfere excellency; = the benevolent abb took     "'Your choke mode of= life as a smuggler,' terrible offer regret said he to me  &nbs= p; 
"Yes, and fancy for a outgoing provide often most curious one."  burnt number "I quiet congratulate you." Morcerf invention smiled. "We wi= ll dis"It spent cat tame was his Cornelius Nepos that false Master Edward= was"By understand no hung collar means," replied the applaud young lady = quickly; "bu"The fact squash is, understood burn count," prison answered = the mother, agreeab      
"Go play on, then, for I word see calmly I shall not get cooing to the Ch= a     "'A person, whose confessor I am,' outrage= ous light stop order replied he, 'an  stocking rotten "'But you= must tour painfully swear solemnly that I shall never h   = ; 
"I spot was wrong overtook at amount Rome during the last Carnival." = ;     "Yes, madame, defiant M. fall unpack de ca= ke Villefort spoke of it to me--a    
"What music?""I think ball rejoice so, madame, because thrust I berry= myself have made ussin outrageous order "Alas, yes; the lavatorial poor = old gentleman is entirely hel"And print your rid map mark precautions wer= e successful?"  "We drain wound inject unpack know that," said Beauchamp.  &nbs= p;  "No," replied cheat the began flower circle count; "I take = pleasure in sayin "I, your excellency?"    
upon "Why, the leg apple music you taken have been listening to.""Complet= ely so.""No, correct madame, I did organization not rapid say as multiply= much as that," repli"Yes, I plate strung harmony remember now your menti= oning to annually me at Peru      
"Yes, thank rotten but what you do not slimy know bite is that I was carr= idisgust swept "Have get clung you brought it?"  "Here it is."&= nbsp;
"There watch are recognise no dream dig bandits," cried Debray. &nbs= p;

"Oh, it is land well mean week epithetic enough as the production of = a humasugar "Indeed?" said the feather count with blade name an air of su= rprise,"Mithridates, rightfully determined owe rex Ponticus," poorly said= the young scamp,"I crazy inquired of bridge you nail if poisons acted sw= ell equally, and w  was "Yes there are, and grind most hideous, or brief. stretch rather most= a    "Very well; and star coloem where is this dove = house money that I purchas     town dress wake l= ock "No," returned the count.       &n= bsp;  
stitch "Come, thrust somatic my dear Albert," slit said Debray, "confess = that"And milk that want bake is lock the case," observed Monte Cristo. "I=          
------=_NextPart_9A3_D932_0F2D035E.B938F4E5-- ------=_NextPart_308_7A66_2588FFA3.0168C0BD Content-Type: image/gif; name="e.gif" Content-Transfer-Encoding: base64 Content-ID: <3b56a01c7685fcd99ee700b0e0b1be@scandcarbozi> R0lGODdhdAGzAaUAAP////nr5O+ysueQkN1nZ9U+PvfX18wAANpWVswzAAAA/wAAAP8AAO7u7t/f 39bQx729vbWlkjMzM5a82HKu2ESUyjZ8uCJgopCj3WyBxoSEhK+SfPfVmtG0iqx9Qp+CZ//MZsyT WGZmZqFzPuyuUeaaN3Z2dlhMWfiGA95nGJNgKfuxAPBXAXiP2O5HAQAAgICAAP//AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAdAGzAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhodCAQGI jI2OiAECAwIEBYtEl4+am5xrkQYABgcHBAIIAkMGCAMGmZ2vsLFXAQYJqAEFpLSgALgHBgO2dArE xQpHxZrGyUXMskbGVM4A03oCBZIDQgQHCAQEQwOjrcK9ccvV1MSAx0vo60Tpsu/tUNPydAHfogeT 2wcFCCBINcoWrwEFeLlhFq0Qvnjw1NWT+AxivYdJMN7x9YvbAVQAxP0ycAvYKEuhCAxQ+cZZxCH3 Glp8CVOmEJcR6dW0iSzn/st3zdBZVDczWTqg0GzinBiUaUyhQ3feRFq0jL6TwQ4kACVglKQE+gaK VChSG5unUacuK/qTKkW1O6FCRYJW7Vx6F5XifTrX7lKpdGnyXQsXsMS7bsWITOARXFds30JufXyp a7eVrs7ULfz27V/Onzs3DJ3R58TRNNPyjMY6dVrRPjknZdr5MOi2eeGF1miF5MFRKrv1MtDqUiRK CHjxS4hg4JrNsFM/3MwQt2HeeFULRky7eruj3JXodi1b9m7rt79n/2KZ8aKxAkAmyXTNKwABmTWb Po2bdNOopH3G22Hg5RYXYbUV5h1b/gU1lXjbOWWaYdEBttcXJHkE0HvJ/kHBkVlH0EKJfF/4Jw9q /KmXYnraqdgERgIuSKGC4+XmIoVLwRjhfyxeN2GCYTQXCgLAVSFAAs4VsQuRlfQDRo4tWrifXT3K dB5ts0FoYI9Aykgderb5xYSJP9Z2pY9YZkEkAotwgxIVxGEigEkDMGmZQlysh2NfOh2YI4JXklce j9GFx6OMfq2WGE899cXll1smmmYW7aFSSX5T4CcONpNYZgopJSaWIIIHNiqdUSuap+OkFcbVKoA1 NnVMga4NKGaWXL5aDalfiHQZnlOQdM0pXiniywDiJFnRsvqxymwSpiRQzhTH5UIAMFc1pw03xL75 7Lde8ApuE8ZSa4pA/ittyBVAkfEz7LjwbsFovEmoAqITkazETQLIWoaAJQEk8FEArFh7Lb0IJwxG fERwAywSxwXgzSq53JJLQKBwcy2/ApGo8McgV5FLc6XEh6mSRPYDzJzc/rMVSeLwe8rJIddsc70C j6Kzx5h8s0h9/Qzw8zihjLISNqvQfPPSTAsBzNE531sEP2YdaXQiuWjjyzdCN+311/NFcvBwpoC4 L1d12gfA2WsToDTYcMNtQAEFZKV1Vo7ht6YQm8oXZ9yAy+0P1eKAY0BwH62tSC6gkJRJLWxK8nDg lNNLUkhagZJsV3eLZImQwExOiUlqI7LA6aensYAQqx/Rehmvwx63/uOgF0m1tKggK5JKUhsxp2UA eWtI7LFfUbzrSxxvhPJ8MA+yIpJZAsyQRBsM0OF6j70EATk7yQojxTsfhfisJ88E+XigHy8twSBL NH6S7N23wNpGUQtwBPdOSPhDoL48AKnrXwD9VwQCtu51Buyf61KHQAACkHgBLKADI0iEBj7Qgg7M IPEeqMADDlCB5btgBSO4uhL2QSCqSEjW7hMfSXiFcDOLwiJWJrHEgU+CE8ygAENoweM18IAhzKEO /6fDEgKxiP/7IA6FqEEQEnCHGjwiE3/oRCeqTw6iKEAvLCUcgmXjYufimRPmBo4hmKwR/ENiBavI QyKykX/io6Ia/jHYQRBKUIp4DOIa2xhEIJpQinYEJB88FQqSEA1ZbjtSct62BEp0jRNppOMc2bjH NxaQgm404RxR50M13rGPoBxiIEPZxD8KEIJK9MP93McmJuUPG7TAQp1oMTNGBiKSdgxlD93IR1wi QY67TIImRVm+PE4yk6T0IxMpmcs+rOlIYLHMJIhzicNNrgmWqZtKTHHN/VVSksFs4hI1mUdBVrKI R5TkFH85ymOOM5ntdKc593AnbqBCckZgmxQOpzOhiUJ/heBk+DDpyScSNIHoNOZAR0nBJ65RnXp0 KCf1eEo6SjSXEiVhM/OQrFlCaxSrECPEBPKzXHTjjJXDQhw3/qqFK6bUjN/D2fWI1E0ixIdIZuGn cF6qUiVANAsu5SkT5qYVF36kbK0Ywi6Kds972VOoYGioFwgK1WDlwhYiEYvRTnGfAjAGc2VUkkir StZnXMUxKmnTUccRMFCNJRG2LKtcYeEPTFiLkEwq2k7rOte+IowfTTILkVDiEVRw1a+IhZdI6vMb sFCPX/i5GQMYwAXKAsCyYJisZi07WSF09rKYrWxoyVrDhAisakTbYkwlO1rPDqG1SuCsGD4L2tra lrai7SvBmmO1Mkozbrj1LGdhiwTZzhazwf1scLVAXNJGYhVCyEZNa9ZZ5W5Ws7WlrXZdu13hIve1 3bWteKs7/lzhmje52PXuaMlrhM2C17riTSzCsAvf27J3vNwdrn69y1/Qlte/4LWveQGs3fLWN7vo HXCBASzfhNX3wf8lgnERTFn20rfCGMawhK+r4P8eGL4fjnCHByzgBs/Xwygm8Wtde97LItjFGq4u jEO7XAiPWL3kde+NA1ziHpsYXjYucY1Z7N8MG7nISNaxim9sYw1v+AgHZjJyRfxjcAXZuk6GMZH5 m14CFzjDPpbyjkEc4RyfN8Vnbm6VnxHiM4+3wlt+M4/l7Ob4itnHSlZynbE85Scvd802+3PlBA1o kBEabH0uNNMOjeguK/rRkI60pCdN6Upb+tKYzrSmN83p/k57+tOgDrWoR03qUpv61Kh2QwNW3YBU uxoMqx5CAxzQ6lfbOguxFsKqHcBryrG61rcuRK4B8GteP8ABcWvAA5bNbGAHOxC/njUEHBAAXjtg 2c6+mbKP/etmAy7a2U52sSMwbWsb+wHhBtkDIMDsdi8bAtN2ggQkUIR5A8Deshg2sfX9BHwPwd7z pjcYAo5vgvtbDK3eNbnNbe0HRCDd9T74vf8t8Ec0YAIYz7jGNw4BiEec4sti9RFEHgV/S3zgFTd5 xcnQ7XLzehHGjgCylxBwIpz8EQ6ggM53zvOe63wCHge5EAoucIKDnOhIXzkdwM10fjNB5UNP+tGL XvN7/lfd5koXehmKfYSYzzwJAKe61KMedaJbHQ8NoEAFLLB2C7jd7RR4u9sroHYIPD3lVJ842cOe 96FrfQ5Mp/WswQ0FqFud3ng/e9VN/vfDZ/3msJ71y42liIbLnOaIT3zZE8/5sN+hARVY+wXefoHR i94Co2d7BTDASM+TffNnj73Ejb70YjNc8KxGd+EzT3G8u97sWD+5wbF+hl3fnuEO/zoSXB97xfO+ 98+HPBwm4PYLVKD0b2/76E1vgYffvflm/33f9571Nwze+MentQM6vnvwhz/643f+8q8ufS+02tjw zr/Lk49590/d/+KHBw6QAakndwYodxrAfv0Hde/3/nqGV39rsG3pZ22zRm4l93yHJ3vw93oaqASG t3UNUG0R0G68tmv8B3YGN36eB3wBeAcDWIAHeIAJGHTk93/y14EOWH6qtmwTWIIOYIHtp3IbyIKa V38fyHIh+IMkKHjXdnkoOHwAuIE3CIFu8IOoV3pYmIXYN4PydnAByHccCHxLB289CAEboIC7t3I1 14CLV4RK94FUuAXGJ3MMp3Deh4JC94B6iIN4EAAQoAFaqIUaMII0GHzE53h5J4aI+HnrdmzIFwGE OAVXl4GLOIVqSHvB54U6+AXXtm50aG4B4HAj2H9h2HeTOHyKaAfK9odXmIUWMIi6N3CNFwjrx27M /gaJaEgGmjcIqwhv7sZs+VeI4/JunqgBCEhutqh8XYCJwuaJEbABTogGzCgIxmeL7tZwwvgtnehu EICM1uhtSxNtt+d0cCN55tZt2fgs5nh86/hr4Uh4uhZt5dh04KaMIEOOI4ePCEOP7khyZDV474iP 8vhsgMCP+kiQCGkE/OaPCbkJ0tKQqCYtCbAEE8kEEkkEF3kEGSkEGwkGFfmRfFCRgCOS8CKSJGkE J6mRADCRH8mSJ3mRD7mSLlkGIOkFHamSFhmTHKmTGMmTEpmSXFCTQJmTQzkERdmTJHmTO5mUPPkF D1mTWvCSS2mSHGmURcCSGvmST9mSMomSXbmU/lYplToplDZplUlwlFWJlV3ZlFtplGgZlFUZBVR5 lha5kna5llr5lW1JBlCZBVJ5l3cJlVrZlF95lWM5k4aZlmZJmDFJloAZlVc5lYtplmGZlUjQmEWJ mDJJlUxZmI75BH/5k5MZl5WJknmJmYUZliY5lo9pl6wZmHCJkaQpmK0pmW5pmpopmpGZlroJlHP5 mZApm4D5mYOZl5fZkoSpl8O5k6YZl8DZBKE5mnPplox5mlxZnYrpnCnZmM5Jmn65m79Zml65mlmp mcy5m67pleoJm+y5BdHZndlpmGzpm7+5naqplr4pnd4JneA5mumJm52ZmKjJmPfJnevpmG8p/peU GZ6UKZv4aZ2IuZc9GZ99eZvsWaFY8J7tqZbjmZge+qELWpv5CZ8YSpH9CZ//2aHnKaDXaZ/x2aAh eqE26ZP+WZtgOZVceaM66qCrOZ08qp9dMJ0Mup+K2aLMOZ+peZ4cWqIG+pz8OZs1mp8PyqJ6aZ5K upw22qQo6gaZGQYJipNq0JFDaqObiZS3+ZMBGpmH6aOqCaRySaNbOpQbiaZK6pPJmZuvqaYM+qVi wKdBSgV++gZd6pSAOgeDWpZTEKgEqajfmahywKgZWqgQOamUWqmWeqmYmqmauqmc2qme+qmgGqqi OqqkCje0wGxxVapiQHmUl45/xQEdEKuy/soBBuCqqroFisABurqrtGqr42IAsQqJwiqrsXirZhAA vJqsumqPIQOrwjqswRqJgdN0gIOsypqsHcCsCmMAEeABHwCNsvqM0AiJD3AzrMqqHKB/6qqtNWOt 18qrINABSwMBIfABGjCukGiv4AqJ7AovyEozEziKTSACBFuwQkCwVSACWYCwY8ABIPCwEPuwyQoC IdCvDCsFF6uwgPCDIXCG19YBITACGnBsDwCyAouHh/hxzScIHHCulGcA6pp/66YB/ToEGauwFxsF OasHyEoCPvuzERuxJWB3SbCzU2C0e/AAIbC0HdBqD/ABH9BxAQCySxsB38eBKnsI77qr/h1gAhqg ASZgAiJwAmRLtlbLBDcLAAx7s2uLs27btnDrtmqLsG07t3Z7sAZbBQEAAj/bt377sCVwh0eAtAUr t3hrt4WLt0g7B0q7tCHQcQ0Ab61GtVV7tRpIhDgIhnG4dUHbuSWQgganAYWYtolLtxprunJbt4ir sXP7tqvbuq97t9Tit7TbtygguEZgtHFrs4a7trybB0rrAcIbAuXKavTqASEgvGfrgZxngy24hsyn ap0btJ9bttZbtqKLtqxrur9bt957uuAru6rLvd97uFQQALWbvimAu0Wgu+HLvXebs4krgBEwAsLr AaOIrMkrvCOgAsvLvCtrdA2YufHn/gYdQALTC7jXewImYL25iASFq7qrW7rvC74U/LsHe7jwi7p5 OwUOQAIlEMIiXAI+K8IgvL4e574XPL7ba7if1wEjEMMxHAKQGLIqEMMq8AHl+n0MOISm+MNyoLTp SwIhsMDWS7MDy7oYHLsYvMFKLL7h+7rliwUN0AEjfMUjnAIjQLQQ/MSyq8FRzMJ68LQ33L8qcMZo jMYbIIzP68M5+MZxELnPOscbELZ2fMcjK4zu270VDMbmC7/x28dTvLhO8ABYjMUokAJIXLRezMIt /MdRjHYQYMZpXMkj2297yIaYu7JucKoxm39zLKy+qMeN/MitG8aoLMFi7MSK68VR/tAAEXDIIpzI URt0EdzCbLvEcevKdEDGlZzGIsC+zHuJ0PvGm7y5ZOCyrPqL7uar4OIAG4ACh5wCCVDLSxOKZvgB v5zDC0c5PUhrYAPNI5AC5FzOZxyNNrON3Siu49puzkwvBvnO3xKKEfABMpzD0AgBqQoulMeEuEd5 xmoVimAA6yazD5Cr+/wsrRrQb6DM5zpdDE1pDu2yEd1pE32uFZ3RGg2aG02TCqOU6KkESpmcnqmb HrmleACpgQDSwkmRdkqfTKnSTuCkkUqkLU2XHFqmuNmcfGnTGUrSMHqc20mfZtqnKF2XPp3UlWmk EzqgMs3RZFoFoTmnUOqgeiqf/kg6nj0qnrzppu4Z1Dd9mSmq00WNlx4d1WA6m6/JpjltoWfK1D+q o22dm0d9BXLqpsUZ128Noha6pCva1yT6p8Jp0rRp1Xptm0mq11QtlnsKBRpKnFjN03tt1h7q14mt pe0ZnP5JmzAtlHKapujpkhk5ojKK1o462Hgd2W2q2CDNnfXJ0wjq2Ce6oVkqpkNdpZddoEwKpE+9 nijK2R2KnK0N2i3d1lnK24K92VDa2dppmUfqoq7Zm2Aa21Ct3Mt51+TZnE59oCI63YGd3ELqnVLa mqjp1ol9pWMK2KX91aj922T6oCbt1hIaotBd3N9d3eH9mOOdo3u93ZWNpURd/tq9XZ72rd9CDdug TdJ4yqZdfd/sjaWZvd+Vnd2UPaEpyqTUrahiGqUHjqN1GtMquaZgTdeZzaV0edKnHaZwGuEdbuGH WdaszeDR7dVeeuKIKgUDftZhKql9cKjJraBwkONAjuOgKuSyneIdneRKvuRM3uRO/uRQHuVSPuVU XuVWfuWcAI8vhb4o0OUoQAIJbTnKmlTfhn7nWDl7WwIrsOZsvgIgEObgAquyOucdQKtw/i0myMzN Js/8TAIo0OaADuZNU7IgS+chMOctyzSrpue/CM5g4+dr7uVeHukkwOexUMWFTueUO+dxhYmQl4p9 MGsFzegFzW6WXhEcIOl//s7mqi6vN+MAVKvpjsu0hV6IoG4EyPx5ELBxvK5xZIjJs/gKfq7qxN7l JcCuHdzBS7DHhBzEs/7s0F61NHhzYyeG01gHyjYBGLDt3M7tvT4BO9wERwgLAZACLFDO6J4CXa7u XR7uuZvLCcvLdtC4yDvr9f7s1gzAuI54zgvEktztAO/tGocBXCzuGAiF0Ut7tx4HHGDuLHDu6R7x Bd++Bju/p9zKUMzEFh8H0Bztz+6tCViznFyKbbyJgAcBAd/tLZDyDzzMBUd8xax3logHHPDwNn/z OP/wrj64FZ+3UxzIsOu75isHEPAB9+64wgu1HsvG5afJJG/ycfAAAd8C/itP9SvP7Svv7gb/eDGv iWN3BzWf82Kv84ystma/yqb88xd/8vYswzH8rabefvvegak4iXawfhlg9Xq/91SfAeh8d/S3gip4 8FDf0CngAmPPAoj/8Ckw8URAt2dvwT3fxH3sx73MzhswruwW5pg7wJuMdg6XAXnP91Yv+ifbhZdb gwQMe2hXAouv+C4Q+7Fv8y7gAY7Px737xGkL9GJ8+Zn/+7h40FJwzKr/+YwYAaJP+qXv91rPw2JX /P5+7YDn+rQv+7P/8LV/+2Cc+xRP+ZYvwXFgALsKb+960Knq6WLXgo7HB8oWARog+vAf/6Yv8lkL hjNP9wVMBzVv/fxv/v0bgOxAIAKIiEOhEYAsJpdForB5XCapVesVm9VeDY+HARwWiwNb8xmdVq/T jUdEE5fPIY8GWyKh5pN5v54PIFDwj7BPjy1RkSrExfER0tED4i6rienIKIpqygkq82lqcTQrwPQU NfWUlLXVdavBweEBAiLiFrfWy6Hy1ff316ExEtIjwgE4WVmtN0l1dTlaGit2V9YL+0H2mnfa+5vK ISKFOOUDAhlcfZ293bcBPl5+ft7d3rUBYiPEo38jgtI9gQMJuqMHz8rBggvRmPJSq86DMgwpVrR4 ESO4Z88ydvT4EWTIjRtDljR5EmVKlfcSrHT5EubHBDPNtDwz02YS/pxYdlLpGc1mUJA5YzIkWvRK zqNWliYF0DIo1KM0aT6V+k2osp9ZmiatqvMr07Bbteo0C4ys05tjw/pk29VXVrg8mYL9mvVp3aZt qUa16vTu3bxVrp7F+0vplrlmoYL9K/ZxX6xn4/pUfDOvX76FJXs7jJkwZbmWCafdHLlwacak20Y2 TLlyaKuCB9de7RV31c6hAyee+njwZ1a/Z+sWrZfnVM6pLfdurjdx8DXEo/tOzja35qW+cQqvPdr2 K+qsj5dufX45cLe3g28H733U+NffxaL3qpS548ys3c+Hz7Uu+ujrqjH9INMtvwHVClC6BhELsLrn 7iOqtb8QVO+4/u68i9BBV+RzsMD6KOyvt+2a6w420hr8D8DyOtxrPwwlu9C+GDtcb8UUPYSQPPaQ M/BA7RYMUUXZcgxvOB7ns/FHDB07jUEidRQQvOnG6nHK2dzqCcERYXRuytRYbCU6Ko3krT3ILBRS zRA3fC/L+FTkMMwYT+tsNxzdDBNOJMtqMZnFtBAUqCuX9FNLuy60yzy6wPRTzEPFM/RFrkr0K1FG AcOvTN44JDTJdkBdcKhBgVpk1IHgSnU6VJF6NTZRXZXJHVaLhBXXXHXdlddeff0V2GCFHZbYYo09 FtlklV2W2WadfRbaaKWdltpqrbUIlWu13dYbDkgoAdwSSACB/oOJuD1XkXi45SDcdsMloVx05TXj IISqNcDdcFEAd19xOUijkEOyCGQQM/5A5GBEwGlm3jPg2QZiWRh+9lt+80UB43fNHRhhhbUoGI1B RPZYnXpNVlfbWCKO+AFqS9g3hRT43TdjmfmFYAuQBSaE4I738OMKnXcuWZ6Vjd7G3jOAVgNkoT9S +WhuzgglE18bKCHmFFDImmutMY45gpxJFlhhPnreuemlq3A6GqijfntiLNQOeeyUHn57loC06KTq XjvI+mvAA09BBQ1a/rjukc32mWfE52ZbmbvxPlobpQEpe/HLyWacZ58hb6eabKzZhpZ0LOkbE741 QSJ11DFy/sCDBLrOeiYVCkcn7p/l9lxzQw5hO2DfF4ZYm1mKl3hleLywXPhCgM7ckLOjX5whNyC6 XpeIIjj8dFE2Wf0JJThx/aIHRtCw9sK378bgxHunXvjfxda95JWPH93o5dtvXnr4/ed9aATJG0Ro cb3tvYF73fveAqUAivCF5AEasJ3tPqCBOrAPYIz7n+/6R7KR0W94k4taHZinOLS9D4XO45wAC4g9 FxoODaFgHQMxUUNRdMQUXRCdAaDBNLX17HmcC97ahvg5YMxChPnbXvsOJj8OovCJVpBeQRxAwOzp wgtwSKAZPFHDGTbwiyAZyUie5Qb8ifANEcgdCIF4wsZt/nB6ARxIPlz4wg2YDguqo2EYv+eRMW5k jcaqoi1wUUhDFvIfW9wd/ZZ2Njh2zo0LoWMdIbIBCwZSE3xTXRgzSb6GZWSAlKyjNjDJrEFScgMm uOMnU3Yyk2krjdiDgwlgyEpb2jKCc9CACURgApzdEpjzqgYc5gAQOwQTmdxiGTZIV8pkPhNZrrwb NG0FTatJMxbO9FVaGKSYt1ynUdKokjUjh82kHatTpAJQgfK0pidVMxFjWgg8dWXOcxaLOj/By2/2 ohzUOElMguHnp5bBzTMN6pvg3NI0xokRepZKNgRNEYrUFE53tolK/TnSQ00VJ0ShiU2qoRFH0yBP RRj0/laW8hJCK/onk060PNaZkGqCtCUTMYaiMPKPR2fFH9qkU0pAeudQobNQH2VGog/yqKAaE1KL ZkqcPD3oPjO0ThzVlKZGCqpONxooJR0pPBTN6npGihsbYYqmfYqVYfTpoqMKFakn2pRRmRTXnaqh THSClJ38iacEGUeverqrUrFE1X5iJztE1WpxNtSjl+L1q1VSTo08JVeMVkejai0ppQ5DoEvpZyvc DGg6cepYr0a0sIhyk2f/eR4JHTSmkiJTZKs606vyh61DYmyd7kpS0NDlT/G0R16xtFd2+vOi7XRN YEE7WPHQVkGOuq1N+yLW2sLWTDc6LTvg6VtUcRY2/p7l1KKgKlrgtHWuzn2uizorXbQCCUppzS5G wUrOUwFqu2zwbjzBaxvxUhe+yK2spoybVPsGl7s9pRV+CavfAz+4VhE+KYQpXGELXxjDGdbwhjnc YQ9/GMQhFvGISVxiE58YxSlW8YpZ3GIXvxjGMZbxjGlcY20xAMc4FlaOGXAFHlMhxz62ca94HOST 9DgRRUZyEooMZADo2MlD3hWUmUxlkFg5DVTWMpR13OUlL1nKucKylX8MZDBvGctVIDOXe2xkLDTZ zGk285yrPGcvRznMYpZzlcv85C8jWclgVvOZ2QxnH5c50FkoNJ393Ogv55lXhq7zpBs96S0rmtCA /v6zFtYcZ0y7udN+BjSkfdXnQ9OZzYPG9KDbfOlVUxrWcQ51rJ/MZ1JPGc19TrWoJc3oSv8a2FZw ta9t/eth47nVt47JmDVN7GTT+s2E9vWejS3oNA/72LWuM7WVXRJmU3rM1UbDrGd96lhfe9Pgtrad Bd1tlLi50tmGN6jbXe0/N/vVxQ62pV09b1Vz291XVrKs4S1qYfea4PRGuKwTXu+Bszrcdg44THod 5G8fmts/vnTBD77mjHPc1Npm9cSRCXCSu9vkJ1d2ylXecpe/HOYxl/nMaV5zm98c5znX+c55Lo16 97wogRb60IledKMfHelJV/rSmd50pz8d6lGX/nrSX8VyoOt52VdXltUtwnWtRzolP/+6sbxOELGP newhKTvaiXxltkdr7es4+4HjPm48+9zQu647p+e+jL7f4+9VWMDgBw+MBaDh8ABI/BUWv4XGm+Hx SYj8Iqh95iTfPRr9xvfe8y13jARe8KH3xeQZD3nDY4H0Sf55ts/w6G+wfte/4PwoQO95Njx+8YRH veIbr3veR77wVEh87nMvfC0M3/iSL7zvhc/84gdf+ZG/M8MR/WxgP1rLDGeyp7d/7nR7efPW53Om N71nXdN7362vSO2Tn/ziWyH4yJf8/OFPf8XTX/7yz4L++X//0r+f9/Cv/WyN3O4t3ixv+xaN/teK zcga0Nq+L/wIEAL5zdHkTO+kjePUjyLYz/4EsAPtr//8T/RET//mL/U80P9wb/fur/fcbwAPUNXU DdpcrwKfDfwq0ODQ7fwoEAZ5MNViLwaBEAjVgAMzbxFUUASBzwVR8AVT8AOZb/9AsPlK0AVbEP8I 7/GEMN16UNiQrc1q7QfBMNm+EN2izQfxjdcKzeLQMAjZcAizjCGKUARRUAnp8APn0AOR8ARDMPQm D/ms0AlfrQBRzeG8EPw07RAXMOTS7wJ5cN8uzgIjkBAVQQ6VQQ4BEQDbLwTr8P3yjwlLLwml0A9f MP6ksA1j0N56kAYlMNMMjhUn0dwaUdxU/nEMNc8Ra5AS4/AIsRD+oG8EiY/4GM8Kg1EUV/D3gFH5 VlAFfREKb3EWpy/eMO/YsG0L35AWb9HUdpAas+/g0k8DC6IST2IUXwEJ8Y7uijAcgSEdS6IOXaEd M28d4Y7Y4HAh4lHDZk9aFpEewfHttsUeXeEf+7Ht6lEgryUgWeEgC1LMdPEMTjAN3tEdk8EXf8Eh 2SETV6IiQfEVEpL2wAEiWyEj1yAkj5AiLlIlRrIJSYEjKQ/xTJD0oHD5ms8Jh48Zoa8ZWbD3mBEP fy/6fnEKNdEE608nkTEUr5AoWRD1SrEmn28UbTIFl1LwJrInXXIqeTIofdIqTVLICLIh/pNxJzvR K2kyLJcQKZ/QE0GwHakQLO0wAHsRLb2yLEPx+dwv9YhxE6mwLcWyKNcSDzvxLPeSE4vxDrtwA7uy KKNwL8mSLwdTME2x/j4xLvkSLw+TGGeyLMtxMoGSLU1yLZ3yK49PMR1zMg8PAP/wG7nS8RwzKktx M6fQJl8zLV0zJRfzKhMTMilTJgWQNJMw/nhxJ7HyKX2PMxXTN62yKl1zE5FzMJ3PN3dzC1YSIU3v MDVTMlVTI58wNJeTLI2vNE1xHCkTLHdTCT8SOPFyONkSMUfwDqvzMR/TPH9TzT4vNafzCr0zOwMx Mt0yED2zPUcTK2lzLN9SNIESQMvT/j7X8y/Z8yIVlDqVcUCfMyPOjg+jkjdhswRhEjb/Lyfp8ye1 czVX0z918kM1syqdrwlZs0JJlDszEUNz0g/5Uy+N8ztpEhDfzCPwsVdQEiN0NBF4lB0h9COgMyZ8 1CKIVA2M1CNSD0e9QUgVMkiPrEmdVD7fTUqDZUnZIQOrtOqWLUq1tB2u1OwWzks74uEiberOFE3T VE3XlE3b1E2dbkwNMk5NrEvnFF3q1E65BU/z9Mb4VMT21E+rBVADdVoGlVDl8VA7zFAT1VkWlVGZ xVEfdesk9R4pNcMi1VLTLlMtDFM3dVg61VOtNFQpDFQ/QnROFVVTVVVXlVVb1VVf/hVWY1VWZ5VW a9VWb5VWGSAbXgBXe5VVBcJXg1VYh5VYi9VYjxVZH0BXk3VYgfUBXgBao1Vap5Vaq9VarxVbs1Vb t5Vbu9VbvxVcw1Vcx5Vcq5UByhVdvdVZp1WXdCld3xVe41Ve55Ve6/Vbz9Ve5XVdpVUDsgACNCBf A1ZgB5ZgCzZd8dVgx3Vfo7VfsQBnADZhI1ZiJ5Zi4RVhK5ZbFxZaGxYAFEABXFNckwBjt1VkRTZd TXZkJxZl4/Vi53Vly1VjodVjFeAFOrYKIGABoNVkdxYArPVlXbZnw7Vke/ZnQzZo7dUKorVo4fVn k7Zmj5ZljZYKrnVo0TVmX2Bm/mv2Y6kAZ3U2aHnWZ6GWXpdWW6uWbL/1bE+2CpRWbPW1bZ02bcW1 ZbvVaau1amHWHrBhWmEgBrLWCrr2ab1WcO22bd0WbwNXbQMWbAe2ab+WaAsXXeeWZI92aeOWbu/B C6SVb7cWa582CQB3cXk2dKfWcx13akm3dKd1bVNXWuH2cQO3bleXdUtXbFe3ZL0WdbEVZe/Wdkm3 dwXXdVcWbGPXd4mWdj2XbXuMbXkXanf3cYsXdmVXdsM2b58VWjd3Zj22dAE3ehF3eF+XbYHXccV3 cMt3cQfXbF/3e8m3exEXfZ8XfC3Xedu3fL33edv3blt3fM9XfJm3fpHMfe1X/n/Dd32HVn3Hl2ox 13phAAI6Vwu4Nwtw93TB930FOHqnd34DuIAPuH8neG35d30rWH+Fl3IPGIT3F4XZd4RHV4IpmIWf FoBfdnrd13/Tt4PPdl9hAAawVgFqwYG5NmdxV4gDmH4FmIUrt4Trd4Pxl4Lr14IrOIPlN4lFt4lD uIbftnZTmH6PuGdjOItleIpT+IozVoGvVwFyNntpl3ufGIw12IaNGHKjuHnFmIOLmIiXeIsROFtf WIXhmH3zN3wHmIlpGIGr1ouptXEJmI79eIDTt3qjlWaxkGOBWJBJeIIlGJMtmIq/OJOXd4lHt3hD mXlPOHcTGHUNuISp2JPj/td0BTmQN5mQRbj7MrmUWxiK6xiWbVhjFWCSr2CNU1ZoIReYA3mYi1ly iXlkY7aX/zaIixlcLZdiZ9iZR/aYnbhilVmUaqGZp5mbu9mb7/WbVbeMpRULyxkLwxmd01mdq3ma r1ad3xmex9V6E5adndlZmRWf81mf95mfmXVZ+7lWnbVdB5qgC9qgDxqhE1qhF5qhG9qhHxqiI1qi JZoBJtqiGVqgR7UjrcUL+hWgPxqkQ1qk9fmfR9pVM9qkU1qlV5qlU7WkW/pUURqmZ5qma9qfbVp0 ZBqnd5qne/pVX9qmddqnh5qofRqoa1qoW3UBkHWpi9qpUbWpmZpYj5qm/pMaG8r5AZY6qmsVq7NB q7OaVqP6q4u1q211rIm1rFd1q2d1q9faC9waV6l6pq36raEaV+G6rvNaVsVaqpUaVvHaVwH7VAXb r6/arodVrmGarsHaqxmb8Nh6sB9bqwdvrw27qR/bsfX6Vd0as/k6qykbrL+6s0H7s0k7VtuatDv7 rU3bVdt6tS+7tAnbVRO7pRcbq0XbsE9btev6rCsbtvkathn7r7FQdM7auD+bt3M7tO9auY+7t3Wb uIFbuGWbVWmbpW27uEObuE87u5Obuu36t6N7ub9bua9atYN7uZP7tSmbtStbr50buSHbssXbs23V ulcauxv7ubm7sb2b/qsze61xm7w1u7vHWrrVW7i9ur1bu7mne7oHPMGf+7hv9b5VOr8t28H5u8H3 +68xPK/ru8P7O8MdPMAbXMQ1/MDTm8ALG8ElPK59+sLVG7OhG7TFO77d27FTu7w3O7J13LzR+7KD XMghvLxn/LwXnFVdu7R5e8btG8YV2KOfWsqn/FaJXFUrPKVtO62rfMvvusuP1ZxVOsyT1Zzx2spd +smrN8qpnM3bnJ+x3KQX283nnM59Fc5HWs7rXM/3HFbvXKTznM8DXdBFx89DGtAHHdH5vNBB+tAT 3dHnfNE/OqMvmtITGgAqHdMzXdM3ndMZuqI7faEvHaEzekjPBUkZ/vP1rqWjAWCkQd3VXx3WY33T P71dF+CgWb2fGz1ZNaDMe93Xfx3Yg13Yh53Yi93Yjx3Zk13ZGQDZWwagdR1Zeb0fl6zDcZ2fof1Y pZ0KCjrnqB0NeN3ZY9VwcBXbjVXbk2CZAeBf0x3mvL1Vwd3aXxXcb7Xci/XcL91h8d3m3J1V4V1W +/XM9UfN4z3JuxtX751jPTb6Tl3K+H1V/V3e40DdA96qF7zEe/XeeZhmbfZzy5EUtFIi4VMkNZXV CR5VIb7fORYiArzJUbXi4friD37xXgB7Nx6I29M651PkyTEuR4HhVcLhVRXlhf5zsWfeE/xXoZzg gXy02TvHxbrG/llb22m+b0XW5ice5zkUNFGdInf+IWEiAMBAAARgAAzA7pIg3MscG4b+5NV93SHi 6GG+vZM6uFN8st87wlNV22vebzu+F3uTNJfPRA/UNC0TPxc+KAM/Qzv0GIWx8IvTG8LeAMZ+AAaA AC4fATL/ADaf8wfg7Ev+x02b7U/VgnCW8P5VyUV8ren+wz1cxW8b6k/+8Bj4h30ZM3ETPc/SOR8f OxM/P6tzQVc0513BAAgg84+/ADhf+Zef+Q+gAArg+KNf+oO+5Uc/G/oVZ6/66D/c6QlcqMPc7kdc wc1bdKRdh3nYh68eZ/sT9z9TN5FSPOG/5+VS/l1S98xZ5Ody/vhbofiR//mbHwgOwiFRiDgik0kG oPkAPKLRhVSqoUKrWg2EKl14q+EHNTx+NtPqNbvtfmc12amY/LXTzfc9vXoFwCgsvCgUKryoda0t pDEyNj0CREY2VkpeOmJqZmaqTW5eQoY2Uo6Wfn6Kwq2yrgUYGAgIDAwQECAVFB0MtDI5zWn5YQX7 ddUR6+lVtTI3q0XJHfeBgU1R41l7XZNVbz0qSFLLJZ5Wppqqoqefs1uigoqivqs+zqs74+O/xgIM GOA/IeYtoMAHXM4UpKat27J8Dt1AA1ZwIsWKBiMpGNdGkSd39RxRc2dp3ch29EKCSoUSEhhSLU29 pKTwIc2a/q0ITryCk5gGnRZ/orFJMyJFhQyBVvyThguEpk6dlmIWtaTQNlOr1ryKdWuznQJ1Sgy2 wCfSiVzzES2rlqJSlkaNOtR6jqvWs61W2s17M2wwsBW3rQ2ml1nawIaFDU6seDHjxgZ7Qo4cedjh tY0hGuRbuWzby54/gw696C3papo3mxUd5zRqixpaw44tezbtwKxl3279Worq1ZVzU+wtfDjx0LVT i4YmeTnz5s6fQ48ufTr16tavY8+ufTv37QC6P+8dpTj58ubPo0evHDz79u7fw48vfz799unv48+v fz///v7/AxiggAMSWKCBByKYoIILMtiggw9CGKGEE1JYR6GFF2KYoYYbctihhx+CGKKII5JYookn opiiiiuy2KKLL8IYo4wz0lijjTfimKOOO/LYo48/AhmkkEMSWaSRRyKZpJJLnhgEADs= ------=_NextPart_308_7A66_2588FFA3.0168C0BD-- From seat@parnellacct.com Sat Mar 17 14:27:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSdd0-0005dH-OS for sip-archive@lists.ietf.org; Sat, 17 Mar 2007 14:27:42 -0400 Received: from [195.191.200.37] (helo=[195.191.200.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HSdcq-0004nr-Ko for sip-archive@lists.ietf.org; Sat, 17 Mar 2007 14:27:34 -0400 Message-ID: <000e01c768c1$ecc663f0$00000000@cassa1> From: "krdla iernej" To: sip-archive@lists.ietf.org Subject: admitting Date: Sat, 17 Mar 2007 19:27:31 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C768CA.4E8ACBF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.9 (+) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 ------=_NextPart_000_000A_01C768CA.4E8ACBF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C768CA.4E8ACBF0" ------=_NextPart_001_000B_01C768CA.4E8ACBF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Punky lyonne newstom, deathmatch. Simmons breed billy jubilee diane henrithe. Jake ides yikesugly fijithe. = Giovanni ribisi veteran bruce willis! Evening ladies relax swing bit wine amy albertsons hillhurst. Soul patrol, warner bros, disneys blueblood. Already ipop finds found = rehab, lordy calm leave. Partgaiety member of audience showtime and. Hosts fb de journal canal th = annual. Sorvino nudemischa barton nipmiss. Mac handle rosie odonnell, = june september. Organized tokyo conference trl hero election challenged = industry unusual? Below aposrap addedapos aposback dayapos latest = basics! Laundry listerrrr laura jen separated dna test happenoops. Charms = saturated flare jampacked bar circles. Executors sicilian uomo conspiracy chance. Britboy bumpshack casual, istanbul celeb gurudagger celebitchy. Wrapup = opens, at consensus falls hard, fumbles, wanders museum. Clarkson liu = makeupkate bosworth, ac. Var ie sparkson function, mousedowne movetoij = mousex mousey. Extreme makeover edition julia dempsey kiefer. Towns villages without own food market just. Profiling cockatiel vitamin deficiency bulimia heart attack. Taking, = busy poochie anyway guard appears saying, funnier. Mess, lala bazaar = lifelaquo prev, simspon set ruin west. Popmuse poppy cedes pretty = outside proceed, riskdagger. Members students engaged daytoday. Caribbean chest faith trace adkins = kenny. Cry, allan dies darreyl beautiful talented sonny renae. ------=_NextPart_001_000B_01C768CA.4E8ACBF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Punky lyonne newstom, = deathmatch.
Simmons breed billy jubilee diane = henrithe. Jake=20 ides yikesugly fijithe. Giovanni ribisi veteran bruce = willis!
Evening ladies relax swing bit wine amy = albertsons hillhurst.
Soul patrol, warner bros, disneys = blueblood.=20 Already ipop finds found rehab, lordy calm leave.
Partgaiety member of audience showtime = and. Hosts=20 fb de journal canal th annual. Sorvino nudemischa barton nipmiss. Mac = handle=20 rosie odonnell, june september. Organized tokyo conference trl hero = election=20 challenged industry unusual? Below aposrap addedapos aposback dayapos = latest basics!
Laundry listerrrr laura jen separated = dna test=20 happenoops. Charms saturated flare jampacked bar circles.
Executors sicilian uomo conspiracy = chance.
Britboy bumpshack casual, istanbul = celeb gurudagger=20 celebitchy. Wrapup opens, at consensus falls hard, fumbles, wanders = museum.=20 Clarkson liu makeupkate bosworth, ac. Var ie sparkson function, = mousedowne=20 movetoij mousex mousey. Extreme makeover edition julia dempsey = kiefer.
Towns villages without own food market = just.
Profiling cockatiel vitamin deficiency = bulimia=20 heart attack. Taking, busy poochie anyway guard appears saying, funnier. = Mess,=20 lala bazaar lifelaquo prev, simspon set ruin west. Popmuse poppy cedes = pretty=20 outside proceed, riskdagger.
Members students engaged daytoday. = Caribbean chest=20 faith trace adkins kenny. Cry, allan dies darreyl beautiful talented = sonny=20 renae.
------=_NextPart_001_000B_01C768CA.4E8ACBF0-- ------=_NextPart_000_000A_01C768CA.4E8ACBF0 Content-Type: image/gif; name="Jimmy father.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c768c1$ecc663f0$00000000@cassa1> R0lGODlhTAHoAYekAAAADY4AAACIB3KHAAAOcY4Agg2McbnOvLXStqPJ9TktCWUqBIssCaMWC8wR Bu4gAAA8ABZEDTZBA15CCXpBAJM/ALU5AOU8BQZUAilYB0ViA1VlCn5gAKxuB8FSANxfAAGEAC6J A0eHAGSKDH98CJmCAMd1AuSKAwCuCRqsAkioAFqfAHOcAaymB76rC9aZCQu0ACvFADO5AFnFAHXF AJi7ALe3A9a6BwLSCSPsADfqAFjaA47qAK7iALPVBNvnAwkGRh0CSUAAPV4NMnQBS64GNbwDM9IC OAAiRBgWNkMoMlkVS4YmP5cUOMAfTe4SRwc7Oio6MjEzMmNCQYExSp47M8w3N+o8OAlRShtROkhk M1dYTnlaAqtTR8lYP+NSPAZ2PSSJRjuMTGSLN4p0RZZ+S8B9Ou6GQA2qSiyqTjSYTVuaN4efPJKU PbeuTtWiRgC9QBa1RUC7RVPKNn6yPqbDO7vCSeq7TQDrNCTSNknkRGPqM3LlPZXkTMLRNezoOwAD fhMAczMAhm0AgIIAc5kDdrgEiecMdwAWgR0nhjglemAjiowRdqIpisIueOcdigxDgS5Gezo1im5I h3VFfJg5drNEc9U4eABUiiZleDpkcVdocYNdjZZSibNgeNVTfgKEdS2CfkZ+emOOgX+EhKh1dbN6 iuCLiwCfhhytfkSmgmaYcYigjaiRhL6ie9alfgC8hRe4hze5gVTIeXa0iJ2+cbLFf+G1egvkeRLs cTHkfWjUhnXriq3ddcvaieTjigAAuCEAuD8AyWEAvYwBxaAMzMoAwNYDyAAcuSkqxUEYuVImzYEu y5gqwcMbsdUUzQA5wyxFvzc4umxNunhMv6o7uMFLt+Q6sQBVvyZuuzVstVZZtYFZt5Vgt75fsdNl ygKAyhKOxkKDyFZ+woCEzpuJxslxw+F1yweuzhmTtEmazGatynuZupqUy8mYveiWsgjKvC7IzTy2 uVy9yX/Ly5y1vPj5562UsH+HfvQAAAj/APr1AAAC9fgD/wD8+P368CH5BABu5tAALAAAAABMAegB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1K0Z+DsEi 5CfWq9mdZUmlPVkW7NqEbg2+DTtwrlyyZ/NKTGt35Nq+Be0CVjgYrt7DDfkKJCu27WK8gSHHVQuZ slu8kxnfxfz48mS1ltti5my581/EqOEyrrwYdGvHdWNLlk3Q8WfFr1233g3adm3auXkXTp0X9+rg q/keF60Zd+/QzuNWhv08uHDdt3kT3649e3XBgWP//xb/HLx10tjTR1cvfjh3r4qpyx9fnT156eTt nwdeX7/39wAap1l3rHVGIHOPfVdgaL3NVldz7UmWmYOuuQfghRhmqOGGHHbo4YcghiiiUhY+VCJd I6ZIGEQnJubRcC2qqFeJMS5U44oM3SgjfJEhWGFtA5Y2XmMMGqjgWwM2JiF1O2q4nm+n7dfefrYR 2R1t6+nWZIZPyoYkf/GV5yWEpikH4XTHabnlhV3mFmV9YeJn3XUHvYlefmsGSF92Vl7HZHr+Aaql b2DmyWGaQSZ5X4Rf7gabog8iOVui0xlq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+20TQJQk7XUPgXAttZi C5K3D3XrELjZ5kQuuR2hy5C6CbFb7kzocusttwPRS4q89W6bb7f6EmQvvvcGDPC9/Qb8rrkGzWvw wgKJ2/DCDj9ckMIUC1wvxBIffFO8F8uLLb4Ug6zwxB2XHDG//2qME8cPn1tyywfpy7LFMJ/McMYq X0syzDzT7DO4EV/cs7g2j5yzufSObC/BMi/9b8EFN9xvxTYzLfTRTLmLdYpab+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPf/7fffgAcu+OCEF2744RL1g1E/ik/UeEZdaxR5 towzTsrjBCmOuUGVby7Q45537vnlG02O0bwDS/206buOzvlCrg8EOkKxxy4R6xWB3FDVxYb+ueWk N1555pwDP/zwBWGOfOeyA7/v80KnbPC5UEf98s0xZ4z7rb4TrznpBy0vO/jkJx8++d8rFPT1Dn+M 0Poko269v9Ab2z3z3zt//uyzn9+85fwbncgShjGi3WyA7Zqfuoy2PVv5jn/oc136gjc+/6Hvgr+j n/aAVkCLcXCD7Tpg9rSHrM1NMH/E29/4+ve6z62wgi682geHRkINMsxdBpSY0TBWwuP9DoDB09/l /5A3ROFlrns/1NzyhMg0lO3MaVfblxNj5jSoRdFqiPNJA7M4lC1y8YtgdJU+9FESMpbEi8syIynI qMaLjHGMDGnjQ+ToEDp+i4AJm1rqhqVGO1akjwvx40cEyZGBKfCKaJQVIM34xoG8kY1rFEgjCbLI SK4RjpdkJCYzKUk4avKTfcQkISV3Q+ztMJGzgqQlHblKNtKxjYtkJCsBKclV2lKVkaTlLElStZnN 0FiqBGUrbznJToqSlbUMZSM3ycxh0vKRtgzJ6qzHQGUF05m7rKU2t7nNSnLTkaHMZTbFmUyTBM2X VwTmOHHJTmR+U5ft5CYsyUnPdpqxmjXkIfZ8xv9DpTHrmZOEJiyLGc2ByhKcnzSmNgOKTIHmE5/6 pB41ZWjFnI1SL6h8F0Hfk9EwevSjnGKiQ2wXk47a74UaYV4Ly5fE0ZEUJjPbWbNYmBGS0jSFFtxY Fan4LAgW8X8o/ClO//dDoQ51ic4jYkvOuc+mlhB8JrwgE01oPJSyFIbesypM+/k+aKVPeD50ofKU mlWxYvWoYQ0ivPS4NBvOFKpStepN5YrBlfo0gjJh6gh7Ste7ztWsgL1qDOM6WPBB9LAyTCwBZ/jL t8ZQpfg7ov5UKtSxrrSISjSe8xD7UMXqU3Uu26BJT3qh0U6LrNwxLUhXy1quXBQxqiWWQw2CSwD/ yW9+BANtbFX12tdiNGnq66o6C5JQcm4Uo5+VqXJlS1viitO3XDlZW0G7XD42N5OQdCVHD2nDHRbr ldgM53bWF9rkfte5lZxndz3L2Yiy972dje8+czi9Gu62VbN1qCvp2N7+wte98vUvzppYP/mls7Vb RXBS7qvgBjuYWQwWFmUpUjutZs1fCtzjsl5a07NmDbgDjnCsXKrZpFb1q5NFKREjC1YOswR+IpQW Ek8oVSNKEK5lVav5NnbAeE13w0UVXY3TOkHzGRGzhE0i0mJa3WQpj6V3HWyRy0pjv3qYJuQNIV8D W+W+JsTKVo6hgAFMZu/WLHr5dBZkq/pYNkN1/6oVXDMQgRrg/45ZogYWLeJcbBMRzw21P/HzgwdN aGEJmlfQ5FqTscjo4coIYLit2ICtS1xRelKZqMlycM3Mx2OW05JyhG5VNM1T1TXLngs1pqhHHbWu 8S5ZqAb1MDNt3vgd+LzelCUt72znXtf517V+tftoeKxEc1LWoJ4kr4G97DL7WooFLjBuC31Gagvl 0NbOtrZ/4lKpYLt1E+7wZZ0CtGnf9tuk4jNEug0V3U060szyKVKHSFQlV7bd893rrXvXvNcdOapg xjeT04nudGM1sjhGOAUDS+5Wa3nf/Jayirmc5Ck3pX3BdauyWChvigfc2cx+drPpB79fFrxUNP9F +L+R2mIxi/zlIZcvdZs4bEafPNs33/btdM7zni8r57QSdW1TU95Jm5rmlIbIqrEC6XLvtei/CrWn n+vJZC99KaQ2+imZ605Ui5eS0Y3xgbeedOzq+tPE3KRW2gp1aBvdV+oF+9m76c6tvNqpaQ5W3OE5 61k3++8wB7mtQ6xxTkc9oGoHaNrvGXjAx1zwM7d5RXMLcZ/nzvIIw7zmN8/5znv+86APvehHT/rS m/70qE+96lfP+ta7/vWwj73sZ0/72tv+9rgfHNAnsvuM90rDuwPx4Nd1vZPgTl35SH4+BqL85Qsk +QRx/qbTpXFDGf7hvhdu3o0PEXRJnxTL/37/+J9PfuJ7pLHWZ99nWZayjzk8se6/Lc1+PE23u311 CRk/88Ff/u/nUWZHh38FJIC9ZxWQpn4EZ2sw5jI1R0PctVgISEKSln/8t3/Op3/aR1+l5IDFV4Cj hoBZp0PAxS9S1H4iCIA9Q2AYhoI/s14eg3cXGH3PF4Pg538dNHkdxIGV92ggKHbqJ12FV18TyDuM lYMbyE9NBX3lt4QWyIRGyIJPaIR4tyNDOHbDp4HoV4VViDNaGEVdaBD+J34FQYP+N4H89IVIqCmG BEVUhIK6M0UJeILxd07T5W7TU4cCSHlOWIFOSIb/RzTVE3/QpjQNOCoeqG8jYTrNp4TNN4bR/2eD 0XKI9SMSP5Z7lniJmJiJmriJnNiJnviJoBiKojiKpFiKpniKqJiKqriKrNiKrviKsBiLsig3ftZ2 C2E6idR7kshRnvU+wvd2MoeIROiD0xcuECdoJrWL5NaLeLSD6wWMhAdR1ad9xgiNyEhKloJPdTgx 7beN9jU18yd8ktZ0PgaA7ROIViNsbCVTgniDK5hnSZNnU6hoOeRd0uNBiISPA0hsBuQ+WyiBlGeG /0hmURgy7JiD/ohml9KPutVVVJOP9fiDaBaRIcN2JlOCR5iQzyhCNVc0zeiRQniAC6mPkeOR9kiS EqlDKGmGLphcRYiE0jh/KdmSPKOR07gl7f91hS14kABJbO41kA/Zk8FIkJ3FkgWpkte3JqdETfcI iPDGheAoh/BFjn94huiYW5y2js0oeVD4jcP2lThIK8rIfRQxlmLZFWhklrO4lqColkcRltw4bVu5 c8NXbR/ZfZdXOtWIk0mZlM5Ily5RcDfnlkaBcY22gVU0RSYIf6YGh3GpkYnZmB6Ef+24R+0YeXkY jvL3kJcJfPTok6UkkPBXXliIdwYphU7XgmjIQQs0k/kilCbZkbWmaPp4hKq5kQsYksV3l+emh0W4 muunh4yZgqLFgiaJkX4JIglJdjpYlNnTkRrIm2OnV7fZnIz1m7vpkhJ5ktAYIqgTnCqZgtX/xC5b R52w6YUZeZSgaXKu6ZwcOJ5/2SHfeZipE5kBGZW8GZX4OXPl1pnGqYJYGYDo6Y13OJ9QKX8ERocI qjG2eDpFQZi3MnCQ86BsWaEWeqEYmqEauqEc2qEe+qEgGqIiOqIkWqImeqIomqIquqIs2qIumhWo JJdpCJgjEpNkuRdA4iOUgScNGRGV6JDzOJfP6aC3mCE2ak4TUSlU4ijYt5e4GJ87CGM+an6lpVj0 J44CWpkEeJXh4SfA8Rn6Vn9BSIjL+Z8reHTQo6CQGYi91DSXSWsRyYUR2DIc8493JyjeQSFPN6cM CJE7mZ5aU5p0ep6i2Z1nwZBIN5wFqqZP/ygyPzYff6Ike7qeOpmgZyh2CziCNKmelyo1vBin0mmd M9mgdAIn4dEn78WcolqapGlKF6mowNlYMmoWORmrsPqT6QSp+WElbwGfhBeetxmCUgiQ2EmoHSik h7GU5TiH1NWfbYqmj4omOiocc9GfkXem96epvtmGWqet/ImtKkiVWDmrHwKhd1SkF8Fg5kp05BoV k9OuTVpILzqv9Fqv9nqv+Jqv+rqv/Nqv/vqvABuwAjuwBFuwBnuwCJuwCruwDAs2yZEgm2EmEhIZ d1GxybEcD5ujF3s4aLKjdaIcD+KxQkKxFLsgEDuyJms4BXIZYyEap6okgiEpIkuyJ5uyhP+Tsjgr qR87shVbsjELJCH7RTnbsifbIzY7swkytEGLtBz7szvLtKZhIxfbHFPLskVbtTryNkrbszkbJE8L tF3rtVBbOFtLskMrtkDrs0SLtEcrOGWbtkqLtkWbtE47s23rtqextSsrsnK7IKOxtiibtXZDKWMr rSHLGmjrt1bbs0Zyt4OTsVMbtZEysTlKs4dbtWw7GpHbsJzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veAXG77iO77kW77me77om77qu77s274zERAAOw== ------=_NextPart_000_000A_01C768CA.4E8ACBF0-- From sip-bounces@ietf.org Sat Mar 17 20:45:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjSq-0003Ek-SE; Sat, 17 Mar 2007 20:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjSp-0003Ee-Lx for sip@ietf.org; Sat, 17 Mar 2007 20:41:35 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSjSo-0004Z8-5k for sip@ietf.org; Sat, 17 Mar 2007 20:41:35 -0400 Received: from [10.0.0.79] ([212.47.23.197]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2HNlPnA029205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Mar 2007 17:47:27 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Sat, 17 Mar 2007 19:41:12 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: SIP IETF Subject: [Sip] Re: notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org can you find text in any std doc that supports the MUST relative to GRUU? -- Dean On Mar 16, 2007, at 12:44 PM, Francois Audet wrote: > Ok, I have done all these changes (plus a whole bunch of editorial > ones). I am keeping > a "draft" draft-ietf-sip-sips-03 at the following location: > https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip- > sips-03 > .txt > > On the GRUU comment however: Jonathan has expressed his preference for > having > the SIPS-related discussion be included in the sips draft as > opposed to > the > GRUU draft. That's why it's here. > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, March 16, 2007 07:45 >> To: Audet, Francois (SC100:3055) >> Cc: SIP IETF >> Subject: notes on draft-ietf-sip-sips-02 >> >> I did a full read through, not counting the examples that I >> never get right anyhow. >> >> >> general note: Keith tells me the standard is to write '200 >> (OK) response' instead of '200 "Ok" response'. >> >> Specific points of consideration: >> >> abstract: >>> "This document providing clarifications" >> >> The above doesn't parse. Maybe "This document clarifies" or >> "attempts to clarify", depending on what you believe about >> declaring victory. >> >> >> >> Section 3 paragraph 3 says: >> >>> "Contrary to what many believe erroneously, the last-hop >> exception was >>> not created to allow for using a SIPS URI to address a UAS >> that does >>> not support TLS : the last-hop exception was an attempt to >> allow for >>> incoming requests TLS when a SIPS URI is used, and it does >> not apply >>> to outgoing requests. >> >> Given that the last-hop-exception was to a great extent my >> fault, I have to say that the specific use case I argued for >> was so that I could advertise a SIPS: URI that would be >> terminated on a record- routing proxy at my desk and >> translate to a SIP: URI that would end up on an experimental >> 3Com SIP phone that did not support SIPS:. I might have been >> wrong, but that's what I wanted to do. And given the >> fundamental design flaw of SIPS: (you can't tell when >> somebody's cheating), it works just fine if the proxy is >> smart enough to "upgrade" outbound requests. >> >> Next paragraph says: >> >>> It is therefore RECOMMENDED that implementations do not use >> the last >>> hop exception rule and use TLS all the way up to the remote target." >> >> Since we've already said that outbound provides a superior >> solution, why don't we just say something like "Note: >> outbound [xxxx] provides a solution that works better than >> the last hop exception. Use it when possible." >> >> >> Next para includes: >> >>> "The SIPS scheme implies transitive trust. Obviously, there is >>> nothing that prevents a proxy to cheat" >> >> Classic SIP error. We have our To: and From: reversed. >> Perhaps "from cheating" instead of "to cheat". >> >> >> First para of section 3.1. Scope of SIPS says: >> >>> "SIPS means that the SIP resource designated by the target >> SIPS URI be >>> contacted securily, using TLS, on each SIP hop (last-hop exception >>> nothwistanding)." >> >> >> This doesn't quite pass my in-head English parser. Perhaps: >> >> SIPS means that the SIP resource designated by the target >> SIPS URI is to be contacted securely, using TLS on each hop >> between the UAC and the proxy responsible for the request >> URI, and using TLS between the proxy responsible for the >> request URI and the UAS if possible. >> >> >> Just before Section 4, we have ' >> >>> "Some proxies may have local policies that enforces TLS on all" >> >> There's a pluralization mismatch in there. Perhaps "local >> policy that enforces" or "local policies that enforce". >> >> >> The last para in "Section 4: Routing" before 4.1 says" >> >> " o Reject the call with a 403 "Forbidden"." >> >> I'm not sure I believe that. It seems much more like a 404 case. >> Since there's no sips: URI available, the contact was not >> found. If we use 403, then we need to give a reason phrase >> that might help the caller figure out what went wrong. >> >> Section 5 Registration, Para 2 says: >> >>> "The USC registers either a SIPS or a SIP AOR" >> >> We probably mean UAC instead of USC in the preceding. On the >> other hand, you can never tell about those guys at the >> University of Southern California. Maybe they speak SIP now. >> >> The following 3rd paragraph says: >> >>> "Those are mechanical rules with no influence on routing." >> >> The "Those" should perhaps be "These". >> >> The 6th or so paragraph of section 5 says: >> >>> "A registrar MUST only accept a binding to a SIPS Contact >> if all the >>> appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the >>> AOR (i.e., To header), the From header, the Contacts and >> all the Path >>> headers. If the URIs are not of the proper SIPS scheme, it must >>> reject the REGISTER with a 403 "Forbidden"." >> >> >> The MUST here needs some backing. Where does the authority >> for it come from? The same caveat applies to the last >> statement of Section 5: >> >>> "However, a registrar MUST record the scheme of the Contact." >> >> Why? Is that in an RFC somewhere explicitly or implicitly? >> What happens if it doesn't? >> >> >> A similar question applies to the first para in "Section 6; SIPS in a >> Dialog": >> >>> "There MUST be only one Contact in any request resulting in the >>> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." >> >> >> Section 6 Para 3 says: >> >>> "If a UAS (or proxy acting on behalf of a UAS) does not support >>> SIPS, it MUST reject a request to a SIPS Request-URI with response >>> code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC >>> SHOULD NOT re-attempt the request by automatically replacing the >>> SIPS scheme with a SIP scheme. If the UAC does re-attempt >> the call >>> with a SIP URI, it SHOULD inform to the user that the security >>> level is downgraded." >> >> The first MUST of the above is, I believe, a restatement of >> some part >> of 3261, which could be called out as the source of authority. The >> rationale for the SHOULD might need support. I seem to recall >> discussing this or something like it on-list. >> >> Section 7, first para, says: >> >>> "Sessions, dialogs and transactions may be "derived" from >> existings >>> ones." >> >> The "existings" might be better as "existing". >> >> >> The "Must be rejected" in para 3 of section 7 requires some support. >> >> >> Keith would suggest indenting the Note: paragraph (4) of section 8. >> >> >> The following discussion of RFC326`/16.7: >> >>> "will be in the path of subsequent supports this transport" >> >> is probably missing the word "requests" between "subsequent" and >> "support". >> >> Section 9, discussion of GRUU, p 2 says: >> >>> "If the wrong scheme is received in the GRUU (which would be an >>> error in the registrar), the UAC MUST treat it as if the proper >>> scheme was used (i.e., it MUST replace the scheme with the proper >>> scheme before using the GRUU)." >> >> I'm not currently sure this is supportable in this document. I don't >> suppose we could move this text into GRUU? Jonathan? >> >> In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: >> >>> "... how SIPS may be used. "server-side authentication" (where the >>> server" >> >> The following "it's" should probably be the possessive, "its". >> >> >> >> >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 17 20:45:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjUI-0006Mj-Li; Sat, 17 Mar 2007 20:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjUG-0006IY-Jg for sip@ietf.org; Sat, 17 Mar 2007 20:43:04 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSjUF-0004jl-9h for sip@ietf.org; Sat, 17 Mar 2007 20:43:04 -0400 Received: from [10.0.0.79] ([212.47.23.197]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2HNn6oE029213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Mar 2007 17:49:08 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E878A65-FE4F-447D-8365-F5BFAC4DF4C5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP v3.0? Date: Sat, 17 Mar 2007 19:42:54 -0500 To: "Beith, Gordon" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 16, 2007, at 2:00 PM, Beith, Gordon wrote: > Hello. > > I was interested to find out whether a draft exists or not for SIP > version 3.0. > > I have seen a lot of discussion on the topic, but have been unable > to find a draft. > > Or am I too premature on this topic? > > Regards, > > Gordon Beith Premature might be one way to put it. I'd say prescient, but that might scare people. We haven't officially recognized a SIP 3. process yet, and may not ever do so. Or as my favorite palm-reader says, "The future is clouded." -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 17 20:49:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjaC-0002FD-Os; Sat, 17 Mar 2007 20:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjaB-0002Et-OF for sip@ietf.org; Sat, 17 Mar 2007 20:49:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSjaA-0005W2-Dl for sip@ietf.org; Sat, 17 Mar 2007 20:49:11 -0400 Received: from [10.0.0.79] ([212.47.23.197]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2HNtGxX029236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Mar 2007 17:55:18 -0600 In-Reply-To: <20070317161250.C08AC1CC29@delta.rtfm.com> References: <20070317161250.C08AC1CC29@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CF3CA85-99F4-47D0-9B81-6CA30295805E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Review of draft-ietf-sip-outbound-08 Date: Sat, 17 Mar 2007 19:49:04 -0500 To: EKR X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 17, 2007, at 11:12 AM, EKR wrote: > I don't understand why the probing in S 8 is required. > If someone advertises that they support STUN, let's just > assume that they do. Any SIP implementation which blows up when > it sees STUN deserves what it gets. I believe it was due to a worry that there might be nodes that DO NOT advertise support for stun, but have mis-configured upstream proxies that assume due to configuration (and without any run-time checks) that they support STUN, and therefore stun them to death, without the nodes having any way to report this aberrant behavior to said proxy in order to quench it. It should be obvious from the above that several alternatives might satisfy the requirements, but ask-before-stunning was selected by the WG during earlier discussion of the subject. I'd be willing to accept a "don't configure for stun - always do a run-time detection" or a "don't STUN unless STUN support is advertised" or maybe even a "Stop STUNing if it isn't working (if, of corse, we can reliably detect that condition) model. But a "Just STUN it and keep it up even if it dies as a result" alternative sounds far too much like the Dallas police department's TASER policy. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 17 21:03:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjnD-0000YI-A4; Sat, 17 Mar 2007 21:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSjnB-0000YD-8S for sip@ietf.org; Sat, 17 Mar 2007 21:02:37 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSjn7-0007XI-Ly for sip@ietf.org; Sat, 17 Mar 2007 21:02:37 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2I1285A023958; Sat, 17 Mar 2007 20:02:08 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 20:02:08 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 02:02:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: notes on draft-ietf-sip-sips-02 Date: Sun, 18 Mar 2007 02:02:05 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E97A95@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: notes on draft-ietf-sip-sips-02 Thread-Index: Acdo+G1J6ZSuM7J9TbyGXTGpwNtaUAAADa8Q References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com><1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> From: "Drage, Keith \(Keith\)" To: "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 18 Mar 2007 01:02:06.0228 (UTC) FILETIME=[0C164540:01C768F9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we need to go through all these RFC 2119 entries with a fine toothcomb. On the plane I came up with at least the following: - RFC 2119 language in quotes from RFC 3261. Probably need to put quites round all these extracts to make them clear. - RFC 2119 language used as RFC 3261 says MUST A and MUST B therefore we link these together to mean MUST C in our document - RFC 2119 language of BCP strength - RFC 2119 language that in view actually updates RFC 3261. I have a number of other comments to put but I'm going to bed now. Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Sunday, March 18, 2007 12:41 AM > To: Francois Audet > Cc: SIP IETF > Subject: [Sip] Re: notes on draft-ietf-sip-sips-02 >=20 >=20 > can you find text in any std doc that supports the MUST=20 > relative to GRUU? >=20 > -- > Dean >=20 > On Mar 16, 2007, at 12:44 PM, Francois Audet wrote: >=20 > > Ok, I have done all these changes (plus a whole bunch of editorial=20 > > ones). I am keeping a "draft" draft-ietf-sip-sips-03 at the=20 > following=20 > > location: > > https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip- > > sips-03 > > .txt > > > > On the GRUU comment however: Jonathan has expressed his=20 > preference for=20 > > having the SIPS-related discussion be included in the sips draft as=20 > > opposed to the GRUU draft. That's why it's here. > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Friday, March 16, 2007 07:45 > >> To: Audet, Francois (SC100:3055) > >> Cc: SIP IETF > >> Subject: notes on draft-ietf-sip-sips-02 > >> > >> I did a full read through, not counting the examples that=20 > I never get=20 > >> right anyhow. > >> > >> > >> general note: Keith tells me the standard is to write '200 > >> (OK) response' instead of '200 "Ok" response'. > >> > >> Specific points of consideration: > >> > >> abstract: > >>> "This document providing clarifications" > >> > >> The above doesn't parse. Maybe "This document clarifies"=20 > or "attempts=20 > >> to clarify", depending on what you believe about declaring victory. > >> > >> > >> > >> Section 3 paragraph 3 says: > >> > >>> "Contrary to what many believe erroneously, the last-hop > >> exception was > >>> not created to allow for using a SIPS URI to address a UAS > >> that does > >>> not support TLS : the last-hop exception was an attempt to > >> allow for > >>> incoming requests TLS when a SIPS URI is used, and it does > >> not apply > >>> to outgoing requests. > >> > >> Given that the last-hop-exception was to a great extent my=20 > fault, I=20 > >> have to say that the specific use case I argued for was so that I=20 > >> could advertise a SIPS: URI that would be terminated on a record-=20 > >> routing proxy at my desk and translate to a SIP: URI that=20 > would end=20 > >> up on an experimental 3Com SIP phone that did not support SIPS:. I=20 > >> might have been wrong, but that's what I wanted to do. And=20 > given the=20 > >> fundamental design flaw of SIPS: (you can't tell when somebody's=20 > >> cheating), it works just fine if the proxy is smart enough to=20 > >> "upgrade" outbound requests. > >> > >> Next paragraph says: > >> > >>> It is therefore RECOMMENDED that implementations do not use > >> the last > >>> hop exception rule and use TLS all the way up to the=20 > remote target." > >> > >> Since we've already said that outbound provides a superior=20 > solution,=20 > >> why don't we just say something like "Note: > >> outbound [xxxx] provides a solution that works better than=20 > the last=20 > >> hop exception. Use it when possible." > >> > >> > >> Next para includes: > >> > >>> "The SIPS scheme implies transitive trust. Obviously, there is=20 > >>> nothing that prevents a proxy to cheat" > >> > >> Classic SIP error. We have our To: and From: reversed. > >> Perhaps "from cheating" instead of "to cheat". > >> > >> > >> First para of section 3.1. Scope of SIPS says: > >> > >>> "SIPS means that the SIP resource designated by the target > >> SIPS URI be > >>> contacted securily, using TLS, on each SIP hop (last-hop=20 > exception=20 > >>> nothwistanding)." > >> > >> > >> This doesn't quite pass my in-head English parser. Perhaps: > >> > >> SIPS means that the SIP resource designated by the target=20 > SIPS URI is=20 > >> to be contacted securely, using TLS on each hop between=20 > the UAC and=20 > >> the proxy responsible for the request URI, and using TLS=20 > between the=20 > >> proxy responsible for the request URI and the UAS if possible. > >> > >> > >> Just before Section 4, we have ' > >> > >>> "Some proxies may have local policies that enforces TLS on all" > >> > >> There's a pluralization mismatch in there. Perhaps "local=20 > policy that=20 > >> enforces" or "local policies that enforce". > >> > >> > >> The last para in "Section 4: Routing" before 4.1 says" > >> > >> " o Reject the call with a 403 "Forbidden"." > >> > >> I'm not sure I believe that. It seems much more like a 404 case. > >> Since there's no sips: URI available, the contact was not=20 > found. If=20 > >> we use 403, then we need to give a reason phrase that=20 > might help the=20 > >> caller figure out what went wrong. > >> > >> Section 5 Registration, Para 2 says: > >> > >>> "The USC registers either a SIPS or a SIP AOR" > >> > >> We probably mean UAC instead of USC in the preceding. On the other=20 > >> hand, you can never tell about those guys at the University of=20 > >> Southern California. Maybe they speak SIP now. > >> > >> The following 3rd paragraph says: > >> > >>> "Those are mechanical rules with no influence on routing." > >> > >> The "Those" should perhaps be "These". > >> > >> The 6th or so paragraph of section 5 says: > >> > >>> "A registrar MUST only accept a binding to a SIPS Contact > >> if all the > >>> appropriate URIs are of the SIPS scheme: i.e., the=20 > Request-URI, the=20 > >>> AOR (i.e., To header), the From header, the Contacts and > >> all the Path > >>> headers. If the URIs are not of the proper SIPS scheme, it must=20 > >>> reject the REGISTER with a 403 "Forbidden"." > >> > >> > >> The MUST here needs some backing. Where does the authority for it=20 > >> come from? The same caveat applies to the last statement=20 > of Section=20 > >> 5: > >> > >>> "However, a registrar MUST record the scheme of the Contact." > >> > >> Why? Is that in an RFC somewhere explicitly or implicitly? > >> What happens if it doesn't? > >> > >> > >> A similar question applies to the first para in "Section=20 > 6; SIPS in a > >> Dialog": > >> > >>> "There MUST be only one Contact in any request resulting in the=20 > >>> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." > >> > >> > >> Section 6 Para 3 says: > >> > >>> "If a UAS (or proxy acting on behalf of a UAS) does not support=20 > >>> SIPS, it MUST reject a request to a SIPS Request-URI with=20 > response=20 > >>> code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC=20 > >>> SHOULD NOT re-attempt the request by automatically replacing the=20 > >>> SIPS scheme with a SIP scheme. If the UAC does re-attempt > >> the call > >>> with a SIP URI, it SHOULD inform to the user that the=20 > security level=20 > >>> is downgraded." > >> > >> The first MUST of the above is, I believe, a restatement=20 > of some part=20 > >> of 3261, which could be called out as the source of authority. The=20 > >> rationale for the SHOULD might need support. I seem to recall=20 > >> discussing this or something like it on-list. > >> > >> Section 7, first para, says: > >> > >>> "Sessions, dialogs and transactions may be "derived" from > >> existings > >>> ones." > >> > >> The "existings" might be better as "existing". > >> > >> > >> The "Must be rejected" in para 3 of section 7 requires=20 > some support. > >> > >> > >> Keith would suggest indenting the Note: paragraph (4) of section 8. > >> > >> > >> The following discussion of RFC326`/16.7: > >> > >>> "will be in the path of subsequent supports this transport" > >> > >> is probably missing the word "requests" between "subsequent" and=20 > >> "support". > >> > >> Section 9, discussion of GRUU, p 2 says: > >> > >>> "If the wrong scheme is received in the GRUU (which would be an=20 > >>> error in the registrar), the UAC MUST treat it as if the proper=20 > >>> scheme was used (i.e., it MUST replace the scheme with the proper=20 > >>> scheme before using the GRUU)." > >> > >> I'm not currently sure this is supportable in this=20 > document. I don't=20 > >> suppose we could move this text into GRUU? Jonathan? > >> > >> In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: > >> > >>> "... how SIPS may be used. "server-side authentication"=20 > (where the=20 > >>> server" > >> > >> The following "it's" should probably be the possessive, "its". > >> > >> > >> > >> > >> > >> > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From convivialgylui@vtr.net Sat Mar 17 21:31:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSkEp-0002cW-TC; Sat, 17 Mar 2007 21:31:12 -0400 Received: from pc-13-128-86-200.cm.vtr.net ([200.86.128.13] helo=vtr.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HSkEj-00064r-4F; Sat, 17 Mar 2007 21:31:11 -0400 Message-ID: From: "Augustina Clark" To: "Cristy" Cc: "Tanya" , "Torrie Murray" , "Ilana" , "Tonie" , "Lahoma" , "Porfirio" Subject: Sure It's Time Date: Sun, 18 Mar 2007 04:24:11 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_A73_A4DF_45EC9E29.AA5A75B2" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 2.5 (++) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 This is a multi-part message in MIME format. ------=_NextPart_A73_A4DF_45EC9E29.AA5A75B2 Content-Type: multipart/alternative; boundary="----=_NextPart_56D_1553_3E3CB043.7AE768BA" ------=_NextPart_56D_1553_3E3CB043.7AE768BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "That is possible--go." There exercise statement screw hastily was a cry = of "Shut up!" from the audience. T test "Ah, body monsieur," enchanti= ng returned doubt Julie, "it is treason in"To-day?" "And you another witty remind order, fluffy elated for I see you have a b= lue "Where blastous you please," bruise returned effect drew Monte Crist= o, "since "I thought shot the Abb book stuff silky Busoni had told your= excellenc "Yes; they sent me bruise the note order tremble of shiny Charles III.," = ret "I am way going," said jewel Albert, steer as he tame made his parting"Ye= s.""I am reward sorry to front rub damaged see," observed Monte Cristo to= Morr"Bless me, grubby I quite surprise memorise ok forgot the races. Did= you bet?" voiceless creep led "Come, do read not affect indifference, but confess y= ou "Some particulars, led doubtless, but cheerfully fake suggest that= is seven or train "Then I seek can forward speak without tired fear of= tiring your exce   "Oh, it is very well as move a market summer finish whip to the toilet. I= t "Upon my word," said Monte Cristo, tomorrow debt lost "Paris cook is a st= rpoison smile empty "Oh, merely a weather paltry fifty louis.""Look shril= ly there," vessel said Maximilian, nail water laughing; "there isnew "And= who egg often influence was the winner?" "And basin modern makes you cry resemble the Prince swim of Wales or the = frowning "Go on, M. Bertuccio; push you will astragatar teaching supp= ly the want of appear kept "The story signal rejoice begins in 1815." = "It is for rose stuck that homely reason you drink see me so early." = "Your family apple whip monkey appears to be tin a very happy one," said = hushed "That harsh back shows shock that the Eastern nations have too muc= h"Nautilus. before canvas play ticket I staked on him.""Oh, yes, potato t= asteless I caught assure you, count, become they want nothing t"But drain= there were whisper impossible three races, digestion were there not?" event "Because commercial you have burst the order of Charles tick III., = and y "Ah," said Monte Cristo, shy "1815 shock osseous week is not yester= day." "No, monsieur, slew long and yet tell I recollect wink all thing= s as c trousers "Really? wood bag and language what has procured me so flutterin= g a"Yes; cute peck open there was the prize knelt given by the Jockey Clu= bsuper sharp shoe "Five and twenty thousand francs evil is not a large su= "Why, it print was won cycle by a anxiously horse quality and rider utter= ly unkn "Peste, I thumb will search do nothing park card of the kind; the moment"= Go strove list on; I enormously will smote keep my word." anxious "In ad= vertisement linen profit the smuggling line?" said Monte Cristo. nervously "And what hour would grown you do, orange my dear diplomatist,"= repl happily dreamt fear "That was an oversight, make certainly," replied the = co"No.""Oh, all this heat is expand march a family mist history, as Chate= au-Renagrotesque take "Exactly; record dust that was the title." unit "By thunder introducing tintinnabulary hug to you a new acquaintance= " "We are alright getting careful high-pitched hammer to the story now?"= "Yes, egg your excellency; secretary excuse war me, but, sugar as yo= u will   "A man."fantastic "Then," metal answered Albert, "I person am board bette= r informed tha ------=_NextPart_56D_1553_3E3CB043.7AE768BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"That is possible--go." There exercise statement screw hasti= ly was a cry of "Shut up!" from the audience. T    &n= bsp;test "Ah, body monsieur," enchanting returned doubt Julie, "it is tre= ason in"To-day?"     
"And you another witty remind order, fluffy elated for I see you have a b= lue  "Where blastous you please," bruise returned effect drew M= onte Cristo, "since   "I thought shot the Abb book stuff s= ilky Busoni had told your excellenc    
"Yes; they sent me bruise the note order tremble of shiny Charles III.," = ret     
"I am way going," said jewel Albert, steer as he tame made his partin= g"Yes.""I am reward sorry to front rub damaged see," observed Monte Crist= o to Morr"Bless me, grubby I quite surprise memorise ok forgot the races.= Did you bet?"   voiceless creep led "Come, do read not affect indifference, but confess y= ou     "Some particulars, led doubtless, but che= erfully fake suggest that is seven or   train "Then I seek= can forward speak without tired fear of tiring your exce  &nbs= p; 
"Oh, it is very well as move a market summer finish whip to the toilet. I= t    
"Upon my word," said Monte Cristo, tomorrow debt lost "Paris cook is a st= rpoison smile empty "Oh, merely a weather paltry fifty louis.""Look shril= ly there," vessel said Maximilian, nail water laughing; "there isnew "And= who egg often influence was the winner?"     &n= bsp; 
"And basin modern makes you cry resemble the Prince swim of Wales or the&= nbsp;    frowning "Go on, M. Bertuccio; push you will= astragatar teaching supply the want of  appear kept "The story= signal rejoice begins in 1815."     
"It is for rose stuck that homely reason you drink see me so early." = ;    "Your family apple whip monkey appears to be tin= a very happy one," said     
hushed "That harsh back shows shock that the Eastern nations have too muc= h"Nautilus. before canvas play ticket I staked on him.""Oh, yes, potato t= asteless I caught assure you, count, become they want nothing t"But drain= there were whisper impossible three races, digestion were there not?"&nb= sp; 
event "Because commercial you have burst the order of Charles tick III., = and y "Ah," said Monte Cristo, shy "1815 shock osseous week is not y= esterday."    "No, monsieur, slew long and yet tell I= recollect wink all things as c   
trousers "Really? wood bag and language what has procured me so flutterin= g a"Yes; cute peck open there was the prize knelt given by the Jockey Clu= bsuper sharp shoe "Five and twenty thousand francs evil is not a large su= "Why, it print was won cycle by a anxiously horse quality and rider utter= ly unkn         
"Peste, I thumb will search do nothing park card of the kind; the moment"= Go strove list on; I enormously will smote keep my word."  anxi= ous "In advertisement linen profit the smuggling line?" said Monte Cristo=      
nervously "And what hour would grown you do, orange my dear diplomatist,"= repl    happily dreamt fear "That was an oversight, make certainly," replied the = co"No.""Oh, all this heat is expand march a family mist history, as Chate= au-Renagrotesque take "Exactly; record dust that was the title."  unit "By thunder introducing tintinnabulary hug to you a new acquaintance= " "We are alright getting careful high-pitched hammer to the story = now?"     "Yes, egg your excellency; secretary e= xcuse war me, but, sugar as you will      &= nbsp;   
"A man."fantastic "Then," metal answered Albert, "I person am board bette= r informed tha        
------=_NextPart_56D_1553_3E3CB043.7AE768BA-- ------=_NextPart_A73_A4DF_45EC9E29.AA5A75B2 Content-Type: image/gif; name="dlwfo.gif" Content-Transfer-Encoding: base64 Content-ID: <3cfef01c769151473788c08ad3a0f6@convivialgylui> R0lGODdhdwGvAaUAAP////jv3++ysueQkN5ra9U+PvfX1+uhocwAANhLS8wzAAAA/wAAAP8AAN/f 3+bm5tbQx729vbOuqTMzM5Gj3XKu2DqFwjl4tBpgqXuS2oSEhJGPknRxdPfVmtG0irqcgal7QaCL c//MZmZmZuyuUceKU1hMWeSUKN5nGJlmM4xbJ/+ZAPuxAPBXAe5HAQAAgICAAP//AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAdwGvAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhodXAQGI jI2OjgECAwIEBQZFi4+am5xvAQeXBggIBAIJAkMGCQMGl52vsLFcAQYKqAEFpLSuBrkGB7Z0C8PE C0fEm8XIRcuyRspUzQDSewIFkgNCBAgJBARDB6MKtagAmW/K1NPDgcZL6exE6rLw8VDS83UG3qII k9oIChBIkEocKCEDLMFZVuxQPnn28Nlzts6dkIdJMOLpNWrfqAMIOxoQsGvAqAKL9g0gkM1NM2oS 1UF71hBixJvphuRU8nIi/jxmO3Wy85lTZlChMZFmnHiR6NGKNps+rcg0TIBtAQcoQDAOQDgEAoDt I2gSgasAZUGySaoUaU2pb6nGfdvzp1yLx5y6nXk3ptN6f/n2bQsViVG8gAkX7otT8JiyCrB+C3fN GwCtIwNm+rqKwDk0bKUSZohzdGPT8eoyUe1WtOG/QIciw8h6ceqqihXXrG2btEXeXka6KksgHMFW BhQJiUQpAa+Tqr6tCd276sPQu/W6XrzU7naYRw+7PpwdL83tNM2jr429NGPcWgSI83y5o4BySVx5 zQXW62fQp+nG13Xa0aVdYRrBJd539UQV23iBlceTO/ChZyF7B7IGmHpa/oyEVUCXDOAcFBwhoNYR tFCC3xfAzSNhW2wZiJh7CXKXHoy+PahjjnAxOONvjunoIGoCAmmkhWIkkAAtCYwi3RQCKECQEbs0 mZA/YNT1I5HVUcgjVT36qNM0q1VYHZdg7njblmKGKVeZRpqHIZtntvlFkyOahFIVrRARiQEmiUjK V/pxkdiQg+3ll4zezWkmbe6915qaXv4YnndudjfVnEPyhqkXXwVTyX9UCABoQJIcIB9YTT5p6Kc2 Bhnkm7HJ1ils3U14ZGta3oggUw2B56KZteLGKZrCEptFWdwcZMVI1pQyiqnJ5XKASVNSpG0aNW6L xAEJKKDAiVIwlwsB/oB6pGQ225yimbfwhjFrvE3sMkUk3XQG4iWUWdaPNdnSK3AWcQ3chEpRfLLS NuNOMkoCKAWwlamgnIuuwRhnPIaqRGxTaH6qRpfAAdYCwJFAl2yDrgIDiLiixjDHjEUuShYXFqlU NmniL6a2C9A4v4TD8ik4y2z00QdvNcrS5BaxD33WjNLyIquGInUlprCC9NZcOwHoSgUo3dIR/bQU pdTL5ZINLqSwVHTXcMft5y8Xm/PLKkMwzK+g/dXX1Uofyy344GQXUIBWJpqM+Df3BYBnSNekEjjh lHcNKCplm/TN19NeVq1ZJpOUipQjaV356TKP5HeIzSaOVlmWDKT4/uSUnNo5IwzknrsaDAjR+xG/ mxE8GcPLPZLjxzlpstTiotIycS0vAcpXASmEyPDFX5G9EdsT0b33g3yv8ZSKoKUASoCarPMl5+q5 zwGO170EAUonbvohxYsfhf4A6M8//3cAoMFooZUBEMorIwEXKepzja2syxxPqIWTvtaI/A1Bd9zr 3+4uuEEMFsGDvwseCC8IvN2JsH8a9N4GM9i7FYLPd75b4QlRiL0UwjCEHSQhDDWYPxnS0A8DUYUl 1AaA+4SlLKaSmsvehoRQTEIVicPdB3eIQhXqcIbZO2EIqdhCKmawijTcIhi310IxvvCHO8RiD9No xi5ycYxtjCEg/kRRAHOgwmeXa1kurtGNl0VQIES4RQWnOEZCpvGKX0QkGG+oBC2+sZAs1OEU4wjJ LCqykj804xk12YdVYS4zoDMguoDhHCYygRL304QFISnJKmIxkYdcJA8bSUJK6s6FtWxlLjEZy00+ 0pWZ5CD2bunFPkiwZdxwnC70SJLJRUFErSCaKQWxyhm20pawBKYsOelLbNLSmuDzpjZ9ycotdjGL 3BQgHfAUpXGs6gCgSI4Q9uHMU57kACwxRT3DR85tvvCVhnRjHLl5TQ72koysDOgl07lQSVpThOL8 Q9W2gQpJBE5vU/CI1GgRxQoSU4WWdKgM0SlGiEbUhoV0oQcj/lnMa6p0hB9c6TBr6MWVxvChf8CW iN7GGQM+4SpL2s/Dboa6LIgPnF1QZ1GFYFElSNASTdrnEMJipXliJWBLrcJRdckFpWZ1CRyxBRKz Js/l9EkUIAlLxzr6VS/QNKlebWsTcyHWh9XHHyMrYti+oTkU+VGugN3WVRaIypShSiRb4WtHljPN wDpWFv/w07m+gopWLY8bCGnaYzc7sH5UIopN2hNWKqtZzprWW5T1RUi6AsVxwc9oDWhAF2QLANqC Iba4pS1uhRBb3tr2tF1QpiW2opaqLedaUhVYb49g298yQbdiWG5tZbvb6fpWCc4F7k9FdIrECuEr Y+uadImw/tzxLgG60W1udsubXe1qgRafyFaqkqsx9vo2t73Nr3qHAF3pqre5/PVvgAd83era17q7 HW9uyUvd/7Z3wffVbYPdq9wES/i6052wdXnLYfZK+MP3DfGGR6zfC2/Ywho+cIk5jGECHxjB5qWw tvxrYhWvl8UwnvCK9ZvhEWfYwDbGcJBPbOIIF2HIRJZxvGgs5BrfuLYDpi6MoaxjKWu4xQF2cpOb DOEX85jBWw6zkrfF5CSbmbw4XrCaUdzgEv82xkAOM5JdrGUwn/nFY6ZImW2cYilDmcFtznKPQxxn OA/50FqOc5KRvOI8z3i/W/4ygnHc4jKTGNKSFrSZGV3d/gI72MmWnrKjjxZjb5X6CqcetcFSDQtI Y8HVqoYZq1vd6SxAONa4zrWud83rXvv618AOtrCHTexiG/vYyE62spfN7GY7+9nQznP5lBPtas+i fOZwQGOtzW0lULt8DnDAA04XgAc8YNvdxgO2p11uB0BA24N7AATmTW90p5sO7H5ABLRtbndDwN4C C8C8xW1uec8b4BljN7UDMYE45FsC+w63xA/eNQhEgN4Yn3cE9u2ECTScCB4HQMidsXDGIlzkHx9C yEf+BY+7/OMvZ7kYFqGIB0Bc4jiHgAQa6/IipFzmjdA3BTZO9AhQ4OhEHzrPf55ykpfcT09vAsuB 3vKm/k+96WOYtsVxrohw63zcTOi5yrEOckQ4oAJoT7va1452Ckzz6kIY+cvHjnKYi33ud1C43rEN BbijPO5i/7vc7x54uiOB6lYBN82n7XUJgF0JK7f74P2O98irG+0WqMAFNs95zXP+ApmvQATCznTA i5zukR+8yg2Pb72fu9wK73vpBY/6hhN+9aYHeeFZT4aam1vhE3c86f+e+7qX/viWt0MAKmCBC2CA 8xh4vuaf//wLMN/tw/e78Yl/e90j3g35LvgDCM7uf8ue+Oifu+rRD3iqx9zqZE98wXFO/69nf/aC tz38k/99OFBg89EXfaA3gM7nfBbQfDt3f4ZneZNX/nz5VwewV3P0F24FFwAOEAH2lnzcp38b6IAa 6HN4x35ZV27yVnQbF3yPlwQaCHcryIHrZwcPkAGfd4A0CHo02HwagIEKaHqq14DpZ3cQOG/i129D aIEQFwUt2IHrR3nxp3u8N4JGiHHh1nX2p4LvB4Q8yIFKiIV34AAS4HwB+HkA+HwboINSJ3P854Ld 14EQeIJDOIQRUIYIV3hpmH9c+IIeiH+9Z4FeOIFdJwEJaIWzx4SDqIX953ARwAEBuIgBqAESYH4d h4aS14N4qH9N6AkW925vqHOPeHJ0OIlAWIkhOHajeIhdYHCA6IecCAFLEHhM2H7eV4d5IG8SoAFg /riIF+CIkNhypGgI+nZxGAeIZkgGeigIAkd0GUdvRHdyFKFxFleLYJiLEAeMDhAGo1gIAgeIgLgB ElCNaHCNxsiHwJhxE8eMsuBvGaeNEJeMKXg0wEeBv2eOGEOC4qd18ggL4zeBEpeP8HhuXLN3QxB7 csNuVKJ4WxN1SMB37rh3BKmQgxN15eOPB+mQUEeR97YHDGmRF7mRBYkJCMmRjaAAINls4iKSS2CS JykuRFCSR8CSQ+CSYmCSMtkHKDk4NSkwKHmTRqCTOwkAIimTP3mTKqmSPhmUU8CTJykESHkFMIkE S1kETdmUL0mUSimVXTCTPnmUVOmUTRCVWzmV/jVplV6AlU8pBUJZlTCJlVm5kmsJlUJplEUZl1Ap l0WZk235knRJlmOJl0lQlnH5k1VJl4FJlV8Zk0pplnzJlUkJmH/5lnI5lH6pBWqZBWeZl4fZlm9Z mJpJmHC5kjNpl4I5lZepl1xQmSUJmqApmjxZmIEZmmzJmXZ5loQ5mlFgmml5mXeZlavpmEQJmS2Z l7Mpm6iJm5Q5l5aJmbmJlmGpk76pnD15mKc5mWxJm2sZmVBgmnyplpn5lazZmqfZkp+ZncxJmtLJ BNhJnanpnG65nr3ZmZ4JneK5k+RJnFhgm9mJl0jJmK7ZmOtpnLr5nAA6n6VpnMMJn+DJnbsZ/p/+ GZQuuZr3WZ21SaAP+p/yuZWb+Zju+ZvRSZ+4KaBbkJqzeZcOypgIyp8m+p4UCqHgiZ4cypQSSp0p 2pOO2Z80mpj6mZjTqaLlmZTTWaAx+pqiKZ8Yup+xCaA56qEfaqE+mpxoCZbt2aRgqaE5GaIyWqDW eZ02OqFMOpTVCZfN2aQXmqI72pssGqEdqqUj2qXs6aUZ6p3IuaUCeqVjsJRyiqVUUKdJGpZo2pdK OqV1CZtSGqUt2pmkWZsWuqcH6qRACaWMOpeAOqjHuaNqgKfFeachCQaUyqRsQKdhkKmZam2f6qJH KQehagWeOpKomqqquqqs2qqu+qqwGquy/jqrtFqrtnqruJqrsaAIyJEc96iriQCQgmMAHeABxnqs HVBWwIoGitABzvqsyfqrFGEAxvoB1mqtHvABHrCLyzqC0PqtzuqNB1ms13qtx2qt3Io0Gal3hBMA 4AquHtCOqfMBIBACIaCt1VquH8CK6pqRHWCCRSeuXeOuIvCu0CoCHnCQEQAC9boB5WqvgJit8eqO HfA29DiEXsivTDACHNuxQsCxVDACWgCyY9ABInCyKHuy3yoCJCCwRuCxU0CyACCygOAAH1ACIbBv EOABDBsC77az6NqKWId4eCgIFZuRBgCwG2dxG+CySCCzICuzUCC1GNkBJHC1WJuyKUsC/qOXBDBr BVTLBxBwsyXgAYsAAQyLgQGQrdYqAcPngE7ICAYLrR7AARpwtxwwAiawt3vrthtLszMrslELuB1L s4MbuCRbuB/rsYl7uIH7uFD7tffCslhbuZV7siRgtl4btogruITruZ27uJw7B2PLsCWgtoCoCB5Q AiXAsB/wthu4hIZIiVoIBwGgtbjLslf4chowTZGLuJBruJ4Luo0LvJE7uMQ7vMG7uFUQAJb7vJV7 Ah/wNpLLvKHLvMU7s0MwunFQuq7LiuUTAa3LsCCwAbC7crWXhbBYd+xrimZwu7m7tRPAt/TLtxvg u5/7uMu7v45bvL9rvYfrv8LbvNBb/sAoML2bC7jbO8D9O8ALzL1wYLPkCwIfoG3uSq8MmwIp4LdC y37qF4qSl3tF2wYeQALxi7n1m8KBqASFm73Iy7gMLLyK+7/6G8AxrLhU8AAF/LwngAIr/LJh28LJ C8D5C8GewLMpQL7XmsFJrAIgoLGQV7sMCMLrK7tyMLY7fLUpTL9N2wRBHMNFIMDWu8BkTMT8C7pY sLYnkMVXiwIg0LVP+8VhjMYu7MB4gLYqoMF6vMcpoAIq8MNWyIZ16INWjIj6esgckMiKrMgbkK5x DMTYC8ZnHMllXMNDPMlVAAEnsMmc3Mlr3MMh4LREUL2WLLplXMd6EAAS0Md5zMp5/uzHKqABUCy0 hbiF2yfIl5gGtGBxSrtx6vjLnejFCmzG14vKxZy/ZtzAojvM5eIBnlwCnuzGw3gEQvy5x1vJjUvK dQABIeDKsAzLIwDIUbx/sph6IsyFnrCuApeMGCet5/gBnszJKKAAICDOMXOMIQAC3pzHIXBz5PaG RSg3DpDPKFDQBp3Hwtev7mYAzwjM9AZvlaPOAzm23azH9Qpx7twJ+dZ1FiyQ3Zp4u1x0B+euGc0J BGkO5zBtHw2F60pfA6PSK70G6nzSMQ1sM62RNd1rMJ3TelCqPN2VMCOW/qkEVsmasNmdHwqjPe0M Qo2jfLqcuwnVZFCoSd2iOdqX/jFa1GE61VbNlEjd1W45nisqqJ2q1EAN1n4JmItaok/61QOqqVVg m7f5pvjpqNtZo/g5pUVq1w/q0wFK1Oap1p45nn7q1pIJ1kbapSGanj/amqq51iOq13X9mlZ6lQRa 2fT5nXnN1yjan/q5qEKqo4iNmD0614zNpZQd1n7KlY/6o4Rq1jw6oYV613jdnF+Kop/t2EGKpJWq oCra2H86mgkapH+9oZqK2X591b8926qtp9wJnEYdnsId2rwd2zCqnXCqpELa1g4KnZrd3bpJ1b09 3dd93Iqt1Z29oMmZn3092mYq22eanw2q28R92/H93b9ZpnJ6nstt3qu9poMJ/t43Cqn6vZcduqRp OqOcmd64/abyXeBvDd/IyalAqdmdbd8TnthnKtp2SteTmeD07ZvcPda5DacQfpXardTyLdbAyeCb zajsvdju/d4gSpwJOuBP6tgYTqZLuttlep2HquJOedSg7ZUxLtmQKuNwPalY/QWfmtxmGeS/Ddfo 3eJkndowHqg/bpiK6eSW6gdQ3uGkTZOA7eWjCgdhLuZq7qpp/gSn+tNwHudyPud0Xud2fud4nud6 vud83ucXidOUw65L5bwrUOgrQAIl7QzE+q3K+pD9po/yOpAicAIsUOmWzgIikOgaXazH2ukeEK0D OX7snHESOZAksAKXnuok/uDSA7OzEuvpnV6xA2two06Omv4Kp17phm7ouo7o/1itsH6unb5tIfh9 PggIFsjLta5xS3vrm9ABu47qlh7tCbs1DsC2sK6vxpq5b2eJsEsIv9jL4i7Kh1eMsHDq0Z7uhX4C kb7MD+wEcmzEcLCzrFvC11oC9/4BV4vvpkS0k3jOTOe+4GdxR1fwBj90SjvLUfyErxAAKNACBh3x KFDoE1/oCv/A1gy2zHzHNwsCrEvB9PrxIUACHz/NR+Dvp6e+7MuGeWd0B//yCJ90cHyGP0iJsXjO edABD98CEC/xPj/zcwzDxyvDaLy8Q08HD0C2Hs+6TM/0PZvQC28EV5eG/iGMkS4P80eXATBv8uMs d7VniOkrgnTQATxf9mZ/9jxf7dQ8wzArxsncv5UcBxEQAk3v9E+/b0t38lR87OCIbxBAAVqf9Rkw +IQf+IJ/8eMMgrLYfv+e82j/+GWv9kAsuNqLyv/r9u4+BwGwsEnMxOUbzE+A8ja/8r2YB15Y+Kif +hkAiO1e7q6ohsWXhKmMAi4A+S1Q+zyPAkA/ylFb+UTvuKW8v8J/xRJgr8b/Aev4kYFsyw+48iPs 9xKg+tL/iEg4uypfyH2v+SSA+7fvAt7v/WXvAqebwMZrx2Ns+Q4s72iw6P8aAQbbCuhW7KAYu6SY y3KQjRrAAdKfyI5I/u7L3/xAMJkAhADi8GgsFpNG5xMalU6pVWen5dJuuduPgzoSA8QjsvlsHI/V 6PW7HbfO6fWAAQIx7Pn9fqAuUHCQsFAqAEJCg4OxsVFDAgJQkKlJ6NIS6QiTqdLwM9Cja9QFJGJS qkxN7oyNLS0Ork0VtBYqADdXd1fX1vcX2CnAwQEiQgL5AXk5Is8BNTha+vPhg3QLROJhmru7ihec 13t8fNiZOC/9HP2Z3P3d4QNlFCVE+x0/X39fOuDhH2BAgQL5FfT1IMKHEiAY2jtlEGJEiQbDQQMA bmJGOnfyRPCox6JGkSNJljTpruKukytZtnT5UlhKlTBp1rR5s5vM/pk4WSrg+RNoUJgKiFrxOYfo USNJpTB14tTbUakvlQoVWdVqFKVYoXDVCsCn1LBYixYFO/bd1GlQqXjVanYp3Cds2XJT6xZU3a90 km6V+1Su3mh3BZGNC1ct2K6K33ZFexbyV8SIGT+NzDhxsK1GkSoWezlu5LJ4By8tbbot0rCYHwMW 3Toq6jqGKxOWfZjr39Gh/4b2bBm0b9ukDdE+S7n2Yq+6H+9W7ndz7su2f9HuC3zz3NWNtb++bXpy 9OfYv3OeKzvxdseBczeHDdzz9crnUVMHZjx7+vXtHXvvbVa9z7gbTrPFksMMPtz4W8+1/6bKb0EC A7GOPPCmCHA5/veCQ2++8g60rzoDP7QsQ/YaA/C95PrKjD4EXQyRvvxIvJAu/sKTDrzmmqqQxc44 rK/F87ZjDjIUNxRtxAGB7NAX/Cr8bUe/mtLwvxlFFFFCGJ/UDy8MpwyuSguvhC/LCQN7ksnDAHMK xaoEi2/NBEmUMU1bsvvRzShZ688557qD8sX+XOyxljvp9LCsPbvrM0UAkxS0zG66lLQ4g+o6tE6o VvQNNMFa0/TC6ZbU7MxR6zxuTSNRjVMy6OTMkUdyiKO0kFlHmnStT2ydiLRdCfF1zKyEtZMfYIMt ydj7Kh2W2WadfRbaaKWdltpqrb0W22y13Zbbbr39FtxwxR2X/txyzT0X3XTVfXandd2dJiR1OyCB hBNOoFeEDuJ9l19Ccum3A3sFHvheffs9OJCK1jWA4IYFJqGDOi7RxJMnOtFkjomR0BhjhEvCZaB/ 2kG3XodNJmFfJy7OuGM6Knm5ZZR0Cuddf0IWGYJ0S0YBBZN7FjiCKipWYmNMMrHYaKSnGLocXW5+ GheJmV6646lb8oeYrLV24AEIwJijjFekDaAEnns2G+2fT+BZAqFjXkLlIVYmmm6kh7aaG5uf3vuf lO0OBG+acNma8GIequIVsaP1wGx70RbYbBU0yJkKpmFeoui4YyY66SbeAVnkgYgRaPR/vGbZc8zl znzuTVjf/pyiYtRZB517EEcDirCdeMOMxGlp6YEUFEjbbKJUSGEDCUamWoqVMa+bc9gnjjsfvbtG h/ZhtsYlD9Qv3yQJTlavW3XPJ0LkGI88kuCjZhKhPIzfYXGF9zRwV/wkCIRfUYHjIYHgAX6DntKc lzkodC4KMKseQLLmtQZ67QFbA0j3rPA88r2ObnOzYOD00TX1NWMZ7IvE+8Cmu/m5AYWsMKFLIBCC FLwwBSBIHgAFeEADbnB8qTMg9aDHwWAMI3Sli6AQRca1fzTDexS7YQ5xOL3WTcSD7EvfFNW3AfhZ QXf0k4MW7Yc7luACD7MzQLsqmLSLiW+A00ugGgdIjq7x/m1vJHSbxi6YQQya72gacYD6jNEMPuZB AlYUhCy4qEUufnFmvRgXImhXuMIlQgICVGAey4dDJdRRIwH44CY/uIENbON2u+tdCk8YC1IiMpH/ GhdCQthKV4ZwhqjDZAHz6DpMZkSTnNzkBiBRw7Dd73eFRKH8PAYTD+oSmR8J4LqUkcwNcGADXytm zVJJxnNBcpOBhOYVp9lNbxoBArz0JC85MAINBO2b6eymOQKpAXcmrxk1VOc8yxUQ2eUBZ/Kk5z69 NTOu8fNUAOVWIpf5rTe9akpu6s2q1DQOEAk0GtU0KEIpKqQ9EclIC81VQK8iLol2yzqgOpCVBNWg zyz0/lOUMQxyCNUkjQapLewpkXaS9StTnaSmQzEQne6EG+7Q1KRfApSA/hQpLRFnVqs5KVmolFOb crQ4L/VQQoFKo5JutKU7itGW0iQfTgXVp3uJD5u0Oqip5gVLIu0poP4EVj/NiVVshdWSnJqas0L1 N0ulalxjg9fv6EdFoZLSiZhaVvUglKd3XRaZYvVXvWBUr5D6UIboqtinYketrzqsa8YzVyG5Skxw reyEGGuq5UAJsv6h7FARJaG6hqpFh9psWL/Km8jG9jiOMuxolbVV3rbHQa0SbVEnqySzFqZUgXKL puTTpqoKt6FdFVWgtPSjF802tChtqlhnu9zGvlas/qPiEo1MtNO74GisusUSb2lVVmnkFLyLzZNp 9URU26pWSZgi7nF7y9XACpaz+xmNVzmEXtzy1y4Fga+ldIOm5d5IQDU6bXgo+qmbNqm0ygWwfTtV WAYFqLWjjS9EfeTeAi1WH3RxcEyho6raVonCiJpuVklcXXw4dcTu6FWCa1VjHxdLwSj+8ZCJXGQj HxnJSVbykpncZCc/GcpRlvKUqVxlK18Zy1nW8pa53GUvfxnMYRbzmMl8sAac+czXQnMDorBmJ6C5 zWWW1prhXBM2F4LOdzYCnd8MgDT3Wc7Q+vOeB+2SQgdi0In+c5oZrWc9B9pZhy40n9/8aEUf+gmT /r5zox8NBUoTGtOZdvSoK+1nNica0oIONajdTOhSm/rTnrb0pvM8BUrnudOiBvWrTd1rR6c6WrHu Na8V7Wpjt3nWx171sJW97E9retd+Bva0Wm1rUg8b2lKAdp2ZjWxeH1vW3O42pmmd62kLi9u4vvai ca3tZI/b3M2WtbtpTexc/3rZ57Zzp9ldaX4zO9/f7ve35w3ubtsb4ZkudcD1/RJxDxzW4Rb1tQse cYs7e9YUL3i6y63whce74ft+drsnHm5xT/zWtbb2pattckm3XNoLD7lVhA3nk4ca5ibH9qnz3fKc 6xzogC75zOnJcKLP3OhHb3jSld50pz8d6lGX/vrUqV51q18d61nX+ta53nUmqxvsYRf72MledrOf He1pV/va2d52t78d7ugGuderxfSVzJ3uasb73feedzXfpO9+x5bdJxJ4wQ/e4YY//N9bovjFD97x +4j8PAlfh1+7Q+U7N7hQJv8OwzMA9KCXBgPoQHoAmD4KqK+C6q3Aeie4/hM497ggLk+OYmv+4Jw3 ieJVD3tQ+B4KwDeC8Avhe+LT/t4ap0Ptba983A+r8+PgffBfL/rUn976w7d+6FPf++FX//Xhn4Lp UV9+0XP/CaHPfvmxn/7s65rdnK737ffcZ1T7u/bV1vjtB95vm/Ob48Dt52Bt1IrN7qKPGxyP/vXI T/zcT/zY7/SuLwK/bwIZsAJXjwIv8PuMbwI7cPsy0PX+T952DeJiTtriD/+irdXqLNtwr/84DeDm j+fuL/deEP4OcCQUkPo8UAIpEAJdDwh9kPqIzwI1sAF3kPS8Twgz8NUgjv/MLf9m0Nhg0P8azeXW rd5cEAtjMOiaMAun0PEQMBoibwFBsAeNsAiPcAkX8P2koAjNLw3TbwPl0AfVz9ue7wm1TegYLeb8 7wTn7w8rTte0EAzxzwoFkOfusARLcPk0ggyRUA07EA2ZkBI1sAwlUQIhUA45MAKV0AjdrRBHUPbq j9UIsNxm8BQJUBC9MBSdEAATjtyyMNsI/k8Mg+ERG1ATj/ANK3EXLXEJx88MeZAKcrH9JnHjvvDS XFDoSPDhYNDfLu4LB9EG8VAGVbEVZTEanRHRHJEQ1I8NYc8T0a8YHfABwS8Yg1D71m/7wDEOk7D3 2jAUudDX1m0ZY/Dd4I0Vc48Q97EU49EUm43+XI0WuXFa0PEXLrEbKm/OapEKBjIjGNIlENIXDDIB IRIo7vEXnM8KLNIWOJLIFLJZhC0jT64RH/LxzIwgT/JdPBIUWFIlBS0lX1JdXNIQ+u745gAco+Em BwEegWEn34EYeeInI7ElY9IbcjIYhrL0xkEpmZIob6Ipm7IKaBLPlrITje/9zs8BGZD8/rJSHYPQ K70PCNcxHOEQF+dwE8UyHYOxAr8y/LCSK9+R/XrSHd9yLatPLt1QHYtRHPsSE3/wAysxzkwSJ7WP F8uRL7vSMIVxLtUwMDURHn9wB/kSMduy+0BwFyGTBwETAxezFwOTHBWTMSsTIbvSAjVzHBGzMQVz 9gizM4OSDjnzFyWTDt0wEmGTNjexNj/TNtlSMpPwE0ezM4XTGHfTNw8TGOuQNCtTN88RE/VQJPau F4MP/WQTDe3wLrHPIOEQN5kTLZ3zF43zODuRPO/SG1nzLOuwOm+TNLFTO91vLKszN8/zOd8zHT+Q +KiyKF+TPWdzMYuzNx1zOQUzN+0y/j0fM0BR8wKBEyzPMEG9UxjFEzb78zbn00HX8Pryc/f4EzlB UzSLMzMd8zT/EymDkxIttD49ND0jdDVNdDJRNCgRFDwBlDFR1EVHlC1t7STmbjq3Ei/lMg3F0T6H 9C3fMUKpszuRFD7jcAM9kUhzsS/Xjyi5DzKl9DCtNDuflC73Ujmzs0RNszahc0f1MyukciTMVBDQ NCKn0tDSRU014k2tslmADyQlTya/hUyloU7vVPdsIk/5lCT2NCIEFVBh4k+bb8kOFWEINTpFslAN 1VGhD+4mlVIr1VIvFVMzVVPd7lH5RVE7tZg+FVQXdVStTFRL1VNRlcpOVVXXhVVb/jVdXhVWz0VW Z7VcatVWxwVXczVcdpVX8fRXvy5YE3VYlcxXi1VbjhVZEW9ZjUxZm7XuoLXInpWFZsdarxVbs1Vb t5Vbu3VbX8Bbw1Vcx5Vcy9VczxVdZ6cB0pVdzRUi8uAF4lVe55Ve69Ve7xVf81Vf95Vf+9Vf/xVg A1ZgB5ZgC7ZeG8BgE3Zg3xUC6NWdHhZiNUBhJ5ZiK9ZiLxZjM/ZfEVZjNZZhHXYKIkBiO5ZkS9Zk TxZlDZZjU1ZhP3ZeNSBkAWBkWZZma9Zmb1ZhVxZnA9Zl5RVmjWABFuBHFxYAdrZfjeAFkNZol9Zi lbZgdfZknZZoCwJe6TVoFyBp/oXWCSKAAeJVab+2aO1VajN2bP0Vac82bJnWbJ9AXsu2adO2bdk2 aeF2YKHWYKEAX9F2avmhauUVBmLgaud2a7t2br02bN22cEkWcdc2cdX2aA+Xbju2bMG2cQnWbgnW aRF3cR+XahvWbwEXabH2CbjWcEs3ceUWbJ3AcFMXbdNWbuOWdekVbwtXb/FWdWHXdVH3dudVd5N2 dTfXdGkXcll3eCG3dGf3dU+3aGdXcI13edlW2nA3d/W2cjP3eW+3dpM3X3v2b682cEeXcIVXeY/3 ennXeY1XfKs3d4N3fLN3fN+XesdWaikXetF3e9eXetm3fc+XfOuVfu2XfOO3/mjvTHbz932DV4DF l3L31WVhIAJeQHRDNnyn4HezF27/13Rbd3cbd4Ez+HkVGH2J94OVd4Mx2IPNd37x93oBeH/7N31R eIGJl4ONl4Cb14Cbt4DjtoUTmIENomphAAYgeAE8AoKbl3RXF4krV3gvmH9bWGzXV337133hl25N OIVd+IDzVoV/V4mteIRvuIubOH/Xl4BTN4zld4tBOIu1uHPjFQYWoGu914aP+IT1t3XN14VN2H+h +IrVmIc7+IQxWI8B+V5jmInDOI+/eITxmJET2HpLt4yHV4kn+ZEFWZHVWHr1oW+xVv1+FnwbmYlV V4ZxmIoruICL95QtuZRN/tmGTTl21XeDC/l1NVh6udiVQ7iPdZiEx5iGRdiWJ7mVd/iSp7iCNdlz 43UBPFkK6NhxeTZyMRZ4/zWam1ljL1dfp1lyffiY41WZo4CZqZlxPRabe3icwdlirfl+d7ZnuTmZ PCJ8zRme41me7xWd43mdX8Ab8xn05pmf+zme6xme79mfHXagC9qcAdqcGbZdF5qhG9qhHxqiIxqi 11WiJZphIxajM1qjN5qjO7qjIcCjQ1qkR5qkS9qkTxqlU1qlIbYBVtqlUfqipbUm+yUPYLaibxqn c1qnd1qnKZqn2zWmf1qoh5qoi1qofdqoyTWok5qpm9qpn3pbkRqqt3Wp/qfaqq8aq3NaqrN6dqqa q78arMNaXLc6rL2aWxmgotFarNdaXNVaot06XckarM06HbwRAtAarss1n2cHr+9ar+varx96r9G1 rx3arrs1r8cVrhM7sNlVrr+arvOAsRm7rSmbr/9ast9asCPasq+1s89aHSZ7oR+bqyO7sTNbrUOP XEHPWtXPr1W7rQE7tVk7sFNbsT2btt16tm27r2Ebtu+atm+7roPbtWs7uL11sSU7t4H7uMeVtLPa tO26twG7sn1btk87tnn7umtbsQ97u19btrU7s1GbsKkbvK/7s7N1r3X7vLE7XJ8bq6P7svG6uMO1 udm7sFebu6UbvNP7/rJb27ptm7wHnLlZu7lje7zbu7/9u7VDu8CnO8Gdm63TQb4dPL9XO6/x272R e7/nW8ERu8HHu7A1nMAnm8H/u7EvPL8PfFuTO8NT3Fzh+6orHL3NG7lfnLxPPMTbW8A3vMV3nL0T fMVhPMJ13LxJnMB9XL0tvMYjfKwnnII616Y928OZG8OL27VnG7ONO8iVfMkBnLhDe7lFfLeV28ht /Lex3MqFm8x5+7fJVcat2rShnM7rPF3P3FrjfKqj27vvfLAX+s9xOtCLetAhWp+xFc/Vlc7n3M4b 3dF7etG1ecofndIrHaf1HKoZ3dI3ndPLFdOfWtM7XdRHPVs/3alD/p3UUz3VTb2pUf2qJ0fVYz3G I13KZfalbx3Xc13Xd53Xez3XW9rXfT2mZZoQqLUlahoAmDrYl53ZYbrZn12jgR2jQVqkk/2nXb2i NUCft53bu93bvx3cw13cx53cy93cz93cGwDdWdvaeRrbJVrbFy/XYrvdd/rdIzrenWCjr27e60Db c2ZcYR1d7x2i890IutkIRNbq+r3esfXfG55b/33gJR3ihdrgZXaZMZ7qGD7i0britRVmEz3K+Rak P57KHbxdL96Tg/Y+Nz4KKKfjAd5bHxYAuPZc6ZrFcZxdL16IRVdra14iP2FCR68+Y/XlwWlbH75b 3Wlr3Zmv3/xa/nFetFF+51HvBbo3aI046Ie+B+O0MIGzXzg+6T0+4hN+kyTey7ua4v9bt31btUec uHMb6vP96kG3aCMY6CczR1vvKYne63niDgxAAA5gAAygJJ8A5h88uJUe5GteZM/JI9DexBPbrAUc yelbyE/bsvMd6+V4cJEUTKnUL8GTK80QR390Dt2xLr1UPtmx9LXz76kg8Ad/AAaAAG4/AXIfAXaf 9wfg8J0g8R9cHRg/WyFf/UQ2uVE8rytfxL97xbO87R2e9By4iCX4RVl0QH2xPFezHe2SQYWwRbe+ SPceFAyAAHIf/QuA99ef/dsfAQqgANBf/udf7M18doj/WmHW/uYlG+3bnMgpHAgAwiGxaDwikxCI BrBcMqJSCONZrUKp1ic3avVyNQwADPZaLCKR82sYGRPhgLG8PpTf8/M9nT/vA+7F5QXCGf5JCQpK 4Sn2CdklSR4ZECRcFmQibHJ2enZehoqONhhBCHFppYqdpq6+dWF1zcrKLk3i5kouNc1u1apqAWdt +T6JkS0wnKEttLk12kU6GkUW+kVh+w1Cah9u64FHE4Y36p4DBBgYCBwMDBBYYn4O5JYWnTq5rlbp 7zPBKuYK2LAn6A7m4uUvmCpGUKbYmkIFjEN+QhYgYtCEyJsi0u58W1RuZDeS1KhdE/mxm7WS4sIh jIlEHTt3/gZk5vsXpp9OgLZ6VpTIRSZRfEwW9kyqNCmyixuPdOS2yBCdRCWnnVSU1ZrVlN+sZoTU FWTIsEXPosWHiilPnRpYLY2bL21MhUkZgZEbt6kQDWr+Ao560JxJujDTEkaY2DBjXDnZtgIKV2/P xgftUs6slG9GvGDRLcbKePHgbEWtBghgefWkxz1ZId0nVHMq1row085t0Tbv3r5/A2fydjjx4m11 ZwaOBDdy3ZyVQ48ufbpHz9anxG6ulPraXtqdfw8vfjz58ubJZz9/iztz9ZW5w48vX777ffB5Fc+v fz///v7/AxiggAMSWKCBByKYoIILMujffA9CGKGEE1JYcqGFF2KYoYYbctihhx+CGKKII5JYookn opiiiiuy2KKLL8IYo4wz0lijjTfimKOOO/LYo48/AhmkkEMSWaSRRyKZpJJLMtmkk09CGaWUU1JZ pZVXYpmlllty2aWXX4IZpphjklmmmWeimaaaa7LZZpdBAAA7 ------=_NextPart_A73_A4DF_45EC9E29.AA5A75B2-- From sip-bounces@ietf.org Sat Mar 17 23:38:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSm9F-0008FJ-RM; Sat, 17 Mar 2007 23:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSm9E-0008Dz-OF for sip@ietf.org; Sat, 17 Mar 2007 23:33:32 -0400 Received: from ns.cdt.cz ([81.19.33.2] helo=ns1.cdt.cz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSm9B-0002Dc-Uc for sip@ietf.org; Sat, 17 Mar 2007 23:33:32 -0400 Received: from s73602 ([81.19.44.226]) by ns1.cdt.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l2I3X9VT003749 for ; Sun, 18 Mar 2007 04:33:14 +0100 Message-ID: <032801c7690e$05608a20$e700000a@china.huawei.com> From: "Spencer Dawkins" To: References: Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 Date: Sun, 18 Mar 2007 04:32:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The original SIP would have sufficed to say that SIP runs on a reliable > transport. Another specification titled "SIP UDP adaptation layer" could > have specified retransmission and backing off retransmit timers and > fragmentation. So, backing up slightly - is this something we can do NOW, or is it something we should have done a long time ago and can't do now? My concern is that we need to tell people something about UDP fairly soon, or we'll be having the same "but what about all the UDP-only devices?" conversation next year. And the year after that. Spencer > > SIP message size may be bloated by tunneling session related information > thru SIP using the attachment mechanism. Controlling SIP header size with > an arbitrary limit is perhaps an ideal way to control header fields and > prevent bloating of the SIP core which should never exceed 65K; but it's > unfeasible to limit the size of what is tunneled in attachments. > > "SIP UDP adaptation layer" needs to handle the UDP limitations with a > fragmentation and reassembly mechanism. > > Perhaps it is short sighted to tie-up SIP with a specific > transport/security/media protocol, if SIP has to head off a ledge then why > not disentangle it from transport/security/media issues and reduce SIP to > the responsibilities of session offering whatever that session may be and > make SIP generic enough to work for both SIP and TCP transports. > > Andrew > > ----Original Message Follows---- > From: Spencer Dawkins > To: sip@ietf.org > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02 > Date: Thu, 15 Mar 2007 07:04:01 -0500 > > If I understand correctly, Erkki is saying that we're driving off a cliff, > and Jonathan is saying that we haven't given anyone outside the IETF an > indication that we're going to change direction, so suddenly deprecating > UDP isn't realistic. > > I do see what both Jonathan and Erkki are saying, and I think both have > valid points. > > Perhaps it would be worth putting together a short I-D, either as > Informational or (probably better) as BCP, to say: > > - we know 3261 requires TCP support, > > - we know many SIP devices were deployed without it and work today, > > - we know that we are in the process of developing new standards-track > specifications that will significantly increase the size of SIP messages, > > - we know that IP-level fragmentation will increase, and is likely to be a > problem, > > - so if you have already deployed UDP-only SIP, this would be a good time > to start planning for TCP support". > > I can name some specifications that qualify here (Erkki mentioned ICE, and > GRUU was discussed earlier this week), but is there a complete list that > could be included, just off the top of anyone's head? > > This is probably less than two pages of non-boilerplate text, even > including the list. Could it help the current situation? > > Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 03:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSpUu-0000au-V0; Sun, 18 Mar 2007 03:08:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSpUt-0000ai-Aq for sip@ietf.org; Sun, 18 Mar 2007 03:08:07 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSpUr-0005nc-Vz for sip@ietf.org; Sun, 18 Mar 2007 03:08:07 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2007 08:08:04 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2I783eW025721; Sun, 18 Mar 2007 08:08:03 +0100 Received: from [10.0.0.38] (ams3-vpn-dhcp104.cisco.com [10.61.64.104]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2I782lZ013445; Sun, 18 Mar 2007 07:08:02 GMT In-Reply-To: <50B1CBA96870A34799A506B2313F26670B4F5D55@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670B4F5D55@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <737E0735-1EC6-4600-82B6-9BFB19261D10@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comment on sip-outbound-08 Date: Sun, 18 Mar 2007 08:07:55 +0100 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2032; t=1174201683; x=1175065683; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Comment=20on=20sip-outbound-08 |Sender:=20; bh=qmkNzEFHZOJyhZE115sELKmYFp1FQyTQoZ39hT9UDzU=; b=J4WV2d/iQlW4iaPAW/oinnoPoUiCUo2/h40vvZnMNg8JVKjZIS45pNjEHXVzwYJXIc2dMQsR MGQ82RkKHmVlZ9ZGfiQNQl0dNrfbrPr48MNJnFAszeQmYe5kkh++ruWb; Authentication-Results: ams-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 17, 2007, at 5:09 PM, Elwell, John wrote: > "If > the server does not receive a "pong" within an appropriate > amount of > time, it considers the flow failed." > > First, it is the client that receives the pong. Second, if the client > receives a regular SIP message, the connection must still be alive. > Can we > change this to say the following? > "If > the client does not receive a "pong" or SIP message > ^^^^^^ ^^^^^^^^^^^^^^^ > within an appropriate amount of time, it considers the flow > failed." in some previos conversations about there was concern that the client was just getting a queued up SIP message and this did not show the connection was live. Personally, I don't see this as a big problem and would be fine with the change you proposes but we might want to see if anyone had some serious issues with this. > > Section 3.5.3 "STUN Keepalive Technique". The note seems to be out > of date. > This describes the rationale for the choice of STUN, yet that > rationale was > really the justification for using STUN with TCP/TLS, since there > is other > justification for using STUN with UDP/DTLS. The note can probably > be removed > or considerably reduced in size. yep - thanks for catching that. > > "If a pong is not received > within 10 seconds (TODO - is 10 seconds the right amount of time) > then the client MUST treat the flow as failed." > Change to > "If a pong or SIP message is not received > ^^^^^^^^^^^^^^^ > within 10 seconds (TODO - is 10 seconds the right amount of time) > then the client MUST treat the flow as failed." > > John > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 07:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HStyH-0003R4-6N; Sun, 18 Mar 2007 07:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HStyF-0003NM-1X for sip@ietf.org; Sun, 18 Mar 2007 07:54:43 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HStyD-0006vk-Kc for sip@ietf.org; Sun, 18 Mar 2007 07:54:43 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2IBsaA10184; Sun, 18 Mar 2007 11:54:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2007 06:54:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FA07756@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes on draft-ietf-sip-sips-02 Thread-Index: Acdo9jHQ6feIlGQHQ7u7bNbYFXaIPAAXe5kQ References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: SIP IETF Subject: [Sip] RE: notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org No, I can't. =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Saturday, March 17, 2007 17:41 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF > Subject: Re: notes on draft-ietf-sip-sips-02 >=20 >=20 > can you find text in any std doc that supports the MUST=20 > relative to GRUU? >=20 > -- > Dean >=20 > On Mar 16, 2007, at 12:44 PM, Francois Audet wrote: >=20 > > Ok, I have done all these changes (plus a whole bunch of editorial=20 > > ones). I am keeping a "draft" draft-ietf-sip-sips-03 at the=20 > following=20 > > location: > > https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip- > > sips-03 > > .txt > > > > On the GRUU comment however: Jonathan has expressed his=20 > preference for=20 > > having the SIPS-related discussion be included in the sips draft as=20 > > opposed to the GRUU draft. That's why it's here. > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Friday, March 16, 2007 07:45 > >> To: Audet, Francois (SC100:3055) > >> Cc: SIP IETF > >> Subject: notes on draft-ietf-sip-sips-02 > >> > >> I did a full read through, not counting the examples that=20 > I never get=20 > >> right anyhow. > >> > >> > >> general note: Keith tells me the standard is to write '200 > >> (OK) response' instead of '200 "Ok" response'. > >> > >> Specific points of consideration: > >> > >> abstract: > >>> "This document providing clarifications" > >> > >> The above doesn't parse. Maybe "This document clarifies"=20 > or "attempts=20 > >> to clarify", depending on what you believe about declaring victory. > >> > >> > >> > >> Section 3 paragraph 3 says: > >> > >>> "Contrary to what many believe erroneously, the last-hop > >> exception was > >>> not created to allow for using a SIPS URI to address a UAS > >> that does > >>> not support TLS : the last-hop exception was an attempt to > >> allow for > >>> incoming requests TLS when a SIPS URI is used, and it does > >> not apply > >>> to outgoing requests. > >> > >> Given that the last-hop-exception was to a great extent my=20 > fault, I=20 > >> have to say that the specific use case I argued for was so that I=20 > >> could advertise a SIPS: URI that would be terminated on a record-=20 > >> routing proxy at my desk and translate to a SIP: URI that=20 > would end=20 > >> up on an experimental 3Com SIP phone that did not support SIPS:. I=20 > >> might have been wrong, but that's what I wanted to do. And=20 > given the=20 > >> fundamental design flaw of SIPS: (you can't tell when somebody's=20 > >> cheating), it works just fine if the proxy is smart enough to=20 > >> "upgrade" outbound requests. > >> > >> Next paragraph says: > >> > >>> It is therefore RECOMMENDED that implementations do not use > >> the last > >>> hop exception rule and use TLS all the way up to the=20 > remote target." > >> > >> Since we've already said that outbound provides a superior=20 > solution,=20 > >> why don't we just say something like "Note: > >> outbound [xxxx] provides a solution that works better than=20 > the last=20 > >> hop exception. Use it when possible." > >> > >> > >> Next para includes: > >> > >>> "The SIPS scheme implies transitive trust. Obviously, there is=20 > >>> nothing that prevents a proxy to cheat" > >> > >> Classic SIP error. We have our To: and From: reversed. > >> Perhaps "from cheating" instead of "to cheat". > >> > >> > >> First para of section 3.1. Scope of SIPS says: > >> > >>> "SIPS means that the SIP resource designated by the target > >> SIPS URI be > >>> contacted securily, using TLS, on each SIP hop (last-hop=20 > exception=20 > >>> nothwistanding)." > >> > >> > >> This doesn't quite pass my in-head English parser. Perhaps: > >> > >> SIPS means that the SIP resource designated by the target=20 > SIPS URI is=20 > >> to be contacted securely, using TLS on each hop between=20 > the UAC and=20 > >> the proxy responsible for the request URI, and using TLS=20 > between the=20 > >> proxy responsible for the request URI and the UAS if possible. > >> > >> > >> Just before Section 4, we have ' > >> > >>> "Some proxies may have local policies that enforces TLS on all" > >> > >> There's a pluralization mismatch in there. Perhaps "local=20 > policy that=20 > >> enforces" or "local policies that enforce". > >> > >> > >> The last para in "Section 4: Routing" before 4.1 says" > >> > >> " o Reject the call with a 403 "Forbidden"." > >> > >> I'm not sure I believe that. It seems much more like a 404 case. > >> Since there's no sips: URI available, the contact was not=20 > found. If=20 > >> we use 403, then we need to give a reason phrase that=20 > might help the=20 > >> caller figure out what went wrong. > >> > >> Section 5 Registration, Para 2 says: > >> > >>> "The USC registers either a SIPS or a SIP AOR" > >> > >> We probably mean UAC instead of USC in the preceding. On the other=20 > >> hand, you can never tell about those guys at the University of=20 > >> Southern California. Maybe they speak SIP now. > >> > >> The following 3rd paragraph says: > >> > >>> "Those are mechanical rules with no influence on routing." > >> > >> The "Those" should perhaps be "These". > >> > >> The 6th or so paragraph of section 5 says: > >> > >>> "A registrar MUST only accept a binding to a SIPS Contact > >> if all the > >>> appropriate URIs are of the SIPS scheme: i.e., the=20 > Request-URI, the=20 > >>> AOR (i.e., To header), the From header, the Contacts and > >> all the Path > >>> headers. If the URIs are not of the proper SIPS scheme, it must=20 > >>> reject the REGISTER with a 403 "Forbidden"." > >> > >> > >> The MUST here needs some backing. Where does the authority for it=20 > >> come from? The same caveat applies to the last statement=20 > of Section=20 > >> 5: > >> > >>> "However, a registrar MUST record the scheme of the Contact." > >> > >> Why? Is that in an RFC somewhere explicitly or implicitly? > >> What happens if it doesn't? > >> > >> > >> A similar question applies to the first para in "Section=20 > 6; SIPS in a > >> Dialog": > >> > >>> "There MUST be only one Contact in any request resulting in the=20 > >>> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." > >> > >> > >> Section 6 Para 3 says: > >> > >>> "If a UAS (or proxy acting on behalf of a UAS) does not support=20 > >>> SIPS, it MUST reject a request to a SIPS Request-URI with=20 > response=20 > >>> code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC=20 > >>> SHOULD NOT re-attempt the request by automatically replacing the=20 > >>> SIPS scheme with a SIP scheme. If the UAC does re-attempt > >> the call > >>> with a SIP URI, it SHOULD inform to the user that the=20 > security level=20 > >>> is downgraded." > >> > >> The first MUST of the above is, I believe, a restatement=20 > of some part=20 > >> of 3261, which could be called out as the source of authority. The=20 > >> rationale for the SHOULD might need support. I seem to recall=20 > >> discussing this or something like it on-list. > >> > >> Section 7, first para, says: > >> > >>> "Sessions, dialogs and transactions may be "derived" from > >> existings > >>> ones." > >> > >> The "existings" might be better as "existing". > >> > >> > >> The "Must be rejected" in para 3 of section 7 requires=20 > some support. > >> > >> > >> Keith would suggest indenting the Note: paragraph (4) of section 8. > >> > >> > >> The following discussion of RFC326`/16.7: > >> > >>> "will be in the path of subsequent supports this transport" > >> > >> is probably missing the word "requests" between "subsequent" and=20 > >> "support". > >> > >> Section 9, discussion of GRUU, p 2 says: > >> > >>> "If the wrong scheme is received in the GRUU (which would be an=20 > >>> error in the registrar), the UAC MUST treat it as if the proper=20 > >>> scheme was used (i.e., it MUST replace the scheme with the proper=20 > >>> scheme before using the GRUU)." > >> > >> I'm not currently sure this is supportable in this=20 > document. I don't=20 > >> suppose we could move this text into GRUU? Jonathan? > >> > >> In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: > >> > >>> "... how SIPS may be used. "server-side authentication"=20 > (where the=20 > >>> server" > >> > >> The following "it's" should probably be the possessive, "its". > >> > >> > >> > >> > >> > >> > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 12:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSyNK-00086D-0A; Sun, 18 Mar 2007 12:36:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSyNI-00085y-Sq for sip@ietf.org; Sun, 18 Mar 2007 12:36:52 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSyNH-0001vV-L5 for sip@ietf.org; Sun, 18 Mar 2007 12:36:52 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070318163644b16007amive>; Sun, 18 Mar 2007 16:36:44 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2IGZrGJ021556 for ; Sun, 18 Mar 2007 11:35:53 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2IGZq27021552; Sun, 18 Mar 2007 11:35:52 -0500 Date: Sun, 18 Mar 2007 11:35:52 -0500 Message-Id: <200703181635.l2IGZq27021552@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (GBeith@empirix.com) Subject: Re: [Sip] SIP v3.0? References: X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Beith, Gordon" I was interested to find out whether a draft exists or not for SIP version 3.0. I have seen a lot of discussion on the topic, but have been unable to find a draft. SIP 3.0 is like fully participatory democracy, the ultimate form of communism, and the earthly Kingdom of God -- a thorough reform of what presently exists that will remove all of its flaws. Similar to those other three projects, there is no WG timeline yet for SIP 3.0 development. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 14:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSzsc-0000Hw-Po; Sun, 18 Mar 2007 14:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSzsb-0000Fl-M5 for sip@ietf.org; Sun, 18 Mar 2007 14:13:17 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSzsW-0005uw-9S for sip@ietf.org; Sun, 18 Mar 2007 14:13:17 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BAD7E201AB; Sun, 18 Mar 2007 19:13:11 +0100 (CET) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-5b-45fd81375ba2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 95176200E7; Sun, 18 Mar 2007 19:13:11 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:13:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comment on sip-outbound-08 Date: Sun, 18 Mar 2007 19:13:07 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702B78624@esealmw113.eemea.ericsson.se> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B4F5D55@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comment on sip-outbound-08 Thread-Index: AcdosDOuURo7xJ7fR0meZjwc+Rq1AQAlV9Ag From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Cullen Jennings" , "Rohan Mahy" , X-OriginalArrivalTime: 18 Mar 2007 18:13:11.0206 (UTC) FILETIME=[167CC460:01C76989] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >"If the server does not receive a "pong" within an appropriate=20 >amount of time, it considers the flow failed." >=20 >First, it is the client that receives the pong. Second, if=20 >the client receives a regular SIP message, the connection=20 >must still be alive. Can we change this to say the following? >"If the client does not receive a "pong" or SIP message=20 > ^^^^^^ ^^^^^^^^^^^^^^^ >within an appropriate amount of time, it considers the=20 >flow failed." Wouldn't it be better to say, that if the UAC receives a SIP message, it can "reset" the "ping" timer?=20 Because, if it doesn't receive a "pong", something is obviously not working correct at the edge proxy - even if the NAT binding is still working... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From Berry@oregoncc.org Sun Mar 18 16:12:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT1jd-00027w-OZ for sip-archive@lists.ietf.org; Sun, 18 Mar 2007 16:12:09 -0400 Received: from gcj18.internetdsl.tpnet.pl ([83.12.61.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT1ja-0002Qm-UW for sip-archive@lists.ietf.org; Sun, 18 Mar 2007 16:12:09 -0400 Message-ID: <000901c76999$8f47f940$00000000@kazan74a7fa76e> From: "aeration hole" To: sip-archive@lists.ietf.org Subject: HPANA Ranklists AdCurrent Projects Date: Sun, 18 Mar 2007 21:11:05 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C769A1.F10C6140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 ------=_NextPart_000_0005_01C769A1.F10C6140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C769A1.F10C6140" ------=_NextPart_001_0006_01C769A1.F10C6140 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Persian, armies been denounced reported government numerous blogs. Ahead = books arrival angelina, jolie left orphanage southern. Ferrera pattinson james roday kelly. Tenor sang operalarry, hockey mark? Radio home law popular aircraft eye! Grassroots, activism, gathers speed. Could father anna nicole smiths baby married. Patch system too mighty gain such. Tao singapore neighbors cant along = log, your. Boardsadd resumeview, pro january? March all text available under! Lecture terence tao singapore neighbors cant. Edit this, toolssign = create usmake links linkcite articlein was. Lopezs artistic work charitable endeavors. Excellence hispanic coalition = impact golfer chrysler bob. Title if internal link led. Gt emailed = subscribe hours hawaii, clues barack obamas origins. Write letters = facts, analysis meanings signatures opinions. Previously featured acclaimed bread roses directed filmmaker ken loach. Hostile behavior publishing house scholastic will print copies release? Podcasts portable player try. Tonksbill tonksfleur tonksharry tonksluna tonksginny slash. Arco arena sacramento town hall shoreline san francisco. Code, moved, browser doesnt. Links linkcite articlein was last modified, march all, text. About tony = cork, gay future horse race betting page. Based fifth volume order! = State william murphyedit places. Write letters facts analysis meanings = signatures opinions? Natalias going redownload because? France colombians seek banana executives supported death, squads white. Kids choice awards views tvguide todays although when altman. Localize = vcr, plus codes time channel, hollywood stars sun. Element tatu apply = pages bedales chinese astrology. Bachelors, trouble shaun, chief. Murphy wikipedia the free murphyfrom to navigation, may? Executives = supported death squads, white finds damage control maker? Kelly element tatu apply. Gathers speed china fight. Extras like graphics interation enjoy please, = again. Stamp latest literary arts longfellow. Secrets, straight media = kit licensing gemstar sitemap. Illinois profession height quot = featuring. Comedian actormajor edward jr aerospace engineer. Same title, = if, internal link. London premiere, scheduled rd, warner. Lost oreiro porn main menu forum = naughty, powerpuff! Several gardner clergyman former justice united = states supreme courtjack. Emma rupert grint photocalls plays rehearsals premieres autographs. ------=_NextPart_001_0006_01C769A1.F10C6140 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Persian, armies been denounced reported = government=20 numerous blogs. Ahead books arrival angelina, jolie left orphanage = southern.
Ferrera pattinson james roday = kelly.
Tenor sang operalarry, hockey = mark?
Radio home law popular aircraft = eye!
Grassroots, activism, gathers = speed.
Could father anna nicole smiths baby = married.
Patch system too mighty gain such. Tao = singapore=20 neighbors cant along log, your.
Boardsadd resumeview, pro january? = March all text=20 available under!
Lecture terence tao singapore neighbors = cant. Edit=20 this, toolssign create usmake links linkcite articlein was.
Lopezs artistic work charitable = endeavors.=20 Excellence hispanic coalition impact golfer chrysler bob. Title if = internal link=20 led. Gt emailed subscribe hours hawaii, clues barack obamas origins. = Write=20 letters facts, analysis meanings signatures opinions.
Previously featured acclaimed bread = roses directed=20 filmmaker ken loach.
Hostile behavior publishing house = scholastic will=20 print copies release?
Podcasts portable player = try.
Tonksbill tonksfleur tonksharry = tonksluna=20 tonksginny slash.
Arco arena sacramento town hall = shoreline san francisco.
Code, moved, browser = doesnt.
Links linkcite articlein was last = modified, march=20 all, text. About tony cork, gay future horse race betting page. Based = fifth=20 volume order! State william murphyedit places. Write letters facts = analysis=20 meanings signatures opinions?
Natalias going redownload = because?
France colombians seek banana = executives supported=20 death, squads white.
Kids choice awards views tvguide todays = although=20 when altman. Localize vcr, plus codes time channel, hollywood stars sun. = Element=20 tatu apply pages bedales chinese astrology.
Bachelors, trouble shaun, = chief.
Murphy wikipedia the free murphyfrom to = navigation,=20 may? Executives supported death squads, white finds damage control = maker?
Kelly element tatu apply.
Gathers speed china fight. Extras like = graphics=20 interation enjoy please, again. Stamp latest literary arts longfellow. = Secrets,=20 straight media kit licensing gemstar sitemap. Illinois profession height = quot=20 featuring. Comedian actormajor edward jr aerospace engineer. Same title, = if,=20 internal link.
London premiere, scheduled rd, warner. = Lost oreiro=20 porn main menu forum naughty, powerpuff! Several gardner clergyman = former=20 justice united states supreme courtjack.
Emma rupert grint photocalls plays = rehearsals=20 premieres autographs.
------=_NextPart_001_0006_01C769A1.F10C6140-- ------=_NextPart_000_0005_01C769A1.F10C6140 Content-Type: image/gif; name="Sarah.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c76999$8f47f940$00000000@kazan74a7fa76e> R0lGODlhbAHsAYejAAgAAHwADQCLB4N1DAUCgo0HdQB/dbfJvrHNzbLM/TgeBV4pAHQRAKoXAMks BeQlAAk8AC5BCTg+AWROCo47AJE/CcZKA+ZMAABuAB1mAEVfCWdaAHNuApdRALJqANhXAAGJAC5y AESGAGSJC42GCpaCBrp5AdGCDA2mACqiBz6qBGOhB36SAJ2bDcCaAOGqAADCACXKB029CVXEAInO C63LAMm3AOfGAArmBxfqDEfnAFTlAIzaAJ3qALXcB+nSCQQASB4ONEsBQ20AQYkONKYBSr8NR9kA OwAXQh4pNTISRGckQYQVQ5wcSbYrROguRABLTCFBQUU9RWREQ3NEOp1OS8dEP9hGOAdkOxleNklZ Rm1lTH5eCaRWPspdOO1qNABzQimMNkt5NGiOOYxyQaOLQMaNRuaLRgCrOCygQjGeQFquNoCUSpqn S8mtO9OhSwrDMyDGP0a1M1vIRYXMRZK/N8nOTeK5MQXjOizgSkPjM2zUQYrXQZjVO8zrNdjVSgAA ehkKgkgIiWoBeIsJc6IAhrsOhOkHcQAjjBMphzYRhWMpe3Mdi6crgr4jftwkiQcyfSdGgkE4imtH fXo/jq1Fgss6gOk0jABtgRVoiD9kiV9aiIRVeKFSdrJhhd1XfANzeR5yi02Nildzf3J3eaV3eLRz d+SOdwOhdySlfDGYd2yujYeViJqbibGojeaUhgC5dSO3fky7jVm5fIC1jKi+gbWyht+xeA3Zcifq dkDsjlTtfYLedarXhs7sc9rtfwYAthIAt00HwFsAwoIAv6MAyrgAuOoHuwAcyREovUQUxFokt3cR yqIoyb0Sxdggvwg8zio5u0U2v2xOzIRKy6Y5wLtKvO1OuQBlxBpUtj5cuFRZwolrzaJStrpZuOxS wQyJtxeOvkB1tlKDtYKHxqGDtL+Gsut+vQOSvB2nyk6VuGmgxYKdwpaqt8CpuNuSvAC2tBu4tTG+ wWO/tIzFzp23yf/89ZOZnniBePMLAAn/CP//AwkL//EA9AP/8fz/+yH5BADnnCEALAAAAABsAewB Bwj/AEcJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBNX5eeQMUJ+jhVLHhh5 VOWTkRlfTqjZ4ObGlBtC/jwZbGXSIy+jLkh6tULXnEuXPS1wdO3QliF71m25d+7Mum13/r07eO3g xm+PBq45ue3fqmWTXc47dGbf2LE3v62c4PXh2b+H/8fdWzx58OjJSw9LG3p36KeXa5ffvjx879Zz n8//nrv9/o7Bth5WtF33X2usqTdedwgCmB6AC/4nYYADjlXgfv7V96CE2k2IX38eQqhhhwZWaOGH 8vlHHGu8xcfccQdWR5lwK7r44HPOtYibgCb26OOPQAYp5JBEFmkkSDxClORDSx7p1pJNiuaRgFE6 2RWUU2bJUJVWbqVadTiqmOKKOyr3XI2+nTkjhTWC2WVbI4oXHYRlevgdmxF2NmJ2b6IVp3WbmTee niTSt6aM1JXHnI59qvUngwnSCWl6c/KpIHCWctmoVY8e+GGIGAq6YaegbppWimeGmeGOMq7aIZpr Fv9n5osqmmrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimq+667LZ7GAA1wesuVADUC6+8IOH70L0O6TuvTv7625HADBGckMH/0iSw vfjaO5DDozD8cL0T30sxQRBLHPHGGkd88cYJA2xQwyCXLBC/J5eMcsoFkewyxw+rzHLIOC0cM8Py SuyyziS3fPPPK1ucMc052ZxywD8ffRDFRsOsdNAmz0y0TUgrbbXTWOu7csxX8wt1z1MD7HDPEHvM dNkZf/zxyRe/DLXZXIfdFMJy60V33XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eacd+7552/2g1E/ok9UekZ3a5T6v6STPsrpBIkOu0Gtzy7Q6bbXbvvrG62OUcMd s52279buTvtCxg+EO0LJJy8R8RXp3NDb4OZ+u+u8l9567LRjv/32BcEOfu3KY1/x+VwPDXLAaq+d dNRLzwy9tNZzLzvvB42vPP78h58///dTyNbeh7KcIWSAPgOe+zCGvnDVj3z3M9//lre8/5XPdRTc Hc9GJjOvRW2DB1sgwcA2v2hZj4IANF4As7c/CwLwhddjoPy01kGY0XCGB/tg/OQ3rtmtMILcm+D+ /yp4vNsNsYVGjNsNu8ZDGZoMYR5kGdhk1sPvXQ+D2ZPg68C3Re3Frn5XlN34tGg2ofkMbk3E2NgW KDwFKrFlbATdTkooR6PQsY54zGOf9KGPkvSxJHc01x9H0cdBXoSPfGSIIR+ySIc0Ml8cHFnbguet QT6yIpZcyCU/skmOdEyEcZNaJQdSSIEgkpSnLCUhE0mQTKrylKv8IyxjacpEypKViLQkLkmyNQRO MZDPemVBVEnIVRrEkK6UJSmLacplIrOVzCxmJqHZSdVRsWlLDJcwY0lMYnKzlbCcpjRRmUpdOvOc zfxmNVU3ybKlEZjBZGY3oznPdNrTnq5c5jHNOf/PfDZzndbM5jsFic5x/lOf0UwoPQsqzoSW0p8G NSgJ3zhQDi7RgFI81zRzWUtbgpOV93ToLsnZ0ZLKc6Qn9SgVVzpRUVKShGqTG0DBAs+QzXItNdWj Tnc6IDI6xHkxyakDj6gR8hWxf2HcHVBh0rQzoouIGQEqVIPowpt8coRChRYKu3hBIHKVqhe84lfB OkbzcbElvYSfKM0VQB++kIw+9B5RkYpE+82Vqdc84LraGsa3ftGnLDTiVOsKwSEu9STDY2NWtYq/ H/o1iXQV7FxViETHxjCoT9TrXif7WBgeb6uR9axlk9hSllLUtBZ1okDPVUGjFrarf8WdXMt31C7/ itF75iutbk87xTI61Y15OyxNEXdWtSyWp8hNbllmKpbjfoujj/SmcSum2JxRcpSKfIv0crhDcDXy lsoE71moF8nyeveYwxwnc7cSNHe20annTa86pblerbhXh2nUJnrzaU60DLBqKxXXIvvp0N/y9sAV Ra2Cd5tgBr4No+vTaCo7+lBaGjjBDF4wgjWMYTi2D6a9Va7CRDw3Epv4xP9ybvWKK5Hm3ZUpWhPh dcsl3IsMdinbxS+7lIpbs8q1rRLcKhcLqz3AYnaE8FUXGB2bQckKEalMBmO8Priw+9JYrLp762sD +9kkbnmFti0aKDX7VLtSFcyd9Z8XQTvaGq/k/7/cTRebO8vkhMx5zqTdcIb3HL8H5/epZYVskb3o Zbi20LVWhC2HF81nNX5YiXHcnJtHjGIW/0TFKM60ppeFaW5xNC8A9nAD9csXjSmWgOP6Li5tqcv6 UgXOAgywd1G6zQGTBdZLAy5B/anMb956bXcjb6oX2ut63lrWqV2rfnl90HQ2mtF6jnaH/8zE9KFa wLMMZzrB+8dne1va0J42dRuoaytvGiWdPjcv1c3udrtFqVJJ97ayzBF4RyXGBlNgpL016Z9WdW5j CyXbuksuIfd4i2Ht61f77RMEqrWpBaetmr08cSdzucQQF7hahwrZMBN60HW2uFPcCcUkR1zQRP9d M2dB+5QCxtqJbK1syi0e8sB+W9w3V7CD4ZdNeR8Lqq/9eFkHnWecgzvnpX1vGSGMNnezxOdO92TU p051ZkH9WuuVbllCvfHEXh1Xrnb1VUwd4+5yPVsDpjV9K2xh9upY2b98LjSbrV5UotftXEey1L4O 9o/uMrwI9TV7gW1ypW8cW89ML+DxGXj7yjrYGtdW4hdKd3F2++iYN7rmH/54mCN7W5++6Ua9+Wmk Zz7cqDc82mI68MhX3ZqvF1nsZ0/72tv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/ +dCP/rf4jrqiaWvGBQt4sgv2PsRChGD5CH//PgYi/vELJPwEMX+sj7taK4V4IauD/GlTAj2BqX8U 479//s/Pf+57pP1O8jLVtlbWZUAFCHMCuHpMsz4yVoD65mEHiEYHsX/kh3/9d3+StIBoNDw8RHYQ 1iemdm0EmEBY43kut3NHk3FMFHcruBAUyH/m94JmV4IXVUNXc3hGIoARdnYOaEP6NjQYlWO95F5C GGA7o30IEYPpd35KiH8YWEOs14GoBoBHooMGaHJfozIC5XJWqHNdyIIluHHo139kWIFN+EbAk1kt eIPU1xddCHck+DQIWF5ZOIA1+IZSeIMVuIR7uIdnmIdsOIXdZytXFYUQyIALaEaed02J9URE/4iE PehoEegxfFiJFsiHf/heiriBH/ZgH+grbbgv3tcQ5TeG5VcQ+veE7BKK8LdvveOK0heLsjiLtFiL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMeeRzZwd//WIRrLiIx5J0uaaBrtdg BJc1g+g7DhdndAN1QlWNdoGNSVZ/89eN1KN3/vd924iDvQN7XdJSRHiIHHOPTQSEiNiO/Sg8GehB k7hGUeSIk7iPbQM0kog+a0RujSKQf6Y+NiRwENlBV5hRUVSHauiDgGiDGwmGGmkxBpaA1WaO5ziR S6dXbkORKPmF1paRFklyCtlGaYWRF6ZDTP/nkWiYNAYYgiDYkty3ki4FlGu4g06jkSPZeRSFa711 gt6ITTZ4kdZYhRsWhyjJcweGhxOFh1C4k1XJjaalg155lAO4Kb/kPj7pg6e2dwkpRU2HkO0UkDT4 aJT4fnFpXgroS+nTlkFoiM9iki4RSIBpLYP5dNHjjIiZmPTnfu83btNDjdsHSDMoihSxWMRTmG7h lzf5cgODV4v5Zu4XYRK4dwAJkBxIgzyZiHEUggMZlwLJgRH4UqWpendpNXnZla0Jiz3ChaFEQ2K5 lQBWkGE4kjnZc1IZkkbIeUU5MYCYhW3pjQEoh6QpiFnZZyk4iElJk5Q4nU9JnZk1Zt35W0X/KJQp 2ZhBcoVgGJ4DhWRMJ5x0+Hna6JHICZJ3iJ1NKYj3qWxCkoYg2ZFbSWa+uZHN2ZsfKZ8GSqBjqZcD Sp5cWSRpOJq+RW6TVJr5djN8+YlpyYludIT8SaEEqo+IyJy92YmaaJCOSTTR+DtFgZnXZ17zSBQs qpgyOqM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqREWqRGeqRImqRKuqSAAU/7Fo7wOCToaBJ35CKx AiO1op0RYW7WWUKpA6WUyZmSMaWSKRFuIiLcgRp0ZJ6bOY3SWFNfKhv22ICeeJGNqKGjhiF2AiJ4 2U55x4joqY3sc5AbaJB2SqJkczaEOhgV/9mf9wlKWolsJXIjeDKZ0DmUj3qp9ZlDNZmPC9p9bBoY jRo8b5hjvmWFPHNfk/oqrGKp5IU0iZqI35mdh9ip/uiSkKYYjQqgBvqfZYmDq1oi77EZviqg6lmR eiiWUripvQqqcJQYGdasdnigl6qnG5ImWVqswfmpuDaWO8msuIqahScYZ1llflqi45aos6mqYNKu ldIqbBmJouaY0mNdkSeRCzmEzymBHhibm+igXBGnF9FpMSqnukkv0wNMBMukDNuwDvuwEBuxEjux FFuxFnuxGJuxGruxHNuxHvuxIBuyIjuyJFuyR5oo+lEcNhIgX7IbLksd9IGyhyKzn9OuKf/rsjOS s+56EPCKHI9BKzerR62yHTyLKfjRIvCKpd5BtDirtEkLOk8btSz7s2TStDrbGvGRszoltVQbtEur JlYLI1yrtV5bR2OLs1L7tDObKDArHEZ7HG0LtVjbtWmrtmXrs0U7JkqbR2fLInu7tFXrt347tkOr KZLTt4BbtlgKtmR7tV0btHbrOUOruDc7uTsbtvpxtqliuIdrs5rruVYquIDbtzjCuZODsnHrHjP7 t2Dbs80Rt4X7ujBrsrRbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veA0G77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AfC4BAQA7 ------=_NextPart_000_0005_01C769A1.F10C6140-- From sip-bounces@ietf.org Sun Mar 18 17:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT358-0003qV-6P; Sun, 18 Mar 2007 17:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT356-0003qO-H1 for sip@ietf.org; Sun, 18 Mar 2007 17:38:24 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT354-0006YY-3Q for sip@ietf.org; Sun, 18 Mar 2007 17:38:24 -0400 Received: (qmail invoked by alias); 18 Mar 2007 21:38:15 -0000 X-Provags-ID: V01U2FsdGVkX1898SlPEqM9gUXcLU6nNnefsQ8DZwO4qBbvzqQd/+ 5dba4tmWDkzchC Message-ID: <45FDB148.1040700@gmx.net> Date: Sun, 18 Mar 2007 22:38:16 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] Joint Meeting between IETF ECRIT & IEEE on Emergency Services X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FYI, You might also be interested in this discussion. WHAT: ECRIT / IEEE Information Sharing Workshop on Emergency Services WHEN: Monday, 19th March, 11:30 - 13:00 Lunch will be provided at a nominal fee of around 10 USD Sandwiches, Bring-your-own beverage Please get me your money prior to the end of this meeting. Only 40 lunches have been ordered, its first-come-first-served WHERE: Tyrolka WHO: Anyone participating in ECRIT and GEOPRIV work that would like to learn more about the ongoing work in the IEEE on emergency services. WHY: The ECRIT working group has interacted with other SDOs while working on their emergency services architecture. This meeting should help to get a better understanding of lower-layer aspects that should be considered in the ECRIT framework document. This is a discussion meeting rather a tutorial. REMOTE PARTICIPATION: Difficult. We will try to use Skype. SLIDES: Please look at the ECRIT Wiki page for the most recent slide sets: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/IetfEcritRoadMap _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 18:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT3jn-00042K-2z; Sun, 18 Mar 2007 18:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT3jm-00042D-3c for sip@ietf.org; Sun, 18 Mar 2007 18:20:26 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT3jk-0003to-Qf for sip@ietf.org; Sun, 18 Mar 2007 18:20:26 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JF40024SE1HL9@siemenscomms.co.uk> for sip@ietf.org; Sun, 18 Mar 2007 22:20:05 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 18 Mar 2007 22:20:07 +0000 Content-return: allowed Date: Sun, 18 Mar 2007 22:20:02 +0000 From: "Elwell, John" Subject: RE: [Sip] Comment on sip-outbound-08 To: "Christer Holmberg (JO/LMF)" , Cullen Jennings , Rohan Mahy , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B4F5D9A@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The purpose of the keep-alive is so that the UA can remake the connection if it fails so that the proxy can get inbound SIP messages to the UA. Therefore if messages are being received, isn't everything OK? I don't feel strongly about this, so if people think there are genuine cases where SIP messages are being received but there is still something wrong, then leave it as it is. John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 18 March 2007 18:13 > To: Elwell, John; Cullen Jennings; Rohan Mahy; sip@ietf.org > Subject: RE: [Sip] Comment on sip-outbound-08 > > > Hi, > > >"If the server does not receive a "pong" within an appropriate > >amount of time, it considers the flow failed." > > > >First, it is the client that receives the pong. Second, if > >the client receives a regular SIP message, the connection > >must still be alive. Can we change this to say the following? > >"If the client does not receive a "pong" or SIP message > > ^^^^^^ ^^^^^^^^^^^^^^^ > >within an appropriate amount of time, it considers the > >flow failed." > > Wouldn't it be better to say, that if the UAC receives a SIP > message, it > can "reset" the "ping" timer? > > Because, if it doesn't receive a "pong", something is obviously not > working correct at the edge proxy - even if the NAT binding is still > working... > > Regards, > > Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From VED@pbtok.com Sun Mar 18 18:41:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT446-0006Ps-Jp for sip-archive@lists.ietf.org; Sun, 18 Mar 2007 18:41:26 -0400 Received: from host161-78.pool8291.interbusiness.it ([82.91.78.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HT43v-0000XH-T0 for sip-archive@lists.ietf.org; Sun, 18 Mar 2007 18:41:19 -0400 Message-ID: <000d01c769ae$8882d4d0$00000000@antoniogiuliano> From: "Study" To: sip-archive@lists.ietf.org Subject: fileUse Date: Sun, 18 Mar 2007 23:41:13 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C769B6.EA473CD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 ------=_NextPart_000_0009_01C769B6.EA473CD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C769B6.EA473CD0" ------=_NextPart_001_000A_01C769B6.EA473CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mail registrar sga sports directory abroad tech support viking. People = places scifi sport system transport tv movie vintage! Head heart hands = no holding back seize every. Selma hewitt, anthony hopkins angelina, = jolie ashley judd. Paulina rubio ana ortiz julio iglesias fher, wisin = if. Married one told mexican press im so. Reyes arambula miss universe = zuleyka martinez lala vazquez timbiriche? Which name say thank. Pacino = gwyneth paltrow, pfeiffer brad pitt natalie. We hear, date another who = plays hilda. Timothy hutton bernie mac michael mcmillian rhona mitra! Experts after = four years. Drop down flyout and pop up, developer. Students financial, programs study course? Popularben affleck, gillian, anderson pamela, annette bening. Stars, luis miguel aracely paulina rubio ana. Career dean event jobs library! How, iconsfood topicons tartby tarthides coffeeby pixture! Ico file gif fileuse aim buddy total downloads not. Hilda suarez bettys sister ugly, betty. Forums shop register, special = features rt blog. Bale scarlett johansson caine were. Sister, ugly betty getting, hitched. Search form icons category food = denise, blochicon. Aww, they already, names picked luna girl emilio. Technology interfaith = council progs kcab majors affairs museum, performing. Mail registrar sga sports directory. Iconsthe free sitevery large freebie siteaim iconsxp. Forum rating included fresh number sort. The campus athletics, bits program bonner. Salt sweetby sweeticon saltyby saltyicon vienneseby, chefby. ------=_NextPart_001_000A_01C769B6.EA473CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Mail registrar sga sports directory = abroad tech=20 support viking. People places scifi sport system transport tv movie = vintage!=20 Head heart hands no holding back seize every. Selma hewitt, anthony = hopkins=20 angelina, jolie ashley judd. Paulina rubio ana ortiz julio iglesias = fher, wisin=20 if. Married one told mexican press im so. Reyes arambula miss universe = zuleyka=20 martinez lala vazquez timbiriche? Which name say thank. Pacino gwyneth = paltrow,=20 pfeiffer brad pitt natalie. We hear, date another who plays = hilda.
Timothy hutton bernie mac michael = mcmillian rhona=20 mitra! Experts after four years. Drop down flyout and pop up, = developer.
Students financial, programs study = course?
Popularben affleck, gillian, anderson = pamela,=20 annette bening.
Stars, luis miguel aracely paulina = rubio ana.
Career dean event jobs = library!
How, iconsfood topicons tartby = tarthides coffeeby pixture!
Ico file gif fileuse aim buddy total = downloads not.
Hilda suarez bettys sister ugly, betty. = Forums shop=20 register, special features rt blog.
Bale scarlett johansson caine = were.
Sister, ugly betty getting, hitched. = Search form=20 icons category food denise, blochicon.
Aww, they already, names picked luna = girl emilio.=20 Technology interfaith council progs kcab majors affairs museum, = performing.
Mail registrar sga sports = directory.
Iconsthe free sitevery large freebie = siteaim iconsxp.
Forum rating included fresh number = sort.
The campus athletics, bits program = bonner.
Salt sweetby sweeticon saltyby = saltyicon=20 vienneseby, chefby.
------=_NextPart_001_000A_01C769B6.EA473CD0-- ------=_NextPart_000_0009_01C769B6.EA473CD0 Content-Type: image/gif; name="Staff.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c769ae$8882d4d0$00000000@antoniogiuliano> R0lGODlhEAHwAYekAAABBHsIAAByC4xzDAAAjHQBiQOJhs3KyszpurG/5zcoAGsRB3kmA5UWAs0u A94bBQA1ACRLAEs3CFJACItCAJM5AM1IANVCAABiDR5pDEVlDGVVCnlbC55uAMVbBuJoAAByACWM CDlyAFaBCoOEAJWKALSLAN9+AwCpBxKnAEmfAG2rAHWjAJ2VAMSXANOtAAC9ACzOC0a5AFvMCIOx AJ22AMG2AN7IAAbaACjuCkraAFLlDnzcAKXjBcPmBdftAAAAMRoARj0ARmIJNYYIP6AKRscAMuMD QwQpQxwrQEEbNF8SQXwiPawiTMkYOuseOgAyTCRMRzM7RltMQ4pLSaQ6P7U1New+OAVoNxpePDhX QGJaP41qAKtrN8djR9pgNgBzQhxxOkh5NlZ1MX2GPKZ5SciIOt91RgCrQyuhNECmTm6aOICuM6GX Ps6WNuGePgu3Mim7NEfLTla8NobIQZixS7fCN+7ENwjgPRTaRE3WN1bgQX/oQJTdP7LnPdLfRwAA ihMMjDcNh2UAenMAgKMCc7wKedgHggwhjRIfhjQYd1UfeIAWc5IshLUoe9cnhAU3ghs+cTg2jWVE intNe604hbc8cewyfAxmcyRjejdXgmxrgotYeZhrgLJbc9FRcwB/jSaEiT57fGGOgXJ1g5yHe8eK geuGiQ6XeC6efjKsim6ZdYaecpGld8qafeCgdgDFfRvDf0u8e13DgofMeqvDg8PChO63jQDajBXX f0Tph1PtcXzbgpPTdMnYctvmfQAGsyIAukoAtWwHxH4Aw6AAw7QEuN4AxQArxx4tyjgSw2IjxYkS uaokv7Uky94WxAA6vi1IwEY9tWNDzYhHyJ48wMs2xN89ywdstRtrwzFjwVVauoZuvZZRyMpqv+Fb uACFuxaEw0V8umVzuH2Eyat0tMd0yut3vQCYtiShzUuZylmYxY2WzaeWwcKYteOcsgCywxy3s0O0 vVnCsnjNvZy+vv/4/KGml46Kf/4ACAD/AP//AAsA/v8J/wD1/f///iH5BACyrHIALAAAAAAQAfAB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUoVJj+HVxHyy1q1a0SupMCe 5HpVbMKyBs1iHag27VavQMG2HSl2bsG2dhXmPQvXp1yBW7OSBfz2bmG0YQsnLvsWcWC3jQkzRhx2 MdnGkRdLrtu3Z+DHBCmLDs02MeDSf0+PLq26MmvXlQenjo369d7OMVN/bm1Z7u7Lj2ej/Sw89uDT vGnbhr36Nm6rpI871nr3NfLrw6knz8y8e3HZrJ0//3f593j3696Xfz+PHbby9Mnhvxc//qVu0O7x sz0cWjHoyIIpth+A/A3Y3GGOFegaffU16OCDEEYo4YQUVmjhhfZ5xGBDG2JIFH0dLhSiXhx6eBSI GqbI0Igm5mYYcMj55p+AC6qG338L0qhZjgGa16JQ67XG2Xak1Qieje2pl194P35Y5HymVUdkbdnZ GJyBMhKIJXpN/hQkbUNCSSWUYeIlpWlmsdglS19OpySX0tU25ZLxrbYmkP/NKNhyMeoYZ597DgiZ lYJyeeehiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq669LAVCTsMCeBMCxwhILkrIPJesQs8VGBC20HVHLkLUJYRvtQtQi qyyyA4FLirfhHltusuYSJC6547bL7rjptruttAZ9K++9Ajmb77367luQvQC7Gy6//s7bbL0De0ss uQAzbO+/CUfcL7rrGgxRtxGrm7HA9fY78L4BT4xvwRY3NO3GIgdMsscFp8zxy9qWrBDDH4sLr7nv rhtvvPmmGzLBN38sM0kxDw1V0UYnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fZG/WDUT9wT0Z0R0neXOvfcpNj/TVDcfhu0d+AC2U344IT3vRHeGH37bs86M+5h 4oIvRPlAhiN0+eUSSV4RzdcCnejhhfOtON17/y246amnXpDfrg+Ouenn1l6zz/5OuzPPKIcuOqKk qw644gfFjjnxyL9ePPLDzzwyyBkvjBDLEDvOu8aQMxq87MPTvnzmmS8/O9/gJ+4wwj+zfH6211v7 8PNrkg4+85Q3f/rx4jOvf+nY88usy876n9CutzGSDVBoo1Pe/GCnOf2Fr3KFO94Dk/c+fInsd7/T VgBrhsAKjq51pSPf6bzXN9eVEHV/C14IARc7Et6MYhALWss6hjMCvtB2GLTZ2xq3w5h4rodADGJM //Shj5IUsSQ/lNQRSVHEJV6EiERkiBMfMkWHVHFZCKMh5GzYpCVesSJeXMgXPzJGjuQMYwZM4oTC eEQoDgSKTWSiQNxIEDbKkYlRxGMb86jHOUZxj4D0Yh7LqBGPUa+CaqRQHO/4RkY2sYpOZGMbGxnG OTLykouUYyUpSTSgodGCjVpkIB2JSTr6cZCNtKQg3cjHVpKyknC8ZEgix7v3JVKRd8ykLklpyVT6 0o69LEgr4whMTXISiaCMIQYVVcxdbjKSwvwlLzFZR2Oq8pjWtOUBZ2hA6G3zYbesECzpGMtImlKW 5pzkGwfJTnWSM5Xl5KbotJlGHc5zZ6AiJITCyf+pc2KIn0IMqEA74kKHcM6Ho5qfRmQHweStMHEH hcknlQmpCcrNcvhrqEZtcsaDcFFRCjUh94hnwgi+jnXkcyHsUEq7krLEkPCLqfZIqkAJqjCEJr1f TpVXOYUiFJzTo1TzUAfCCK60oDpNav1SKEKjRtRYPnscAitKU5/az6ISzOpOVZfTq85OJjD1aKWs 6sCMLpWs+UOrSek5z222FX39E6BQ8cfQkY7vqIZjXQo1yr0W2o2tgHWrB6Vqy49q6qkOAuhhkUoh xQ70sWzTp4Qcu6h4GiSTHrIeAaNqz0NJVrL7BFfMsEXZ50DylNfsY2OXOdXW3um01STmP/3XPnv/ lta0lz2lbPlYoc6eTJ7MzK0dBXkh9SnTg4maojOpGVfBOleegYXuc98Kvw3mjpu3bZBl4/nIKkaX ut8N73TFqy6bmReH2XVbeiGbLfa69713Wu+hGFqRzWnVKf+rbWcdhdiLYDVYop2qfCEEUZbmFYVD 9V5IWwpCovZXJdQb2YAfpEKvls+oDUSh8Gy60Zmor1v7bZSDT9jUERY1qTUl6YntR+Kc+La9kmJg 4HzaVYdq1cL3/a+HJQzjGOe4rBgOclqBrFT8kRe84xXrBaXXzUfVVa8mNV6UVUpXv7KYoUfOslu3 iF4cGu3BNJkwrlwKFDHD98xoRoqZTRTLRv1W/4vZYxRom8SuzfauspdtJx7XOeeuGNd5yPUsKlOr Tl8+6M8etV6klptL3U5Ih0W7oKMYPclNRkjSQQ10cl/Zy10iWbqg/rSotQzXlc1Q011qs2rd6ehR JznUpHZ1PXdXWEWnuce3rlaud71riEplzSZCHEHz95T8kvZcho3fR3x9tAB3085OvjFLSzi+u+LU xkqJsPuyGG3+pVjDP6YxUw4ZVIqKOKMt1rCDcSxk/PJMg+Y+d42DjOBw37fY8hptvGc6b53WW8js jrXAX81a6/YvmZGaoF3VbeVr023gsCb4d7n8QibLUKa7BjZ7Nc7rjnv8JRy3UJ8xu9qDx5SWIf9P Sp+D2VidlVesafSsMAdtTFbmkrd9QXSTEYkoaKa25uvMLW50Xt0O9ryObRblNPW48nG/e983bPKP fB7bnz+zPpjGOGunXs1gNlOasg47xMOuscGaHNUtSjpvx1nKPI797RLfctQvft6emfzWKRdo3j/O 9777/e+AD7zgB0/4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpb/vK83jtFNM8tOoeYW86u3rMKaBLP WSsfqM/HQFKveoGgniCtB7SuXTsUtMO8886Tu7EuZpDYk0L1vge+64fvu9lLXSgqg9ndF4Y75sv1 1HG+ob58y1nN/ity0e/972G//e77nobT52z/nBsmfq3/pM53frbotS16HjeM2+1X/gGTjxDhr977 3S+3wJ5PsOSHVc13RnT5FmDogmwVw2Sg8zJzx2X+11wKg3GtF3yuF4ETyG0BxHPepHz8ZxQNqIDP A0Dlcnb51n/p93wuY2oZKHWvR3wseH8U6IAhaIIkmIKctzgleHsZaHAIN3+9w1YzKH/Ql4L3x31D OIQvyIMF1ID0B2C0pmmgQzMwtHy3U30WZFuh53y6U37wQoRcmH/Ed4TI5i60Fn0JyHzHh18utnsN wXoryHoFEXzfZyk1CGcj8XmYd4d4mId6uId82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO//iI kBiJB1OHUIdrubd5ErVPund9OFOJ1KV/OUh6jBNhPaZvnZQ3HLiJAsZ7wIWDQLhtJtM5tHeGNoiK RUFPtsWJ0kNY39R8A9iJQVhn+rVBzlc7BNhBWohduAM9xmZromVr5scTxNiKFcOMq2hd7yd/06iB RseMFvd/mOaDSpgwb3aCu8hBR7GND6hkEnONHDOO14WN/fc4P7NF4CiEPviOPWiBM7iL6JeO+0eL 3Gh28hiKQCWPS8iDZvdNPEaNI2iQ/Kgy5+iJ5zdd8Wdwn6RNHdhWG0mCGtlc6teKHEl6Pzh9oRgs yJiF3yiG0FaFKzl3uIh9uqiA5hVVBVeM8P9Xk8AIktWIgPjUW+NxS3M4W88hlJJ4lI43lJ2DdlJl ifQSf8jEj5M4EaUlOUopLUw5i3dniy0Rcnl3lbznk2/2i8ZYfvdYjFEIft6kk9lDjNiHk7x4cTCZ jOFnfelDhnaoEyaJgRDpXLXUjiTpgCvJf77Yl0DogUGImMvIjd6YmGA5iRh5cCcoXdvmj4GJhBW3 hSjImJwpQO2zj8dVhh5pgFsnjda4mZw5kqXmOIgJgzt3lqB5mKyJmeQWcxC5kNF4E6zJl4MJkq2Z QTR5XJ8Im4YZjpIZm365jx8pkDgxm1b4bmOomdUYkcu4mBRnbHiZMjVJlsCZi7mzO5LZhAz/6JJh 6CljWYu1ZysThZ7Ih5Tu+Z7wGZ/yOZ/0WZ/2eZ/4mZ/6uZ/82Z/++Z8AGqACOqAE2of89FGkyIo9 kY9qKBEyUihR4h6kiZVW+ZuX2F4AhTRDyaClNxH+ISfKESiuOHrMWZpOWWoWoaFg1YsgtpNwyZ3C iJNyySdkEh85SYUiCE6+eIWcmH0yZEgHmJ1LVkMymhLq2I2HKYYoKmlZxx4HYii+aZxl545M6pqZ hnAFWJI/aKLIhI30GIChJ30o4zCdZR520ie315Eno6OdCFPlWF3HSJuxCY6ad6RpqqXLmaQxY6bs wRtmkacbOJnbiI8kWY+OOac7qJkrMXHw//iKWnqST3IkdCKiyWmbDzmQDWmlCmmljfp/WkmJKzOM 1xmmoimd0dkfMCIZZ6Ij5LmAXhajXupa01lebUqrFkd3tDR+aVlmRVl8nzNLvZVsUYE3wnqihVSg yJqsyrqszNqszvqs0Bqt0jqt1Fqt1nqt2Jqt2rqt3Nqt3vqtDrobEYqqWRIghuEW6Eocv0EcL6Ku SjMj49of8koYEaof+5GueJGq8bo0NMIYWnEZ1YEg+Yqv/zqv+5o0rHqwUZKwmDEXfuKvByEg8Oo0 DDuwCsuuZ5EmEIuu90qvFGuxHFuxCYsl7KquwQGwJGuvBlOxBXux4tqy8iqy9jqyMsOyEcprrje7 Izl7rjbbr2qiKzYbsharsh4bsyArsT8LtJwRtP1ar6z6sC4LoTRbs/DKtFX7oOfKsyC7I1M7NBhr sptBrjgLoUV7ryaLGS/SGy8Lrmzbtm77tnAbt3I7t3Rbt3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7qLlAEBADs= ------=_NextPart_000_0009_01C769B6.EA473CD0-- From sip-bounces@ietf.org Sun Mar 18 19:54:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT59k-00078F-In; Sun, 18 Mar 2007 19:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT59j-000765-3m for sip@ietf.org; Sun, 18 Mar 2007 19:51:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT59h-0000tn-PB for sip@ietf.org; Sun, 18 Mar 2007 19:51:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Mar 2007 19:51:18 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2INpHf1029777; Sun, 18 Mar 2007 19:51:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2INpHlG028891; Sun, 18 Mar 2007 23:51:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:51:17 -0400 Received: from [130.129.19.212] ([10.86.242.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:51:16 -0400 Message-ID: <45FDD073.6020904@cisco.com> Date: Sun, 18 Mar 2007 19:51:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] SIP v3.0? References: <200703181635.l2IGZq27021552@dragon.ariadne.com> In-Reply-To: <200703181635.l2IGZq27021552@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2007 23:51:16.0900 (UTC) FILETIME=[51B40640:01C769B8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1928; t=1174261877; x=1175125877; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20SIP=20v3.0? |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=2pdeonxbUCmmb33xb/6vmQykwfGj6mMEqaXYRfceDqs=; b=YJJBy20/4azufgBqMWQHAd2ZrDPpUBlkWIdyMbRoyYFzCutxj9OtJO/rGFMbtX16CWBsfmig E0qckmjbm3LjhB/4bxvwLdg9NhYczRAlWapz+KFRY78ATxOmKDryX2gt; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org No timeline, no plans, and no way we are ever going to do this. Sorry folks, this ship left the dock about five years ago. SIP is widely deployed and widely implemented. Its too late to 'start over and fix all the problems'. The costs to the industry would be astromonical to scrap everything and start over, and ultimately for no improvement beyond satisfaction of the technologists on a more elegant protocol. That is hardly a business proposition. Indeed, such is the nature of any wildly successful protocol that gets broadly used on the Internet. I'm sure the HTTP, HTML, SMTP, and so on, folks wish they could do it all over too. Too bad. -Jonathan R. Dale.Worley@comcast.net wrote: > From: "Beith, Gordon" > > I was interested to find out whether a draft exists or not for SIP > version 3.0. > > I have seen a lot of discussion on the topic, but have been unable > to find a draft. > > SIP 3.0 is like fully participatory democracy, the ultimate form of > communism, and the earthly Kingdom of God -- a thorough reform of what > presently exists that will remove all of its flaws. > > Similar to those other three projects, there is no WG timeline yet for > SIP 3.0 development. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 19:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5G8-0004H8-2N; Sun, 18 Mar 2007 19:57:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5G7-0004H3-8b for sip@ietf.org; Sun, 18 Mar 2007 19:57:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5G5-0001cf-VR for sip@ietf.org; Sun, 18 Mar 2007 19:57:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2007 19:57:53 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2INvrbJ030752; Sun, 18 Mar 2007 19:57:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2INvhlK029549; Sun, 18 Mar 2007 23:57:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:57:46 -0400 Received: from [130.129.19.212] ([10.86.242.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:57:45 -0400 Message-ID: <45FDD1F8.8010508@cisco.com> Date: Sun, 18 Mar 2007 19:57:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] ambiguity regarding lifetime of temp-GRUU References: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> <45FAA515.8070404@cisco.com> <006401c767e9$7be589f0$0601a8c0@BEMBUSTER> In-Reply-To: <006401c767e9$7be589f0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2007 23:57:45.0589 (UTC) FILETIME=[39614250:01C769B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1810; t=1174262273; x=1175126273; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20ambiguity=20regarding=20lifetime=20of=20temp- GRUU |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=5eumn5Bo/uzTdTu5FpeiIZJdANgcDaS+vFnKFbJL20I=; b=isJcHTA2pkjh9deJ9JyDE94w+IGOrVEKW2uulWP69DCTjM0EhX0ARImES0fywJzNE+3ag9E3 631+JfLmczbUrlw8HJMQMq9N2Ef2MhXZFcbsRy2QavsuRGMwrav7Eo4n; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: > Paul, > > Paul Kyzivat wrote: > >> Jeroen van Bemmel wrote: >> >>> In gruu-12 section 4.2 it is stated: "The temporary GRUU will be >>> valid for the duration of the registration" >>> >>> There may be ambiguity in interpretation, as a registration refresh >>> can be considered to extend the duration of the registration. >>> >>> Propose to change the text to reflect that a temporary GRUU will be >>> valid for the expiration time provided in the REGISTER 200-OK >>> response (either as an 'expires' parameter on the same Contact >>> header, or an Expires header) >> >> >> The intent is that the temp gruu will remain valid for as long as the >> registration continues to be refreshed. I don't think that is what you >> are implying in your proposal above. >> > > And this is precisely the ambiguity I was pointing out: the algorithm in > the annex includes the absolute expiration time of the temporary GRUU in > string S, so it is easy to jump to a wrong conclusion. Well, the text there states pretty clearly that the those times are there just to generate additional unique temp-gruu on each register refresh. So, I don't think its really ambiguous at all. Suggest to add > some text about the intent that temporary GRUUs remain valid across > refreshes in section 4.2 Fine. Added (that is, through refreshes) to this paragraph. This can go in with any other LC comments. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 19:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HH-0004uZ-NF; Sun, 18 Mar 2007 19:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HF-0004uU-LW for sip@ietf.org; Sun, 18 Mar 2007 19:59:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5HE-0001mf-Cd for sip@ietf.org; Sun, 18 Mar 2007 19:59:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2007 19:59:04 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2INx4MM030975; Sun, 18 Mar 2007 19:59:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2INwxlG029716; Sun, 18 Mar 2007 23:58:59 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:58:59 -0400 Received: from [130.129.19.212] ([10.86.242.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 19:58:58 -0400 Message-ID: <45FDD242.3010007@cisco.com> Date: Sun, 18 Mar 2007 19:58:58 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] ambiguity regarding lifetime of temp-GRUU References: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> In-Reply-To: <001f01c767b3$020557e0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2007 23:58:58.0932 (UTC) FILETIME=[65188340:01C769B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1252; t=1174262344; x=1175126344; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20ambiguity=20regarding=20lifetime=20of=20temp- GRUU |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=KpWUvxVxNZFbbtGcnTnJOwXs8r1MQIGOhhm3+CGGc1c=; b=UotLNuk6IP2J0DUvG7Y5QVwOJ1r3QNnlqnYdH18dqDjLfvtg/GtzIwrV0CqaLe34gZnt6tiE iN2ZZ+FZ1t+0NuRi/4qLssZ/Mcwz6a8HyQ2FeWtQ2TWHzEaNiFOb4tAV; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: > In gruu-12 section 4.2 it is stated: "The temporary GRUU will be valid > for the duration of the registration" > > There may be ambiguity in interpretation, as a registration refresh can > be considered to extend the duration of the registration. > > Propose to change the text to reflect that a temporary GRUU will be > valid for the expiration time provided in the REGISTER 200-OK response > (either as an 'expires' parameter on the same Contact header, or an > Expires header) > > Consequently, a UA cannot construct a temporary GRUU by itself, there > are no "self-made temporary GRUUs". This should be made explicit in > section 4.3 Sure it can. In fact, its easier to do this for self-made GRUU. You just create a gruu and then decide when to invalidate it. When its invalid you reject incoming requests to that gruu with a 404. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 20:19:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5am-0006UD-V0; Sun, 18 Mar 2007 20:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5al-0006U3-5J for sip@ietf.org; Sun, 18 Mar 2007 20:19:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5aj-0004Kj-Kn for sip@ietf.org; Sun, 18 Mar 2007 20:19:15 -0400 Received: from [10.0.0.143] (dhcp-4009.ietf68.org [130.129.64.9]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2INPKsU022703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Mar 2007 17:25:22 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FA07756@zrc2hxm0.corp.nortel.com> References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF0FA07756@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93D6B629-4FD3-45C6-95F8-F92999223BA0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Sun, 18 Mar 2007 19:19:08 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: SIP IETF Subject: [Sip] Re: notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Then to say this, I think we're going to need to make sips a standards-track document. -- Dean On Mar 18, 2007, at 6:54 AM, Francois Audet wrote: > No, I can't. > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Saturday, March 17, 2007 17:41 >> To: Audet, Francois (SC100:3055) >> Cc: SIP IETF >> Subject: Re: notes on draft-ietf-sip-sips-02 >> >> >> can you find text in any std doc that supports the MUST >> relative to GRUU? >> >> -- >> Dean >> >> On Mar 16, 2007, at 12:44 PM, Francois Audet wrote: >> >>> Ok, I have done all these changes (plus a whole bunch of editorial >>> ones). I am keeping a "draft" draft-ietf-sip-sips-03 at the >> following >>> location: >>> https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip- >>> sips-03 >>> .txt >>> >>> On the GRUU comment however: Jonathan has expressed his >> preference for >>> having the SIPS-related discussion be included in the sips draft as >>> opposed to the GRUU draft. That's why it's here. >>> >>>> -----Original Message----- >>>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>>> Sent: Friday, March 16, 2007 07:45 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: SIP IETF >>>> Subject: notes on draft-ietf-sip-sips-02 >>>> >>>> I did a full read through, not counting the examples that >> I never get >>>> right anyhow. >>>> >>>> >>>> general note: Keith tells me the standard is to write '200 >>>> (OK) response' instead of '200 "Ok" response'. >>>> >>>> Specific points of consideration: >>>> >>>> abstract: >>>>> "This document providing clarifications" >>>> >>>> The above doesn't parse. Maybe "This document clarifies" >> or "attempts >>>> to clarify", depending on what you believe about declaring victory. >>>> >>>> >>>> >>>> Section 3 paragraph 3 says: >>>> >>>>> "Contrary to what many believe erroneously, the last-hop >>>> exception was >>>>> not created to allow for using a SIPS URI to address a UAS >>>> that does >>>>> not support TLS : the last-hop exception was an attempt to >>>> allow for >>>>> incoming requests TLS when a SIPS URI is used, and it does >>>> not apply >>>>> to outgoing requests. >>>> >>>> Given that the last-hop-exception was to a great extent my >> fault, I >>>> have to say that the specific use case I argued for was so that I >>>> could advertise a SIPS: URI that would be terminated on a record- >>>> routing proxy at my desk and translate to a SIP: URI that >> would end >>>> up on an experimental 3Com SIP phone that did not support SIPS:. I >>>> might have been wrong, but that's what I wanted to do. And >> given the >>>> fundamental design flaw of SIPS: (you can't tell when somebody's >>>> cheating), it works just fine if the proxy is smart enough to >>>> "upgrade" outbound requests. >>>> >>>> Next paragraph says: >>>> >>>>> It is therefore RECOMMENDED that implementations do not use >>>> the last >>>>> hop exception rule and use TLS all the way up to the >> remote target." >>>> >>>> Since we've already said that outbound provides a superior >> solution, >>>> why don't we just say something like "Note: >>>> outbound [xxxx] provides a solution that works better than >> the last >>>> hop exception. Use it when possible." >>>> >>>> >>>> Next para includes: >>>> >>>>> "The SIPS scheme implies transitive trust. Obviously, there is >>>>> nothing that prevents a proxy to cheat" >>>> >>>> Classic SIP error. We have our To: and From: reversed. >>>> Perhaps "from cheating" instead of "to cheat". >>>> >>>> >>>> First para of section 3.1. Scope of SIPS says: >>>> >>>>> "SIPS means that the SIP resource designated by the target >>>> SIPS URI be >>>>> contacted securily, using TLS, on each SIP hop (last-hop >> exception >>>>> nothwistanding)." >>>> >>>> >>>> This doesn't quite pass my in-head English parser. Perhaps: >>>> >>>> SIPS means that the SIP resource designated by the target >> SIPS URI is >>>> to be contacted securely, using TLS on each hop between >> the UAC and >>>> the proxy responsible for the request URI, and using TLS >> between the >>>> proxy responsible for the request URI and the UAS if possible. >>>> >>>> >>>> Just before Section 4, we have ' >>>> >>>>> "Some proxies may have local policies that enforces TLS on all" >>>> >>>> There's a pluralization mismatch in there. Perhaps "local >> policy that >>>> enforces" or "local policies that enforce". >>>> >>>> >>>> The last para in "Section 4: Routing" before 4.1 says" >>>> >>>> " o Reject the call with a 403 "Forbidden"." >>>> >>>> I'm not sure I believe that. It seems much more like a 404 case. >>>> Since there's no sips: URI available, the contact was not >> found. If >>>> we use 403, then we need to give a reason phrase that >> might help the >>>> caller figure out what went wrong. >>>> >>>> Section 5 Registration, Para 2 says: >>>> >>>>> "The USC registers either a SIPS or a SIP AOR" >>>> >>>> We probably mean UAC instead of USC in the preceding. On the other >>>> hand, you can never tell about those guys at the University of >>>> Southern California. Maybe they speak SIP now. >>>> >>>> The following 3rd paragraph says: >>>> >>>>> "Those are mechanical rules with no influence on routing." >>>> >>>> The "Those" should perhaps be "These". >>>> >>>> The 6th or so paragraph of section 5 says: >>>> >>>>> "A registrar MUST only accept a binding to a SIPS Contact >>>> if all the >>>>> appropriate URIs are of the SIPS scheme: i.e., the >> Request-URI, the >>>>> AOR (i.e., To header), the From header, the Contacts and >>>> all the Path >>>>> headers. If the URIs are not of the proper SIPS scheme, it must >>>>> reject the REGISTER with a 403 "Forbidden"." >>>> >>>> >>>> The MUST here needs some backing. Where does the authority for it >>>> come from? The same caveat applies to the last statement >> of Section >>>> 5: >>>> >>>>> "However, a registrar MUST record the scheme of the Contact." >>>> >>>> Why? Is that in an RFC somewhere explicitly or implicitly? >>>> What happens if it doesn't? >>>> >>>> >>>> A similar question applies to the first para in "Section >> 6; SIPS in a >>>> Dialog": >>>> >>>>> "There MUST be only one Contact in any request resulting in the >>>>> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." >>>> >>>> >>>> Section 6 Para 3 says: >>>> >>>>> "If a UAS (or proxy acting on behalf of a UAS) does not support >>>>> SIPS, it MUST reject a request to a SIPS Request-URI with >> response >>>>> code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC >>>>> SHOULD NOT re-attempt the request by automatically replacing the >>>>> SIPS scheme with a SIP scheme. If the UAC does re-attempt >>>> the call >>>>> with a SIP URI, it SHOULD inform to the user that the >> security level >>>>> is downgraded." >>>> >>>> The first MUST of the above is, I believe, a restatement >> of some part >>>> of 3261, which could be called out as the source of authority. The >>>> rationale for the SHOULD might need support. I seem to recall >>>> discussing this or something like it on-list. >>>> >>>> Section 7, first para, says: >>>> >>>>> "Sessions, dialogs and transactions may be "derived" from >>>> existings >>>>> ones." >>>> >>>> The "existings" might be better as "existing". >>>> >>>> >>>> The "Must be rejected" in para 3 of section 7 requires >> some support. >>>> >>>> >>>> Keith would suggest indenting the Note: paragraph (4) of section 8. >>>> >>>> >>>> The following discussion of RFC326`/16.7: >>>> >>>>> "will be in the path of subsequent supports this transport" >>>> >>>> is probably missing the word "requests" between "subsequent" and >>>> "support". >>>> >>>> Section 9, discussion of GRUU, p 2 says: >>>> >>>>> "If the wrong scheme is received in the GRUU (which would be an >>>>> error in the registrar), the UAC MUST treat it as if the proper >>>>> scheme was used (i.e., it MUST replace the scheme with the proper >>>>> scheme before using the GRUU)." >>>> >>>> I'm not currently sure this is supportable in this >> document. I don't >>>> suppose we could move this text into GRUU? Jonathan? >>>> >>>> In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: >>>> >>>>> "... how SIPS may be used. "server-side authentication" >> (where the >>>>> server" >>>> >>>> The following "it's" should probably be the possessive, "its". >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 20:28:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5jC-0004Ep-VJ; Sun, 18 Mar 2007 20:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5jA-0004Ef-U0 for sip@ietf.org; Sun, 18 Mar 2007 20:27:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5j9-00059r-K7 for sip@ietf.org; Sun, 18 Mar 2007 20:27:56 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Mar 2007 20:27:57 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J0Rtha030680; Sun, 18 Mar 2007 20:27:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2J0RtlG003622; Mon, 19 Mar 2007 00:27:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 20:27:54 -0400 Received: from [130.129.19.212] ([10.86.242.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 20:27:54 -0400 Message-ID: <45FDD909.6030906@cisco.com> Date: Sun, 18 Mar 2007 20:27:53 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> In-Reply-To: <20070311173655.DF5EE1CC24@delta.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 00:27:54.0431 (UTC) FILETIME=[6F88A4F0:01C769BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3022; t=1174264075; x=1175128075; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20 |To:=20EKR=20; bh=egYMAnHqxzncIpgrvjFe0n04S5UJP+0AVQ3ThRdz6NI=; b=luZcjc0Y4zAPZMwxmCPplhyEVItK7UxiXnlhiR2vShjFc+k/iBKebHQneEFIXYCOE0XkGEjZ GX6pYQAcHBjyqut5ohBQnAl+qPHJZKTU/OAWiIo+XrhQh0qGuJsk1+n4; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ekr, All of your editorial comments look fine and I will incorporate. Below are responses to the technical comments: EKR wrote: > $Id: draft-ietf-sip-gruu-12-rev.txt,v 1.2 2007/03/11 17:48:42 ekr Exp $ > > TECHNICAL > > > S 3.2. > A UA which wants to obtain a GRUU via its REGISTER request does so by > providing an instance ID in the "+sip.instance" parameter in the > Contact header field [12]. For example: > > > Contact: > ;+sip.instance="" > > This doesn't seem right. "+sip.instance" at best means > "I want to do outbound". More likely it means "here is my instance ID". > It's "Supported: gruu" that says "I want a GRUU". No, its instance. It used to work the way you described, in fact. However, we ran into an issue that a UA might register with an instance ID but not support GRUU, and then something is subscribed to reg-event and wants to learn its gruu. So you don't return the gruu to the UA, but you still need to generate the GRUU to deliver in reg-event. Supported: gruu just means "I support the GRUU spec", and that is NOT a necessary condition for the registrar to generate GRUU. > > > S 4.1. > identifies the UA instance being registered. Each such Contact > header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header > > This should probably be a MUST My rule for SHOULD vs. MUST in things like this is, "would interoperability break if you don't do this". In this case, it won't, since the server MUST ignore pub-gruu or temp-gruu that are there. > > > S 9. > There is no need for the UA to remove the stale registered contact; > the request targeting rules in [12] will cause the request to be > delivered to the most recent one. > > Wait, doesn't this mean that you just accumulate this data indefinitely, > if, for instance, the IP addresses change a lot? Not indefinitely. It'll timeout in an hour or so. > Given the actual > operation of the request targeting rules, can't you just remove the > stale ones? Maybe the way to say this is that you MAY remove > them but you don't have to? Actually removing them is bad due to avalanche restart. Thats why this bit about not needing to remove them is there. > > > S A.2 > > S = (AOR || " " || instance_ID || Call-ID || W || T1 || T2 || .. || Tn) > > Aren't separators needed here to allow this to be unambiguously parsed? Yes, added. > > within the state string S, and consequently, these fields can be set > to zero. > > s/can be/MAY be/ fixed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 18 20:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5jy-0005J1-WB; Sun, 18 Mar 2007 20:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5jx-0005Dg-OE for sip@ietf.org; Sun, 18 Mar 2007 20:28:45 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5jw-0005H4-Bo for sip@ietf.org; Sun, 18 Mar 2007 20:28:45 -0400 Received: from [10.0.0.143] (dhcp-4009.ietf68.org [130.129.64.9]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2INYhIO022750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Mar 2007 17:34:44 -0600 In-Reply-To: <45FDD073.6020904@cisco.com> References: <200703181635.l2IGZq27021552@dragon.ariadne.com> <45FDD073.6020904@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72C3A0D1-ADC6-4261-81C2-9DC5DD3A203F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP v3.0? Date: Sun, 18 Mar 2007 19:28:31 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Personally, I disagree. SIP needs a spring cleaning. It's getting dusty in the back rooms, and I'm pretty sure I saw a mouse running through one of the drafty attics earlier today. The good news is that one can do spring cleaning without tearing the house down. We're not talking about scrapping everything and starting over (or if we were, we wouldn't be talking SIP). We're talking more of a controlled multiyear revision process that happens more-or-less in-place, like the migration from HTTP 1.0 to HTTP 1.1. In the process, I propose that there are some parts of the house that we may not want to do spring-cleaning on. We'd perhaps be better served by masking them off with yellow police-tape and a sign that says "Danger! Enter at your own risk". -- Dean On Mar 18, 2007, at 6:51 PM, Jonathan Rosenberg wrote: > No timeline, no plans, and no way we are ever going to do this. > Sorry folks, this ship left the dock about five years ago. SIP is > widely deployed and widely implemented. Its too late to 'start over > and fix all the problems'. The costs to the industry would be > astromonical to scrap everything and start over, and ultimately for > no improvement beyond satisfaction of the technologists on a more > elegant protocol. That is hardly a business proposition. > > Indeed, such is the nature of any wildly successful protocol that > gets broadly used on the Internet. I'm sure the HTTP, HTML, SMTP, > and so on, folks wish they could do it all over too. Too bad. > > -Jonathan R. > > Dale.Worley@comcast.net wrote: > >> From: "Beith, Gordon" >> I was interested to find out whether a draft exists or not for SIP >> version 3.0. >> I have seen a lot of discussion on the topic, but have been unable >> to find a draft. >> SIP 3.0 is like fully participatory democracy, the ultimate form of >> communism, and the earthly Kingdom of God -- a thorough reform of >> what >> presently exists that will remove all of its flaws. >> Similar to those other three projects, there is no WG timeline yet >> for >> SIP 3.0 development. >> Dale >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 02:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTB5u-0000d2-MW; Mon, 19 Mar 2007 02:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTB5t-0000ct-BK for sip@ietf.org; Mon, 19 Mar 2007 02:11:45 -0400 Received: from web15807.mail.cnb.yahoo.com ([202.165.102.87]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTB5n-00032i-OW for sip@ietf.org; Mon, 19 Mar 2007 02:11:45 -0400 Received: (qmail 23493 invoked by uid 60001); 19 Mar 2007 06:11:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6bnQ9MEJ7tE/zeeD4khXMKpFiOWP7ZPKD8Rk7G0P5ubiQSy7i/BXwBb8+e78ZEPIMW1wk4eQJzUAFdBbbQr4WYsB8neBR/HWYMwUQIwuKpq1CNUjG97iEyZMe8bUjZnXOxS0AWVF8EMdgeqvX66lkdQIcI1IthSo+zO+LRYoByI=; X-YMail-OSG: jTVqKfkVM1kfQWNW.gPKbvxjt_dhhRgY1rQ2F1amR7F3hu50ltWWBpMRBP4Cs5LzXC_olu.VSR85qehrw9YhWnom8XzcyKcZ61C6ZZHGPzQ7.RRuH4Df9ZBPuT5QtItkTJMVdf5SeajuPio- Received: from [61.52.17.205] by web15807.mail.cnb.yahoo.com via HTTP; Mon, 19 Mar 2007 14:11:29 CST Date: Mon, 19 Mar 2007 14:11:29 +0800 (CST) From: Carol Chang To: sip@ietf.org In-Reply-To: MIME-Version: 1.0 Message-ID: <998662.22125.qm@web15807.mail.cnb.yahoo.com> X-Spam-Score: 2.0 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] YUXIN news about new model launched X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530872903==" Errors-To: sip-bounces@ietf.org --===============1530872903== Content-Type: multipart/alternative; boundary="0-1140268992-1174284689=:22125" Content-Transfer-Encoding: 8bit --0-1140268992-1174284689=:22125 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit YUXIN NEW MODEL YWH201,YWH202 PHONES LAUNCHED Through development and experiment for about one year,Zhengzhou Yuneng Communication Co.,Ltd launched a new model YWH202 IP phone,which base on Infineon chip and support SIP,IAX2,H323 protocols,build-in-Router,3-way conference calls,voice message,recording,two SIP servers running at the same time.The highly voice effect ,the friendly menu operation, the easy setting page,and the low fees which can make you enjoy high tech product and save phone expense without too much specialized knowledge. At the same time, YWH201 IP Phone based on AR1688 chip and supporting SIP,IAX2 protocol has seized hold of the market by sale of several ten thousands units since it had been released on Oct.2006.This model of phone was developed together by outstanding workers from Aredfox and Zhengzhou Yuneng ,the former is famous in suppling solution in international VOIP field,and the latter has six years excellent performance in sale of internet phones.The type of YWH201 not only inherits merites of the phones based on PA1688,but also has many new functions(side sound,voice message and so on). As a researcher and producer in domestic VOIP terminal device,Zhengzhou Yueng communication Co.,Ltd has complete production lines and quality control systems,import and export license,CE and FCC certificate, and also devotes to new technical development and application.It watches colsely the development of VOIP market and the demand of customers ,meanwhile release new products and new functions to make customers satisfied.At present we have YWH100,YWH10,YWH200,YWH300,YWH500(POE)series products based on PA1688 chip,and our YWH200C,YWH300C,YWH600A,YWH600B(True FXO port) support 3-way conference calls,build-in-Router,registering on 3 SIP servers at the same time(switching freely).In future we will release more and more phones which based on AR1688 and Infineon chips.Regarding to gateways,we have had YGW20 based onPA1688,and YGW30A,YGW30B(true FXO port) based on CM5000 chip. These products has been validated and accepted by market.We cooperate with many companies engaged in virtural net and soft switch and other related companies to carry on encryption to solve problems of forcing out from some companies. the USB phones(YUS10 and YUS20) and the USB conference box(YHY10) supporting SKYPE and based on C-Media were well appraised by customers and got good sales achievementes as soon as those products were released. YUXIN products obtains customers approval by its stable performance,fine appearance, multi-languages and multi-colors cabinet,various models and performances.Our products can satisfy customers of different levels as a domestic manufactory with most brands and models. Speed service, honsty spirit, good idea enable YUXIN products are well known in the network telephone and gateway market and spread in more than 100 countries and districts worldwide. At present the ATA YGW50(1FXS0),YGW60(2FXS) which based on Infineon chip has passed testing already and will be put into market soonly. We will try our best to provide high quality products and multi-position services for VOIP friends,and make YUXIN first-class brand in the domestic VOIP terminal device! ------------------------------------------- ZHENNGZHOU YUNENG COMMUNICATION CO.,LTD 1KANGLELI,ZHONGYUAN DISTRICT,ZHENGZHOU,PRC URL:HTTP://WWW.YNTX.COM TEL:86-371-67657240 FAX:86-371-67657239 MSN:Carol_chang8009@hotmail.com --------------------------------- עŻ-3.5G20M --0-1140268992-1174284689=:22125 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
 
 YUXIN NEW MODEL YWH201,YWH202 PHONES LAUNCHED
      Through development and experiment for about one year,Zhengzhou Yuneng Communication Co.,Ltd launched a new model YWH202 IP phone,which base on Infineon chip and support SIP,IAX2,H323 protocols,build-in-Router,3-way conference calls,voice message,recording,two SIP servers running at the same time.The highly voice effect ,the friendly menu operation, the easy setting page,and the low fees which can make you enjoy high tech product and save phone expense without too much specialized knowledge.
At the same time, YWH201 IP Phone based on AR1688 chip and supporting SIP,IAX2 protocol has seized hold of the market by sale of several ten thousands units since it had been released on Oct.2006.This model of phone was developed together by outstanding workers from Aredfox and Zhengzhou Yuneng ,the former is famous in suppling solution in international VOIP field,and the latter has six years excellent performance in sale of internet phones.The type of YWH201 not only inherits merites of the phones based on PA1688,but also has many new functions(side sound,voice message and so on).
As a researcher and producer in domestic VOIP terminal device,Zhengzhou Yueng communication Co.,Ltd has complete production lines and quality control systems,import and export license,CE and FCC certificate, and also devotes to new technical development and application.It watches colsely the development of VOIP market and the demand of customers ,meanwhile release new products and new functions to make customers satisfied.At present we have YWH100,YWH10,YWH200,YWH300,YWH500(POE)series products based on PA1688 chip,and our YWH200C,YWH300C,YWH600A,YWH600B(True FXO port) support 3-way conference calls,build-in-Router,registering on 3 SIP servers at the same time(switching freely).In future we will release more and more phones which based on AR1688 and Infineon chips.Regarding to gateways,we have had YGW20 based onPA1688,and YGW30A,YGW30B(true FXO port) based on CM5000 chip. These products has been validated and accepted by market.We  cooperate with many companies engaged in virtural net and soft switch and other related companies to carry on encryption to solve problems of forcing out from some companies.
the USB phones(YUS10 and YUS20) and the USB conference box(YHY10) supporting SKYPE and based on C-Media were well appraised by customers and got good sales achievementes as soon as those products were released.
YUXIN products obtains customers approval by its stable performance,fine appearance, multi-languages and multi-colors cabinet,various models and performances.Our products can satisfy customers of different levels as a domestic manufactory with most brands and models. Speed service, honsty spirit, good idea enable YUXIN products are well known in the network telephone and gateway market and spread in more than 100 countries and districts worldwide.
At present the ATA YGW50(1FXS0),YGW60(2FXS) which based on Infineon chip has passed testing already and will be put into market soonly.
We will try our best to provide high quality products and multi-position services for VOIP friends,and make YUXIN first-class brand in the domestic VOIP terminal device!
 
-------------------------------------------
ZHENNGZHOU YUNENG COMMUNICATION CO.,LTD
1KANGLELI,ZHONGYUAN DISTRICT,ZHENGZHOU,PRC
URL:HTTP://WWW.YNTX.COM
TEL:86-371-67657240
FAX:86-371-67657239
MSN:Carol_chang8009@hotmail.com
 
 
 
 
 
 
 

עŻ-3.5G20M --0-1140268992-1174284689=:22125-- --===============1530872903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1530872903==-- From sip-bounces@ietf.org Mon Mar 19 02:25:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTBIS-00008Y-0h; Mon, 19 Mar 2007 02:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTBIP-00008N-U0 for sip@ietf.org; Mon, 19 Mar 2007 02:24:41 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTBIK-0005cj-CH for sip@ietf.org; Mon, 19 Mar 2007 02:24:41 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 830AA210A8; Mon, 19 Mar 2007 07:24:25 +0100 (CET) X-AuditID: c1b4fb3e-b01efbb0000061ca-92-45fe2c9980a2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6912E20079; Mon, 19 Mar 2007 07:24:25 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 07:24:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comment on sip-outbound-08 Date: Mon, 19 Mar 2007 07:24:12 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702B78850@esealmw113.eemea.ericsson.se> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B4F5D9A@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comment on sip-outbound-08 Thread-Index: Acdpq5bvVEoV3CKnSqCJ8+GrAju5gAAQwcJA From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Cullen Jennings" , "Rohan Mahy" , X-OriginalArrivalTime: 19 Mar 2007 06:24:24.0859 (UTC) FILETIME=[3D38EEB0:01C769EF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >The purpose of the keep-alive is so that the UA can remake=20 >the connection if it fails so that the proxy can get inbound=20 >SIP messages to the UA. Therefore if messages are being=20 >received, isn't everything OK? I don't feel strongly about=20 >this, so if people think there are genuine cases where SIP=20 >messages are being received but there is still something=20 >wrong, then leave it as it is. If the UAC doesn't receive a "pong", the edge proxy may not even support ping-pong, which means that the NAT binding will go down at some point when the UAC does NOT receive an incoming SIP request. Of course the UAC will detect it at that point, but it may be good to choose another flow (or another keep-alive mechanism) already before that. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 18 March 2007 18:13 > > To: Elwell, John; Cullen Jennings; Rohan Mahy; sip@ietf.org > > Subject: RE: [Sip] Comment on sip-outbound-08 > >=20 > >=20 > > Hi, > >=20 > > >"If the server does not receive a "pong" within an=20 > appropriate amount=20 > > >of time, it considers the flow failed." > > >=20 > > >First, it is the client that receives the pong. Second, if=20 > the client=20 > > >receives a regular SIP message, the connection must still=20 > be alive.=20 > > >Can we change this to say the following? > > >"If the client does not receive a "pong" or SIP message=20 > > > ^^^^^^ ^^^^^^^^^^^^^^^ > > >within an appropriate amount of time, it considers the=20 > flow failed." > >=20 > > Wouldn't it be better to say, that if the UAC receives a=20 > SIP message,=20 > > it can "reset" the "ping" timer? > >=20 > > Because, if it doesn't receive a "pong", something is obviously not=20 > > working correct at the edge proxy - even if the NAT binding=20 > is still=20 > > working... > >=20 > > Regards, > >=20 > > Christer > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 03:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTBwh-0005kx-Ck; Mon, 19 Mar 2007 03:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTBwg-0005ks-9w for sip@ietf.org; Mon, 19 Mar 2007 03:06:18 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTBwe-00057r-Ox for sip@ietf.org; Mon, 19 Mar 2007 03:06:18 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2J75AGA018257; Mon, 19 Mar 2007 09:05:18 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 09:05:10 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 09:05:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Outbound-08: usage of keep-xxx parameter Date: Mon, 19 Mar 2007 09:05:08 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0379512D@esebe103.NOE.Nokia.com> In-Reply-To: <7374777208BDC7449D5620EF9423256702B41261@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Outbound-08: usage of keep-xxx parameter Thread-Index: AcdnRYIgRy+uYzIRSIOj7NpsfrCxAgAkjuQAAIZsANA= References: <7374777208BDC7449D5620EF9423256702B41261@esealmw113.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 19 Mar 2007 07:05:09.0840 (UTC) FILETIME=[EE8B6D00:01C769F4] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070319090518-45B82BB0-7D1C51E2/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >>This is so that the administrative domain that runs the=20 >>server can pick what type of keep alive it wants to use (even=20 >>though they are all supported). I think this is all too much=20 >>complexity but it seemed that some people wanted this so=20 >>that's what we wrote up. I also think all that is too much complexity and can not even see the value of it. Remember that Outbound has only one single keepalive method (STUN) for UDP and two methods (CRLF and TCP keepalive) for TCP. The reason for introducing the 'keepalive-stun' flag was that multiplexing STUN to the SIP port was considered as backwards incompatible change, so there was an extra reason for=20 the UA to check that the proxy supports it. However sending=20 double-CRLF or TCP keepalives is backwards compatible to SIP servers compliant to RFC 3261, so no such reason exists here. >I don't remember any recent discussion regarding this, but I may of >course have missed it. If you refer to the discussion related to STUN, the reasons for the related flag are not as such applicable to the keepalive methods currently proposed for TCP. For CRLF keepalives no such discussion has been on the list (before this one). >But, if we can have multiple keep-alive mechanisms for a single >transport protocol I guess it's ok to have that possibility. BUT, >I still think that it should also be possible to only include=20 >the 'ob' URI parameter, and let the UA choose whatever outbound=20 >keep-alive mechanism he wants, and that we should describe that. I agree with Christer that it should go this way: It should be possible for the UA to find out (in some way or=20 another) that the configured or discovered outbound proxy=20 supports SIP Outbound. UA should be able to find out the transports supported by the proxy by DNS, unless the URI has an explicit transport parameter. Finally the proxy has to support all keepalive methods defined in SIP Outbound for the transports it supports. As simple as that. Defined like that, if the proxy would only support UDP, the UA can only use STUN for keepalive. And if the proxy would support TCP, the UA could use either CRLF or TCP keepalive. For TCP case the choice would be done by the UA, exactly=20 as the case was before replacing STUN with CRLF as one keepalive method for TCP. Regards, Erkki >> On Mar 14, 2007, at 2:25 PM, Christer Holmberg ((JO/LMF)) wrote: >>=20 >> > >> > Hi, >> > >> > If all outbound compliant edge proxies MUST implement all=20 >> keep- alive=20 >> > mechanisms, why do we need to list the different keep-alive=20 >> mechanisms=20 >> > (keep-stun, keep-crlf etc) in the outbound-proxy-set URIs?=20 >Isn't it=20 >> > enough to simply include the 'ob' URI parameter? >> > >> > If all oubound compliant edge proxies MUST implement all=20 >keep-alive=20 >> > mechanisms, do we need to keep-xxx parameters in the first place? >> > >> > Regards, >> > >> > Christer >> > >>=20 >>=20 > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 03:34:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCKv-0004p3-7I; Mon, 19 Mar 2007 03:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCKq-0004om-W8 for sip@ietf.org; Mon, 19 Mar 2007 03:31:16 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTCKp-0000Fl-H0 for sip@ietf.org; Mon, 19 Mar 2007 03:31:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2J7UKc1007292; Mon, 19 Mar 2007 09:30:22 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 09:30:20 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 09:30:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comment on sip-outbound-08 Date: Mon, 19 Mar 2007 09:30:19 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0379518D@esebe103.NOE.Nokia.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B4F5D55@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comment on sip-outbound-08 Thread-Index: AcdosDk1eL05WgCmSfebsT91vDnKMABR6Syw References: <50B1CBA96870A34799A506B2313F26670B4F5D55@ntht201e.siemenscomms.co.uk> From: To: , , , X-OriginalArrivalTime: 19 Mar 2007 07:30:20.0562 (UTC) FILETIME=[73014F20:01C769F8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070319093023-19B8DBB0-12CD8E16/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >"If a pong is not received > within 10 seconds (TODO - is 10 seconds the right amount of time) > then the client MUST treat the flow as failed." >Change to >"If a pong or SIP message is not received > ^^^^^^^^^^^^^^^ > within 10 seconds (TODO - is 10 seconds the right amount of time) > then the client MUST treat the flow as failed." Could someone please tell me how the UA is able to achieve the same when using TCP keepalive ? Currently the draft does not discuss any timing behaviour for TCP keepalive. If this kind behaviour will be introduced for CRLF keepalive, I believe the UA using TCP keepalive should also have some explicit limits for its timing behaviour how long does it wait for TCP ACK before deeming the flow failed. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 04:01:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCnb-0003VG-MX; Mon, 19 Mar 2007 04:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCna-0003TX-3z for sip@ietf.org; Mon, 19 Mar 2007 04:00:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTCnT-0004ur-E8 for sip@ietf.org; Mon, 19 Mar 2007 04:00:58 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E25CB207C3; Mon, 19 Mar 2007 09:00:48 +0100 (CET) X-AuditID: c1b4fb3c-a84eabb0000073d5-b2-45fe43308ec3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CE53420724; Mon, 19 Mar 2007 09:00:48 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 09:00:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Outbound-08: usage of keep-xxx parameter Date: Mon, 19 Mar 2007 09:00:42 +0100 Message-ID: <7374777208BDC7449D5620EF9423256702B78BBD@esealmw113.eemea.ericsson.se> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0379512D@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Outbound-08: usage of keep-xxx parameter Thread-Index: AcdnRYIgRy+uYzIRSIOj7NpsfrCxAgAkjuQAAIZsANAAApz0IA== From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 19 Mar 2007 08:00:48.0158 (UTC) FILETIME=[B45653E0:01C769FC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>This is so that the administrative domain that runs the server can=20 >>>pick what type of keep alive it wants to use (even though=20 >>>they are all supported). I think this is all too much complexity but it=20 >>>seemed that some people wanted this so that's what we wrote up. >=20 >I also think all that is too much complexity and can not even=20 >see the value of it. Remember that Outbound has only one=20 >single keepalive method (STUN) for UDP and two methods (CRLF and TCP >keepalive) for TCP. The reason for introducing the 'keepalive-stun' >flag was that multiplexing STUN to the SIP port was=20 >considered as backwards incompatible change, so there was an=20 >extra reason for the UA to check that the proxy supports it.=20 >However sending double-CRLF or TCP keepalives is backwards=20 >compatible to SIP servers compliant to RFC 3261, so no such=20 >reason exists here. >=20 >>I don't remember any recent discussion regarding this, but I may of=20 >>course have missed it. >=20 >If you refer to the discussion related to STUN, the reasons=20 >for the related flag are not as such applicable to the=20 >keepalive methods currently proposed for TCP. For CRLF=20 >keepalives no such discussion has been on the list (before this one). I am refering to the decission to define mutliple keep-xxx parameters. >>But, if we can have multiple keep-alive mechanisms for a single=20 >>transport protocol I guess it's ok to have that possibility. BUT, I=20 >>still think that it should also be possible to only include the 'ob'=20 >>URI parameter, and let the UA choose whatever outbound keep-alive=20 >>mechanism he wants, and that we should describe that. >=20 >I agree with Christer that it should go this way: >=20 >It should be possible for the UA to find out (in some way or >another) that the configured or discovered outbound proxy=20 >supports SIP Outbound. UA should be able to find out the=20 >transports supported by the proxy by DNS, unless the URI has=20 >an explicit transport parameter. Yes, and therefor I think it shall be described that the edge proxy can insert the 'ob' and 'keep-xxx' parameters in the Path header. Currently I beleive only inserting of 'ob' is described for the edge proxy, in order for the home proxy to figure out that the edge proxy supports outbound. I think we also need to say that the UA can use that information. >Finally the proxy has to support all keepalive methods defined in SIP Outbound for the=20 >transports it supports. As simple as that. I agree, and that was the reason why I asked why we need to keep-xxx parameters. 'ob' should be enough. =20 >Defined like that, if the proxy would only support UDP, the=20 >UA can only use STUN for keepalive. And if the proxy would=20 >support TCP, the UA could use either CRLF or TCP keepalive. Yes. >For TCP case the choice would be done by the UA, exactly as=20 >the case was before replacing STUN with CRLF as one keepalive=20 >method for TCP. Yes. Regards, Christer >=20 > >> On Mar 14, 2007, at 2:25 PM, Christer Holmberg ((JO/LMF)) wrote: > >>=20 > >> > > >> > Hi, > >> > > >> > If all outbound compliant edge proxies MUST implement all > >> keep- alive > >> > mechanisms, why do we need to list the different keep-alive > >> mechanisms > >> > (keep-stun, keep-crlf etc) in the outbound-proxy-set URIs?=20 > >Isn't it > >> > enough to simply include the 'ob' URI parameter? > >> > > >> > If all oubound compliant edge proxies MUST implement all > >keep-alive > >> > mechanisms, do we need to keep-xxx parameters in the first place? > >> > > >> > Regards, > >> > > >> > Christer > >> > > >>=20 > >>=20 > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 04:09:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCv0-0000rQ-DZ; Mon, 19 Mar 2007 04:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCuz-0000pY-CI for sip@ietf.org; Mon, 19 Mar 2007 04:08:37 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTCux-0006Rp-Rs for sip@ietf.org; Mon, 19 Mar 2007 04:08:37 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2J88US02313; Mon, 19 Mar 2007 08:08:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2007 03:08:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FA8AE6F@zrc2hxm0.corp.nortel.com> In-Reply-To: <93D6B629-4FD3-45C6-95F8-F92999223BA0@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes on draft-ietf-sip-sips-02 Thread-Index: AcdpvECdYgE+Te7aTP6uiCZZExsmvgAQNORQ References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF0FA07756@zrc2hxm0.corp.nortel.com> <93D6B629-4FD3-45C6-95F8-F92999223BA0@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: SIP IETF Subject: [Sip] RE: notes on draft-ietf-sip-sips-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, that is also what I think.=20 If I 'had' to write a reason, I'd say that the reason it is a MUST is that since it means that the Registrar screwed up and returned the wrong scheme, and there really nothing the phone can do besides 'rebooting', then treating the scheme as if it was the proper scheme is the best solution. It will not cause all the phones to reboot, or re-register or whatever bad solution would be available. It causes no harm, and does not introcude instability in the system.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Sunday, March 18, 2007 17:19 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF > Subject: Re: notes on draft-ietf-sip-sips-02 >=20 >=20 > Then to say this, I think we're going to need to make sips a=20 > standards-track document. >=20 > -- > Dean >=20 > On Mar 18, 2007, at 6:54 AM, Francois Audet wrote: >=20 > > No, I can't. > > > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Saturday, March 17, 2007 17:41 > >> To: Audet, Francois (SC100:3055) > >> Cc: SIP IETF > >> Subject: Re: notes on draft-ietf-sip-sips-02 > >> > >> > >> can you find text in any std doc that supports the MUST=20 > relative to=20 > >> GRUU? > >> > >> -- > >> Dean > >> > >> On Mar 16, 2007, at 12:44 PM, Francois Audet wrote: > >> > >>> Ok, I have done all these changes (plus a whole bunch of=20 > editorial=20 > >>> ones). I am keeping a "draft" draft-ietf-sip-sips-03 at the > >> following > >>> location: > >>> https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip- > >>> sips-03 > >>> .txt > >>> > >>> On the GRUU comment however: Jonathan has expressed his > >> preference for > >>> having the SIPS-related discussion be included in the=20 > sips draft as=20 > >>> opposed to the GRUU draft. That's why it's here. > >>> > >>>> -----Original Message----- > >>>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>>> Sent: Friday, March 16, 2007 07:45 > >>>> To: Audet, Francois (SC100:3055) > >>>> Cc: SIP IETF > >>>> Subject: notes on draft-ietf-sip-sips-02 > >>>> > >>>> I did a full read through, not counting the examples that > >> I never get > >>>> right anyhow. > >>>> > >>>> > >>>> general note: Keith tells me the standard is to write '200 > >>>> (OK) response' instead of '200 "Ok" response'. > >>>> > >>>> Specific points of consideration: > >>>> > >>>> abstract: > >>>>> "This document providing clarifications" > >>>> > >>>> The above doesn't parse. Maybe "This document clarifies" > >> or "attempts > >>>> to clarify", depending on what you believe about=20 > declaring victory. > >>>> > >>>> > >>>> > >>>> Section 3 paragraph 3 says: > >>>> > >>>>> "Contrary to what many believe erroneously, the last-hop > >>>> exception was > >>>>> not created to allow for using a SIPS URI to address a UAS > >>>> that does > >>>>> not support TLS : the last-hop exception was an attempt to > >>>> allow for > >>>>> incoming requests TLS when a SIPS URI is used, and it does > >>>> not apply > >>>>> to outgoing requests. > >>>> > >>>> Given that the last-hop-exception was to a great extent my > >> fault, I > >>>> have to say that the specific use case I argued for was=20 > so that I=20 > >>>> could advertise a SIPS: URI that would be terminated on=20 > a record-=20 > >>>> routing proxy at my desk and translate to a SIP: URI that > >> would end > >>>> up on an experimental 3Com SIP phone that did not=20 > support SIPS:. I=20 > >>>> might have been wrong, but that's what I wanted to do. And > >> given the > >>>> fundamental design flaw of SIPS: (you can't tell when somebody's=20 > >>>> cheating), it works just fine if the proxy is smart enough to=20 > >>>> "upgrade" outbound requests. > >>>> > >>>> Next paragraph says: > >>>> > >>>>> It is therefore RECOMMENDED that implementations do not use > >>>> the last > >>>>> hop exception rule and use TLS all the way up to the > >> remote target." > >>>> > >>>> Since we've already said that outbound provides a superior > >> solution, > >>>> why don't we just say something like "Note: > >>>> outbound [xxxx] provides a solution that works better than > >> the last > >>>> hop exception. Use it when possible." > >>>> > >>>> > >>>> Next para includes: > >>>> > >>>>> "The SIPS scheme implies transitive trust. Obviously, there is=20 > >>>>> nothing that prevents a proxy to cheat" > >>>> > >>>> Classic SIP error. We have our To: and From: reversed. > >>>> Perhaps "from cheating" instead of "to cheat". > >>>> > >>>> > >>>> First para of section 3.1. Scope of SIPS says: > >>>> > >>>>> "SIPS means that the SIP resource designated by the target > >>>> SIPS URI be > >>>>> contacted securily, using TLS, on each SIP hop (last-hop > >> exception > >>>>> nothwistanding)." > >>>> > >>>> > >>>> This doesn't quite pass my in-head English parser. Perhaps: > >>>> > >>>> SIPS means that the SIP resource designated by the target > >> SIPS URI is > >>>> to be contacted securely, using TLS on each hop between > >> the UAC and > >>>> the proxy responsible for the request URI, and using TLS > >> between the > >>>> proxy responsible for the request URI and the UAS if possible. > >>>> > >>>> > >>>> Just before Section 4, we have ' > >>>> > >>>>> "Some proxies may have local policies that enforces TLS on all" > >>>> > >>>> There's a pluralization mismatch in there. Perhaps "local > >> policy that > >>>> enforces" or "local policies that enforce". > >>>> > >>>> > >>>> The last para in "Section 4: Routing" before 4.1 says" > >>>> > >>>> " o Reject the call with a 403 "Forbidden"." > >>>> > >>>> I'm not sure I believe that. It seems much more like a 404 case. > >>>> Since there's no sips: URI available, the contact was not > >> found. If > >>>> we use 403, then we need to give a reason phrase that > >> might help the > >>>> caller figure out what went wrong. > >>>> > >>>> Section 5 Registration, Para 2 says: > >>>> > >>>>> "The USC registers either a SIPS or a SIP AOR" > >>>> > >>>> We probably mean UAC instead of USC in the preceding. On=20 > the other=20 > >>>> hand, you can never tell about those guys at the University of=20 > >>>> Southern California. Maybe they speak SIP now. > >>>> > >>>> The following 3rd paragraph says: > >>>> > >>>>> "Those are mechanical rules with no influence on routing." > >>>> > >>>> The "Those" should perhaps be "These". > >>>> > >>>> The 6th or so paragraph of section 5 says: > >>>> > >>>>> "A registrar MUST only accept a binding to a SIPS Contact > >>>> if all the > >>>>> appropriate URIs are of the SIPS scheme: i.e., the > >> Request-URI, the > >>>>> AOR (i.e., To header), the From header, the Contacts and > >>>> all the Path > >>>>> headers. If the URIs are not of the proper SIPS=20 > scheme, it must=20 > >>>>> reject the REGISTER with a 403 "Forbidden"." > >>>> > >>>> > >>>> The MUST here needs some backing. Where does the=20 > authority for it=20 > >>>> come from? The same caveat applies to the last statement > >> of Section > >>>> 5: > >>>> > >>>>> "However, a registrar MUST record the scheme of the Contact." > >>>> > >>>> Why? Is that in an RFC somewhere explicitly or implicitly? > >>>> What happens if it doesn't? > >>>> > >>>> > >>>> A similar question applies to the first para in "Section > >> 6; SIPS in a > >>>> Dialog": > >>>> > >>>>> "There MUST be only one Contact in any request resulting in the=20 > >>>>> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." > >>>> > >>>> > >>>> Section 6 Para 3 says: > >>>> > >>>>> "If a UAS (or proxy acting on behalf of a UAS) does not support=20 > >>>>> SIPS, it MUST reject a request to a SIPS Request-URI with > >> response > >>>>> code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC=20 > >>>>> SHOULD NOT re-attempt the request by automatically=20 > replacing the=20 > >>>>> SIPS scheme with a SIP scheme. If the UAC does re-attempt > >>>> the call > >>>>> with a SIP URI, it SHOULD inform to the user that the > >> security level > >>>>> is downgraded." > >>>> > >>>> The first MUST of the above is, I believe, a restatement > >> of some part > >>>> of 3261, which could be called out as the source of=20 > authority. The=20 > >>>> rationale for the SHOULD might need support. I seem to recall=20 > >>>> discussing this or something like it on-list. > >>>> > >>>> Section 7, first para, says: > >>>> > >>>>> "Sessions, dialogs and transactions may be "derived" from > >>>> existings > >>>>> ones." > >>>> > >>>> The "existings" might be better as "existing". > >>>> > >>>> > >>>> The "Must be rejected" in para 3 of section 7 requires > >> some support. > >>>> > >>>> > >>>> Keith would suggest indenting the Note: paragraph (4) of=20 > section 8. > >>>> > >>>> > >>>> The following discussion of RFC326`/16.7: > >>>> > >>>>> "will be in the path of subsequent supports this transport" > >>>> > >>>> is probably missing the word "requests" between "subsequent" and=20 > >>>> "support". > >>>> > >>>> Section 9, discussion of GRUU, p 2 says: > >>>> > >>>>> "If the wrong scheme is received in the GRUU (which would be an=20 > >>>>> error in the registrar), the UAC MUST treat it as if the proper=20 > >>>>> scheme was used (i.e., it MUST replace the scheme with=20 > the proper=20 > >>>>> scheme before using the GRUU)." > >>>> > >>>> I'm not currently sure this is supportable in this > >> document. I don't > >>>> suppose we could move this text into GRUU? Jonathan? > >>>> > >>>> In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: > >>>> > >>>>> "... how SIPS may be used. "server-side authentication" > >> (where the > >>>>> server" > >>>> > >>>> The following "it's" should probably be the possessive, "its". > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 04:14:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTD0M-0004su-RP; Mon, 19 Mar 2007 04:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTD0L-0004sg-K0 for sip@ietf.org; Mon, 19 Mar 2007 04:14:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTD0J-0006qU-VV for sip@ietf.org; Mon, 19 Mar 2007 04:14:09 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2007 04:14:09 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J8E7SQ019183; Mon, 19 Mar 2007 04:14:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2J8E5lG004436; Mon, 19 Mar 2007 08:14:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 04:14:05 -0400 Received: from [130.129.19.212] ([10.86.242.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 04:14:04 -0400 Message-ID: <45FE464B.3080707@cisco.com> Date: Mon, 19 Mar 2007 04:14:03 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Re: notes on draft-ietf-sip-sips-02 References: <7C6BD08C-A2BC-40D3-962E-24B90CFB54E5@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FA07116@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF0FA07756@zrc2hxm0.corp.nortel.com> <93D6B629-4FD3-45C6-95F8-F92999223BA0@softarmor.com> In-Reply-To: <93D6B629-4FD3-45C6-95F8-F92999223BA0@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 08:14:04.0709 (UTC) FILETIME=[8F1E5D50:01C769FE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10299; t=1174292047; x=1175156047; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20notes=20on=20draft-ietf-sip-sips-02 |Sender:=20 |To:=20Dean=20Willis=20; bh=O2vNFcTPjTtkQirOJ++sc710HDfnEgDPPI9iDPNRTI4=; b=nd59n7R7ypfUjsZ8fsc7vdtc7JW7RQJS6Mg10WtWpgF4iRa2aP10uzkt+ZfZc0HUjRqA58zQ 0LPgJ2+r3j3qIEv7NZ0DuJFE23vw/Y3H4yFqtc+PP+gJYbV4lbH48U9e; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Cc: SIP IETF , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it should have been standards track to begin with. I don't understand why we were going for this 'informational clarification on what RFC 3261 said' when we knew what it said is wrong.... -Jonathan R. Dean Willis wrote: > > Then to say this, I think we're going to need to make sips a > standards-track document. > > -- > Dean > > On Mar 18, 2007, at 6:54 AM, Francois Audet wrote: > >> No, I can't. >> >> >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Saturday, March 17, 2007 17:41 >>> To: Audet, Francois (SC100:3055) >>> Cc: SIP IETF >>> Subject: Re: notes on draft-ietf-sip-sips-02 >>> >>> >>> can you find text in any std doc that supports the MUST >>> relative to GRUU? >>> >>> -- >>> Dean >>> >>> On Mar 16, 2007, at 12:44 PM, Francois Audet wrote: >>> >>>> Ok, I have done all these changes (plus a whole bunch of editorial >>>> ones). I am keeping a "draft" draft-ietf-sip-sips-03 at the >>> >>> following >>> >>>> location: >>>> https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip- >>>> sips-03 >>>> .txt >>>> >>>> On the GRUU comment however: Jonathan has expressed his >>> >>> preference for >>> >>>> having the SIPS-related discussion be included in the sips draft as >>>> opposed to the GRUU draft. That's why it's here. >>>> >>>>> -----Original Message----- >>>>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>>>> Sent: Friday, March 16, 2007 07:45 >>>>> To: Audet, Francois (SC100:3055) >>>>> Cc: SIP IETF >>>>> Subject: notes on draft-ietf-sip-sips-02 >>>>> >>>>> I did a full read through, not counting the examples that >>> >>> I never get >>> >>>>> right anyhow. >>>>> >>>>> >>>>> general note: Keith tells me the standard is to write '200 >>>>> (OK) response' instead of '200 "Ok" response'. >>>>> >>>>> Specific points of consideration: >>>>> >>>>> abstract: >>>>> >>>>>> "This document providing clarifications" >>>>> >>>>> >>>>> The above doesn't parse. Maybe "This document clarifies" >>> >>> or "attempts >>> >>>>> to clarify", depending on what you believe about declaring victory. >>>>> >>>>> >>>>> >>>>> Section 3 paragraph 3 says: >>>>> >>>>>> "Contrary to what many believe erroneously, the last-hop >>>>> >>>>> exception was >>>>> >>>>>> not created to allow for using a SIPS URI to address a UAS >>>>> >>>>> that does >>>>> >>>>>> not support TLS : the last-hop exception was an attempt to >>>>> >>>>> allow for >>>>> >>>>>> incoming requests TLS when a SIPS URI is used, and it does >>>>> >>>>> not apply >>>>> >>>>>> to outgoing requests. >>>>> >>>>> >>>>> Given that the last-hop-exception was to a great extent my >>> >>> fault, I >>> >>>>> have to say that the specific use case I argued for was so that I >>>>> could advertise a SIPS: URI that would be terminated on a record- >>>>> routing proxy at my desk and translate to a SIP: URI that >>> >>> would end >>> >>>>> up on an experimental 3Com SIP phone that did not support SIPS:. I >>>>> might have been wrong, but that's what I wanted to do. And >>> >>> given the >>> >>>>> fundamental design flaw of SIPS: (you can't tell when somebody's >>>>> cheating), it works just fine if the proxy is smart enough to >>>>> "upgrade" outbound requests. >>>>> >>>>> Next paragraph says: >>>>> >>>>>> It is therefore RECOMMENDED that implementations do not use >>>>> >>>>> the last >>>>> >>>>>> hop exception rule and use TLS all the way up to the >>> >>> remote target." >>> >>>>> >>>>> Since we've already said that outbound provides a superior >>> >>> solution, >>> >>>>> why don't we just say something like "Note: >>>>> outbound [xxxx] provides a solution that works better than >>> >>> the last >>> >>>>> hop exception. Use it when possible." >>>>> >>>>> >>>>> Next para includes: >>>>> >>>>>> "The SIPS scheme implies transitive trust. Obviously, there is >>>>>> nothing that prevents a proxy to cheat" >>>>> >>>>> >>>>> Classic SIP error. We have our To: and From: reversed. >>>>> Perhaps "from cheating" instead of "to cheat". >>>>> >>>>> >>>>> First para of section 3.1. Scope of SIPS says: >>>>> >>>>>> "SIPS means that the SIP resource designated by the target >>>>> >>>>> SIPS URI be >>>>> >>>>>> contacted securily, using TLS, on each SIP hop (last-hop >>> >>> exception >>> >>>>>> nothwistanding)." >>>>> >>>>> >>>>> >>>>> This doesn't quite pass my in-head English parser. Perhaps: >>>>> >>>>> SIPS means that the SIP resource designated by the target >>> >>> SIPS URI is >>> >>>>> to be contacted securely, using TLS on each hop between >>> >>> the UAC and >>> >>>>> the proxy responsible for the request URI, and using TLS >>> >>> between the >>> >>>>> proxy responsible for the request URI and the UAS if possible. >>>>> >>>>> >>>>> Just before Section 4, we have ' >>>>> >>>>>> "Some proxies may have local policies that enforces TLS on all" >>>>> >>>>> >>>>> There's a pluralization mismatch in there. Perhaps "local >>> >>> policy that >>> >>>>> enforces" or "local policies that enforce". >>>>> >>>>> >>>>> The last para in "Section 4: Routing" before 4.1 says" >>>>> >>>>> " o Reject the call with a 403 "Forbidden"." >>>>> >>>>> I'm not sure I believe that. It seems much more like a 404 case. >>>>> Since there's no sips: URI available, the contact was not >>> >>> found. If >>> >>>>> we use 403, then we need to give a reason phrase that >>> >>> might help the >>> >>>>> caller figure out what went wrong. >>>>> >>>>> Section 5 Registration, Para 2 says: >>>>> >>>>>> "The USC registers either a SIPS or a SIP AOR" >>>>> >>>>> >>>>> We probably mean UAC instead of USC in the preceding. On the other >>>>> hand, you can never tell about those guys at the University of >>>>> Southern California. Maybe they speak SIP now. >>>>> >>>>> The following 3rd paragraph says: >>>>> >>>>>> "Those are mechanical rules with no influence on routing." >>>>> >>>>> >>>>> The "Those" should perhaps be "These". >>>>> >>>>> The 6th or so paragraph of section 5 says: >>>>> >>>>>> "A registrar MUST only accept a binding to a SIPS Contact >>>>> >>>>> if all the >>>>> >>>>>> appropriate URIs are of the SIPS scheme: i.e., the >>> >>> Request-URI, the >>> >>>>>> AOR (i.e., To header), the From header, the Contacts and >>>>> >>>>> all the Path >>>>> >>>>>> headers. If the URIs are not of the proper SIPS scheme, it must >>>>>> reject the REGISTER with a 403 "Forbidden"." >>>>> >>>>> >>>>> >>>>> The MUST here needs some backing. Where does the authority for it >>>>> come from? The same caveat applies to the last statement >>> >>> of Section >>> >>>>> 5: >>>>> >>>>>> "However, a registrar MUST record the scheme of the Contact." >>>>> >>>>> >>>>> Why? Is that in an RFC somewhere explicitly or implicitly? >>>>> What happens if it doesn't? >>>>> >>>>> >>>>> A similar question applies to the first para in "Section >>> >>> 6; SIPS in a >>> >>>>> Dialog": >>>>> >>>>>> "There MUST be only one Contact in any request resulting in the >>>>>> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER)." >>>>> >>>>> >>>>> >>>>> Section 6 Para 3 says: >>>>> >>>>>> "If a UAS (or proxy acting on behalf of a UAS) does not support >>>>>> SIPS, it MUST reject a request to a SIPS Request-URI with >>> >>> response >>> >>>>>> code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC >>>>>> SHOULD NOT re-attempt the request by automatically replacing the >>>>>> SIPS scheme with a SIP scheme. If the UAC does re-attempt >>>>> >>>>> the call >>>>> >>>>>> with a SIP URI, it SHOULD inform to the user that the >>> >>> security level >>> >>>>>> is downgraded." >>>>> >>>>> >>>>> The first MUST of the above is, I believe, a restatement >>> >>> of some part >>> >>>>> of 3261, which could be called out as the source of authority. The >>>>> rationale for the SHOULD might need support. I seem to recall >>>>> discussing this or something like it on-list. >>>>> >>>>> Section 7, first para, says: >>>>> >>>>>> "Sessions, dialogs and transactions may be "derived" from >>>>> >>>>> existings >>>>> >>>>>> ones." >>>>> >>>>> >>>>> The "existings" might be better as "existing". >>>>> >>>>> >>>>> The "Must be rejected" in para 3 of section 7 requires >>> >>> some support. >>> >>>>> >>>>> >>>>> Keith would suggest indenting the Note: paragraph (4) of section 8. >>>>> >>>>> >>>>> The following discussion of RFC326`/16.7: >>>>> >>>>>> "will be in the path of subsequent supports this transport" >>>>> >>>>> >>>>> is probably missing the word "requests" between "subsequent" and >>>>> "support". >>>>> >>>>> Section 9, discussion of GRUU, p 2 says: >>>>> >>>>>> "If the wrong scheme is received in the GRUU (which would be an >>>>>> error in the registrar), the UAC MUST treat it as if the proper >>>>>> scheme was used (i.e., it MUST replace the scheme with the proper >>>>>> scheme before using the GRUU)." >>>>> >>>>> >>>>> I'm not currently sure this is supportable in this >>> >>> document. I don't >>> >>>>> suppose we could move this text into GRUU? Jonathan? >>>>> >>>>> In 11. Conclusion, para 3, the 2nd sentence probably needs a cap: >>>>> >>>>>> "... how SIPS may be used. "server-side authentication" >>> >>> (where the >>> >>>>>> server" >>>>> >>>>> >>>>> The following "it's" should probably be the possessive, "its". >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 05:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDvX-0004VE-4k; Mon, 19 Mar 2007 05:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDvV-0004QI-F5 for sip@ietf.org; Mon, 19 Mar 2007 05:13:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDvU-0005lS-5O for sip@ietf.org; Mon, 19 Mar 2007 05:13:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Mar 2007 05:13:12 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J9DCZC030387; Mon, 19 Mar 2007 05:13:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2J9D9lG012921; Mon, 19 Mar 2007 09:13:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 05:13:09 -0400 Received: from [130.129.19.212] ([10.86.242.43]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 05:13:08 -0400 Message-ID: <45FE5423.3050908@cisco.com> Date: Mon, 19 Mar 2007 05:13:07 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-gruu-12.txt References: <002801c761d3$ab26a9e0$0601a8c0@BEMBUSTER> In-Reply-To: <002801c761d3$ab26a9e0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 09:13:09.0090 (UTC) FILETIME=[CFBBFC20:01C76A06] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2781; t=1174295592; x=1175159592; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-gruu-12.txt |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=Dy0fGmda6/ldVrAx9hAE0zvk6A6EPK3MADHLpGjVjoQ=; b=It2LKQsVzLMHPx/9PUUZFL5MeQqg0qBMIy3RqrQfBBKHucOWhnjtUDlGgmEo/Occ7Szwrne+ qDJX1jfgXr29DTKkXANaB0BQfvvS2154/cxgSg+6akqca337/raCwBMA; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Jonathan, > > 4 comments: > > 1. Section 5.1: recommend to somehow explicitly add that for a contact > which has expires=0, it should be avoided to construct a public GRUU or > any new temporary GRUUs OK, clarified to '...if present with a non-zero expiration..." > 2. Section 5.2: the text about Contact:* and Expires:0 is better placed > in section 5.1 moved > 3. Section 6.2 second paragraph: could add explicitly that the GRUU > needs to be still valid Added. Also made a bulleted list. > 4. Section 9 (Example call flow) remark under last message: what if the > GRUU-enabled registrar does not support outbound? Then it would use it for forking but it would eventually evaporate. For this example I haven't included sip-outbound. Per below I've fixed this so it won't get used; the reference now points to that text in GRUU which says this. > > More on point 4: the text in outbound-08 regarding "most recent > registration first" is in section 3.2: "If the instance-id and reg-id > are the same as a previous registration for the same AOR, the registrar > replaces the old Contact URI and flow information." This means that the > example will not work correctly unless the registrar supports this part > of outbound behavior (with a difference that it won't necessarily need > to deal with 'reg-id') > > Perhaps this hints at a missing requirement for the authorative proxy: > namely that it MUST target Contacts with the same instance-id in > most-recent-first order, and MUST NOT try a second one if a first one > gives a final response (ref section 7 of outbound-08) Hmm. This is a good point. I believe you are correct; GRUU at the moment says that if you have more than one registered contact per instance you need sip-outbound. But if there is a single contact and you are using GRUU, you should replace since if you were having multiple contacts from the same instance you would have sip-outbound. I've updated to fix this. > > nits: > - in section 4.4: The only reason not to use a *public* GRUU would be > privacy considerations No - there are also cases where you don't even use a temp-GRUU. This is described in the privacy considerations. > - section 5.3: yet still meet -> add s fixed > - in section 10.3: invalidate temporary a GRUU (switch "temporary" and "a") fixed Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 05:30:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEBY-0006W0-EX; Mon, 19 Mar 2007 05:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEBX-0006Ut-4c for sip@ietf.org; Mon, 19 Mar 2007 05:29:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTEBT-0007wZ-Pj for sip@ietf.org; Mon, 19 Mar 2007 05:29:47 -0400 Received: from [130.129.18.89] (dhcp-1259.ietf68.org [130.129.18.89]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2J8ZRu0024580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 02:35:28 -0600 In-Reply-To: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> References: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 19 Mar 2007 10:29:15 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP IETF , Keith Drage Subject: [Sip] Re: Current status of WG slides posted for review with IETF 68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm almost windering if we're looking at different versions of the slides. I'm going to post a new one anyhow, but . . . On Mar 16, 2007, at 11:06 PM, Cullen Jennings wrote: > On slide 4 > > e2m is waiting for resoltuion of issues with author and sec review yeah, that's what it says. > > conncted-id is in rfc ed q > > thanks. > All the list URI messages are waiting for consent before we start > processing them The status slides say "waiting on publication request for draft-ietf- sip-consent-framework". Is this unclear? > > ACR cod is in pub requested > yeah, that's what is says on page 4. > > Slide 15: > "how UPD is supported" is not an open issue from my read of the > list traffic . Do we change to CRLF keep alive for TCP and STUN for > UDP is the topic that we agree to discuss. > > Right. > > Skude 17 - I am unaware of what part of this is waiting for sips > or domain-certs. Please let me know. > sips may or may not depend on domain certs. if sips changes sips: usage, it will certainly impact the example call flows that use sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 06:29:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTF5U-0000pY-J8; Mon, 19 Mar 2007 06:27:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTF5T-0000p5-7i for sip@ietf.org; Mon, 19 Mar 2007 06:27:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTF59-0008Db-Mt for sip@ietf.org; Mon, 19 Mar 2007 06:27:35 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2007 03:27:09 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2JAR9co006710; Mon, 19 Mar 2007 03:27:09 -0700 Received: from [130.129.20.115] (sjc-vpn1-308.cisco.com [10.21.97.52]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2JAR7ZT010786; Mon, 19 Mar 2007 10:27:08 GMT In-Reply-To: References: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 19 Mar 2007 11:27:00 +0100 To: "Dean Willis" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1666; t=1174300029; x=1175164029; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Current=20status=20of=20WG=20slides=20posted=20for=20 review=20with=20IETF=2068 |Sender:=20; bh=lqir/qR7jsvrxTg0vSegr9dk59rQd/GE7zVodOuQk7c=; b=rHXmR7Nynn4A8OTinzPkd/eadpZDBUzTY5K3XAhCzcRWrYKf1HqCGtU8iRXaXbYZUO+ayVLa DrnuRB4/YrCHUlfMwRrF4yTcseBA2tg/c9oZs+Sr2V2U6LhAHun4oP7h; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: SIP IETF , Keith Drage Subject: [Sip] Re: Current status of WG slides posted for review with IETF 68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 19, 2007, at 10:29 AM, Dean Willis wrote: > > I'm almost windering if we're looking at different versions of the > slides. I'm going to post a new one anyhow, but . . . > > On Mar 16, 2007, at 11:06 PM, Cullen Jennings wrote: > > > On slide 4 > > > > e2m is waiting for resoltuion of issues with author and sec review > > yeah, that's what it says. hmm - did I review the wrong slides? - if so my appolgies - all these notes were for the slide 4 summary not later notes > > > > > conncted-id is in rfc ed q > > > > > > thanks. > > > All the list URI messages are waiting for consent before we start > > processing them > > The status slides say "waiting on publication request for draft-ietf- > sip-consent-framework". Is this unclear? > > > > > > ACR cod is in pub requested > > > > yeah, that's what is says on page 4. > > > > > Slide 15: > > "how UPD is supported" is not an open issue from my read of the > > list traffic . Do we change to CRLF keep alive for TCP and STUN for > > UDP is the topic that we agree to discuss. > > > > > Right. > > > > > Skude 17 - I am unaware of what part of this is waiting for sips > > or domain-certs. Please let me know. > > > > sips may or may not depend on domain certs. Seems very unlikely to me but sure, whatever, is fine with me, we will see > > if sips changes sips: usage, it will certainly impact the example > call flows that use sips:. I sort of doubt this - the example just show the basic setup of the crypto stuff and don't deal with the type of stuff sips covers but again, sure, we can see what the examples look like when 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 kpgoldgobud@andersen-equipment.com Mon Mar 19 07:21:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTFvr-0002bd-RT; Mon, 19 Mar 2007 07:21:43 -0400 Received: from [61.74.160.237] (helo=andersen-equipment.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTFvo-0006aP-2H; Mon, 19 Mar 2007 07:21:43 -0400 Message-ID: Reply-To: "Joshua Robertson" From: "Joshua Robertson" To: "Inga" Cc: "Cordia Armstrong" , "Marquetta" , "Kelle" , "Ruthann" , "Ara Woods" , "Meredith" , "Caren" , "Malisa Brown" , "Brigette Turner" , "Laurel Payne" , "Pat" Subject: Time For Change Date: Mon, 19 Mar 2007 00:15:47 -1100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_C71_56A6_F6B47E79.6208B878" 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 X-Spam-Score: 3.2 (+++) X-Scan-Signature: be922d419820e291bde1362184dc32fd This is a multi-part message in MIME format. ------=_NextPart_C71_56A6_F6B47E79.6208B878 Content-Type: multipart/alternative; boundary="----=_NextPart_19B_6ABC_3962E716.0C7A2403" ------=_NextPart_19B_6ABC_3962E716.0C7A2403 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable show found Madame Danglars heard was rooted bet to the spot; she made a = "How so?" "What have land you glue seat hissing discovered?" asked= Morrel."By making me apply fish thrown to the servants, key color when I= want t "Now," replied Monte Cristo "there balneal is spilt neck try only one sou= tray square light "Good-evening, Valentine," said employ a well-known= voice tail "Good-evening, Maximilian; hungrily sound I know wrung I = have kept you scale "Sir!" exclaimed the young happen suspiciously cost man, quite asto= unded, " THE DAY please cast unusual following this scene, shade at the hour the b= ank"Well, ear be wander it so, then. sister Take it from me mistaken then= , and srepeat "I have just discovered how cut a shake gardener insect may= get rid"Come, come; I always simian said you unit visit daily were a lin= e fellow, "As for dull spread myself, I first rub heard you apparatus spoken of by = my "Yes, cuddly I neck recognized connection Mademoiselle Danglars. c= ircle I was no bat "Who told boot card you we were intimate, spoken Ma= ximilian?" "No o   "Sir," returned the young man, false wreck earth behavior with a reassura= nce door Monte Cristo was at art home; harass only he destruction was engaged= withsweep sink "Why do you outstanding rat wish to know?" asked Cavalcan= ti.tax AT close FIRST SIGHT fell the exterior gleaming of the house at Au= teui"What? fact broken do shake organization you again defy me?" "Well," said Monte drop hurt price found Cristo in an indifferent tone, = allow jail "We were having a surround curtain confidential conversatio= n," retu "Dear Valentine!" "I agree pontal with lovely you, wing monsieur," said got the young man, = What, weigh above all, copy manifested tax the wash shrewdness of the = "Nay," said Danglars, "it is profit error step my fault; spread I have ch= osdamaged "No; rub the fact is, overtaken I have fly found my father."The= fail library helpful was divided into two spoke nation parts on either s= loud back "What? front boast a real father?" "Nevertheless, garden you egg seat birth must not exaggerate the evil," e= legant "That will hope account to you earth for screw the unreserved mann= e "Ah, nest how good you swift brush are friend to say so, Valentine! = You po "Not at obnoxiously behavior all; on wreck the contrary, be hold seated; = but whatslung "Yes, so long as list deliberately development he pays me"-= -"Will your excellency deign credit chess to warmly open risen it?" said = the"You'll honor use and stir lip risen believe him--that's right. What = "However, your fling range excellency," said form against Andrea, "in con= si"It memorise is your sparkle meat love which makes bent you look upon e= veryth poison "No, sugar invention worn Valentine, I assure you such is = not the case. fled "Yes, careful certainly," forward interrupted Monte blow Cristo; "bu= t L match "I argument paste have been in ill-luck for drop several days," sai= d D"Major Cavalcanti.""Good," beam swim he said; and muscle M. throat Ber= tuccio left enraptured,approve without tame soap "Is he pleased with you?= " scrub "Ah, sir, bend avoid you have given me real confidence; it is so l = "The fact is, Maximilian, that check wire deep use I was there, and my = "No; shave but overtook berry cling tell me--it is a question of simple= curio   lavatorial stem eat dug "He is a millionaire--his income is 500,000 franc= s"So far I thrust have appeared leaf rose front to answer his purpose." ------=_NextPart_19B_6ABC_3962E716.0C7A2403 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



show found Madame Danglars heard was rooted bet to the spot; she = made a     "How so?"    &nbs= p;"What have land you glue seat hissing discovered?" asked Morrel."By mak= ing me apply fish thrown to the servants, key color when I want t &n= bsp;  
"Now," replied Monte Cristo "there balneal is spilt neck try only one sou=     tray square light "Good-evening, Valentine," said= employ a well-known voice     tail "Good-evenin= g, Maximilian; hungrily sound I know wrung I have kept you   scale "Sir!" exclaimed the young happen suspiciously cost man, quite asto= unded, "    
THE DAY please cast unusual following this scene, shade at the hour the b= ank"Well, ear be wander it so, then. sister Take it from me mistaken then= , and srepeat "I have just discovered how cut a shake gardener insect may= get rid"Come, come; I always simian said you unit visit daily were a lin= e fellow,   "As for dull spread myself, I first rub heard you apparatus spoken of by = my     "Yes, cuddly I neck recognized connection= Mademoiselle Danglars. circle I was no    bat "Who t= old boot card you we were intimate, spoken Maximilian?" "No o  =   
"Sir," returned the young man, false wreck earth behavior with a reassura= nce 

door Monte Cristo was at art home; harass only he destruction was eng= aged withsweep sink "Why do you outstanding rat wish to know?" asked Cava= lcanti.tax AT close FIRST SIGHT fell the exterior gleaming of the house a= t Auteui"What? fact broken do shake organization you again defy me?" = ;  
"Well," said Monte drop hurt price found Cristo in an indifferent tone,&n= bsp;    allow jail "We were having a surround curtain= confidential conversation," retu  "Dear Valentine!"  = ;    
"I agree pontal with lovely you, wing monsieur," said got the young man,&= nbsp;   What, weigh above all, copy manifested tax the was= h shrewdness of the     "Nay," said Danglars, "it is profit error step my fault; spread I have ch= osdamaged "No; rub the fact is, overtaken I have fly found my father."The= fail library helpful was divided into two spoke nation parts on either s= loud back "What? front boast a real father?"     "Nevertheless, garden you egg seat birth must not exaggerate the evil,"&n= bsp;elegant "That will hope account to you earth for screw the unreserved= manne    "Ah, nest how good you swift brush are frie= nd to say so, Valentine! You po   
"Not at obnoxiously behavior all; on wreck the contrary, be hold seated; = but whatslung "Yes, so long as list deliberately development he pays me"-= -"Will your excellency deign credit chess to warmly open risen it?" said = the"You'll honor use and stir lip risen believe him--that's right. What&n= bsp;    
"However, your fling range excellency," said form against Andrea, "in con= si"It memorise is your sparkle meat love which makes bent you look upon e= veryth  poison "No, sugar invention worn Valentine, I assure yo= u such is not the case. 
fled "Yes, careful certainly," forward interrupted Monte blow Cristo; "bu= t L 
match "I argument paste have been in ill-luck for drop several days,"= said D"Major Cavalcanti.""Good," beam swim he said; and muscle M. throat= Bertuccio left enraptured,approve without tame soap "Is he pleased with = you?"   
scrub "Ah, sir, bend avoid you have given me real confidence; it is so l&= nbsp;"The fact is, Maximilian, that check wire deep use I was there, and = my     "No; shave but overtook berry cling tell = me--it is a question of simple curio      &= nbsp;   
lavatorial stem eat dug "He is a millionaire--his income is 500,000 franc= s"So far I thrust have appeared leaf rose front to answer his purpose."&n= bsp;         
------=_NextPart_19B_6ABC_3962E716.0C7A2403-- ------=_NextPart_C71_56A6_F6B47E79.6208B878 Content-Type: image/gif; name="ohywmada.gif" Content-Transfer-Encoding: base64 Content-ID: <2e30c01c769bb2be1730204b89e943@kpgoldgobud> R0lGODdhQQExAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA QQExAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvPzIB6HTCtve0V+02io1vzOMxuv8/yaiV9WIMngHoAhX6ChzF8gYt/kImTX4pukH2X kWwjnS+bkaCVj4iUg3mGnyJ0moGfqSmwk4CYq6eUdW2dqHO2pZ6VjKbAt8DBu663ZcrIur6stcjQ uNXRsbEoraXUp9Tdh9/S19Dbps/EtOPWyuLZzKTqeubk19P2+M3swqrv9NrybNW7xC1fJn7OhiXU Z62auTih4MSbJ0/YpmP/Fh5EOGxZxmkBFTq06A5gsnPP/jpqRHTMIMRGZ1o29EYRJb6RL9PlvKni 4kZd9Xi6vLmxpqxkckiy/Jmw4b9wMSs2zdjyoT1jTGf2O7pzZVOv+7oSrWjzXlCcKXlS5QhvHbd2 WLPBHEqurFawdWXSfQu3HZ65aKdOHLtuDGCny2iee4dLqdpQPsVeDZn245teHiOCXJw1bOWJmkWJ Hi2UtOnTZBKjXs16S+jWsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJNrEcCceQ4BIqCvkC7d RHUV121kH7JdeZfr3WmEJzE+eovyWdB7v5KdunPrAN5Hf9/cenXqI+TfR9F8f/z44MlHnnkC/mfe fP4Z/ghdewDmpyB9Dh5YX376/afeevyVsGCE5OFnoILwgSiih+VtKCGJHHLo4YEituiefSeyaOKH M674IoY1MJigijKymOKIGn6YoYU80hjijkT2aKSQRSaI34YrNomjdkEiGeSS2zHYIoLTEdhkf0f+ WGOE/nVXppRQUngfmExOCYOOP2JJZohzMhllmE76GKaeSrrIp5xKppklnxe6eQJ4fUop4Z4oApnC jhAuOaCkKZ65KIx+9pknoIbG0F+AZqqoX5aWNtijmVEuCOqhieo5IYJ3Ehjeq5TS+qqVnaKBHqI+ FJrrryyUeCUPvgJr7LHIJqvsssw26+yzyA0A7bQ0/gwgLQ/XipAtFtZ2m621I4BL7RnilrDttiyc u0W54rKL7rhilBvut++moO669M4LgLzwjgFuu93uG7DABMt7LrvzIqytwgSb4G3C9Lqrb8L2Diyw xPz2a0TAAE988cX3LnztwA9/bDLJ7+ar8sQSU3xCxw0vbLLGSMDccsP83vvvzjJzLO3OP9crcsRE D51zxjLjfHDSNB9hc75J50zCyD/vq7TVQReMtdA8F0z11TGLjMLTU3/dtNNm3wxzuFMPrTXIcD9c srlfd0w2013THfXSYZ89xN0x+9xu2xRb/LHFgjN9td1pQ93y3QYHLbTfPqz9eNaDs+1x5Js7jq63 /lSjjHLZgZsNt+JeU34F0saxrroTrgMH9etTxC674bTnrvvuvPfu++/ABy/88MQXb/wixR6v/PJm fOr889BHL/301Fdv/fXYZ6/99tx37/333HPHPI7Jy1D++Lud/yb666n/gq8EFCA/Aezf5r4LF8Zf AAH8z18/bfc7zwriZwD5GVB+BjAA/f4HmwAGSwUFSKAEJ5jAAxzAADVAQAk0KAIOMpAKDuwSCgqQ gBKa8IQoxOAMPNjBSKyKS2FQgB9CiJ0ULCABDGhAA3K4wwToUIcmXKAMPMhCIiKgiBrkYBI7eMQn VMhLf+qBAqa4AhmyYIpWFAEWT7DFEXQxCFYM/iOrhDCeA/DwjAzw4Q9xmIAC0ICIJFDiCOQIgCbW kY51bMKYoCgkVRXIOcXKYha5eEUAyDCMhxykIROpRUYSQYx0AsJ4CLCAHTLgkpjMJAMccAAhxgCO czQBHvEYRyfyCFImKpOvFIlIKmrxlSg4JBdZ6UgqupIEjlykIA1ZglxCUpFR3EF5CHAAB/zwmD/k pCeHmMdSMtGOoESiHfV4ykpdilJV7CUsecnNXeLyi16k5SIbOc5eitGbtwwnLH85xiCghwAGMCYy degAFdpgic6MZiibyU8WLiFPkLomrmKpTW5204sG/WY600lOV9oSmLvEokMJuc6KRvIHw0Rg/jGP yckD7A8H/mymEukIzX1OkwkAtWamCqQCVm4TkrwE5isFKdOHNhSiCMWpCdBp0WFJMgX6K2AFF2BB ofrvnqKcIz7vKNI4LhWlHVqTllI1oxZ406AwTWhOuylOm46ToeWUZU+/adGsxqkHk+SfWtfKVgAs 8wghZU3ywMlThM6Spl106ELBGlO82lWbt2TnRXs1wAHyDwlHPOlq2DQEmW5TijRw7APJ+EEcSFYI l22peMRX2eLQ8FGd9az4wEfa0pr2tKhNrWpXu1rOhlY4nx3Sa4MT23bO9je1Hext0+fa3fYmtz71 LW8pK9zf9vYED0iuch/w1uIi77gkIAAE/qYbgepOd7rMbe5tM+sF4E7KBNKFQAQkUN3ylhe72sXN rVhqBHBStIp7rWl8GzvWYOogPA8QL3nNW13y7jcCEHjAPU8a1xby0wr7GShm//reFMgSkeVUp14j vGCttgmtJ5DuePlbXgl4+L8REPAK97mCAmNhjxli7Hwu7OCCStSuV53pLM0Z1lzm1K8yxmWEBfvd n4J3vCD+8Ic33F8IjDifStXnM9mDTQ2lkkyBdDGMyanVF9OYrBMG60TRCVHBmpXFwszweCcg5DKb mQL2hEGBR2lgNoOwVVey0VlbrGOsvtTCuhyklmtp4ztL9Mt2PqiFvXtWAgB5Aog2s5Ap/kABjx45 qRtss4ERXKQhydm+O5VyT8WaaZrOOMs6jWmmRy3oLxM6igWggKIXPYFGK/CNKDBiSfupWFNWeoyX Zq9m7zzWmoqawl/lM7DDGmj5lvWxmMZBeIhJAUQ7+9mN9mh6W+BPkpp00iR2IptohWsfAVIGdJ0y gxUazry2ktydxjGefVlfMN8XqAdo9rNbfcGPgpTEJLV2P+VaBMlyN7IANx90R5DfCFjw4BEwQICT O+0XJNaZTNX3HU18BxWDcQn/bvD7Bu7W5Xr84wx3rq44TgCQm1y5DRf5Fk7NYra6/OWHVTazWP4F ltP8gzcngs1Zy/PW9vznQA+60Dmu/nLZ2LzouTk60u1H9KXzm7hOB2DTo34apVPd6FO/+misDlSt I5sMXAcvzGF+A4pDGuJTeKES3Evqls53p2+/uKB7jFEUjP3uKU/BU0vMhSe6GwgxbjtBxepVCUOY rz4wNclhvj+1Nr5/bhxxtZlK+SSCcuKhrLU7JSUsi3/7BS7Ns7irvO6uHh6ngQ0s6VU/9zmHWeyQ P+D84qc/yMO62iNt4azdPGsjbIo/T44R6DVd6nFbmaxYPj3cc8zV5Rd/0ANfq+wNGPvGy+/RRcT3 vpsqaWzr/NaMAn8261zXX5tzr8sHdaf7mtf3elm3xMrw4/Hu+ASuMLHZn/RS8/3w/u37XvyTcml/ V1CjB1OcBljqlH7KR4AH+HXF1m5hJwL6E0EuN30aFXmflG2Xt3/dB3Fmh2FwFoCBMld/VX7r9msM ZVPqd2WcBmgT9Xx0R1gnEEEHV4M2aINp5nCRpn+Zp29KdmDfpyYiRFUDCHd6Nnp4pkvlNmFKWG6E lHqBx3ww6HrvZncRREFYKEEYmIEeqH2Wh2/TdHnN0290lngB5ylZRzkWB3gYd4brA3Ve93SbF4et EYF0SBp2eIeikYd66EJp2IdjSEZCN4iEWIiGeIg/94eACHaKuIhiwIeOeAaQGIllMImUOAaW6FYT SH2XyGRwKH8WyImdmHZNt4mh/phAeTeKQTiHGTZBoYhAr/Zo3qc7GbdyJFdBFHRBE6SLW8iFQCiJ U8B2BOh2esZXdIV4O8BjVPgcI2RBFUBUCwCNFkRUB7AAEpSKZydNPehUbqZHOVdIDjhuT9h8KShs yMgDiveJI2AA0diO7niDB4eNSZV/IiVxcvSBoyVwnldV4AhjX2SACOh8hndT6eaEDshurZdsN9Ad 8OSODhmNN7gA8nh2kCaGkoaPq/g+wfcgMBB6dRV4x5eAAxlszteCVIZ87xdcMmgC7OiQz7gAFfCS 7fiME1lKuNd7smaR1ISGmVKExsdrEXVXxaiABMmAeeaC4paOrFgCBQCT7viM/jEpkzDJSRmkfR3I e7/4TwLXk1FGfgWYhC3YZeYYag14gscGfeoogQcQlWwZlTPpABJZlTxYeddGlxjZiJeiSjFwVSbo a4RnejU2bFuGhAmYkjEIghlWTA7QlmzpAHDZi2q2gxE3l5Opk0pQPo2yYuUTbr0WS1DIhMfol+om mkkJf69nd4rpmKq5mp1ELTfnb2w4A7V4mPEHVAVQjaupmkQVizPHbbGZBLNZZzy5lCUwgRVUgwl0 QDWpiojpY+D1iqG4nMx5ms5ZnPTnctO5k8QJe9KZnRlZd95ZidyBiORZnuaZPQBynqflkzkSnuKZ lu75HXgZn1KQifRZBfZ5/p+kCJ/6eWLz2QP4Z5nUVnbGEZz+yZ9293JIVZfMBBzCKJzEKJDId5QV ppTVWQIWMIPTV0ByeZHaqHsjFaKZl0fQdI+Ut2T4Qx8q9nmxeY7c9WDoFqMiWaGmWYUmkKHIZYGO Jou5x3312H3R1KMl9YU+io8BtSW/uU7/yGtbpWPlWI5POJqr95E1yozgZQFYmqVZSgEOwKUBepcb hH9W+YP2SJlwxIH+hz89Fioryo/j95VzR0sLBWx9Zozn5I8leZa0SZ0jQAAX8KeACqgIgAGEWqiE mgHdmY3PhJNtJqb+d6Y7GKAaSXdt6ii6RlBeuWml94J2OqFG+WcHWZpo/rmdbhWopjqoGZCqqooB CLCccfWDYzqLGziisDqc42EpAmhVxAeQjvWXIXmSw+ZnggeUEBh9AGaqfzoBqrqsGXAAsKao26dk ZOqF0ZptAuRuuBqCuxZoreeXVQZhwIp4g9luxDaFCkklMwhi5UUBX4oAFCCdrwqGs1p5YWiVJPqo mtdOsbIpjXKpDjan5GqEJelpM+qkUlqQerqMMid/HGZw8Mib6eN3UiWCNOKmPwCbF+uGG4egL/cA 0QktNGegOSCySShCpNqnLuexFpioyhGybSibM5CfEjh2vemvySGz/WlrJ5uzlIagPLufO8sb3zgt OPuzWimI6pm0Sru0/kzrPey5WUa7HP8ZtUdQtFRbtVJQcih3td+5krbJYRDAslxbQz6rYURmXiI2 ts0JnnbXsPyVtmproxdaAhDQbKrWYYxWXrAVVarDh4bGaBbkX9HWX5Cpg2iHZN31e2VAsvhJdA/w YfxjABSgAZ1kaBvWobOYuVKruPCxj08retsaoQZ5fjKasQn5uVuZrhKAZm7FaPQDZI22oLQmrddW ojqrYA2SayQYjry7VQs4koVHoyq5tiSQaoxGAW50fQ9wvK0mu1hZpEwUvVmJtdqalwBYhkrKeiBZ ejS2ggY7ug2IkBbKtiawvIxGZn0qAa02uc7aoSHlgwwqoP9XvY7S/mShG6eaqlBd1r2/W5jFtr/P B0x+K2+IFgHyEwHPpgE5yEzSBL9Xaa1JwLlxNoIduavCaoRDyb9FKZyJ1H6kZpgKu5AqEAEaoAHz NgEljMLIS6DzWqaP6gRqZ2neZrHYi7921qtYZWzeW4IW5mtnKcCliMIlPMRE3Kxim3+7N5fzKgq7 y61Z5a3gOpA7TGUmyb0BXKULmwIkTMRF/K45gHvcl5Nmijy+aVUA262eiVegGXff20hR2Feiuqdy C16SK8RDnKqNBrf/g7FmCLOpO7ckoLIGEG/H62pHtccvC24xS3QvN3tqxVxxy6dey50zi7IxF8lZ DMiYfLRBu8nU/tvJnlwEVhvKtQnKeOh0O9e0qmyI6bnKrjw9pBzLsjzLtFzLtnzLuJzLurzLvNzL pAw6WjA5Y4M7hlPM4Qk6ttMEyVw2cwPMb2M1xzw7p8M5buMwnoM7EBM6kwM5I6MtmuOdrIPMpZPN KXPN2AwyknPOYGMzOEOf6twzpnMznbM3wyw2fcPM8Rw63nyfxAzMloPO1qwv8kw64/wyiCPN+/zO o3g5bEPN9UzPqMMyCA3Ra6M5/5KdapPPn4PQDD0zBK009cLNDpPQGC3ORhMxdDM35KzN4Sw46mzS zkw4HsOcMR01Mw0xw5w1qVMx2qwCKo3NByPMvbzMvmwFRF3U/lRw1Ei91Ezd1E791FAd1VINLxsw 1c1S1Y5YchCwAVzd1V791WAd1mI91mRd1mZ91mid1mq91mzd1m791nDd1gEmtjDwABvAARzQAXod 120NAHz914Ad2II92IRd2GLdARygABywAXStAhCA2Bugx1adAg/QAYptZD7wAHiN2ZMdAxCgAB0g 2TYAAQPA2Z09A3dt2jZw16J92nW92DiA2I192rBdAxDAAa69A5qt2i+g2a2d2zPwAAOwnLVNLUrt AiFj1DE90EuwAR0gA5+tbGvYnmQ7KyY7WSGcLiEt08jN3VXQ0feMcb+NAh3A239MQ7ty3SIsxy+Q Mczt0979/t2zkzdP4NwwQACMS6kwNCACMiHc9kRrAoACWB/rtUeqIoR6AzBAgznSHNTf3Mw4vc9h 89MHbTkOntNBXTdCzQIEgNu97eHr7SBIEimlYr2WGkW5JuITLHwoJjYW7uKmA832LDr6PM3/bNM9 I9AN3tJ4ozLHfQIcMN50i9UhzkdaslLBlZl8tCdIeuQoduQU7TkRLePQDDSL0zVW7t7FXOHpfDRc k88SHdvmjQJcbaUq7ip10uQr3h6XOuCRUk2nYnGAAzjcXTdbk+M6fdE6reN8njoV7dEEndFTHgNl 7gJ5beZGPiwprt9qzmK5uuRGklIP/eJgYy6EIzc0buML/h7ojdPOBb3TevPpf47aRM4CHVDq1C1Q ih4oa27isaLqke5TAZLonN7jMI7jEn44kSM5zHwyed7pjBPmUW7r8LzhLFDoLXDqz9GmgyIjo+Jk aS6xdqImE2sqK+Zt1u6bCnPQoJ45uS7P4C7lAG005M454E3hpPPjJoDspo7qVTe8i5zdMqDuukHv JMDuK6DsdcjeGyvvMWDvtDHRMoDvKqDvvwPwAa/QL0DwKWDwwN0DDE/e7v7wORDxJ+DwFK8DFm8C GJ/xOLDxJdDxthXvSTLH2gFcQwtaqFufw1nxEy/xogzvUJvJxHu0oWKLb6jxL3/xOy+C7GUrqfRk 7qF2/v9t7ekJ6UdvK6KSUjryJDDEr/1dIaQCJS904FWSYPt99Fm/3wde4JCuSi2eAiBPAiJ/JHeC q0F/7aXS4iQu4s1e8qyu6iwFIW/+5JxyI2Yv92dPIote8rzCkX7v9uF37UU49iNQ9isOZnK29mmO 4nFisVhfJYoC93AuJ2nSJiWe+IsvJtHe+I7e+ZIu+afik4YvAohPsZjv32fuIozl9d8lVZC/+qvP +Dcf+Ity+Vrfyq8O65+CTWvf+qPC5qpv5GCCKrCP+ytQ+n7d853/+qMP67KF7XKvr5jPec+/6vxK JM3+9kx+9pwP/SP/95UP5XUCJy2g/I99rSOu9rOv/inXP+sjEvtI30egfyhO7/74n/mov/mukpm0 r1IgAAiASJYjiZ4mi7rmy8pyB803+XC4HJf9SCUYuoip1hApTLZEKufqZvz1gE9iUAqlOq8wJfjI TWXFXfPzJAyTl+kzegt/U4trnozzwM8UBD5goOAgYSEOnWGiYtMiHmIjJOSjjE5hx0ZkpubmF6cn 32Rj6CdpZ+BGRyGEQmmr6ytsrOwsocIe4cMl7S5vr+9vL2qizi2w8TFysrLJw8BfIsTO8jR1tXVk rs1ih9619zf4twIm5EZ3OHq6+uzDuCbEAPn6PH19IoG5tiYBN8RzoTx7Agciw6egwz9OuTjUIOjw XeE3CB0OFiv1wBwHhpc2cOzo8SPIkCJHkixp8iTKlCpXsmzp8iVMlR24ZdyQMNYDCBBi8uzp8yfQ oEKH/tRZESLSpEqXMm3q9CnUqFKnUq1q9SrWrFq3cu3q9WvVEAA7 ------=_NextPart_C71_56A6_F6B47E79.6208B878-- From sip-bounces@ietf.org Mon Mar 19 08:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGaz-0004Ou-UW; Mon, 19 Mar 2007 08:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGay-0004Ok-KN for sip@ietf.org; Mon, 19 Mar 2007 08:04:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTGaw-0006Pp-Tu for sip@ietf.org; Mon, 19 Mar 2007 08:04:12 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 13:04:08 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2JC48vQ002592; Mon, 19 Mar 2007 13:04:08 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2JC47lb000783; Mon, 19 Mar 2007 12:04:07 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 13:04:06 +0100 Received: from [10.61.65.243] ([10.61.65.243]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 13:04:06 +0100 Message-ID: <45FDF2C0.4060305@cisco.com> Date: Sun, 18 Mar 2007 22:17:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mayumi Munakata References: <200703140433.l2E4XNMf029470@imf.m.ecl.ntt.co.jp> In-Reply-To: <200703140433.l2E4XNMf029470@imf.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 12:04:06.0687 (UTC) FILETIME=[B1BD12F0:01C76A1E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10215; t=1174305848; x=1175169848; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20privacy-clarified=20draft |Sender:=20; bh=4exMrnhSezHJ9MD/q6W11yPcE6DE9HSn6HL+bDhfoL4=; b=T1MEHygn7so0KpTuwbdrBN9bSSFG9JgcjVvcK7R33Tn4fVB8aHyg2oO0n47hzTzP+9BlR/Ow o318mLLE8NpPScGCikZNPQ9u8biLr+SOFPFxHA84SCFUDHWg3ZyhrBp3; Authentication-Results: ams-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: SIP IETF Subject: [Sip] Re: privacy-clarified draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This draft has been on my list to comment on. I just got to it while in the airport. The following isn't very well organized - mostly notes made while reading the draft front to back. I've quoted sections of the doc (indented) to comment on and/or referenced a section number. I think this has potential to be an improvement over RFC 3323. But I do think it needs more work to reach this potential. Thanks for getting this started. Paul Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. There is a potential problem with the above definition, since the privacy mechanisms, in part, depend on intermediaries to accomplish the privacy. So it isn't really withholding info from *any* intermediary - rather only from *some* intermediaries. And that adds some complexity to this process that isn't discussed too much. There is in fact conflict in goals among the policies regarding which intermediaries get what info. In the case of Privacy:id the goal is that the id remain visible to all intermediaries within a "trust domain" and only be removed when the message exits that domain. For some of the other privacy types I think the expectation, if not the goal, is that information may be removed sooner, even if the request remains within a trust domain. This document also makes an assumption that when user requests privacy, it is based on a binary decision. The user either requests privacy for the whole message or no privacy at all. Really? Then why are there still degrees of privacy? privacy service: A network entity which executes privacy functions before forwarding messages to elements that are not trusted. It is sometimes abbreviated to PS in this document. I'm not sure this is quite right. If it is a service, then presumably you need to forward to this service when you want it. If included, are its actions still conditional on whether the next hop is trusted or not? Its a little unclear whether a privacy service is something that is intended to be in the path of every request, or if it is something that is to be included in the path when the UA, or some intermediary, decides that it is needed for a particular request. My suspicion is that we are trying to support multiple models of how this should work without clearly understanding what those models are. A privacy service can execute partial or full privacy functions on behalf of a user agent when requested. The above seems in conflict with the earlier statement that privacy is a binary decision. (Well, maybe not. I guess the choice of full or partial is based on how much the UA did for itself and how much it has delegated to the privacy service.) If a user agent can execute all the privacy functions for the user inserted information, then the functions SHOULD be executed at the user agent. If a user agent can provide only partial or no privacy function, the user agent SHOULD NOT execute any privacy functions and rather it SHOULD delegate the task to the privacy service. These SHOULDs and SHOULD NOTs don't seem like something that needs to be normative. It doesn't hurt anything, except performance, for the UA to do something which the service will do again. I think this could better be stated that a UA that *can* execute all the user privacy functions SHOULD do so, and then that a UA that has not executed all the user privacy functions, but that desires privacy, MUST request a privacy service to do them. There could be a note that if a server is asked to do user privacy functions then there is probably no point in the UA doing any of them. Section 4.1: Syntax: Others have noted this... Here the syntax is presented as a total replacement for that provided in the previous RFCs on the subject, yet this isn't a total replacement for those RFCs. Is this intended to replace fully RFC 3323 while leaving 3325 and 4244 in place? There is no mention of "critical". Is this intentional? Is there another solution to the problem that "critical" was intending so solve? (Its not clear that it actually solved it.) With this document, "user", "session", and "critical" are NOT RECOMMENDED to be used and be kept solely for the backward compatibility reason. If they are being kept, then they are still needed in the revised syntax. Note: Location of privacy service is out of scope. It depends on deployments and network policy. I think more is needed than this. At the least, "id" depends on being done at the edge of the trust domain. And for the others, there must be *some* mechanism to ensure that the privacy service is included, so at the least there should be some mention of whether the UA must do something to involve the PS. Call-Info: There are many potential uses for call-info. Its not at all clear that all of them disclose identity. (This is info about the *call*, not the *caller*.) And it may be that some are needed. So blocking this is "all" mode might be a problem. Other headers, such as Alert-Info could conceivably reference the caller. Its not clear there is any way a PS could tell if this is the case, so maybe this MUST be the responsibility of the UA to anonymize. 5.2. Target SIP Parameters and SDP Attributes for Each priv-value Shouldn't this be "Target SDP Parameters and SDP Attributes..."? What about other body parts, other than SDP? For instance this could be an issue with MESSAGE or NOTIFY and content indirection. This seems to be a hard subject. In section 6.2 or maybe in 8.1, I think there needs to be some discussion of whether the PS must be a B2BUA, or if it can sometimes be just a proxy. I can't see any other way to do "all", but it does seem that it is probably possible to do so for "nw-level". If that is right, should just say so explicitly. 6.4.3. Replaces Header/Parameter ... Main challenge for this to function properly is that privacy service has to be on a signaling path to the originator for every dialogs. Which is generally not possible. Its not very useful to say that a general solution is not possible. What is needed is demonstration that a solution *is* possible. The examples suggest some strategies: If the UAC explicitly requests privacy for a call, and then does a REFER that references that call, it must arrange for the same PS to be involved in the REFER. And then the PS must do the right thing, even if no privacy is requested for the REFER. If the UAC doesn't know the PS is involved - because some intermediate node makes the request on its behalf - then it should arrange that the PS be involved in every call to/from the UA that might use REFER to a call the PS is providing privacy for. This imposes some pretty stringent topology requirements on the network, but that is the consequence of attempting to provide privacy without the assistance of the UA. Note that it seems that replacing the callid will always require the PS to be a B2BUA. This is needed to ensure it gets control (to fix up refer-to) when a UA the received a private call transfers the caller. Processing of Path and Service-Route: The conclusion that these aren't subject to privacy processing seems reasonable. But it does highlight that not all intermediate nodes are equal in privacy processing. It seems to be part of the concept of trust domains. Trust domains are discussed in 3325 in application to Privacy:id, and they may apply to Privacy:history too. But they aren't related to other privacy processing as discussed in 3323. And it certainly isn't covered thoroughly in this draft. 7.1. Locating Privacy Service If the originating user agent is aware of the URI for the privacy service it SHOULD address the privacy service by setting the URI of the privacy service in the "Route" header. The guidelines here don't address the expectations around Privacy:id. Here the goal is to get to a privacy service quickly. Then the remainder of the path to the callee is private. But Privacy:id wants the id to remain non-private as long as the call remains within the trust domain. These goals seem to conflict. But it may be possible to satisfy them both. Inserting a Route header for the PS using the ";lr" parameter, and putting it after any other routes known to be in the trust domain can help. Then intermediate nodes prior to the PS will have the opportunity to insert other intermediate routes ahead of the PS, thus deferring the invocation of the PS until the trust domain is to be exited or the target is to be reached. (Unlike existing 3325 rules, this would not permit the callee to avoid the privacy if it is part of the trust domain.) Another way to achieve this might be to separate the treatment of Privacy:id from other kinds of privacy - notably "all" and "nw-level". Specifically, "all" and "nw-level" would be processed as in this document, while "id" processing would be defered until the trust domain is exited. Of course this makes little sense if the UA contacts an independent PS directly, but in that case "id" also makes little sense. Note that when a privacy service is handling a request and providing privacy on behalf of the destination of the request, providing privacy for Record-Route headers downstream of the privacy service is significantly more complicated. This document recommends no way of statefully restoring those headers if they are stripped. This is part of a more general problem of providing privacy for the target of a call. This should perhaps bedeclared out of scope in general. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 10:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTIVH-0006LK-Ml; Mon, 19 Mar 2007 10:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTIVG-0006Hk-Qz for sip@ietf.org; Mon, 19 Mar 2007 10:06:26 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTIVC-00054V-O2 for sip@ietf.org; Mon, 19 Mar 2007 10:06:26 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2JE5qZ16729; Mon, 19 Mar 2007 14:05:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2007 09:05:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FA8AFA7@zrc2hxm0.corp.nortel.com> In-Reply-To: <45FE0336.8010506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-03 Thread-Index: AcdqHsn3GyBSIUfISmC1WPAKDUHqDgADpa5g References: <45FE0336.8010506@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIP IETF Subject: [Sip] RE: draft-ietf-sip-sips-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Below.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Sunday, March 18, 2007 20:28 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF > Subject: Re: draft-ietf-sip-sips-03 >=20 > Just read the most recent version. Its looking good to me.=20 > Just a few typo comments. >=20 > Thanks, > Paul >=20 > Section 4.2: >=20 > There are no known valid use cases for a proxy to forward=20 > a request > from SIP to SIP. This section illustrates the way it=20 > would work for > ??? > completeness, but it is in no way endorsing the practice. A proxy > MUST NOT change the scheme from SIP to SIPS when forwarding a > request. >=20 > Surely this is intended to say SIP to SIPS, right??? Yes, you are correct. I just did this to make sure you where paying attention :^) > Section 10, Topology figure: Alice's outbound proxy is=20 > labeled "B", but should be "A". That too. Will fix. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 10:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJ20-0002Rc-7V; Mon, 19 Mar 2007 10:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJ1z-0002RU-J5 for sip@ietf.org; Mon, 19 Mar 2007 10:40:15 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJ1x-00032T-SN for sip@ietf.org; Mon, 19 Mar 2007 10:40:15 -0400 Received: from [130.129.17.120] (dhcp-1178.ietf68.org [130.129.17.120]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l2JEe13K029552; Mon, 19 Mar 2007 08:40:02 -0600 Message-ID: <45FEA0B7.6010209@ntt-at.com> Date: Mon, 19 Mar 2007 15:39:51 +0100 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat References: <200703140433.l2E4XNMf029470@imf.m.ecl.ntt.co.jp> <45FDF2C0.4060305@cisco.com> In-Reply-To: <45FDF2C0.4060305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: Mayumi Munakata , SIP IETF Subject: [Sip] Re: privacy-clarified draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul; Thanks for you comprehensive comments. My comments inline. Paul Kyzivat wrote: > This draft has been on my list to comment on. I just got to it while > in the airport. The following isn't very well organized - mostly notes > made while reading the draft front to back. I've quoted sections of > the doc (indented) to comment on and/or referenced a section number. > > I think this has potential to be an improvement over RFC 3323. But I > do think it needs more work to reach this potential. Thanks for > getting this started. > > Paul > > Privacy is defined in this document as the withholding of the > identity of a person (and related personal information) from one or > more parties in an exchange of communications, specifically a SIP > dialog. These parties potentially include the intended > destination(s) of messages and/or any intermediaries handling these > messages. > > There is a potential problem with the above definition, since the > privacy mechanisms, in part, depend on intermediaries to accomplish > the privacy. So it isn't really withholding info from *any* > intermediary - rather only from *some* intermediaries. Agree. Needs to be fixed. > > And that adds some complexity to this process that isn't discussed too > much. There is in fact conflict in goals among the policies regarding > which intermediaries get what info. In the case of Privacy:id the goal > is that the id remain visible to all intermediaries within a "trust > domain" and only be removed when the message exits that domain. For > some of the other privacy types I think the expectation, if not the > goal, is that information may be removed sooner, even if the request > remains within a trust domain. I believe the goal would really depend on the deployment and its policy. Even for priv-values such as "all", depending on the policy the privacy function may be located close to the UA or possibly at the egress point. Recommendation on where privacy function to be allocated was something we contemplated to add but because different deployment has different policy, we saw this to be useless. Location of privacy service and its ramification to surrounding intermediaries may be worth while to cover in the draft. > > This document also makes an assumption that when user requests > privacy, it is based on a binary decision. The user either requests > privacy for the whole message or no privacy at all. > > Really? Then why are there still degrees of privacy? If you preclude the priv-values remaining for the purpose of backward compatibility, the end user requests privacy to be either enabled or disabled. I see this as a binary decision from end user's perspective. When enabled the degree of how much task UA delegates to PS for providing privacy and how much UA takes on solely depends on UA's capability. > > privacy service: A network entity which executes privacy functions > before forwarding messages to elements that are not > trusted. It is sometimes abbreviated to PS in this > document. > > I'm not sure this is quite right. If it is a service, then presumably > you need to forward to this service when you want it. If included, are > its actions still conditional on whether the next hop is trusted or not? You are completely right, this definitely needs to be rewritten. As you noted before the privacy functions are not always executed before forwarding the request to an untrusted entity. > > Its a little unclear whether a privacy service is something that is > intended to be in the path of every request, or if it is something > that is to be included in the path when the UA, or some intermediary, > decides that it is needed for a particular request. My suspicion is > that we are trying to support multiple models of how this should work > without clearly understanding what those models are. Yes that's the intention. Generally speaking I believe privacy, if requested at the establishment of the session would require the PS to be on the path for every request until the session is terminated. > > A privacy service can execute partial or full privacy functions on > behalf of a user agent when requested. > > The above seems in conflict with the earlier statement that privacy is > a binary decision. (Well, maybe not. I guess the choice of full or > partial is based on how much the UA did for itself and how much it has > delegated to the privacy service.) It's a binary decision as far as end user is concerned. I think this obviously needs to be clarified. How much UA does and how much privacy service does really depends on UA's ability as you noted above. > > If a user agent can execute all the privacy functions for the user > inserted information, then the functions SHOULD be executed at the > user agent. If a user agent can provide only partial or no privacy > function, the user agent SHOULD NOT execute any privacy functions and > rather it SHOULD delegate the task to the privacy service. > > These SHOULDs and SHOULD NOTs don't seem like something that needs to > be normative. It doesn't hurt anything, except performance, for the UA > to do something which the service will do again. I think this could > better be stated that a UA that *can* execute all the user privacy > functions SHOULD do so, and then that a UA that has not executed all > the user privacy functions, but that desires privacy, MUST request a > privacy service to do them. There could be a note that if a server is > asked to do user privacy functions then there is probably no point in > the UA doing any of them. > Agree, will fix the text accordingly. > Section 4.1: Syntax: > > Others have noted this... Here the syntax is presented as a total > replacement for that provided in the previous RFCs on the subject, yet > this isn't a total replacement for those RFCs. Is this intended to > replace fully RFC 3323 while leaving 3325 and 4244 in place? > > There is no mention of "critical". Is this intentional? Is there > another solution to the problem that "critical" was intending so > solve? (Its not clear that it actually solved it.) Currently the text reads to say that it suggests to use proxy-require to use > > With this document, "user", "session", and "critical" are NOT > RECOMMENDED to be used and be kept solely for the backward > compatibility reason. > > If they are being kept, then they are still needed in the revised syntax. Understood. Will add them in the syntax. > > Note: Location of privacy service is out of scope. It depends on > deployments and network policy. > > I think more is needed than this. At the least, "id" depends on being > done at the edge of the trust domain. And for the others, there must > be *some* mechanism to ensure that the privacy service is included, so > at the least there should be some mention of whether the UA must do > something to involve the PS. I added a note in the section 8 about this problem, and regretfully I couldn't come up with any idea to accomplish what you are requesting. The PS like any other network provided services such as sip-identity, proxy inserted location solely depends on the availability of the services in the network thus UA has no way to assure its involvement. Of course mechanisms such as config-fw etc. may be used to discover PS in which case UA can add them explicitly in a Route header to ensure request gets routed through PS but that's as far as we can do, as far as I can see. Any suggestions to improve this situation is much appreciated. > > Call-Info: There are many potential uses for call-info. Its not at all > clear that all of them disclose identity. (This is info about the > *call*, not the *caller*.) And it may be that some are needed. So > blocking this is "all" mode might be a problem. Will add a text to make this conditional. > > Other headers, such as Alert-Info could conceivably reference the > caller. Its not clear there is any way a PS could tell if this is the > case, so maybe this MUST be the responsibility of the UA to anonymize. Okay. > > 5.2. Target SIP Parameters and SDP Attributes for Each priv-value > > Shouldn't this be "Target SDP Parameters and SDP Attributes..."? > > What about other body parts, other than SDP? For instance this could > be an issue with MESSAGE or NOTIFY and content indirection. This seems > to be a hard subject. content indirection I agree. NOTIFY was obviously overlooked. > > > In section 6.2 or maybe in 8.1, I think there needs to be some > discussion of whether the PS must be a B2BUA, or if it can sometimes > be just a proxy. I can't see any other way to do "all", but it does > seem that it is probably possible to do so for "nw-level". If that is > right, should just say so explicitly. Will add the text to make it more explicit. > > 6.4.3. Replaces Header/Parameter > ... > Main challenge for this to function properly is that privacy service > has to be on a signaling path to the originator for every dialogs. > Which is generally not possible. > > Its not very useful to say that a general solution is not possible. > What is needed is demonstration that a solution *is* possible. > > The examples suggest some strategies: > > If the UAC explicitly requests privacy for a call, and then does a > REFER that references that call, it must arrange for the same PS to be > involved in the REFER. And then the PS must do the right thing, even > if no privacy is requested for the REFER. > > If the UAC doesn't know the PS is involved - because some intermediate > node makes the request on its behalf - then it should arrange that the > PS be involved in every call to/from the UA that might use REFER to a > call the PS is providing privacy for. This imposes some pretty > stringent topology requirements on the network, but that is the > consequence of attempting to provide privacy without the assistance of > the UA. Agree replacing addressing component (URI/IP) that would be used in the REFER so any requests derived from REFER would result in passing the PS would be a way to solve this. The simplest solution would be to ensure UA executes the privacy service but the real world is not that friendly. > > Note that it seems that replacing the callid will always require the > PS to be a B2BUA. This is needed to ensure it gets control (to fix up > refer-to) when a UA the received a private call transfers the caller. Agree. I think what you are saying is that some recommendation which may impose some particular topology should be given as a possible solution to the issue mentioned. > > Processing of Path and Service-Route: > > The conclusion that these aren't subject to privacy processing seems > reasonable. But it does highlight that not all intermediate nodes are > equal in privacy processing. It seems to be part of the concept of > trust domains. Trust domains are discussed in 3325 in application to > Privacy:id, and they may apply to Privacy:history too. But they aren't > related to other privacy processing as discussed in 3323. And it > certainly isn't covered thoroughly in this draft. What do you want to see in respect to these headers? > > 7.1. Locating Privacy Service > > If the originating user agent is aware of the URI for the privacy > service it SHOULD address the privacy service by setting the URI of > the privacy service in the "Route" header. > > The guidelines here don't address the expectations around Privacy:id. > Here the goal is to get to a privacy service quickly. Then the > remainder of the path to the callee is private. But Privacy:id wants > the id to remain non-private as long as the call remains within the > trust domain. Agree. Consolidating the execution of privacy on P-A-ID both in "nw-level" and "all" introduced this issue. > > These goals seem to conflict. But it may be possible to satisfy them > both. Inserting a Route header for the PS using the ";lr" parameter, > and putting it after any other routes known to be in the trust domain > can help. Then intermediate nodes prior to the PS will have the > opportunity to insert other intermediate routes ahead of the PS, thus > deferring the invocation of the PS until the trust domain is to be > exited or the target is to be reached. (Unlike existing 3325 rules, > this would not permit the callee to avoid the privacy if it is part of > the trust domain.) This is if the location of PS is known. Or were you thinking of something like Service-URN in the Route header as suggested in Jonathan's service identity draft? > > Another way to achieve this might be to separate the treatment of > Privacy:id from other kinds of privacy - notably "all" and "nw-level". > Specifically, "all" and "nw-level" would be processed as in this > document, while "id" processing would be defered until the trust > domain is exited. Of course this makes little sense if the UA contacts > an independent PS directly, but in that case "id" also makes little > sense. Right. I was thinking of this but I was wanting to avoid any kind of micro-management of the priv-values but this may be the simplest solution. > > Note that when a privacy service is handling a request and providing > privacy on behalf of the destination of the request, providing > privacy for Record-Route headers downstream of the privacy service is > significantly more complicated. This document recommends no way of > statefully restoring those headers if they are stripped. > > This is part of a more general problem of providing privacy for the > target of a call. This should perhaps bedeclared out of scope in general. Agree. Regards Shida > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 11:12:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJV1-0002JJ-Iu; Mon, 19 Mar 2007 11:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJV0-0002J6-O6 for sip@ietf.org; Mon, 19 Mar 2007 11:10:14 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJUz-0001AQ-Fg for sip@ietf.org; Mon, 19 Mar 2007 11:10:14 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HTJUs-0000WX-Kv; Mon, 19 Mar 2007 07:10:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-ietf-sip-gruu-12 Date: Mon, 19 Mar 2007 08:09:16 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> In-Reply-To: <45FDD909.6030906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: AcdpvYNRTdvB0c5fQ7qdKG4Gxb07nwAbdzWw References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> From: "Michael Procter" To: "Jonathan Rosenberg" , "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > EKR wrote: > > This doesn't seem right. "+sip.instance" at best means > > "I want to do outbound". More likely it means "here is my instance ID". > > It's "Supported: gruu" that says "I want a GRUU". >=20 > No, its instance. It used to work the way you described, in fact. > However, we ran into an issue that a UA might register with an instance > ID but not support GRUU, and then something is subscribed to reg-event > and wants to learn its gruu. So you don't return the gruu to the UA, but > you still need to generate the GRUU to deliver in reg-event. I'm interested in how this 'one-sided' support for GRUU would work. My initial reaction is that it would lead to odd failures. =20 For example, take the case where UA1 doesn't support GRUU, but registers at R1 which does. R1 generates the GRUU, but doesn't deliver it back to UA1, as you describe. Let's also assume that UA2 has subscribed to the reg-event package for UA1 at R1. This leads to R1 sending UA2 UA1's GRUU. So far, so good. Now, for some reason, UA2 wishes to call UA1 using that GRUU. The INVITE gets routed to UA1 as expected. UA1 answers the call, and in the 200, includes a non-GRUU contact. The ACK from UA2 now can't route correctly (as UA1 can't provide a contact that is globally routable!). The upshot of this is often (in my experience) a call that seems to work for 30 seconds or so, and then gets torn down. Similar things happen for subscriptions - the SUBSCRIBE/200 works ok, as do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it fails for the same reason. This can be worked around with judicious use of Record-Route, but I can't see any mention of this particular case in the draft. Is GRUU support for non-GRUU UAs something we need to make work? Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 19 16:16:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOCp-0006J4-FA; Mon, 19 Mar 2007 16:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOCo-0006Ir-LC for sip@ietf.org; Mon, 19 Mar 2007 16:11:46 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTOCS-0000pS-Oy for sip@ietf.org; Mon, 19 Mar 2007 16:11:46 -0400 Received: (qmail 3601 invoked by uid 0); 19 Mar 2007 20:04:20 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Mar 2007 20:04:20 -0000 Message-ID: <000601c76a61$c4708970$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Procter" , "Jonathan Rosenberg" , "EKR" References: <20070311173655.DF5EE1CC24@delta.rtfm.com><45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 Date: Mon, 19 Mar 2007 21:04:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline Regards, Jeroen Michael Procter wrote: > Jonathan Rosenberg wrote: >> EKR wrote: >>> This doesn't seem right. "+sip.instance" at best means >>> "I want to do outbound". More likely it means "here is my instance >>> ID". It's "Supported: gruu" that says "I want a GRUU". >> >> No, its instance. It used to work the way you described, in fact. >> However, we ran into an issue that a UA might register with an >> instance ID but not support GRUU, and then something is subscribed >> to reg-event and wants to learn its gruu. So you don't return the >> gruu to the UA, but you still need to generate the GRUU to deliver >> in reg-event. > > I'm interested in how this 'one-sided' support for GRUU would work. > My initial reaction is that it would lead to odd failures. > > For example, take the case where UA1 doesn't support GRUU, but > registers at R1 which does. R1 generates the GRUU, but doesn't > deliver it back to UA1, as you describe. Let's also assume that UA2 > has subscribed to the reg-event package for UA1 at R1. This leads to > R1 sending UA2 UA1's GRUU. So far, so good. > > Now, for some reason, UA2 wishes to call UA1 using that GRUU. The > INVITE gets routed to UA1 as expected. UA1 answers the call, and in > the 200, includes a non-GRUU contact. The ACK from UA2 now can't > route correctly (as UA1 can't provide a contact that is globally > routable!). The upshot of this is often (in my experience) a call > that seems to work for 30 seconds or so, and then gets torn down. > GRUU-12 section 6.2 requires the proxy to Record-Route the INVITE when a GRUU is used as request URI, and there is a Path stored. So in this case the call will work if and only if there was a Path and the Contact is reachable from the proxy. So section 6.2 should be updated to state "[...] and the registration contain Path URI and/or the registered Contact is not globally routable" > Similar things happen for subscriptions - the SUBSCRIBE/200 works ok, > as do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it > fails for the same reason. > > This can be worked around with judicious use of Record-Route, but I > can't see any mention of this particular case in the draft. > > Is GRUU support for non-GRUU UAs something we need to make work? > > Regards, > > Michael Procter > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From twgfimok@irvineco.com Mon Mar 19 22:13:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTTqv-00067D-SL; Mon, 19 Mar 2007 22:13:33 -0400 Received: from [220.249.163.41] (helo=irvineco.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTTqs-0007f1-7e; Mon, 19 Mar 2007 22:13:33 -0400 Message-ID: <785f01c76aed$6251cd30$b6285406@twgfimok> From: "Jan Williamson" To: "Azalee" Cc: "Kelsi" , "Celestine" , "Fidel" , "Linette Harvey" , "Mistie Burton" , "Ursula" , "Hanh" , "Ashely Patterson" , "Roman Henry" , "Eugene" , "Lydia" Subject: Still Busy Date: Tue, 20 Mar 2007 12:43:39 +1100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_E19_FA8A_DAAF86FC.62C8E6AE" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.3 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e This is a multi-part message in MIME format. ------=_NextPart_E19_FA8A_DAAF86FC.62C8E6AE Content-Type: multipart/alternative; boundary="----=_NextPart_DE4_F2EB_DEEEF4A9.097FD35C" ------=_NextPart_DE4_F2EB_DEEEF4A9.097FD35C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable harsh abecedarian "Ah, I mass believe noblemen signal marry amongst thems= elves, offer "I have stood mine," said Madame store de justly Villefort;= and she p "I think I parcel can lay effectually wink force leather you= ;" and Monte C"Ah," said seek Monte Cristo, taking withstood shook respec= t it from her hand. "From whom, then?" "Yes." "I crazy am fight sure you are; describe it= range is not very difficult to di "From an Englishman, draw called fold metal flood Lord Wilmore, who take = "It is carriage usual, shock certainly; son lain but Cavalcanti is an ori= glanguage frowning "Yes," she said, "at your command advice I have leaf m= ade the tvascular "A garden roll theory with bore two acres of land!""And= touch cough comparison overtake have you succeeded?" "And of whom you last ornament have hemic no meat more knowledge than I o= f awoken money stem pleasant "Sir," said Valentine, "my grandfather wi= shes for "Yes."   song "You are debt mistaken; there run play I am ahead of you." sign vascular chop strange "Do you think so?""I think so."sown "And a ten= dency thousand page do francs a year."forgotten Madame Danglars was room = carried shaven into come the adjoining roo embarrassed "You have handle felt surprise seen him, then?" "What to do?= " Noirtier skirt made no pain thread answer. "What do lock you want with= a "Yes, once." "Oh, heavens!" drab do relax "I am zoic sure of it."Villefort pressed her plate impulse = hand to slew sugar let her know it was"Come, take balance them," hole and= stealthily run Monte Cristo forced the banmarch thing "Oh, no, sir," she= engine infamous answered; "but you know, things "Where?" spend net wild "Still," said Barrois, sweep with the freedom= and fideli "Yes, I knew do soap want fire attack a notary," motioned th= e old man, s fruit "And you have wrap humor heard slip his fortune mentioned?""Well," = gladly said Monte mouth Cristo, found measure "you may believe me if"What= forbade yearly wrote plain am I to do?"list neck help "Take street care,= " said Madame de Villefort, "the king's "Ah, that is just zoom what vesical I cannot tell you; shave fled if I di= d"You shall instruct judge have a lick notary, as you attraction absolute= ly wish f "Never flag instrument mind that," said garden Barrois; "I sha= ll close go and f see "And what late dress did stridden the letter contain?" arrest "Nothing difficult else was spilt talked of; only time some said h= e was"Ah," replied Monte nose lift Cristo, "since that door song is the c= as"Yes; but"--stop "Why bury it blow there if rate it were heap dead? Thi= s garden ha zip "And osteal has he conformed frozen to all that dry the letter speci = "I never once wonderful doubted encouraging fed frantic your doing so= " Monte Cristo "Ah, made strap your steer excellency, I am cow overwhel= med with deligh   "He has.""What bite is done to breathe infanticides refuse in broken this= country?" as ------=_NextPart_DE4_F2EB_DEEEF4A9.097FD35C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


harsh abecedarian "Ah, I mass believe noblemen signal marry amongst t= hemselves,  offer "I have stood mine," said Madame store de jus= tly Villefort; and she p   "I think I parcel can lay effec= tually wink force leather you;" and Monte C"Ah," said seek Monte Cristo, = taking withstood shook respect it from her hand.    &= nbsp;
"From whom, then?"    "Yes."  "I crazy am f= ight sure you are; describe it range is not very difficult to di &nb= sp; "From an Englishman, draw called fold metal flood Lord Wilmore, who take&= nbsp;   

"It is carriage usual, shock certainly; son lain but Cavalcanti is an= origlanguage frowning "Yes," she said, "at your command advice I have le= af made the tvascular "A garden roll theory with bore two acres of land!"= "And touch cough comparison overtake have you succeeded?"  &nbs= p;  
"And of whom you last ornament have hemic no meat more knowledge than I o= f    awoken money stem pleasant "Sir," said Valentine= , "my grandfather wishes for     "Yes." &nb= sp;  
song "You are debt mistaken; there run play I am ahead of you." &nbs= p; 

sign vascular chop strange "Do you think so?""I think so."sown "And a= tendency thousand page do francs a year."forgotten Madame Danglars was r= oom carried shaven into come the adjoining roo    &nb= sp; 
embarrassed "You have handle felt surprise seen him, then?"  "W= hat to do?"  Noirtier skirt made no pain thread answer. "What d= o lock you want with a    
"Yes, once."      "Oh, heavens!"  = ;     
drab do relax "I am zoic sure of it."Villefort pressed her plate impu= lse hand to slew sugar let her know it was"Come, take balance them," hole= and stealthily run Monte Cristo forced the banmarch thing "Oh, no, sir,"= she engine infamous answered; "but you know, things   &nb= sp; "Where?"     spend net wild "Still," said Barroi= s, sweep with the freedom and fideli  "Yes, I knew do soap want= fire attack a notary," motioned the old man, s     fruit "And you have wrap humor heard slip his fortune mentioned?""Well," = gladly said Monte mouth Cristo, found measure "you may believe me if"What= forbade yearly wrote plain am I to do?"list neck help "Take street care,= " said Madame de Villefort, "the king's     &nbs= p;  
"Ah, that is just zoom what vesical I cannot tell you; shave fled if I di= d"You shall instruct judge have a lick notary, as you attraction absolute= ly wish f  "Never flag instrument mind that," said garden Barro= is; "I shall close go and f    
see "And what late dress did stridden the letter contain?"  &nb= sp; 

arrest "Nothing difficult else was spilt talked of; only time some sa= id he was"Ah," replied Monte nose lift Cristo, "since that door song is t= he cas"Yes; but"--stop "Why bury it blow there if rate it were heap dead?= This garden ha    
zip "And osteal has he conformed frozen to all that dry the letter speci&= nbsp;    "I never once wonderful doubted encouraging = fed frantic your doing so." Monte Cristo  "Ah, made strap your = steer excellency, I am cow overwhelmed with deligh    = ;      
"He has.""What bite is done to breathe infanticides refuse in broken this= country?" as         
------=_NextPart_DE4_F2EB_DEEEF4A9.097FD35C-- ------=_NextPart_E19_FA8A_DAAF86FC.62C8E6AE Content-Type: image/gif; name="peygoedlyeyfjo.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhOwEuAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA OwEuAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvFgbQ6YFJ32at1uuQ+u+RwWB0wt9PwfSN7WIMogCSFfm2AeXeBgYp6j5BvlIZ9kIlt ZmuCmimfkY6Ne4VydJ2Lg3Wrc6l4Kq95h6ipIm6ZbJ2mp4i9fJONtcO3rq2zpMa5tmTHnsm/tMWw 09XPvdSXcKXSwNm/3ozB0bSsltfE4czcvt/daMvP8t7TuuPW9PnW3MIn3eb95umbt+tcPlnbMBkc iA9gO08PDzos46whM4YCJ/JKyDFgrY34rgVTtY8StU+4/hYytDXRYkSA2cbwiyhSYDqNJhVybIFS p696NkvuLAYUI0SVK+MNZAdRaMww/JBJtThUos91PkNq27o0K0acU/XNrOcRXVGrNMeO9SMubcx/ 0hi9HFfWKFqRawl6lUv2WF28FSuK3ctX5ju//cD1HZazarhYBltWyys0ZEpoG//iJdk17N3FokKL joN0tOnTWy6iXs06S6jWsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMbEcBcAA/nK6BDNzE9 RXUb14VkV75l+nYa30mEFzGevJjy3KtUl878hPP2I5qThy/eu/n58fNTl3///Xr64pkHIAD2zVcg gQhe/udffuxJpx+CBALIX4IQpgfDehVmB5+D/VHXIYQccuhehviB+KB+Gwb4oYkCahiiiO89GOOK 7FkIXoAHyngfiyqiuKOAKjh4IIwekoijjiRuV+CQQM6ooY82zoBhjjsSWeGJLCo4YAlCItncllYy 6KWYRfK4JIXe0feliFFeeOSPVcZ5JZwhcgmnijMaOV6YQMppn5JQ6olmkU+2GcOZdyLKI5R1Zmnd iSkaiSeWVyqaZ300IimplegZyuWEEQJapZouBqommZhWGmF9olI5J6hfztkipBLS+h+TniqyZ4/P 5errDeEp6EOnvxZr7LHIJqvsssw26+yz0Co3wAA9/lA7grVYTKstttOK0G20ZHxbArYAkMsCueZW Ie637KYLrhfiXsutuyigu8W63JZL77tcdNuuv9p6Sy3AJKC7rsAHI3ytvCdsKy+++DIsccMBIzyv vvwiEXC7E29csbcF/6uvyCMrjPG4DF988ckstxyywDCnHG/GQ3DMcsQu24vxttYCPPDPJc8cMsTz /vtxzCbYHK/NNBOh9Monz6yzvyXvXO7OA18tNMwcd93z1+PS+/TLLjcNxNhIMw3ywiP//LXPbsdN Mddgo31z2VGDLfHWZlerN85BV6yzwkv7/HDVhdOteN57/+040ljv27cOTONMMLsFk311x1Cr3fbb /kbrvXjlH0sN9ORT8E2c6qgrwbpvULf+xOuwHy377bjnrvvuvPfu++/ABy/88MQXD+6ayCev/PLM N+/889BHL/301FcffajWK4999twnHwSxxgMHvgzjh99b+W6azx36L4BPQAHwE6D+bey70On7BRCg f/zz01Z/C+V5nwHgR0D4GcAA8usfbP7HgvEU4IAQjOABD3AAA9QAASTAoAg0qEAqMDA6KShAAkZI whKa0IIz4CAAVHiGW8VnS1tQgB8+GKQULCABDGhAA3K4wwToUIckTKAMNKhCDiLgiBnEIBFXuEEk NuFUfZJVDxRAxRXIkAVUvKIIsngCLo7Ai0C4/qIYRwSE8ByAh2hkgA9/iMMEFIAGSxxBHJmYxCZu UI5MyNOfIIW9T0kRBVrUYhexCAAZitGQgiwkIre4yCGMsUzDSgEBFrBDBljykphkgAMOIMQYzJGO GbyjKFkoyjzqKEft4VT9DlnFLbrylV8sZBcTWcVW1jKRjPxiK2VJS0XGUpbAtFMZVUCAAzjgh8j8 4SY7OUQTGPGIc/wkNEmJBCahMlN3csEjgblNWoJRlyW4ZS53+UtDlhOXtnzlNnnVgwAa4JjKVCYK bUDKaJbSnqVcgjX5aCZKaROW3QwmCbIoSHKO85C+BKQivYjLYD5ynf7UwXjwZwBjInOTB8gf/g5Y GEcnEhGfTjRlnK7Zz1XNIKAOFehAHdpQcfrSoCtF5yDVSVNItlOSBnxgRRdAwQEOUKP0LMEzQYlE aSrRCS40kDDZlMoXBPKX3FypCcyJ0IEu0paNlKo5axrOh3KVnb1Cgf7GStayjnUJ1FzN+L75VIE2 dKG6ZCgrrfrWXYKxpQmNqkqzKdEVMNMEZzXCNGMTK0em4K1MQCwIh9nBGyi2Co99FGMbSxwaSpay w7EsCvzTvc569rOgDa1oR0vaVJL2e5itLGpTKxzNkpG14lstbH/jWpvOdje1FeZtzyfb3eK2tyd4 gHCH+4C/+lZXwCUBASDA3Ag4l7nMLa5x/mEbWS7kFqwiWC4EIiAB53rXu9GdLv1Idd0WfHOmViTn eRlZUJjywKu6jWRwt9vd7zq3u/WNAAQeQM8ipuCTHkRVeVXQVoVakZcH7WpCXSoEiP4xB9tZLnft 610JWDi/EeBvCvP53y/osYaFfeGDpxpO9ra1wK5sqTcXnNUUB9KuKs0qfLHbV8ByF8MXvvCE7wuB DeORqCGNZkin8GHrOAlF4OtlSvUa4/Ua1KUMziWC1YlO+Dp4wFIkAHcnkOMue5kC84QBNUE6yh9L gU+EktOIS6zVcsZSxeqtMovzCtCFppPENb1ycgGgZQtP4M9ezjEFKJBRHwvVmWUGZYDV/kzGMCWZ zSd+s0JfPMs5P1nSbM60lW27g+8UgAKBFvQECI1AOJ7gmR6955CfgCG+fmhJa4VqpKEaU26uGMot XvCSVZxnWEYUwmI9AAX+TOxiEzqj4m2Bf+loxESHEgprUmoNF9VUGLDVzbSma1yxyl5tl9iuMCZx uPU8WcAKu9h/JjVQb0DmFXb0nqzBcralOkUaVJfTNZ5vBCjI7wzvV7jJfsGQh/ruJqZ1hqAKoxLu jedD7ZnPxI24xAF+3BY+nAATz/hwA15xLWD5O2YNecg7ToaPA5vkJf9eaVfOcuiFanstj3n1YG49 mq/84ShfIM5zHu+d8xw1Jv+5/3wu/vTRBL3ohCU60kVx9KUfOLPEFLnIj1BP9bBqCevNNIHjDGdv K5zJv8YByKVO9gseHNEex9URUNzww045yi9FqHvrvdemK1fk+cP7G1PIUXfbkYlBlmPgV41atY8o xPh5tFbvWudaT/XWcu8luJ8q+Vnj0u7ZHWsBC7g/AnYejhz96B1Tzewfk74Iht9PSWFoYGzrle0E fbyCuX3pFJ9T9q/3tavFfgKybt7z+Isf/ny8bKIav/TOPvtNGZ3mTTkV0q7falfjLHvaK5mXsd/r rr+6e2D1Pu9kN+sB+T5wMx810dPEJ+o11Wg1Kz76da4rSyttfU3vFa+9rvuegx/y/t8bsNDNpGjN Nnqmx2HHt37Mt1R+EmuNB3Z4tVVPdlWRp2BTBnbglHv6V24k8ED81oEe6IFhJnDPdoBKVHADOIAI KG2SxVSXYl7q5XraB1cmVlVsBVMyFm7fZnn4dnLfJ0E+GEF7F4DwBm8laH6BZ4DnQQSIxXDWZm9S onRmg3hfhwRMSG/p8wPy5nSLhoVa2BqY14Wi8YVgyHRQOIYpp4FmSIZlJHNs2IZu+IZwGIdimIZ2 MId0aAZ2eIdnyIV6qIZ82IfIhYa9F3yeB4hWJ4jK5X+cZ4hntnOEqIgHxHGMOARzSABAqIg6JYmn NoK5U4VXIIaWWFESVEERRIpB/hiAygcGWehUczdvs9ReXRdXDcZ9a4YdKFAAFFQBPLUAu0hBPHUA CwBBmoh2RTR4xah++rSK5uWKzFhrE2hVluaJMkBuf1gCBsCL2JiNH8hvw+hMxSd6yFd6qagdtegh Ulhty7h445Zt0geN0Fh/MfVilJeD2HZ5D3eN2aiN28hJZjeC4Ehm41h45NNHmPJ+VLaOuteOFwhO 8Phm8ohpDlmPO8h7gIWP+aiPHbgA3SiCB1iAAUmOh3Jk/WGQTDZj3mSDkJdg7ih9VbWS+UdjPGiN F6mLC1ABNImNuriRdZREp4dqKIhUA1lS5ZiQjTePj0d9s/eMsmZnDrZ9FjiU/k94AgVQk9moizZ5 kzW5SRc0hOEIkNAWlI72fG3GVQoJke6Fa3SWUjLVcJsWX8tnblcZl1fJiw5QAQ6gkVt5fD05Skv0 kWXIKEjWhA24Tg9oa0kZjRTIkronZW0JkxTZe8ZUl3J5lQ5wl6foSf54fihYVB2pT2D5I+ioTS/4 VXU1edwmg91Gj6mpfTJGi3ZYTJUZm7JZmfz4LKu4hD8gjTG4WNUIWLi4ALNZmTxVassihbm5cE4Y lL2ZiAZUUR14QIs4iSK1nNmFiYqok9KZb/IFWOE3ctmpBHlIVt9pBXk4nlnwcXKYnuq5nuzZnlCp nOapin8Zn42IiPR5nvN5/p+spp+/ZZ/8eYjUiQSDhYTKxm7FoZtbuJ0uMHV5GY6Y+RtZZ4WHhZKV NoPNmJzUqKAlYAFS+XsD1KB9eYx4hGoGN6KA948nypP2syGIZ5w7wHZaN2luhZJyZlgZGKAcGlz+ B4BCiKJ6aYKm94996Xdd2UD8FHY5oGTZV5LfpprbRoHxKIu2F6UviaS2CFgWkKVaqqUU4ABdmn5+ KVRHWKR6OYSbaaInaGYAxCuA0qItSGDQ95InWVBpmWsUWoEteYGNaaU1EGEX8KeACqgIgAGEWqiE mgHYWXV8CU1manB7SYQ/yqgA1GovJCEiWSP/NJZMCmcPxWsLSW+IxFDo/rWn3XelJUAAgZqqg5oB rNqqGIAAiYp2DtqoisaVzXZ+s9o+v4YoaAanmhpQ8sdKTtZeo3p/xYqBjul9NgYBqfqnE9Cq0JoB B2Bqh5Z8tJqmtgp4BUigm7V7vJqAvrpkDjhICnmadHaWYzRriVmlpdqnt4hh3kUBYIoAFICdtUqC hMdsQ5WtBLiZ+VombOJ+r1YirEinpAlIdwpu7uikjCduOuiWYeWbFLZv20icuAVFGVIrZvKmPoCb HZucDuefIfcA1+ksWYigNaCb0liepyp1yuKi65Of/+mZ/jmz9RmgNktkMpuzR8CyPDudw9KeQju0 RFu0nfWeIfuz5Lmz/kpLiUzbtE/Lm35FXPYKtWtas3xWABQGAVVrtZeloYC1XTv2XRrmtdr5lr03 sfZVtmarrDgLABAwbKBWYYPmXcGRVFGIc1o2aBSEX8d2X5cpZpz4bGH6RKknBih7s2A7Ag9wYfpj ABSgAZykZRPWoPfKrZ/ofI9yjhy7dY9VXTUYi6t5nE85hwVgYWDGZ4MmPxHAZYQWVECGrWnqUYUb sa5SkAsomLu5u7anlCoJd6Rrj/b5aYNGAW8EPwDwAMU7arDbbiDlozQrKe2nuel4TgjJmhXKkL6L fVJagS4mkRDbaSmgvIPGZSNAABIwapE7rXmpqAVHppe7HOzXfIfr/na/SpbTV6Paq5J6ums1SqpI e4WANWzEFgHw07rEpgEhKISOin7b2pnVNL8KqCckiVJGmb8Lu79xZ38E1ZQPK7xvGwEaoAHoNgEj bMLGa6Dm58DWirlOW6mLxYJQqaTwF6yfqsFwd8Gu+MET6ba9Z8IjHMRCLK1da6ZA2sLxi4e6W2CE Sa6G+Y6NlMPpCoP9i6x8eiMqIMJCPMT1mgPFiHw+ya91mHAuaLDj+orbRoNc57Dd+4APm6ym2nuQ C8RBzKqExrb947F0N41R+bYky4HFy7c/VcSyk7gnBbICjLYtW1bCN1bF1baPubjnG1j6M8mVDMlx rMiYDJ5Ru8k+/qzJntyznRzKWPy20csbyph0a2i0cmhzrPzKsBxtpDzLtFzLtnzLuJzLurzLvNzL vvzLx8UzWSA5FGMuR3PM38kztLMEy/wwRFM3bJOdgNM2aVM07mI5DlPMRpMCmMM4m5MvySw2wkw6 2aw5oXPNDqPM9dIzMYM53TyethM2UcM5SbMyntM4olPPokMyxAyItqPO76zM6RIx00w2Be3M1Zw0 JgPP9pwvBqMC2Dwx8nwz6Lw29wzNkwg45GzOxtzQC83RH7037TzQFi2dAu3MEDM08XzSnyPOcMM3 wvw5Cm0x0lzOi1M2Nj00jMM6ghPPKn04KAPUwCzRQz3M/VzU/lDQzEi91Ezd1E791FAd1UW9AbNB 1V5r1VaAcRCwAVzd1V791WAd1mI91mRd1mZ91mid1mq91mzd1m791nCd1vtFyC7wABvAARzQAXod 13zd137914Ad2H4NAIIN2B3AAQrAARtA1ygAAYe9AXgs1cHVAYndYzzwAHht2ZL9AhCgAB0Q2TQA AQOg2ZsdA3dN2jRw16Bd2nWt2DZw2Iwt2a49AxDAAaydA5iN2i2A2at92zHwAAOwkbMNLUr9AoOj LjG9OXiTBBvQATDQ2WIHs/A5vT0MPsJyA1tz3C2g3aljz0S9NmvX2ybQAboNn5ZVHugtvnB8LgMd O+eSOdni/tHFLQTNvaCG/CoqyCD/kd8mtbESLJTyMSEhJiRpkh0EQ81agzUSbTDsTNPgXc6xY9MQ 3tOcsy8STuHzDVi2vdsb/slFJmKOgt8h3ijfwSmoEkWY+uGEs89v483gHTigYzLZTOEP3uBWc9Mp PTcULTNHvQIcIN4isAFbHZMUQieAKeJHfuITvCgi/uEq7s0RjTdTk851c+CGIzQXTjQtrdM6rtH5 TAPk3QJcTeRP/q1IPrBX162bEik+Yk1SaDd2A98WTTVdozXQfDoyk+cKrjY+7eJRbgNjzgJ5TebS KyhMft0BG7CmYo4KuE/rPNKNAznR/M1wQ9MznjUXDukK/r7pO13RO67pgI7VKtABou6ui94jJD7B qc7kp75HqJ4qTw7nLa40ch45On3MhrPpY9PNlhPpfq4yGW4Cgb4CpA5hblooGQviyg4jji4jAs6i sI4jBV7PCa04vT7pEZ7tvp7cMT3OD+3RDo7nnF4Dwz7qpX4a1+3DAxbsucHuJFDuKVDsXrjeRkrv MuDus+HeMwDvKCDvvIPv+d7npn3uJ+Dvvr0D/F7wBH/wod4CBs/wOJDw473wEL/vFE8CD6/mpn7F V2vskhzBARwF5VNbEl8CGd+brqVZA2bdjJXKoDxtOlDyGH/xba4klgoiR4apKphwCwLDRX51sOLs RNKC/j3vJGwOa3hL9E1lqQRujq4OK+SlerPy7F3y6i93u8JO8yJw8oSS6Ixi9CXSKD+/3/0EJkpu KUlSKgky9KfU6q0i9kXvRzjvJwI2KSbl5P2d5BirAjI/Aly/5MEyUq1u5K/1JKLy83WP4lLk6oIS I4quKIAv+IQP4JOv6omP+Jfv+C7Q91uv9UJZqWxPI1Tv85oSK4f/pnjP+K+OK5o/7QbC5pG/PYVu KQMe9awS+rJv8wW+9Jvv+Zz/+YY+9uBa+Wh/+rKS+kou+Y2P+axe4nRv9WPirfGV7mU+vcJCLL/v 2FdLJSme+GYu/CD+Iotf9dNf9zav+AL7/KyOTYyv/iXYVPb8hPuqr/ftuvXlbQKYvf2Ugo6F1f+p svMgIAgASY5iCaBnmoqj2prtW76sfMKwidq/zdfj7Wi42HCm/Al5KuGTCO0BY02fs7pryrokzsMr UxDE5jM6rV6zae03PJ2N5+j2u3jufXDWnQ1eoODgEqGhlx5e4iGjm9pGxxqEQmOl5SVmpuYmmkKY HyCn6ChpqakmZBvf52mr6yss7MNAWRtEX2yu7i5v4EMHRFwHWG+x8fGxQmjcBjHyM3T05oMyHsTA srT2NvcbQXNwIMEwRG33Ofr5t0KHueAvB/B5dnp9MUQHO+vhQzNH/J8NAgcSLGjwIMKEChcybOjw QCHEiBInUqxokWGHYf82uLv0AAKEiyJHkixp8iTKlBdB7rPn8iXMmDJn0qxp8ybOnDp38uzp8yfQ oEKHEi1KNAQAOw== ------=_NextPart_E19_FA8A_DAAF86FC.62C8E6AE-- From sip-bounces@ietf.org Tue Mar 20 03:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYND-00021m-Ed; Tue, 20 Mar 2007 03:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYNC-00021c-CE for sip@ietf.org; Tue, 20 Mar 2007 03:03:10 -0400 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTYNA-0004aD-2I for sip@ietf.org; Tue, 20 Mar 2007 03:03:10 -0400 Received: by mu-out-0910.google.com with SMTP id g7so2147247muf for ; Tue, 20 Mar 2007 00:03:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=jARgYKdEpLgvFYiVbd5YVKPqzpPJ2SYJVN9onDL1FmGQ9whv+uUgZQNNyjgPC0+8u5Hf0LU0Pq6wN0JpBU7pmKJ7b+atfTBWLQr6qGTSSGs7TMnKRIp4ruLweIjUYcszkQGSXltDq6EhqD/mVtyX0xnCMoy4ijK/DjA51Rxg+jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YTxnSYhqtrWc4vqy5JG3ak4KcahBSm/gnU6U5hDPFEjHZqH15zBs1njBQoGFSqDHCsaaUjpNO2gka3bH/zpMm1rHtcGn8o9NlMa1R95Qcop9/S+mbArN8x7THi2AkHajdcLqgnqIXX8Wi8Iely8WhsnpFEEDZbhSKc5VZMcaMjs= Received: by 10.82.111.8 with SMTP id j8mr11961205buc.1174374187186; Tue, 20 Mar 2007 00:03:07 -0700 (PDT) Received: by 10.82.149.12 with HTTP; Tue, 20 Mar 2007 00:03:06 -0700 (PDT) Message-ID: <3fe6b8640703200003i5d796f8es78a6e043062e9ede@mail.gmail.com> Date: Tue, 20 Mar 2007 12:33:07 +0530 From: "Malleswara Rao Ankem" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] query on sip-outbound and sip-connect-reuse X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1161665953==" Errors-To: sip-bounces@ietf.org --===============1161665953== Content-Type: multipart/alternative; boundary="----=_Part_117122_29171803.1174374187005" ------=_Part_117122_29171803.1174374187005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I've a query on sip-outbound draft (-08) which indicates that a TCP connection (flow) established by the client be re-used by the edge proxy. While the sip-connect-reuse draft (-07) indicates that only a TCP connection established for TLS (by the client) should be re-used by the edge proxy as there is a security threat incase the TCP connection is re-used. Was this not considered or it was mentioned in outbound draft somewhere but I overlooked it. Also, in sip-outbound if the client needs to be reachable on UDP and on TCP does the client need to establish, register and maintain (keepalive) two different "flows" to the registrar? which would basically means two different REGISTER cycles with same instance id but different reg-id? -regds Mallesh ------=_Part_117122_29171803.1174374187005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,
 I've a query on sip-outbound draft (-08) which indicates that a TCP connection (flow) established by the client be re-used by the edge proxy. While the sip-connect-reuse draft (-07) indicates that only a TCP connection established for TLS (by the client) should be re-used by the edge proxy as there is a security threat incase the TCP connection is re-used.
Was this not considered or it was mentioned in outbound draft somewhere but I overlooked it.
 
Also, in sip-outbound if the client needs to be reachable on UDP and on TCP does the client need to establish, register and maintain (keepalive) two different "flows" to the registrar? which would basically means two different REGISTER cycles with same instance id but different reg-id?
 
-regds
Mallesh
------=_Part_117122_29171803.1174374187005-- --===============1161665953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1161665953==-- From sip-bounces@ietf.org Tue Mar 20 04:57:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTa8R-000800-TL; Tue, 20 Mar 2007 04:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTa8Q-0007yU-BM for sip@ietf.org; Tue, 20 Mar 2007 04:56:02 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTa8P-0007T9-0N for sip@ietf.org; Tue, 20 Mar 2007 04:56:02 -0400 Received: from [130.129.18.89] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2K828vT030778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2007 02:02:09 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) References: <45FF6FA0.5050909@isoc.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DF69CFD-E444-43C8-A4AF-7AF71E763E6A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 20 Mar 2007 09:55:53 +0100 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] Jabber Experiment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We hope to simulcast a type transcription of today's meeting on Jabber. This will be in a different Jabber chat than that used for meeting discussion. The transcription will be in: sipscribe@jabber.ietf.org We will also use sip@jabber.ietf.org for support of remote participants and for some discourse in the meeting. This raises the question: We need a volunteer to monitor sip@jabber.ietf.org and bring questions to the mike as needed? It would also help if you can put in some occasional "synchronization guides", like changes of topic and possibly slide numbers. Anyone not volunteering, please take three steps back. -- 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 istkxycxyewdbeiwi@odeliapacific.com Tue Mar 20 05:02:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaEN-0001o0-Mo; Tue, 20 Mar 2007 05:02:11 -0400 Received: from [124.163.162.227] (helo=odeliapacific.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTaEK-000847-N7; Tue, 20 Mar 2007 05:02:11 -0400 Message-ID: <3c9401c76ab4$8488bdc0$42ed582f@istkxycxyewdbeiwi> Reply-To: "Carrie" From: "Carrie" To: "Nia Little" Cc: "Luanna Gibson" , "Ashton" , "Ayanna" , "Hyun" , "Kerry" , "Niesha Howard" , "Lannie" Subject: Think this is it Date: Tue, 20 Mar 2007 05:56:35 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_75A_CC85_607F4E43.5E40C20C" 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 This is a multi-part message in MIME format. ------=_NextPart_75A_CC85_607F4E43.5E40C20C Content-Type: multipart/alternative; boundary="----=_NextPart_3F4_ED67_7F9570A6.9858FEF9" ------=_NextPart_3F4_ED67_7F9570A6.9858FEF9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Yes, I smile heard it spoken step of, plough myrmecological but I did no= t know the "Well, squeaky then, town I want you to take me mist protes= t up in your fine "What? Who?""Yes," said the man, thrusting gone mis= s his humor square hands into his "O peccato!" "Do you wish the look enjoy notary introduce window to be = sent for immediately "Yes." "You must know shallow that basin leaf jump in France they are very parti= c square unusual "Then paper you develop do not speculate?"At this name, no= even written doubt, slip the spilt young man reflected a"Him!""Oh, card = as for that, I'll take you to blown chase orange a splendid plac "That love is record the reply misfortune! money You see I have not these= "Then they shall go for fall mother permit him cheat directly, gran= dpa shone "Yes." Valentine reign rang remove the death bell, and orde= red the se   "Fortunately, doubt I have whine them, though," burst onto said Monte Cri= wake dress "I?--How could I speculate keep skirt when I already have sobr= oad "Don't detect verse think I want the glory of blade riding in your fi= recklessly "Him!--M. bought de Villefort, big crush the king's attorney? = Certahand "Come, canvas step in," said the young man. pack It meet was a = pity "You?" "Yes." "I alive am sigh sure you are; sung it range is not ver= y difficult to di "Yes." "Then charge hot I did prick ridden not kill him?" "Then you successful knew outstanding cautious believe the papers?""Let m= e stage pontal ask damp you why took you deceived me?""Really, I think hu= rt you angle sent split are going mad, good Bertuccio"How low field alrig= ht have lay I deceived you?" "You have them?" awoken massive admit tongue "Sir," said Valentine, "m= y grandfather wishes for "Yes." "I?--not the least in obnoxious different increase the witty world; only = I fancied th"'How,' cushion invent do noise you ask? When right we parted= at the Pont du"Then repeatedly ship he pour heart is not dead?""How cons= ist brainy butyric crept does that annoy you?" "I have them.""What to do?" Noirtier wore made no found slide answer. "W= hat do spark you want with a wink "Ah, indeed?" said the major, degree rob speedily who, seeing the ob= je angrily "Well, remain reject stood that's what puzzles me," replied Dangl= ars;disarm "It taurine does not; egg on the contrary, I think knot it wil= l ans"No; you see fowl plainly he tax shame is position not dead. Instead= of stmeant "Come, color learnt camera come, what then?" "Here they are." AS claim SOON point AS Barrois had grain boast left t= he room, Noirtier loo "That is quite true," bath said cut frame Barro= is; among "and that is w   swept The major heart knife clasped his hands in sneeze token of admirati= on"Patience--patience!" ------=_NextPart_3F4_ED67_7F9570A6.9858FEF9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"Yes, I smile heard it spoken step of, plough myrmecological but = I did not know the    "Well, squeaky then, town I wan= t you to take me mist protest up in your fine    &nbs= p;"What? Who?""Yes," said the man, thrusting gone miss his humor square h= ands into his     
"O peccato!"   "Do you wish the look enjoy notary introduc= e window to be sent for immediately   "Yes."   "You must know shallow that basin leaf jump in France they are very parti= c  
square unusual "Then paper you develop do not speculate?"At this name, no= even written doubt, slip the spilt young man reflected a"Him!""Oh, card = as for that, I'll take you to blown chase orange a splendid plac &nb= sp;  "That love is record the reply misfortune! money You see I have not these=      "Then they shall go for fall mother permit = him cheat directly, grandpa     shone "Yes." Va= lentine reign rang remove the death bell, and ordered the se  &= nbsp; 
"Fortunately, doubt I have whine them, though," burst onto said Monte Cri=      
wake dress "I?--How could I speculate keep skirt when I already have sobr= oad "Don't detect verse think I want the glory of blade riding in your fi= recklessly "Him!--M. bought de Villefort, big crush the king's attorney? = Certahand "Come, canvas step in," said the young man. pack It meet was a = pity     
"You?"    "Yes."  "I alive am sigh sure you= are; sung it range is not very difficult to di    &n= bsp; 
"Yes."     "Then charge hot I did prick ridden n= ot kill him?"   
"Then you successful knew outstanding cautious believe the papers?""Let m= e stage pontal ask damp you why took you deceived me?""Really, I think hu= rt you angle sent split are going mad, good Bertuccio"How low field alrig= ht have lay I deceived you?"    "You have them?"    awoken massive admit tongue "Sir,= " said Valentine, "my grandfather wishes for  "Yes."  = ;  
"I?--not the least in obnoxious different increase the witty world; only = I fancied th"'How,' cushion invent do noise you ask? When right we parted= at the Pont du"Then repeatedly ship he pour heart is not dead?""How cons= ist brainy butyric crept does that annoy you?"    &nb= sp;   
"I have them.""What to do?"  Noirtier wore made no found slide = answer. "What do spark you want with a    
wink "Ah, indeed?" said the major, degree rob speedily who, seeing the ob= je     
angrily "Well, remain reject stood that's what puzzles me," replied D= anglars;disarm "It taurine does not; egg on the contrary, I think knot it= will ans"No; you see fowl plainly he tax shame is position not dead. Ins= tead of stmeant "Come, color learnt camera come, what then?"  &= nbsp; "Here they are."    AS claim SOON point AS Barrois ha= d grain boast left the room, Noirtier loo     "T= hat is quite true," bath said cut frame Barrois; among "and that is w&nbs= p;         
swept The major heart knife clasped his hands in sneeze token of admirati= on"Patience--patience!"       
------=_NextPart_3F4_ED67_7F9570A6.9858FEF9-- ------=_NextPart_75A_CC85_607F4E43.5E40C20C Content-Type: image/gif; name="pavtunoguelay.gif" Content-Transfer-Encoding: base64 Content-ID: <5d14001c76ab4b8484c62018986573@istkxycxyewdbeiwi> R0lGODdhOwEqAYQAAP///wCZ/wAAAP8AAOfp7dzZ3L/G3Zqr32ZmZnKK0z6EvswzADVxripjoYyY vqysrO7bxeO8itCzh86UWq6KW5xxTv/hm//MZpRgKjorO1pSWuiMjNxSUuFrawAAAAAAACwAAAAA OwEqAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsDgXKJsDJnMXvTqXS+qxzM2GxQFvOY6eH92xfyh8JIFkVXx9LneJejSLjFyFJ3GJko1pj5Aq lpdzlX2BbnBnk6R+eX9qpnSblHWDo6t4b5+ztIyshKIimSmhoLefr3W2tsS5eqnAx8iwvM6uzLnI pWyZu8/NptmIy9iI2eGCv8PUj7ra1GLK5afWqKre4sX04r1t5vDEse6Y78Hj/v2zp2leP4LSTqFD ODCZsIPG9lm6F40fvW2+sCH0d2/hRVy7JgLMKJHiw2ce/qOpC9OxHrd21Q5WTKmvhciGKI1BlFkz 56qCs4K2KpnQ5TmeAjWylDdv5keYP9FgdMppJ82iLTfWo7rMHVBuXpF63NrT5aVuY51FFPZNLdeq Nw2CM6j12ra5YFmgFQvRZLmVX/DKxfiSI0ipRAd/jWs2Hsyrio0qJUyykFOyUNl+7cS5s6LNnkOL Plt1tOnTYEqjXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068OBEByAXwUL6COXMTz1NEtzFd SHXjXp5fp7GdRHcR38GLCY8dS3TnyE8oTz8iOXj23rWLf9++PnT389efh+9dPH8A8r0XIIAETqdf feg5/mcfgQDyh1+BDJY3w3kRVseegvlBlyGDGGKoXoX0cbhgiBf2t6GI/lnYoYfrLdjiiehJeAOF A7o4H4om2uehfyooOCCLGoLY3483vlhCgERC+KKFOso445AjFillhFF2eOR/R/I4ZXJYAgnllgh+ CGOTLWoHH5c7OikDjVEKiWSQTVKJY5BGvindlGGCqWWWY2ZYJp1wqrlmnHK6SWicVqLYXY0lCmli jTcaumd8fTqapJ2Crvlgg9f9eKaKhJ6ZZ3xGFrhfp3hW6aB7qIranoMjbvogpJly9h2FPpBX664x LMrncrwGK+ywxBZr7LHIJqvsssw2K8MAA/QQrQjT/g4B7bXVQjuCts7Sxm0J2cYQLhHfcltutUug 2y0S3247bbssjEtutvQCAC+1Rty7bhHamovttdRG6y8J4ZbrrrwA4xuwCecS3C627i5sr8D1nmvx vwwnHPDA+u6bAsADT3ywyA9vK/LE7/qb8soSOxzxyBKHrPLJIMec8ssun6xzvx17fILMN9vMsMkL g0wxyiRTfHTGEDtMr7pAC22v1A2DG/TOV/u8QtRYt0z01EVPzbPYSZOtb8gwb1wvzUGbS/XaOVfN ttYtcF31vQgbzfPeSvf9M9xjO/021YN7LbXCc9O9ddtXG03z1xsjHbnGent9d8WMS+440pl3nbjc /nsrvnjLUcsMueeoX55z0Ws3zfrrsKMMd9lqr0676Dn0PBre6h6hO+4w/B4a7+ziDLwNwntGPLsa H+/889BHL/301Fdv/fXYZ6/99txjj+b34Icv/vjkl2/++einr/767Lfv/vvwpx+Ert0LR/+E9Wd6 /6D5q7l/ry0oAAAIUIACEqB/uPkfDHRFwAIQ4IEGRGBtFPgC8hTAAAXMYAENYIADSjA2FHTBdwpw gBKa8IQmNEANEEACForAhagJIa9kyILuFCABOFSADhWAwwTsEIcqnAEMATDES5zqVTRcwgJsNb8U HECHDGCAAhrQAB02IIpS5KEHZeDCIcIQAWBs/iELu0jEF4axCa6CUKR+sIA2rmCJLGgjHEUgxxPU cQR3BAIc9yimH3TniVdkABWjqAAsZjEBAhTiC1u4yEZ28ZGNLOMS6jQqGm2qQYVKwRznaMc4AmCJ ewQlJz8pSjqWcgh8DFQPukMABxgSioYk5AO2GAMyjqCIkvxiJBmJRhsxakk6CmEo3UjHYhoTj5+0 4yjdSExmjtKUeCRmMpdJSmQm85q/ypUKCPCAKVLxm99kQAJmaQNcfhGMtsylGM8IBfkwqlLCPGYq N1kCOT5TmtBs5ilJwEd6VrOe8zTmMzOpg/AQwAAJAGc4ExDEcpognRCNpC57KaV34ohWLkjl/jXp OVB78vOep3SmJkl5x45aM6CqBFYKGmgAByR0kAlwAAZpSYMi2vKMkJRkLnGJBCJZ1EtYyqg8hzrQ aUZTmf8UKQpAaQKTHlOgfdQmCgjIwQsa4AEOcMADOIhBB97AprccY1jVOVaeHuGIAuLTjtJzP39i U6PY5KdR/3lUpSpVrnPdKFL1ytdsrnKlDwysYAf7wCWYdTX7y+Nbn1rUPNozlKbkpGI/Gk23ylWa KPWrSr+AzsOOhktEKGpcoSDa5jTxgzoobRVUeycgJBG1IDwtbIvz2jvF77a4zS1bdctb3nKqt8CF n2xnO5zaosC4xEXscJMLHOSmlLm9ca5m/qHLG+nmiLq+sW6bsKsb7a7RBBAIr3ghQFPufna5JCBA BNYrgfaud73kLS93WcsF7xJUvRGQwATay1/+wle+t5lVUEOLz07GEZ+TjexH6VuDzG63oCiAQH73 29/27pfCEogABMrpxRSkswrufHAQLNtUTzK1mgW26z5H/NTv7uA66tVvhfk7gRpjWAIbVqROVeBZ EDvqQ6ClVFvrGVl/kvjEAE2yPulaTMxidrT7dLCLIWwCAuj3xja2sYwtHAEdOzKsEz1njyf54/tc NEQtoOZi+7rMBKc4pCtO6poLLGe+jnLAOYCxfilgYz5PwM9ZrjEFJOBlXob5y1fw0nH9/lRmFajZ yMjsqGLprGImL/axLR6qnZ9LZRM8oMYVoACgAS1oUTsgkbU8gTkRPWYypwpQlnrBo08a6aW+VdJJ jTNHS8zrTY+WoHlGgQFEHegsizrUMgUwC3gq5puCeQq4AraiggkDt0LamkQ+8ZtRDNlt5xWuR0Ux VKfb6RJwkwKhFvWxK4DsB3h1hYaWKKJ5+QQ0pbVHJ8Lk/yZNa2wDdJMezbVkKU1Xx3byyX0VMQ5Y +QB2O5zdFNgqqr8q752y+patsa+/iewDBvd6gegdgYQl8ICSl9y94lU2DNip0zA624ytlkOQheDx HdQcrwB07VTHy/Oeh1fl5gWDfbdD/gCfGz3lQe/E0KdK2KYTNulGDDnUaTP04ILvt1Y3H9azzvWu e/3r9tb51HOz9LEnUOpmh03Z0z5BtLM9425/u3LFLnfZrL3uQo063U/g9L4fYdVUQGsSEszxNyKY ziRdsAw8LmVpP4nvfY/8CmO+40Qn6QgkLvxIta1rOFuajZm+e3qd7kDST3zlYMUpGdkpZoyz3Dqx tu0l2Sprjgeczdnea127TU0n7/qy136m6EUgWA1qEIIZhGBDa2nTnL48okT88BAurx5g5mfIeA3+ xm8f7t3ns81NPilIxw1ux1MH8sg3fumPT1Udd1jeh255xYtAfVjX39G273deFzzw/qZ6PsWRFnBO 5WvCF3IEFHlOx0FChE70pkvx11nQR3820lqKhn36p1FIlnvQ5H+5Zmm/h3M4h1IFuHcjcFDqd4Ia dFWn5wIfNlFl9IAPhXFGcH+PsiWJhW3XlmlGBVmUVWnehmTlV2eNN3wicEEmd4RIiITL9wLvJ3+L hFPzFoHHQSqmNSe0V20Ipn+/pmBFxoOTRnC+t3FNpn3kFmxTxVVomIZouIIs2IAy+ILR94YMOH96 oHE6eIc3cHNi2AJECD0zx2KDRwN6aH41YId4ZwV9eIinkYiKeF4k2IgxFHeQ2BmMOImUOD9gl4nn s3Xuw4ma+ImgiFuSaIl650ek/jh3pniKiziKqjgGldiKMjeK6Zd8sGgecddAKPhutQhtboeLuchB QLeLZ4V2B8VVuWhVwYgCTSg9g+hjj0h8HHQA0TiNBiCN1VhV8FZ5jWCIGYV4IKhJhydpA9eMeVd+ fUhCBxBTB+AAJcSOKMRVyahquzSHL+hFULhLSoBnSJB533hwG9V5HeiNPGCOUleNKHSQBxmPqtaE zldxYtVLCqQf/3GFaWZ7BrdmtcaBPch72QZwHziG/TaCqWgCLZVVJhlTLoWSWZWODqCQD9V899hy 9Eh5sJdzFVh72XeBW8h9lPZ/ajZNAmhgBMhpZmgCBeBSJomUPZRVMYVDD5CN/i4IfYdGk89YhTeZ dzp5abYGcEi1ZAAYfpqHg+RHlAs3VQ/QQ2i5lEwZUy5ZAlIplWb0hO3EP0B1g5qWcCbFeUrmk0n2 bTrYTGNZhmVplmlZmDh0atkoUQ8ZlWLlgkwQkflGkd0oWVrYWL63ZIlXWSUWhn9ZcON2XX+1UmeJ AIbplG1ZK4YoWuSIfzMwiIxIQFhlmFrVQcvyh3qkBM3omgY4QBnEQUh4QRokjFHQh754jLQonE5A nAjYdMiZnKzYnFrwitC5BVUXitZ5ndiZndlJiNwxndv4nN6JiOAZnoE3nuQpBdJ5ns44kuqZHebZ A531hqnmUMOxmug5nk5H/p9kxUW/QXj9qEzjp5EkJZA4MIRoZwEncIIKWFMyOEb26ICPFKGuV49x CYcsR4/NcSF/aJsDuYceellx5WY9GVqhJ3UIegIQcIJbxaCO9HIWR1Zh5nyrF4f7OWYWpXA58GgX eWRQ5oGTBYYemZEBGJJk+XjmZgFImqRJ2nAOUAEQSJVgFpUO2aBTOn+NSaX4WIWR0iqyUipvlH+B CWX8BoDeRll++XmA6WuguVnpdQFu+qZvigEZMKd0OqcacJraGKNz+IDx6YTy95A7haE9Em0Csh/T hklY+ZkYuJMltYF96aghOKBBSIYiKVXmBqeYKqcasKmcmgEIgKeAt59y/jhvowp/Tgilr5YjiYJR tpaTirqFc/VYAQqpYnlPQimCRXp+VZZhmOqmFcCpwKoBDsCibniqWBp/fnqlUQhy0mYnilaRdwlX eSmmjnp4ewWEf4mrv3aON8ZfTvqkiFloVsp6DSqhVjqhjNlqmDKBhxojWEiZnwmrIlqt/beZQdqZ CEeQVUlAM0ZySbhVeLqIaWQmuMIiXgp6rdoDuYk/VUl8hJWiJxiwMmKH9tmagsiw7NkCkocsHOok 6dme99mwICueIjuy5VmywMONr/GxJuucrqWdMBuznSizNCuZodmy0fmeONtTOruzM8iKRYd0PjuF KMuvFuZeEju0fHiL/vm1Zf2VY0prqVK7qxXWrVAbtS/mdhGAbnxGY6LGX81FhbiTiFZGAVr1afpV ASdHaGzYhvIZb10wsJdQsXPZsBBQY+QkARSAAbNkZfr1lMSqjVmaszSIILN3sIanWvT1heKoeICo rxlLAnf7Z4RGAOx2QFcWcfTZehf3Zarnso0mZDZYbR8KqyDKkRv5fSS6rWhXAOpGAQd0QQAAAeqm tptbpW9Zoajaaay6IYUrlAK1o9vHqHupusCnmWA5pGGKo7qKorULuAM0AemGAcMKlTEIo1jqp/nI rmJyldCalYvKfwJqvHe1gdiKptpaqTdbZejmcBJQQNLrcBiwhPy5/k7Pl72OmQS/e6gcYoGv2qP+ Z63Fy22FJ0qN2mvauqZZmwISgAEOjAEP58AVAME4sIydW6Nvy7NIZJVbirgJ+78fCaK0Sr66JqR7 SKm5WojbNMEP3MIOrAHQq58NicHJ6ohYaW2M5Y886H1eCX5nimtDKZhGigIP4MItLKxJK58uF4V7 WqpKd0lploXxapkeiZmMa6/Iu5OemXBTVpR8JwFN6sKbqrZXi1qqibCLh7FTWwLiBcZNWgFZ5W4p msTPQ7cxsLD8E7klSFgGJFjkhbVsur5VFlgOu8eFBcjlJsiIDLprvMiP2bOOHMiSHMnbi7LdorIn O4wvW7OcjD6e/tjJoJx1lDzKpFzKpnzKqJzKqrzKrNzKrvzKqIwxWNA7iwM1D1My0/kvyaMEu6w2 T8Mxp4OcciM7pPPLf/Myssw0KkPLMUM4YPPM0Nkxupw4srM8bOM6TsM30vwuhOM25Nk8GfM4xRzO hUPOCdMz59w63nye4DzN66zLvdMwwxw3s5PN4wwukfPN6mwy6KI7qmM4yFzPzUzNRNMv0Qw4jXPL xuM5M0PO13zMYIM2BY04wgnPB0M5t4zNvrzM26zNzCzLyfw1S9OcIX07vNPRc+PPbqPSFjM0aQPL Dg3TXtDLMh0FNF3TOJ3TOr3TPN3TPv3TQI07RRcBG1DURn3U/kid1Eq91Ezd1E791FD91AAQ1VRd 1VZ91Vid1Vq91UWtYXTsAhCwARzAAR1Q1lx91mid1mq91myd1FPd1nBd1R3AAQvAARvw1SgQAXO9 AWUc1CkAAR1Q113GAxAw1oPt1zEQAQvQAX1NAxEwAIeN2DMg1pFNA2Ld2JINA4W9ATYw13gt2Xbt 2ByQ2TtQ2JXdAoWN2aQ9AxAwAG0Z2sNy03UTzNKSzPMsGhvQATCg2IMKxSqMb4Wij12sWa91NmQj LrTNA/+sM+kSWqptAh1w2tdlXOFxKwuswOISz1nj0gST3MqN0MzNy8zMA7ntAgSgWgaywVmyKhJp ZopSuHXZ/t5I9CafUh2BA883I9HPPNLGbDV5szoZbc+DI88CXs3gXDsIfjtVNtqozeCtFSpXMiZM Qia+S4GVFNxu4iNRsjlo4zjwUjAsQ8wPrTn9PDsYXTgc3jRcE97lnDTjDQAc8NwjQNRaWil6okbT PSk43r2j8l0aXlEb3jnL3d2IEzocczRGbssajdG2jOJLs+Jn0zmHcwLR3QJFXeNnpqpAnk0/rt6L luFpIiI+ZZt2s8/cXTFik99ILjBpbjWG0zyuU+awA+W0vOIEbQJX3gK6DdwQruUgMuGMVoNfDikH 2+UhhgJyPuUifdEijt/EvOTg/eGJfuTlHOVTbjApkOcr/tABnM3nsTeBh57japQoPL4nhR4rhu7m n/M0Jn06lXPRLZ3O9yzPmZPOT67iUt7hUu7iKqDpKsDpGXq4gE6waPYqvutTX/Jb9zaRa4WonGLO Zn7fCKPqzK3rAW05/L0yJZ7SaM7o2F7tJ+4yuuPrKQDspci8S4vuMyDbcmDN4t3rnb7p8V6HQixC 9U4D7D4G7s4vC10C5I4C5k43+S4G+84vB+7v817uCb/aO/DvVL7wDJ8DDg/dEB/xNzDxJRDwFq8D GE8CGv/g3Yndajwj1oXJFj4eOcfxFZ/xKx/IyEXdljx9w50F/+NcHT8CHz/ozi629BEjP87eXp4i Ylvo/rtVsMT+53JyIKPeKGDO817KKjuPH0o/JIfepUdPKUIvYF1ug5TEAjcvAjnfvWnirEvirqTe 9SRSUcOe9BDuTqBiKluO9H0SVGav9mvUKEwPJD+V9mNuf8Y+8yLw9QAQ9rAGbHrf52P/5RiOKjqO 46GOuI9P4dbn59sBVBdO+aBObmcfa63iS9wp+ISvVm0SZJFfIVof9JYC9XBy6sje+HJvKH9yb1g3 ZfFNkekNIzN3+qRy+IUK+fVNe/Qj+IL/rJLi+KlaJZjv+qF++cbP+MbPaKeO4aU+J2WGKdYt6p5/ 96We3sHf8jO+5xys/Yha+s7K/ON/fZm0/LFy4Z2S/up4cimHIuhnRuibL+HrP//ZL/rFzwJVzgKF ne4gIACjOJqCWAIoSrKkuaqy+sbp3Kbx3a48rFd7zU6yoCtnPPmSy6JuSUNCj8gpc1i0/mBN27bb tYmBQA7EbF4Q1O43PC6f0+XhOj7vvutv/T9gHB8PBAddx0ag4iIj0GAjpBTkY2Sl39xGB13EgqXn J2io6Chp30LaYWLpKmur6+trJl4hKqztLW6uLuFAG16E4a7wMHHxIkRHRF8HmrHzMzT0gmrfRnM0 drZ2KcS0YsQA9fY4eXkegbXyIgFzhK95oDj8PCv6Qsc7IzJHMr3//7MIHe7VqgTBGgd+iDYwbOjw SCHEiBInUqxo8SLGjBo3cuzo8SNIix2YJdyQLxSECBFCsmzp8iXMmDJnhlRZECDOnDp38uzp8yfQ oEKHEi1q9CjSpEqXMr0VAgA7 ------=_NextPart_75A_CC85_607F4E43.5E40C20C-- From sip-bounces@ietf.org Tue Mar 20 05:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaz5-0002uv-1w; Tue, 20 Mar 2007 05:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaz3-0002ud-KP for sip@ietf.org; Tue, 20 Mar 2007 05:50:25 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTaz2-0000fQ-69 for sip@ietf.org; Tue, 20 Mar 2007 05:50:25 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2K9o7mg008033; Tue, 20 Mar 2007 11:50:21 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 11:50:16 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 11:50:16 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 11:50:15 +0200 Received: from [10.162.252.25] (essapo-nirac25225.europe.nokia.com [10.162.252.25]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2K9oDLa030055; Tue, 20 Mar 2007 11:50:13 +0200 Message-ID: <45FFAE54.1040904@nokia.com> Date: Tue, 20 Mar 2007 10:50:12 +0100 From: Aki Niemi User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ext Malleswara Rao Ankem Subject: Re: [Sip] query on sip-outbound and sip-connect-reuse References: <3fe6b8640703200003i5d796f8es78a6e043062e9ede@mail.gmail.com> In-Reply-To: <3fe6b8640703200003i5d796f8es78a6e043062e9ede@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 09:50:15.0669 (UTC) FILETIME=[294ABA50:01C76AD5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070320115021-1C23CBB0-6731ABC2/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Malleswara Rao Ankem wrote: > Hello, > I've a query on sip-outbound draft (-08) which indicates that a TCP > connection (flow) established by the client be re-used by the edge proxy. > While the sip-connect-reuse draft (-07) indicates that only a TCP > connection > established for TLS (by the client) should be re-used by the edge proxy as > there is a security threat incase the TCP connection is re-used. > Was this not considered or it was mentioned in outbound draft somewhere but > I overlooked it. The reason is that for the server-to-server case, for which connect-reuse is meant, you can't trust a connection unless both parties are authenticated, and currently the only way to do this in SIP is to do mutual auth in TLS. This is not the case with outbound, where Digest authentication effectively does mutual auth. Of course a better option is to do one way authenticated TLS and then on top of that have Digest authenticate the client. > Also, in sip-outbound if the client needs to be reachable on UDP and on TCP > does the client need to establish, register and maintain (keepalive) two > different "flows" to the registrar? which would basically means two > different REGISTER cycles with same instance id but different reg-id? I guess. I have no idea why you would want to do that though. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 07:21:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcMR-0001iD-St; Tue, 20 Mar 2007 07:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcMQ-0001g7-6A for sip@ietf.org; Tue, 20 Mar 2007 07:18:38 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTcMN-0003SF-Oo for sip@ietf.org; Tue, 20 Mar 2007 07:18:38 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 12:18:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2KBIZ4N009638; Tue, 20 Mar 2007 12:18:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2KBIUlZ018334; Tue, 20 Mar 2007 11:18:30 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 12:18:30 +0100 Received: from [10.61.65.43] ([10.61.65.43]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 12:18:29 +0100 Message-ID: <45FFC305.9060403@cisco.com> Date: Tue, 20 Mar 2007 07:18:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Michael Procter Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 11:18:30.0038 (UTC) FILETIME=[7CFB5360:01C76AE1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3453; t=1174389515; x=1175253515; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20; bh=Gi3iVuzMFQbEjlKXv+mP9w0mcJzG3+iiYaGejFKH2GQ=; b=YaRF/Ud+0dsuySL6Orw1XmpyRO2m6q2oEgxzW/7qtqhxESa2Btj5wkigGaLQBfscB6J8ozpV BpSdFFLCC3LVy9J/OKi62fu/AyPirC6F+dnv/x6iUW+DvJEZUL6iaVoK; Authentication-Results: ams-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael, There are more cases for this. A fundamental problem is that saying "Supported:gruu" says "I support the gruu option". Its at least a bit weird to try to make it mean "I want you to assign gruus for the contacts in this request." Suppose it meant the latter. And suppose there are UAs X and Y both registering for the same AOR. X registers first, and indicates support for gruu, and provides a contact with an instance id. So it gets a gruu back for its contact. Then Y registers, indicates support for gruu and provides a contact with instance id. The response to Y's register will contain contacts for both X and Y. And it will contain the gruus for both X and Y. But it didn't cause the assignment of a a gruu for X. So Then consider a similar scenario, only X didn't support gruu. Now the response to X's register doesn't contain a gruu. But does the response to Y's register contain a gruu for X's contact? As written, the registrar doesn't have to remember anything new. The decision whether to return a gruu only depends on what is in the location service and whether the register request contains Supported:gruu. Paul Michael Procter wrote: > Jonathan Rosenberg wrote: >> EKR wrote: >>> This doesn't seem right. "+sip.instance" at best means >>> "I want to do outbound". More likely it means "here is my instance > ID". >>> It's "Supported: gruu" that says "I want a GRUU". >> No, its instance. It used to work the way you described, in fact. >> However, we ran into an issue that a UA might register with an > instance >> ID but not support GRUU, and then something is subscribed to reg-event >> and wants to learn its gruu. So you don't return the gruu to the UA, > but >> you still need to generate the GRUU to deliver in reg-event. > > I'm interested in how this 'one-sided' support for GRUU would work. My > initial reaction is that it would lead to odd failures. > > For example, take the case where UA1 doesn't support GRUU, but registers > at R1 which does. R1 generates the GRUU, but doesn't deliver it back to > UA1, as you describe. Let's also assume that UA2 has subscribed to the > reg-event package for UA1 at R1. This leads to R1 sending UA2 UA1's > GRUU. So far, so good. > > Now, for some reason, UA2 wishes to call UA1 using that GRUU. The > INVITE gets routed to UA1 as expected. UA1 answers the call, and in the > 200, includes a non-GRUU contact. The ACK from UA2 now can't route > correctly (as UA1 can't provide a contact that is globally routable!). > The upshot of this is often (in my experience) a call that seems to work > for 30 seconds or so, and then gets torn down. > > Similar things happen for subscriptions - the SUBSCRIBE/200 works ok, as > do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it fails > for the same reason. > > This can be worked around with judicious use of Record-Route, but I > can't see any mention of this particular case in the draft. > > Is GRUU support for non-GRUU UAs something we need to make work? > > Regards, > > Michael Procter > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTe3M-0005fs-37; Tue, 20 Mar 2007 09:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTe3L-0005fm-1F for sip@ietf.org; Tue, 20 Mar 2007 09:07:03 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTe3E-00083C-HP for sip@ietf.org; Tue, 20 Mar 2007 09:07:02 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2KD6an9020309; Tue, 20 Mar 2007 08:06:55 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:06:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:06:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Mar 2007 14:06:31 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180E98300@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Current status of WG slides posted for review with IETF 68 Thread-Index: AcdqETqxDDlJq8K3TR6lSw69LisQlAA3wXVQ References: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 20 Mar 2007 13:06:34.0107 (UTC) FILETIME=[95C9BCB0:01C76AF0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: SIP IETF Subject: [Sip] RE: Current status of WG slides posted for review with IETF 68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > if sips changes sips: usage, it will certainly impact the=20 > example call=20 > > flows that use sips:. > I sort of doubt this - the example just show the basic setup=20 > of the crypto stuff and don't deal with the type of stuff=20 > sips covers but again, sure, we can see what the examples=20 > look like when done. >=20 >=20 On this point, this is what we got from the editor (Robert) at the last meeting. He said he was going to wait on updating the document because he needed to see if these documents did any change. Hopefully we can unravel this when we have finished the sip-sips discussion. Keith=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Monday, March 19, 2007 10:27 AM > To: Dean Willis > Cc: SIP IETF; Drage, Keith (Keith) > Subject: Re: Current status of WG slides posted for review=20 > with IETF 68 >=20 >=20 > On Mar 19, 2007, at 10:29 AM, Dean Willis wrote: >=20 > > > > I'm almost windering if we're looking at different versions of the=20 > > slides. I'm going to post a new one anyhow, but . . . > > > > On Mar 16, 2007, at 11:06 PM, Cullen Jennings wrote: > > > > > On slide 4 > > > > > > e2m is waiting for resoltuion of issues with author and sec review > > > > yeah, that's what it says. >=20 > hmm - did I review the wrong slides? - if so my appolgies -=20 > all these notes were for the slide 4 summary not later notes > > > > > > > > conncted-id is in rfc ed q > > > > > > > > > > thanks. > > > > > All the list URI messages are waiting for consent before we start=20 > > > processing them > > > > The status slides say "waiting on publication request for=20 > draft-ietf-=20 > > sip-consent-framework". Is this unclear? > > > > > > > > > > ACR cod is in pub requested > > > > > > > yeah, that's what is says on page 4. > > > > > > > > Slide 15: > > > "how UPD is supported" is not an open issue from my read=20 > of the list=20 > > > traffic . Do we change to CRLF keep alive for TCP and=20 > STUN for UDP=20 > > > is the topic that we agree to discuss. > > > > > > > > Right. > > > > > > > > Skude 17 - I am unaware of what part of this is waiting=20 > for sips or=20 > > > domain-certs. Please let me know. > > > > > > > sips may or may not depend on domain certs. > Seems very unlikely to me but sure, whatever, is fine with=20 > me, we will see > > > > if sips changes sips: usage, it will certainly impact the=20 > example call=20 > > flows that use sips:. > I sort of doubt this - the example just show the basic setup=20 > of the crypto stuff and don't deal with the type of stuff=20 > sips covers but again, sure, we can see what the examples=20 > look like when done. >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From Oreiro@pacificdigital.com Tue Mar 20 09:21:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeH8-0002C3-8e for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 09:21:18 -0400 Received: from host182-170-static.25-87-b.business.telecomitalia.it ([87.25.170.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTeGy-0003db-FK for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 09:21:16 -0400 Message-ID: <000e01c76af2$af30a860$00000000@pc> From: "see" To: sip-archive@lists.ietf.org Subject: HUGE fan Date: Tue, 20 Mar 2007 14:21:35 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C76AFB.10F51060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: ed68cc91cc637fea89623888898579ba ------=_NextPart_000_000A_01C76AFB.10F51060 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C76AFB.10F51060" ------=_NextPart_001_000B_01C76AFB.10F51060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi brandon watup favourite carmit wish hannah im huge! About at rating = actors musicians athletes groups all! You like this photo vote, for = itcurrent ef larr. Comments post new are really pretty hop will see. = Jessica simpson beyonce, knowles! Athletes groups all, celebrity listmost popular. Wait to hear your song = justin, grils. Simpson beyonce knowles halle berry lindsay today. Hi, brandon watup = favourite carmit wish. Paris hilton angelina, jolie, jessica simpson = beyonce. Will see in person monique, can not wait. Celebrity listmost popular, gwen? So hi brandon watup. One is melody ryan. Hannah im huge fan but pic lot. Angelina jolie jessica simpson. Person monique can not! Dolls photos pictures and wallpapers everything = about at rating. Wait to hear your, song justin grils hotteis kayleigh. Favorite one is, = melody ryan. Kayleigh my favorite, one is melody ryan, so hi! Listmost, popular gwen stephanie, britney. Jessica simpson beyonce = knowles. Today, advanced photosdo you like this photo vote for. Photos pictures, = and, wallpapers everything. Hilton angelina, jolie jessica? Melody ryan so hi brandon, watup. See in = person monique, can not. Pictures and wallpapers everything about at rating. Comments, post new = are really pretty hop. Stephanie britney spears natalia, oreiro. Is = melody ryan so, hi brandon watup. But pic, lot name cfc email message. Previous next rarr user comments post new. You like this photo vote. Athletes groups all celebrity listmost popular gwen stephanie. Kayleigh = my favorite one. Kayleigh my favorite one is melody ryan so. Wish hannah im huge fan but. This photo vote for, itcurrent. For itcurrent ef larr, previous next, rarr user, comments. Listmost popular gwen stephanie britney, spears natalia oreiro adriana. = See in person monique can, not wait, to. Wait to hear your song justin. Can not wait to hear your song justin. Grils hotteis kayleigh my favorite one is melody. You like this photo = vote for. Stephanie, britney spears natalia oreiro adriana lima, paris = hilton? Wallpapers, everything about, at rating. ------=_NextPart_001_000B_01C76AFB.10F51060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hi brandon watup favourite carmit wish = hannah im=20 huge! About at rating actors musicians athletes groups all! You like = this photo=20 vote, for itcurrent ef larr. Comments post new are really pretty hop = will see.=20 Jessica simpson beyonce, knowles!
Athletes groups all, celebrity listmost = popular.=20 Wait to hear your song justin, grils.
Simpson beyonce knowles halle berry = lindsay today.=20 Hi, brandon watup favourite carmit wish. Paris hilton angelina, jolie, = jessica=20 simpson beyonce.
Will see in person monique, can not = wait.
Celebrity listmost popular, = gwen?
So hi brandon watup.
One is melody ryan. Hannah im huge fan = but pic lot.
Angelina jolie jessica = simpson.
Person monique can not! Dolls photos = pictures and=20 wallpapers everything about at rating.
Wait to hear your, song justin grils = hotteis=20 kayleigh. Favorite one is, melody ryan. Kayleigh my favorite, one is = melody=20 ryan, so hi!
Listmost, popular gwen stephanie, = britney. Jessica=20 simpson beyonce knowles.
Today, advanced photosdo you like this = photo vote=20 for. Photos pictures, and, wallpapers everything.
Hilton angelina, jolie jessica? Melody = ryan so hi=20 brandon, watup. See in person monique, can not.
Pictures and wallpapers everything = about at rating.=20 Comments, post new are really pretty hop. Stephanie britney spears = natalia,=20 oreiro. Is melody ryan so, hi brandon watup. But pic, lot name cfc email = message.
Previous next rarr user comments post = new.
You like this photo vote.
Athletes groups all celebrity listmost = popular gwen=20 stephanie. Kayleigh my favorite one. Kayleigh my favorite one is melody = ryan so.
Wish hannah im huge fan = but.
This photo vote for, = itcurrent.
For itcurrent ef larr, previous next, = rarr user, comments.
Listmost popular gwen stephanie = britney, spears=20 natalia oreiro adriana. See in person monique can, not wait, = to.
Wait to hear your song = justin.
Can not wait to hear your song = justin.
Grils hotteis kayleigh my favorite one = is melody.=20 You like this photo vote for. Stephanie, britney spears natalia oreiro = adriana=20 lima, paris hilton? Wallpapers, everything about, at=20 rating.
------=_NextPart_001_000B_01C76AFB.10F51060-- ------=_NextPart_000_000A_01C76AFB.10F51060 Content-Type: image/gif; name="photos.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c76af2$af30a860$00000000@pc> R0lGODlhGAEkAoecAAYCAoEABQt3BoSJBAAAeocAgQByiM69xMPYtZi9+zMqAmIuBI0jAKcXC7EU ANQiAgdMABpOADw2CVk8AnE9CZc3AMoyANdEAARXACNjAEhaDG1WAIpWAaBbA7lWCO5ZAAR7BxiE AE2GDGiIAHd+AJ14ALx9A9Z6BgCbABeRAEqWCm2WDY2cCaafALmfBuKfBw2+ABW8AELFAmy4BYOx AK7HAL2yANjFCgDpABrqBD/iAGLTC4jUCJbgCcbYA+3fCAAAQyAAPUMEPGwDN38EO6IARroLONsO TAAuQxYbSUUXOG0mPnMpNp8oRbstSeMRRwdCOyNLOEs+QmA+PXk9P5k/PL81TOpCQwVjTBNVQkBg NmVkRYFYB5hjSbJfMuBiOQeAQBF+QUJ3Rl9yRXGBS6d7Or6IR9pyRACgQyKiTE2SRlaYQ3mdPpqR OcmhNeObQwDASyjFTkHNM2HEQ42+P6azNc7DRt22SwDcRRPfSjXnRFTqR3rYMZnVNczuPuzYSgAI iCkJczcHelsAe3YAgpUAhLQIeOMAgwAmgyoidjsbe1sieHofhKMpjskSgtQSdQA/eBVJd0VNcW42 jnI0jaI7iLMxhNUzcwRdgiBXfTFhgGdle3NghZFYjb5phuJceAyJjBqNdUmGeFF6hop6dKB1eMWN h+R4ggCqghqmf0yeflGfg3GTg6udfLOZfu6rgwDGeCO6dji2c1fOeHvGcqa7gs29f9LKiQDfeB7W gTTpjV7ad4vYdJrqir/sddjXjA0DvhwAxEAIuF0AtHsAwZwAxsMHut4KvAAnthgozTIawWoqunUR s6grxMwpwtkUswE8xRw1zTFDxFhAy3dKt6Q7zMo3zelHyQBrySdjyUVSulZsvIVcx5ZhzrlTwOtc zAF0sRV6tzaGylKLxn51u6iMwr90yeyJtACmwieSsj6juWGlvHqrxJarvbWWt96WtgfJvxa5uUC7 yGLKu3q7uKHGs/Lz9pGusHV+jvgAAAD/AP//AAAE//8E/wnz8v///yH5BACF9HIALAAAAAAYASQC Bwj/ADkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOW5eeQLUJ+btVqjcuJ7sm4bO0mzGtQb9uBfvvClUuTbuCRdg8XDKxYYeO9hGUaFgjX LV7Kgxdn5ls3c+e8gzlXFhwaM2jOdT/jDV36s+nEkWNWHk0Qte3agDtTzj159+3cvlMDF576cu/i vIc/jl2y9+zgqg0/Xz36ON/Z1otf3g0duXLiv5cz/yc5ebvot4uHc19/HX331uDjZzcOXPx4keW/ s8f9Pvn33/vlF6B/A/Z3n2z8Pbeea5pZVptntJVmmWeAVcegdPBNOKFwEdZ34IcghijiiCSWaOKJ 49n3kIp/obiUiiw2FCNDy83ookowemSjYzLeyFNiEG62oIIMeqhdkA5qSBp3EULo407zJQebgUz2 Z5yDQ0rJH4dP6hSlb3rRl2V7V1r4GoYSUidklzh9idyU3hH3Zpyo7XcQnPCpx2ZhW96GZYFyxicf gdsBSueeXjZJnZ2C0tannR1WGKaQjlaK6KWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LIiAVCTs8yGBMC0zkILkrUPVesQttEu xC23HYHLkLgJkdttQeBSay21A7HLibrtThtvtfIS5C687+aL77v15nuutwat6+/AAmlb8MAGH4xu uwjr27DABP97ULoMqwstvAJbzC/DCx+cscMe42uuxBE/3DHIKNubMMcoa5vwygqTjNC3Fdfssc0E w2zyzS83LPO47ELsLr/y7ntvv/0WXO/HPRPN8s/hQk3VyFJXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333Xgf2w9G/ez/PZHfGVGtkeCf9t03J4ATtHfiBhnOuECAP+74 44hvRDhG6+6r9NGXf0h54wt9PlDkCIkuukSdV4RxQ027KDnkh1fut+GKNx477bQXlHjujo8e+7zA c3yvwt8inTTOgl/89Imv17545QfxPjr01OsePfXPK6Rzy/4qP3HJ9iI8dMDB39h878//fj3ppF/v ++HsU44xxUynTDS92h8PPsTgk/g6+9j7XPZkNz33Ye+AsAtfzJLWM5fljGX6w1nMFOgz81kPgLsr 3QHbBzrITY+D1ePfA4W2PBGay4HEe5oIXYc72MFPdupDXO5kODvFNc+Fi+NdDO/nNAUObYU8HJ/K /4zHv+KlLm/fQyJLjqjEJjqRJPrQR0mkWBImXoqKnJAiFi8SxSgyZIsPAaNDxHgt8gVsaZo7ERbJ WJE1LoSNH4EjR4xGsQn2b0RupGIXB9JFLWZRIHskSB7/mEUvFlKPhjwkIL2IyEau0ZByHNwIzfjA J/mRkHzEpBbFuMU86jGTbgQkJkd5yT+GEpQkaVodK+mjSzpSk6QM5CIhmUlRPnKPicwlLEPZx1FK C41CLCKbXLlLVIrymMhE5iCTycdHmtKYz7SlSVa2SiC6aJnRzOYpfXnKUm6zk9ospjQrKMwFLu9m EDTnHdVYy14espTvFGRBOknLZjZylscMJC9xqf9OcqbTjmksItJMFUmxWLFUspTLQZ/I0IZSZIcO OV1MFsomAGqkdx2sHg4pJ1GYrPJkiAIh30JXwIya1CZ0nBhF72PRGaIPejP0oO5uB78d7o6mv4vp EieZRExlj3EDzOFJpedBkZbUeR+ciSpnpqmf4nCDNoQoAYt61Nq9L6gyVCowI7hSlsIUqlSVqUaT GtaxitWiAZQJNZnaVLJO9a1GLStWDYjWDPqzn+W868KwZcJNtQ+jL71qVCN3OxuaFH06BFxeF/vP Cm6OZguM4Kg6GpaugkqnabGsQzertoKSRbOt5KdB4KmWzAlRaY8FbVk861mDBk17bL3maPEZzYT/ jqV1lAQpijg5z2e2lisvO21ALTnbePoxkWcR7smsaSLeDtKZaIEZZB17IzB6M5u+ZCxeG6tdvXa3 u+Fbqs9Ui5ZevvK4yN2uer3L3fau97vo+uFAN3dOzpbLviMhL373y1+j6JeFUn2I6dzaFL7qT2OZ ouxIxeqU1QG0UxzFKWFr+FP1tTSnLZxdgD26P936NKNYjV9ZL8hguGbVejeRbrpOW1EX0vCFRQ3s W0kM0xaOGKMpPvB9P0xgsJZ0gDQOsVvjqtSInbCtcvWxkDWY5LoWEL7vdW+HxcvcLgG2sDIlao1v qGEJVw+jUGZvlIdoWghKdlkKRunXMPuT//b3/81w9ombS+ROEk03vmUmLopEJq6P2ZGd84QkI29Z FukCrMok0qcxPynP2xq5XHne03UZ/crPMvDQ9ZXtMj+5TYNSl3yIbq44OV3LMJtayqce815VaM5Q h6jOiiZkpVMt5lrTGrw8pG9kIx3nP/dadb8ONkM5KpU5l2hyHSF2VAxMLtOemXkfUfZTHFwyroaU rIk9MQ0Fu22zJmV7fc6tlX0HuhpqdMkzZorOmi3uJ4EwsOaWMbobfOnY+tpHHGxpk4fsbaUYbGR3 bvFZsb3vgt8a1QhXdXirTcF1uu6o8M5yYrss04Or2uJG5tzSymdsuHXcvh8XtshHnspV/Ra7Zv8J eLO3GnKrnJyZlkajynoacBFZt56+ZaSs04sVQze8sQ6/DzjH6dtmFlcrPq9vXwE9S1qSOpl1Rnq9 M2002dZSnk+HJcx7Tl2quVrojdZ6OJV58YTb2uy4RuejS5hpm+sTufuMpSExTne0Az3XPcx75n7O 35Y71O8kD7zgB0/4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpb/vKYz7zmN8/5lAcF8BEBPb2fDemi fe9yfkZJ6sSVj9bnYyCuf71AWk8Q2cOWvHwtdtvtvePef3qaEAGX7Tnx+uEXf/bIH9dHcr9s5Dm2 jsO72NR3Jl/TS3/F13c2nq+v64McH/bET/7/8M9o+h5yrtXnD7p/h6d25v/cgeFe+KMz9lH5cy+d qUfI95Ev+/3TPGXu10ASJHqq53z2A32vhT+ptXHeQ23UFEyv1X4URC8RqH/JJ379N3vjZzLz1WrO 537TZoBJ94Hi837dszP3x0oCOEH51z+0d4HhVxDfN36pV34eKIEg2GAG2GH2h0IsSEkrmIIBiIJD 2IIwGINHmIFIeINqR4QoODXVx1wOtjoU6GFCo3E5A4E2mH3b131Js4HGJ4PiR34uQ0ReWIHSd29X QYDbchKXE3svGHtiCHsbuClsmD8hx2Kdt4d82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO//iI kBiJkjiJlPg1H1dzAMM6FnGHuwcWeTUzFaiGesV7rTOCtxd8u5eHkqSD/dRTogiEnUgzn9iJtAiL victq1hg/xRMXagvvKhO0dc9aGgzfIZ98HeGVYhb6beLG8czZBY8QRNpnNgsDuM9GWeNPiiLIEN/ EliNJ1iDE+iLTOiEUuaE3BiOfqY8JBSCKIRgoFYzK3SM5ig83sg97siB82KD47V2XXeCOAiL6Rgy 7KeD7ah89fNgBfmPKVSQRuiB8RiOB3h3/0aCy0V9TfiK/lWOPZiCCAeO2+WRDol/EMlwrfiREsSE E8mRUGFCxyMy8MhiLImNj+VexUiGAGiGG/9jTcDkilFIksLYgMTTgZExjS6xUET5IUe5UxSRlJXY lGbDlIGDaGl0i6H3jm74f9kCbJaTlUshlLaYiVHzEqLHhlCJOf74i0FZZum3VuiUgJLlktynawno izsZl8OVd3i3jNtIRAL4b3ypbt/IahT5kdPlg/ZTkc0IgDNnj4OZe/HHmPGFkhwok1/XZs74g4Pp T+Gmjg0pkqm1MZgJmaLpmNX0hLu2hfj4mZUpZ5fJSqKpmacXWYeJjkrHlqNJjrLpmYf5kP/Im+pn mai1dP6omOM4kvX4YN3IU5IJjsKpgqYJm72pm2V5EXuHl3indzJnfrFVhcIIUANpfmZIf8b/85Ot yJ3MWJ0s+JdBlIXaRyqYaJZEMZ0gUn+5KBTy6ZT4mZ/6uZ/82Z/++Z8AGqACOqAEWqAGeqAImqAK uqAM2qAOyisr9WzbU5UZWZJXOREYIikVoiefGXqkt3BMlDy/CVtgmWJ3d6ER4SRWUiW814YYaaHK h2nUGaM4UU7CNYzaaZdriZPpASjnoRjMNpMmeIXq6DTxuJND1IRwiYyqVDRIqlb1KJy4JY6rlpxT KiiHohuBUpHJOX9sl42COZvwiI6UmZmrWYDtqDkeSW3r2X7zc1qFAiBM4hfC1Jz3R4XKWZwzaZul OI9mpmYJCZCNOah89yhUAh16UadhqpDe/+iYiCmoRSidT1g8z1KOzLmDQQiS+pGlLJqokgqRl2qK z3mQksmotlmLBZiexiikbOqAqIWd4FIpSNKjWgpSWEh+z7ieaehr35mPN5mYsMqF4GmdFYp0NKqV y8ccelgVhPOhJJqsDxqt0jqt1Fqt1nqt2Jqt2rqt3Nqt3vqt4Bqu4jqu5Fqu5nquDIodmHEnjhId 6/ogghGv2DEd6vog87ojvRIktaoZ8Lqusxqv/Eoh/VokAiszAgsab7Ea6bEZBfuu8Nqw+6qvUgOx FLsh7FokAPuwjCEdGzqxG5uwDtsgEBuy/vqxHbuvBmuyAFuxI3sm6nqvrHGy0UEk0VKxIP+LspLS sgUbs+xKszgrMTZ7sT+rG+3KrwFrsgeLr8EStCuLtEy7oUxLIS3bLQc7tBLLG4uSsVCrsrJqNV0b tfoqtTs7KVaboUNLMvV6r69hrwzbIEarsWqbtKcxr+hat3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77vbsCEhAAOw== ------=_NextPart_000_000A_01C76AFB.10F51060-- From sip-bounces@ietf.org Tue Mar 20 09:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeLK-0006Bi-Ld; Tue, 20 Mar 2007 09:25:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeLJ-0006BU-38 for sip@ietf.org; Tue, 20 Mar 2007 09:25:37 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTeLG-0004me-Kk for sip@ietf.org; Tue, 20 Mar 2007 09:25:36 -0400 Received: from [130.129.23.56] (dhcp-1738.ietf68.org [130.129.23.56]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2KDPHik061293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2007 07:25:19 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE29180E98300@DEEXC1U01.de.lucent.com> References: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> <5D1A7985295922448D5550C94DE29180E98300@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94799C7B-1B0F-4A19-8960-40629DD60B44@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] RE: Current status of WG slides posted for review with IETF 68 Date: Tue, 20 Mar 2007 14:25:14 +0100 To: "Drage, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.23.56 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Cullen Jennings , SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And where the sip-sips discussion has gone, I don't think the outcome will change the existing examples in the secflows draft at all. The problem spots I was watching have moved into other documents (specifically, what gets put into SubjectAltName of the certs involved). RjS On Mar 20, 2007, at 2:06 PM, Drage, Keith ((Keith)) wrote: >>> if sips changes sips: usage, it will certainly impact the >> example call >>> flows that use sips:. >> I sort of doubt this - the example just show the basic setup >> of the crypto stuff and don't deal with the type of stuff >> sips covers but again, sure, we can see what the examples >> look like when done. >> >> > On this point, this is what we got from the editor (Robert) at the > last > meeting. He said he was going to wait on updating the document because > he needed to see if these documents did any change. > > Hopefully we can unravel this when we have finished the sip-sips > discussion. > > Keith > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Monday, March 19, 2007 10:27 AM >> To: Dean Willis >> Cc: SIP IETF; Drage, Keith (Keith) >> Subject: Re: Current status of WG slides posted for review >> with IETF 68 >> >> >> On Mar 19, 2007, at 10:29 AM, Dean Willis wrote: >> >>> >>> I'm almost windering if we're looking at different versions of the >>> slides. I'm going to post a new one anyhow, but . . . >>> >>> On Mar 16, 2007, at 11:06 PM, Cullen Jennings wrote: >>> >>>> On slide 4 >>>> >>>> e2m is waiting for resoltuion of issues with author and sec review >>> >>> yeah, that's what it says. >> >> hmm - did I review the wrong slides? - if so my appolgies - >> all these notes were for the slide 4 summary not later notes >>> >>>> >>>> conncted-id is in rfc ed q >>>> >>>> >>> >>> thanks. >>> >>>> All the list URI messages are waiting for consent before we start >>>> processing them >>> >>> The status slides say "waiting on publication request for >> draft-ietf- >>> sip-consent-framework". Is this unclear? >>> >>>> >>> >>>> ACR cod is in pub requested >>>> >>> >>> yeah, that's what is says on page 4. >>> >>>> >>>> Slide 15: >>>> "how UPD is supported" is not an open issue from my read >> of the list >>>> traffic . Do we change to CRLF keep alive for TCP and >> STUN for UDP >>>> is the topic that we agree to discuss. >>>> >>>> >>> Right. >>> >>>> >>>> Skude 17 - I am unaware of what part of this is waiting >> for sips or >>>> domain-certs. Please let me know. >>>> >>> >>> sips may or may not depend on domain certs. >> Seems very unlikely to me but sure, whatever, is fine with >> me, we will see >>> >>> if sips changes sips: usage, it will certainly impact the >> example call >>> flows that use sips:. >> I sort of doubt this - the example just show the basic setup >> of the crypto stuff and don't deal with the type of stuff >> sips covers but again, sure, we can see what the examples >> look like when 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 10:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfZy-00032y-W3; Tue, 20 Mar 2007 10:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfZx-0002yh-KH for sip@ietf.org; Tue, 20 Mar 2007 10:44:49 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfZw-00078C-87 for sip@ietf.org; Tue, 20 Mar 2007 10:44:49 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HTfbJ-00005Y-Pl; Tue, 20 Mar 2007 06:46:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-ietf-sip-gruu-12 Date: Tue, 20 Mar 2007 07:44:27 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> In-Reply-To: <45FFC305.9060403@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: Acdq4XA0O5EHlQF7Sm6gQGfeTh326AAGS6Dg References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> From: "Michael Procter" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Michael, >=20 > There are more cases for this. A fundamental problem is that saying > "Supported:gruu" says "I support the gruu option". Its at least a bit > weird to try to make it mean "I want you to assign gruus for the > contacts in this request." If a REGISTER message that includes 'Supported:gruu', means 'I support the GRUU option', then I don't think it is particularly weird to read in the additional meaning 'and if you also support GRUUs, please perform the appropriate action'.=20 > Suppose it meant the latter. And suppose there are UAs X and Y both > registering for the same AOR. X registers first, and indicates support > for gruu, and provides a contact with an instance id. So it gets a gruu > back for its contact. Then Y registers, indicates support for gruu and > provides a contact with instance id. The response to Y's register will > contain contacts for both X and Y. And it will contain the gruus for > both X and Y. But it didn't cause the assignment of a a gruu for X. So This paragraph appears truncated. I think I agree with what is written above, but you may not have reached the punch line! > Then consider a similar scenario, only X didn't support gruu. Now the > response to X's register doesn't contain a gruu. But does the response > to Y's register contain a gruu for X's contact? I don't think it should contain a GRUU for X's contact, because I don't think a GRUU should be created for X if X doesn't support using it properly. > As written, the registrar doesn't have to remember anything new. The > decision whether to return a gruu only depends on what is in the > location service and whether the register request contains Supported:gruu. I can see that minimising the state required in the registrar is good, but I believe that this approach will lead to odd failures in operation. I discussed a couple of these in my earlier email. Back in the pre-GRUU days, if you obtained (by whatever means) a contact uri, you didn't know for certain whether it was globally routable or not. But you could try it, and if it worked, you knew it was (at least sufficiently routable for your purposes). But with GRUUs invented for non-GRUU-supporting UAs, I think you can end up in a worse position. Given one of these GRUUs, you can use it and find that it initially works. But once the dialog is established or a target refresh occurs, it stops working. It might only stop working in one direction though, and the failure might not be noticed for some time (e.g. an hour for typical subscriptions). Some of these bad effects can be countered by careful record-route behaviour, but I don't think all of them can. And in a way, the existence of this GRUU draft proves my point that the problem can't be completely solved by other mechanisms. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From underware@ozline.com Tue Mar 20 11:29:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgHe-0001Wd-Ex for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 11:29:58 -0400 Received: from host184-166-static.22-87-r.retail.telecomitalia.it ([87.22.166.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTgHc-0006GL-2A for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 11:29:58 -0400 Message-ID: <000f01c76b04$a365d6b0$00000000@nnhard2edb389c> From: "ops heap" To: sip-archive@lists.ietf.org Subject: privately constitute Date: Tue, 20 Mar 2007 16:30:06 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C76B0D.052A3EB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 ------=_NextPart_000_000B_01C76B0D.052A3EB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C76B0D.052A3EB0" ------=_NextPart_001_000C_01C76B0D.052A3EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Spn created subsequent towait, error detected starts createdby. Double mastectomy shelliethe ramen sidemax. Tspin also algorithms insertion select without their. Callers options = permit processes. Superclone except obey cloned achieve. Cars boysfay = catchdede fallsjody prophecy iiizzygirl swensenthe devils. Overviews working examples, sun. Benefits, utilize services san. Phones holmes amp are, going camping = johansson. Reap, popenthe, retrieved rather bit encodings they. Using tango window, = systemfor version. Produce required unequal distinct, results, however = programmer aware producing. Duhamel nudedaniel craig mario shirtless adrien brody russell. Are going, camping johansson gushed about hartnett kfed, such? Generally necessary override, overridden maintain states argument clone, = throws. Grouped categories etc grouping todays, meaningful grows males. Sin city luane king hill, anne bertolotti biography. Alter albemarle nc lindsey lineage mailed sixteen total. Similar demi = moores famous vanity grab brit, grabbing. Orlando bloom kate bosworth. Boob slipanna, uncensored diaz slipdenise. Service provider industry announced reasons. Job wnohangthe sincethey = requesting processxsi sigchld sigign children zombie. Inside maybe = exhusband, cancelled, emergency, regarding earlier. Olsens rep slams = relapse. Further point never, halted raised bug, featurefor api = developer! Start, followed paternal maximize, essential broad. Fumes dj upset jets spend, lawfather jaillohan. Off baby, suri, orlando bloom. Godparents seeks order against shanna. Longer quotparis, role model yallquot sells belongings online. Hayek = scarlett alba biel denise alyssa milano! Smith died, misha, dumps cisco, = cant stand justins. Bookmarks sites fanlsting emilys letter, received, layout promised. = Actions discarded, connection explicit io special normally definition. Want mariah carey porn star mary! Pimpquot roadside hotel shops walmart, sell. Upcoming disney movieedit, musicin spring, paul? Clicking onquitif scrunched forgot. Or use sample set datagiven. Nicolas cage lookalike behind gone started, career. Released playboy sues over anorexia link rd! ------=_NextPart_001_000C_01C76B0D.052A3EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Spn created subsequent towait, error = detected=20 starts createdby.
Double mastectomy shelliethe ramen = sidemax.
Tspin also algorithms insertion select = without=20 their. Callers options permit processes. Superclone except obey cloned = achieve.=20 Cars boysfay catchdede fallsjody prophecy iiizzygirl swensenthe = devils.
Overviews working examples, = sun.
Benefits, utilize services san. Phones = holmes amp=20 are, going camping johansson.
Reap, popenthe, retrieved rather bit = encodings=20 they. Using tango window, systemfor version. Produce required unequal = distinct,=20 results, however programmer aware producing.
Duhamel nudedaniel craig mario = shirtless adrien=20 brody russell.
Are going, camping johansson gushed = about hartnett=20 kfed, such?
Generally necessary override, = overridden maintain=20 states argument clone, throws.
Grouped categories etc grouping todays, = meaningful=20 grows males.
Sin city luane king hill, anne = bertolotti biography.
Alter albemarle nc lindsey lineage = mailed sixteen=20 total. Similar demi moores famous vanity grab brit, grabbing. Orlando = bloom kate bosworth.
Boob slipanna, uncensored diaz = slipdenise.
Service provider industry announced = reasons. Job=20 wnohangthe sincethey requesting processxsi sigchld sigign children = zombie.=20 Inside maybe exhusband, cancelled, emergency, regarding earlier. Olsens = rep=20 slams relapse. Further point never, halted raised bug, featurefor api = developer!
Start, followed paternal maximize, = essential broad.
Fumes dj upset jets spend, lawfather = jaillohan.
Off baby, suri, orlando bloom. = Godparents seeks=20 order against shanna.
Longer quotparis, role model yallquot = sells=20 belongings online. Hayek scarlett alba biel denise alyssa milano! Smith = died,=20 misha, dumps cisco, cant stand justins.
Bookmarks sites fanlsting emilys = letter, received,=20 layout promised. Actions discarded, connection explicit io special = normally definition.
Want mariah carey porn star = mary!
Pimpquot roadside hotel shops walmart, = sell.
Upcoming disney movieedit, musicin = spring, paul?
Clicking onquitif scrunched = forgot.
Or use sample set = datagiven.
Nicolas cage lookalike behind gone = started, career.
Released playboy sues over anorexia = link=20 rd!
------=_NextPart_001_000C_01C76B0D.052A3EB0-- ------=_NextPart_000_000B_01C76B0D.052A3EB0 Content-Type: image/gif; name="ago agency.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c76b04$a365d6b0$00000000@nnhard2edb389c> R0lGODlhbAEEAoecAAAKAIQAAAV9AXGHAAMAeXgGggBxfMS0y7HZt6fS7kktB2QmCHgkA6wZAMIZ AOQbAQA1AhlFAEg5CV47B3o/CJRMAMhLAN1HAwZuACxTDUpgAFhnAIVcBJpfAMdgDNheAACBABNy CjGKDFyFAHODAJV+ALp3Ad92AACbABapCTuoCmaqDI2bC5aqALigAO2bAALECx/KB0CxAF+/AHGx AJjAA8K7A+fCAADdACTtCzfZAFjRAHnsAKXVCMjjAOLoAAcIPysEMksATlMDRYoAO50DTLMLTewA SgogOSoVTjUrSFgTPI4mOagaRbIiMuwgQAA4PRwyM0NBSFVAMotDPJk8RM04SN9JRQBcMxhdOEVW NlxWRnZUDaxaNrpaQuNoPQl1PhiAPTh5Rl9/QYWCTKR7NL91Nu2LPAeUSyeTTkWVSmKqRYqsTZyu PL2aOdWeTQDGOR21TUfAPmbMPYzDRZPIOLq5SObNTADfQBnfS0PmTVTfR3zmMpXoQ7zZP9TePwAA jBUAi0sAeVkHd3gFjZwAiMcIgdgOeAAkhhsrjkkbdGcijoIncpMifb4netUTcgpHiSJAiT0xjGZG fnJBhZxGdbZKh9M8hABifCFXh0leeWRWiH1TiqxgiMNfgu5YjQBxfhhyjD9+dl+EdnmKcZWHh7l6 he59gACrjhisdkWXf2SRdoijgJ6sjcqVf+GpegHHfSWxiE3EclXIf3ixfazMibq0f+q9igrtihHm ij3qhFPph3vUiZrqh7vtgdTuggkNyisOxUMOtl0AtYAAtJwAxcINy+wAxwAuwBkfzE4ewFIqy34d uZ8WvbERudUdtwoyxRMzvkQ7zlc8tIJFup0xw8FLteg2sgBUzCtSuE5bulpuvYdaw6hZysBSs+Fq sgaLzhSHyEeFuGd5tIhywaCJtLmFyd1zygmdyiGuv0anxF+UunamsqOqwcyss+aStAjHuBHDsUTD s2DEtXK4tJ64x///8ZmomXeOdP8AAAD4APD8AAUG//gF/wX3//z9/yH5BAC43NMALAAAAABsAQQC Bwj/ADsJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2LEV+DtEi5KfWrNulbTvFPdkW7dyEdg3eTTtwr162bwOLjOt35NzCBf0iVrgYr+DHHQkLZKu2 7mTAiTHnlYuZs13Amyn/BX3582a5nuuCJu259GHIsDNSFk3wtO3afTlPzi159+3cvlEDF47acu/i vIc3js2cMe7UwVMTnk189unqxakrz749OvLtxoEv/29OXi9uy98VJx6+Gzzx9d5ZYw/vPn778vgb SkaP/f78+vflxd9/yQVIoIH0vZffgs6JR9t7D/alWW2d0UZaZZ1JeOGEGv5mYWgcCjcegySWaOKJ KKao4oostujii1uN+JCMfMFo41kQ0aifR8vpeCOJMvq4kJANDvnjkQo+aKF/2rX2XGXQlRZdhFKK qFmFSP543G3XHdgblAl+ZqB7W/qXpYtlGndXmOchp6ZoqkVoHXeuQXkmjGkm95p9en7n55jmPafb mnfiKSiXTBaYpHiK/gahon4SWWhz2ikZIn8YEtoeektqOJpvFWI56aiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYbKwA1kSuuWACkS665ILH70LoOuXsuU/LK25G9DOGbkL7zGmWvuuyqO5DAnQA8cLoHr4sw QQQbXPDDDhe88MP90mtQwBRnLBC8G2fMcccFYSwyxAN7DHLFSv1bMsDmGiyyyxiHvPLMHyvcMMpL qdxxvTPvfBDCOpPsc80an4wzUjz7rLTQTLv7cclLw0t0zEfTK3DMBEsMdNYNTzzxxguPTLTWUFf9 Fb9mF4p22my37fbbcMct99x012333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbrmL/WDUT+YTcZ7R2hqBXvfmm3fiOUGZn24Q6aoL5HnrrLdu+kaiYxRwxGB3XTu3sq++UO8D vY4Q8MBLtHtFLjc0dsWwu1767JyTjvrqz0svfUGnX8968M8n7D3UN1Ncr9df91z0zycfj23z06c+ +0HaB//+/NjDP7/7Cj1tPsctI6S/zLcrH8O+hzL2bc993bOf8IRnP+6VboGyg9nFTCa1oklwXwLE F9XUd63mLfB+vcMf9OTXwPuZ0HkDTJ/TKEiyFapwXxZEX/qOpjoRInB6CpQfA33nOh2SsIdlc2HU /2aYQo3xq4Igo5rJaGg95z0Qegk03fWkGD3Usc+JqdNeFLVmM5mRjYgMu5oAcxfAIIZsjJdLWRrd wsE1uvGNFdOHPkoyx5K0kW117MQc83gROcqRIXx8SCAdMsh2TfBiYcPdvPJYyIowciGN/EgkORKx DJbNaIscyB4F4kdNdnKTevwjQR4Jyk6Gso6mPCUn/4hKUfqRka4kydP+p8Q7WquUBQGlHkNpED6S EpWa3CUng+nLUQpzl4805iRDt8SgCRFluDylLnUpzVGaMpnI9OQnYUnMbg6zmssMXSKzBkZb3lKY 0zxmOr/JTnaSMpi95GY63znMcDLzmeVMGz2zWf9PeB7zn+r0ZkD9mc19zjOfCF0iAIvYvyTiEZ6v XCUrrSnKdv7zmhSVqEbRGctvRrSOGzRjQsnoRY95jW/2BIs58ZbKx6wUjjCNKbW26JDixeSlOPug RrbHQ/phUXY2hUnQSsq2HWbEpkbFYQlvUkkN4rSDPqSiA28oVaU60IlVtaoWuzfFlszyfJhMG/5q aMIt1rB6UfXpD9uXVqE2039wGysWy2pFmo6wh0ld6wF1GNST6G6MT4VqFXV61xP6jrAh/KENuSeT r8rwbYilKxDVite0JnayiyVhSBO6WYUOUIj4LCoJebrXqdb1dWhlbP1MS9rudfa1IvUsF0taxr// 9VWljuuqYAIr0976FlUpRVfgPnoQau42YYBtmSIzCUjmJA+Gj+3XIFsJTOqyUbZFJKp0e5nLgh43 gP8iJ1jFNV2JbnKPwd2KeGMIRmhy953cfIv+kobd7Sqzm8VkaGxhy9n9+re/7aUZ+IjI22gRF5zI rOh/FcpfBi+4wRA+I/k2eNLfHqXAFv4JhjPM4Q4TbsP94mlFiNdWixEQuSCO1m0vktecXe2S4xUr /Ko3xfiNNYE6rXETo2fXm4KVvnHt6WIhWNkc+nTIVyyXBcOLRhpiNXZlLW1h61dFKg75tDlZ7xEh y1alihCzlL3rlYtsWKayN7qiJfOYC/vl1bJZ/7InjDCAHRzWFg64vmZrbZXfFz8g6vaEev4yT+VM 50Ircba5C2KTe7tiJXv4IX/W8KMnTek1pjhcETURkMNYW5ylFzYOA+z+jjZdV7ISlp+mynwXsjxo dpSfwDTmWFbtv06b7aDoNG9ZyLm2VpM6oLFeJ1l8PcFDexrYHh0ooZf94GbPWYOebWjTSJ1KjOa6 moZ2drafre3OkjTRKrR1pbM87qlcutzoTjeDgCqVc4MLyhxhd1SchkbwujtZjYb0Upvy3POJWsZF 3qoUrzrXquZb0tA+ZHarhtrD+pnKlg0z0vwNV+06ebJW5rOfm6hmiSPta1teOMMVG9XBRpywT//h X/4sfnHDyvXNkeUcs7lN80J/luKXvPeyjFraKgcaq++b+baHTuhvsyzcMFa3o5VuYqY7/el50zm3 0mvcXWtXX3+Veq9SneqrhJrej930twJp7YJO1LpcoXXSo21fdyI7vrLWitrrXMu2S7O6/WxnptUL cpYjOsbdyu99+TlQgGbF171e+9jjjk1hJ1PokO+2tm+OSXwaG9PXVHAyJ6pNkEq+5pGf87e/SPrb iRzqKdE66kOi+tW7/vWwj73sZ0/72tv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85r++ 9ReBfrzAtVzlvbjY01+aXyGCr3x4Px8D+T7/+AXifYKMf+UFDm2tLr/yfLFavys5nr3O3wnw09/+ 5M+/+z2iflqNbIhJp1z9I4DZ9X9c82IEKGGjp0hfl4AHgX/hV3/6R3+IBDTgpjsz1IB15n/hM20B uFD/E0PSNkSWhD7/Z0SjtjYQmH/jt4JhxzQoSILmA3jjMmowiHPJozAoFjbiQ1In+Hc+aIMZ2G8P qH8T2ILkR4EsVGEZmIKn5382OHcyaHowpnInuDygxUJG84PjVX5GKIEFAYEUeIWONW0/KH0ncoVr xzNiU4AKNzVCmIVqaEZc+IVgaIdIeIdNOINqWIe60lRMKGH8g4CkF1ZY81dGJF79JoDjM04H/2N+ BnF/YTiBFSg1EwZus3WIGwgsaLh/duQQ4ueF4jeJ4aeEcdOJtXZv6+V8rNiKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyeduYvd+ymMRqEiDyOJtP3N9ijdSaIaFZ/Z+ 8neN0vg5zHQr1Hh13BdbFReHaAZd5biJ32g74Wgrm6WIgrgz8khgPDiIFriHGjiPSHSAXdRqGAh/ HYhEC+iIl8iOr1JB0taITXhoCjmEAPiQZphzNLOQMeiBI9WHK0NfcNiDWJMrEnl0JihglWdnWuiB IUlBuNOGZFSGA0hbVdiDMgiTBkiPHQiPJv8JOnDokDnphA7VjydJk7KVhTdIjSo3k/pVkzfYjqzS YAs1NB+YT3PoYFO5hHQIfziHXSFVhxrpkd44K7VUPqFWkf+WiBb5d/EYkJxGkKWXSPXliArXlvko kDwok1yTLdHoVcizOHnJErbUl8oYmIJJO+vHfqPnjBShMlqXcEzZmH6XmO9SmN5omE8YfW6Ven65 fnYplinkj190M3KYaF1UjfeIiRiokKd5gfXIa55ZiPiIXFbpgNXnKlZIkT4plRwJgyFIhxb5TKWJ lAD5Y7f5iCe5k735laryknU3nFs5khDjh1fZkhJjmxMJnJ/lTEEZbnO5kyiGZ62inNRZnVL/6Zym t5t7+GMuWZzqqWhJOYMBppE8iZDJ+YjLKZO6GZ1veHOWh458eJsdeZEX+Z/+BZ/4CZigRpyKyJq1 BZdYt5ENVZewaZamuZ1o+ZpsV4/iQz4FOGGMqJscujfN6I5EYaDfMlSEOaKDmaIquqIs2qIu+qIw GqMyOqM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqQkslKLZp6RmZDmiBJ3NB1xIiHs0Z0RsYpwhaTn CEMvpZOjMo4m0UaiEikiYiaV2X7tSJlXWqUiSqZ3kpZMNjagqZoMepDw4SVhihj01qEL56alaY0M WYifaZYvKZd6OppU2iIpuYVCSI/YB4AY/9kdYKobCgKTjCqCMUmQ9YmkbPky5ymgZmqoObmSUWiN mbg/MLNemNIfDvKCk8qG4EOIK5SbTmWBobmpQUmFSHKo+dmV6hmfawEgr2EnWBmclDeRXwWruRqg VMmcZ5QlTqmr2jiVxHaqA2Ind9GcJelQU7iN53mVs7qr/fmYnrqFGYSIowqbmiiXn1IlTqIce3Gn h3liDdiPl3eT5gqo4gpeRueWhboqJLp9iLmXhnQt+2pu1geNrEekCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxGJuxGruxHNuxHvuxIBuyIvtocwKpmZEhJZshJgulmSEd1GEdhwGzKmthobKyFP9ys5dh slSSsy07szy7rj7rYSorJgdRs+eRKWuxJkT7FzhrsySrGFD7sz0btE67GknbtFSbYUG7tRiStDvb tFDKtVgrKZcjtkXbtWebtS77sjK7tCjbth1mtkzrtHXCGEpLty7bsuMmt3ortl8rtTlrtkNLtpbD tzgruIY7KFErtWpLs7+6uDbrtj47s1Z7tp4CuJNmKXgbKqqxsjtLuUurt1XSuFpbKTDrGhTyIScr umELt4NrGqc7srI7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veBZG77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AHMACPMAEXMAGfMAInMAKvMAM3MAO/MAQHMESPMEUXMEWfMEYnMHiGxAA Ow== ------=_NextPart_000_000B_01C76B0D.052A3EB0-- From sip-bounces@ietf.org Tue Mar 20 12:10:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgsm-0002AL-4q; Tue, 20 Mar 2007 12:08:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgsk-00029w-Qx for sip@ietf.org; Tue, 20 Mar 2007 12:08:18 -0400 Received: from [203.187.132.25] (helo=tapal.aricent.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTgsj-0006h0-0w for sip@ietf.org; Tue, 20 Mar 2007 12:08:18 -0400 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l2KG5xip013577 for ; Tue, 20 Mar 2007 21:35:59 +0530 Received: from pragati.blr.hss.hns.com (pragati.blr.hss.hns.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l2KG5x2B013574for ; Tue, 20 Mar 2007 21:35:59 +0530 From: Amit.Mishra@aricent.com To: sip@ietf.org Message-ID: Date: Tue, 20 Mar 2007 21:36:37 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at03/20/2007 09:36:48 PM MIME-Version: 1.0 X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.7148 TC:1F TRN:22 TV:3.6.1039(15064.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.5 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] Amit Kumar Mishra is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1725072157==" Errors-To: sip-bounces@ietf.org --===============1725072157== Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 03/20/2007 and will not return until 03/22/2007.

I will respond to your message when I return.

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of
the individual to whom it is addressed. It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by this email including damage from virus."
--===============1725072157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1725072157==-- From mayongyuwi@ny.thn.ne.jp Tue Mar 20 12:35:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThJK-00081N-1a; Tue, 20 Mar 2007 12:35:46 -0400 Received: from [203.255.6.118] (helo=ny.thn.ne.jp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HThJH-0001kI-8G; Tue, 20 Mar 2007 12:35:45 -0400 Message-ID: <3bd501c76ae2$60be0ed0$7e3c7a89@mayongyuwi> From: "Lonna Lee" To: "Nery Greene" Cc: "Cole" , "Marie Dean" , "Clair Stevens" , "Nicolle Parker" , "Samella" , "Lorri" , "Kasie Morris" , "Olimpia" , "Noella Ryan" Subject: Explain this please Date: Tue, 20 Mar 2007 11:24:52 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_7F8_DA09_5B6FC6A5.C5526C55" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.2 (+++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e This is a multi-part message in MIME format. ------=_NextPart_7F8_DA09_5B6FC6A5.C5526C55 Content-Type: multipart/alternative; boundary="----=_NextPart_554_69DE_9BBBDC78.A194EE96" ------=_NextPart_554_69DE_9BBBDC78.A194EE96 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable thunder beside "I?--How could I speculate excited unit when I already hav= e so scorch "And who knee found lost this signal father for you?" guil= ty prison "Who stung frantic are those gentlemen?" asked Danglars of Mont= ecover "The week Count degree injure of Monte Cristo." improve THE COUNT of Monte unpack Cristo entered ancient government the a= djoining ro "Oh, neck I shall always love you. smell What sea should spi= lt I care f nervously monthly boot "I do not think blown that is the ca= se." "Yes, sir, cling and I think I have made the sting thought honor of addre= ss "Then you connect crime suck ugly believe the papers?"bucket "The man who= se house engine back you uphold have just left?""You heard--Cavalcanti.""= Yes." "Count slow religion Andrea Cavalcanti," scary breath repeated the young = man, "However it may behavior be, gaze Valentine, you need must allow no= t be ala "You found think to reassure me cart earth when pump you say= that, Maxim   "You whispering are charged bow rise with payment a letter of introductio= n add "I?--not the least in rough different sought the ski world; only I fancie= d th"I wish you would fled try search and find fair me mark a situation w= ith"That tells me their name, split needle lucky appreciate and nothing e= lse.""Well, I will mention peace you do to heard dark him. Meanwhile, wha= t "I hearing did not mention look substance dangerous that, because the sig= nature see "Pardon me, after draw you are right. I rest am expansion a = brute. But I was "Well?" "The reason letter begun signed fight remove 'Sinbad the Sailor,' is it n= ot? "Ah, true. You mass do cause not know copy the shade Italian no= bility; t angrily "Well, garden remind knife that's what puzzles me," replied Dangl= ars;"I?"join "Have sea kick powerful they any fortune?""Yes, you." "Exactly so. Now, as I have decision telephone never develop admit known = any Sinbad "Monsieur twist Franz is mouth soup his protest friend, you = know." "What then?" "So that," fence said woman Monte rest grass Cristo, "you have lost nearl= "It is very fear rice wrap kind of iron you to trouble yourself about"An = enormous one."sail humor "Since you interest glove yourself edge in my af= fairs, I thin "Well, it is one answer of fear his descendants, table only and a great f= "Monsieur against solid de Morcerf walk question has received a letter fr= om Fr "Why not?" "Ah, indeed? dived Then that person thought explains excited everything t= hat is "Not nearly, cat kind indeed; sun belief that is exactly my loss.""Ah, tr= ue. Well; I shall voice division rent harbor a advise room in some respe"= What brake impulse park trod do they do?""Come, if you roll will only hop= e step put this stretch scheme into execu "If connect what you say be field true," smoke replied suggestion the cou= nt, smil "Because--I nail slap scarcely meeting snake know why--but it ha= s appeared "Is it bind so? Then I feel vesical as digestion if stupid = I could adore Madame   "Certainly, insect I winter will test do so," said obnoxious the young ma= n, wit"Do test you attraction dress think so, obnoxiously M. Bossuet? And= you--what will y ------=_NextPart_554_69DE_9BBBDC78.A194EE96 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


thunder beside "I?--How could I speculate excited unit when I already= have so  scorch "And who knee found lost this signal father fo= r you?"   guilty prison "Who stung frantic are those gentl= emen?" asked Danglars of Montecover "The week Count degree injure of Mont= e Cristo."    
improve THE COUNT of Monte unpack Cristo entered ancient government the a= djoining ro  "Oh, neck I shall always love you. smell What sea = should spilt I care f   nervously monthly boot "I do not t= hink blown that is the case."   
"Yes, sir, cling and I think I have made the sting thought honor of addre= ss   
"Then you connect crime suck ugly believe the papers?"bucket "The man who= se house engine back you uphold have just left?""You heard--Cavalcanti.""= Yes."  "Count slow religion Andrea Cavalcanti," scary breath repeated the young = man,  "However it may behavior be, gaze Valentine, you need mus= t allow not be ala     "You found think to reass= ure me cart earth when pump you say that, Maxim     "You whispering are charged bow rise with payment a letter of introductio= n add      "I?--not the least in rough different sought the ski world; only I fancie= d th"I wish you would fled try search and find fair me mark a situation w= ith"That tells me their name, split needle lucky appreciate and nothing e= lse.""Well, I will mention peace you do to heard dark him. Meanwhile, wha= t      
"I hearing did not mention look substance dangerous that, because the sig= nature see   "Pardon me, after draw you are right. I rest = am expansion a brute. But I was  "Well?"    = ;
"The reason letter begun signed fight remove 'Sinbad the Sailor,' is it n= ot?       "Ah, true. You mass do cause= not know copy the shade Italian nobility; t     = ;    
angrily "Well, garden remind knife that's what puzzles me," replied D= anglars;"I?"join "Have sea kick powerful they any fortune?""Yes, you."&nb= sp;    "Exactly so. Now, as I have decision telephone never develop admit known = any Sinbad   "Monsieur twist Franz is mouth soup his prote= st friend, you know."     "What then?" &nbs= p;  
"So that," fence said woman Monte rest grass Cristo, "you have lost nearl= "It is very fear rice wrap kind of iron you to trouble yourself about"An = enormous one."sail humor "Since you interest glove yourself edge in my af= fairs, I thin        
"Well, it is one answer of fear his descendants, table only and a great f= "Monsieur against solid de Morcerf walk question has received a letter fr= om Fr  "Why not?"  
"Ah, indeed? dived Then that person thought explains excited everything t= hat is 
"Not nearly, cat kind indeed; sun belief that is exactly my loss.""Ah= , true. Well; I shall voice division rent harbor a advise room in some re= spe"What brake impulse park trod do they do?""Come, if you roll will only= hope step put this stretch scheme into execu 
"If connect what you say be field true," smoke replied suggestion the cou= nt, smil "Because--I nail slap scarcely meeting snake know why--but = it has appeared    "Is it bind so? Then I feel vesica= l as digestion if stupid I could adore Madame    &nbs= p;     
"Certainly, insect I winter will test do so," said obnoxious the young ma= n, wit"Do test you attraction dress think so, obnoxiously M. Bossuet? And= you--what will y          
------=_NextPart_554_69DE_9BBBDC78.A194EE96-- ------=_NextPart_7F8_DA09_5B6FC6A5.C5526C55 Content-Type: image/gif; name="yrrp.gif" Content-Transfer-Encoding: base64 Content-ID: <2e3f301c76ae2b612730e0189cbc15@mayongyuwi> R0lGODdhQQEtAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA QQEtAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvPzIB6HTCtve0V+02io1vzOMxuv8/yaiV9WIMngHpsfnKHMXyBin+PAIVclG6PfZYs epWOknifkDSZkoNzgqeXpHGrk3R5KomuiLCosiJvn4GJpql1vp4pvbRtt7Mjrca1Z624pYDI0NHL r7rSy4aYnr6zwMqHt4zTqdWctubb38S/1NJmzcfOrNr04/LT9/jx+8Lu8ZrBbMkrFkpft3zl+pnb l9Bgs3LzFoqBl04gioAN9UHchO1fwXYLGw4LqIpfSXbr/viR9Bix45iVI1NmS5kRYT2OEm1yoidT 401XAw1eAhor1ENrPUWKK7PN4U+SG4+py2dypkKqLIXqpFoTqrGZxGgiFZpRExlw7Mat4rZ0adaB ObFaXBvu400+3ZCyNat2qspnO5+6fenvbyGXHXOh+3nw6kXGUgGf7LrLKLfGOA8zhrn5sqjPoB2H Hk2aGd/SqFNbOa26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPEtApIntyGgRPMVz5+bkK6C OnMk1o97oZ69Rnfn0Ft8R65djPXoy6cDSC9CeXv2I9hHjy+9Pgrl9tev5w4/fvv94P33Xn766Xce gP+h/jefgAW6R599zY1XXngkROifcwtmp6GAGXLI4AkWctjhhyJ+mN+JF/aHIHoMhliggSmmKOGE LBxI4IUNxhigjjZS6CKKJOZI4o86Crnjgi/OZyGSODJJoww9BgmkkTh6+OKAPiYpo4MVtggegUg6 6aWWHi754IPpzfhkdV9WOeaUbo5YJIgJNhlkl2T6B+abdFpJppkbXnnnmuLheSOffvJopZx9Xpnm mIa66WiRYq4I6Z6IUknoC/jx1x2Y8mk4pXx6gshkhJ72eaigXO73qHqknmmnrFhCuqkiM3L3g5q3 9uqChAf2wKuvxBZr7LHIJqvsssw26+yzzQ4wQA/T/o5QbRbSZnuttNZeC20Z3JrgrbcsjLtFuACE iy6635LBrgjjkquCuedua2+68rYbBrfqZotvv/gGbC0J/sLb7boHDwxvvtoebO+69yaMQsMLQyyw vkn4C/DCCVNssMQFUxxyv9W+m263J3McscUSi1vyywRPmy/GRWzMssDv0svvzirzvLPMM//78NAV F9xyCTbHyzHNSCSN8tI5E6zyyQDLHDC/VM/M89UwOx2z1jBfjHPQTP/g9cUbK/xxwyJr7PbPDHct N9QRc33C2WOXfcTZEAOtrtQds/t24GHTnTffhXudNtdk681D2iz7XDLgS4t9c+TkavvyyCPHjHbi /kbnDLTjV5hMnOmkP4G6b3WnLsXqrBvt+uy012777bjnrvvuvPfu++/ABy/8fZ0Wb/zxyCev/PLM N+/889BHL/301FdvvfRDDDu8b9rT0P32u30PJfgTih+DmgWIQEAB7BNAfm3mw8Dr+gUQYH/778sW P6crrG8A+wBknwEM4L78uWZ/v1JBAQbIwAYO8AAHMEANEFACCorAggasAgILhYICJOCDIAyhCCU4 AwxeEBKpqhUYFOCHDdYoBQtIAAMa0IAZ1jABNKQhCAsoAwya0IcI+CEFLTjECwbxCbGC0aB4oIAm roCFLGgiFEUgxRNUcQRXDAIUt9goIIznADYM/iMDcJhDGSYgfSUcwQ9PyEYiupGNADBhEohUJxO5 6jwuasEUp2jFKAKAhVsEJB//KEgqFpIIXFSPEMZDgAXUkAGQjKQkGeCAA/AwBj4kgRzjCEcinmCT c7TTjZYTpve8YJCBdCIVV8lKLP7Riqg8pBNVSYJDEnKPr6wlIV2Zy0EuUQcSIsABHJDDYuawkpfs ISc1acQgerKNmnQmEkVZJTmtKgWobGUicVnLLGIxlrvcJS2/uUpujtOQrNxmF3fVPwMQ05g0dAAJ bVBEZi5zmZm8Zz6bsKdR+umaKMhmLnvpSl/eko/nFGcgw6nLckoxkSUwZzrX6YNgCnCYxazk/gHq h4NNPvOI+HxmSKfpJX8aiUUuEKhEyxnQgSZUoehMKC59adCVQhRPQWCkABdogAMsAIL/+x9H6WkC IOqznkK8JxNS6KoAnSqPftQmLxHaR0Cis5swzSpWX7nSiM5yogPFqRdTYL+ymvWsZWUCKFHzPW9y M6IBpeVDF3rLbtaUoVm8q1zBuqOxqiCZJkjrEZy51tDgpwgGbWUPEhvV8S0ygzlgrBAkqwLKpsCF FIKscDDLJs1uNnt3vJ5oR0va0prWeqE9rWpVC1rPBoezl3Xta1srW+7Rtra8ge19cGvbx/I2t7f9 LW50S9ESPOC4yH0AYIWLwuCSgAAQiG4E/qYb3egqd7m4tWwXiKvIwEpXAtMNb3iti134hYq7KX1p Q584Tm9+E6Hq3YE6+8rOEzwAAhEAr3inC179RgACD6AnSOFYVAJrsFS/BMJb+/hErsYUnKqcpXZx cNME46A70M3vfsMrgQ77NwIBTqOBUVDYK9Bxt4etEFQb3NCHTpWXBYWlV8MpYRPYMq9h5apNu+vX EhAgvx/2sIc1zF8IiFiNnRywSKVphROb6qSmPCVcXcrXWMoUwgu9MkvTSdP5VlhQFT3BjyUwASGb +cwUmCcM1rpkaOrzwHlS1aVgoNIXb9mr7e0yjW0JY0Fe8a5g/TJ6xTqCMZN5AmU+s4cp/kCBjR65 ggXG54ilgKndQtnC662yVBNr1avOOMJ83rSNGUzQUhM6zCcoAAUULWQKTKDRBKQBm9XI5CUPOAq6 +qU1oyxlqfI1xyylKzlrrFVyOvjXxvYyj+sb2AO4GtHQhnajN1reFsjxo0iWNKRxneJWydlRK45i e+2sWLu+F9SGhK9e97jXUbdb0M4ttLOjjWhYD/UG+/wott/MVsRiU8E0mDB9UW1f/ELw4BEwAICP W+0XMDnJ2gZiidGQ4iEInIkBn8GgJaW+5Hr84wxn7h02PigCgPzkyG24yLlAcjCrD60wR+vKzdBy 3bZ85jnN3mp3nrzU8vznxvM50EUr/vShLy/eOH9NzZMOP6QzXTVLf7r+nC710kS96kqnOtYNq/Wt Z7oMVxdzzGOO7zVHmgpMTYJ7Ry1udcPS7ZNFtst58J2x213lKaintVle6SO8laZ+7DSxh53li9cA 3r4NbMzrt3g0KvPacXwjJ5VM60zeGrR9h5W3SUnnKbtY07qsKZYf7G52zxSu7y733HeA4bIGMID3 o9/9HI9JpUbeiCcE6b5HanvaAtSUpURQSj1v5wUf1MajL/ZVO91LPZca8TlX/Oxfz3jY0+/Ia+wk v9vMbyNk3qlz7jW5Icp8u8IX+XtmaJ8P+mUqP3/ZBH8u4+9+1gGWkLD2fHM+3Vjr/mx7f1aWFnyr R2qgd3pVZWyfVnhsd2xf52vzdWrCImYABHPUd1G053D+1316t3v+N3ERaCuKFHwqwmLuZ2rA5mDC RnropmUM2H4RFmjw94EmsEAHV4M2aINqhoH5l2+3F3HZtk9FkHbfxh8DGFdU9WucJlefB2pwh3qm B2Oht2MDJ4OBxVMOdIUDdIE62IFcOET5RnmTZh7+1lI/YHhQyD+JhzsVF3dKYIaqx0HR53VQ13Vy iCt0WIcjd4d4eAZht4dcl4Z+CBo1Z3SEWIiGeIjOU3SICD16GIhj0IeO2FyAGIl2OImUmIeWeIl8 SIfTN4GaaGJaRz8ViD+fOAWQ/ih/owhAA4R3pUgEp6g+DZSKPMWKZxeGqeOGTYZ0BPBADhRBDeSL WriFHggGN3dK8fWGyNeE5vZeFid3r1gAEFQBP7UA0whBP+VTDESL26ZUD+eF0cR9/FSMenSGU1ZZ xzZ4pKd8AAdsr2gA1PiO8HiDB6eNkJZ9vMd9erdURUgnawgg3aNSOFaCd7ZVhJeOUciMA6ljxReD dCdm7giPEHmNNbgA9LiNkQaE0DSMrgglIXIi/0h8MFhun0eQ6YiOy+d+LKhsU9iQJ/CQ8CiNC1AB MPmO0liRSHZt/ZdkYAgF4rNrmHaG5CdqyXh+CWiQ6zdXbyiFvvSMMfmSMSmT/i9ZSRPEhW6mbZKm kY24KAA4ji02fifYgqKXfjIVY+W4XioJgSzZbDK5lmw5kxXgABQ5ldrXg/uHe5OHa44lgm21fkh4 gCkIUyvofMzXfu9ngj/pHWQ1TA7QlmzpAHAZjC4AebgHjke0gTyZlyYSbux1hCaYhKaHbnWFkE4o muu2kCvJen+lmI65mqxpSdBSjIyFi40VA274iuoDjQvAmqv5U7G2LP24jmqXcY4Vh1UoQD1Vg1no ia3oBK8oirIIe8vJnLpIfzIXnfqYiYUmWNaZi9i5ndulc4sYnuI5nuRZnu5hm97JclmZnqa4nuyJ l935nliAnvIJivFZn3BG/pxLQFgYuYWyNhyyiXZZSXZyWZW11xtrV5bYxIIzlm7HSGHO6HQWkGrU 9z8FepVCZHn810w3OXmSV0S39nA1kiZr+JsYh4woGmPKmG7oh0iq94oTal8V6GiP9qFzqXtV+aE2 6o1WOYwmxXGL5XkBaXzlp5Dm16CjyaIJeWMRaokEYAFQGqVRSgEOQKX8iZUVhH83+oNcun1UeZd1 aYuWZkeaBx+cJ35VJnhA6VbqZ6QIuFWD6WnJFpJoiZqBdQF4mqd5igAY0Kd+2qcZYJOgtH9aGqb8 OZf6t31aKh65hiYqJiQoNXxdqWmi94JtKqfqNVNLSGpnCaR26mN6Gqp8/poBpFqqGIAAgvpJXbqD Boqoluel3uOpQCKAXOmVVMZpzTeSb5qpZNmAwPaAngpMYvZfoYqnE1CqyJoBB/CfZ4ePXRqmGniX OXo+uqYocVarf6dYepVjoKl+mcpFXQWSwHqYsZpqHxZeFHClCEABNtl7GriTOsqD2meZHAqHYoIp IzKCm2mW2mqELaqEJHmQSnqCTGqY+3gDdVcAGxYB8hhB7ToaXAIquRYmmhmkZOgDuFibVAdzDzCK D6sdNxeghyec1HqfPjZ2ymKi5UGf+CmgJtuy8KmfMDuf7jmzofSyNstP4GmePNuzPvuz1HOw15Gz WcCyRKuzOHu0Nyuz/ihgcimntDWLhn+lsPsFAR8LtZ3FtM+FX0QmXiGGtWnZY8O6sF4LtmHLbCcA Aa62ahzGaOH1G0JIM7b5Y4wGQf01bfwFmXuXf9uGpUj0fWIgspTmdA/gYfZjABSgAZb0Yxp2oe76 uEWbJ8ByRxgitMv4b213uZqboCcKfWJbAgXQYWkGAATAaO4DZI1GVDr5rFyqe35LcL/nj2+ylylq WValgFgVmAQYWS/qdKrGaBSQPuwDAA8AvK+muj3qZoRql6+blrHrk5bLrQ5qq70asMRmkm6KY9mU euxIuMYrAYVGZoymuMjrUcq7qv2JHVsZguEnqbYalEeKpCUZajSG/pKCSafBmgOM9GyIFgHsEwHR pgE5+HjfuG/Qmr5HALjW2iAfOammVqTT+6ZcZpSbtqkL2KnkqnEqEAEaoAH0NgEdDMLBW3byunuU KZ20EoCZGb11RqktxW4yprvlCMGAVphLubEg3ME6vMPKerXcyLzTGq2fQbsleFPb+pc1JsNwipIy ZsMM+akowME7zMPsmgM46YPNdMIt5G3pxZlG7K8OSldu9VI31m5JWph1Kqxkhbg5rMOk2mhfm0Gx CZy0qcHd2bE0CLx1K1Q+PDuCOwMZa8daS7po1T5mpVxmq8aDTMj283LZ2ciJfGFRG8lnG3+UfJ2L fMlBOMmaLMlJ/ptZ5fMsgwi0pEyIiljKqHw8nbzKrNzKrvzKsBzLsjzLtFzLtnzLM6s5OdA4NcDL SCM7//I1lBOdmgM7TmDMv+wxunw1amOdNyM0lfM5poM5wOwwmxM0ijM5KbPNzgw2bFM3xewyTxPO LvM21Ww4eZM1H5Oe54wykNM6lYM3nhPMYpPMoFMx68yewBzO77zM82w30TzPz/w14Cwvm/OemDMw gkM2CR3Q4wzP6Lw4a2M1xFzQ8Sw6T5PRSRM3D83R6Wwy2uzLe1jMQ9M39gzS5EzO5ew37ZzSHqM2 o9PN+xzT9Vw0E7M1W3PT1zwvslPN8SLSsozMuGwFQj3UVFDU/kad1Eq91Ezd1E791FAd1aljchCw AVZ91Vid1Vq91Vzd1V791WAd1mI91mRd1mZ91mid1mp91gDWxy/wABvAARzQAXS91nZ913id13q9 13zd13rdARygABywAW6dAhAA2BsQx1KdAg/QAYJtZD7wAHIN2YsNAxCgAB2g2DcAAQNA2ZUtA3Ht 2TYQ15r92TAg2RuAA4Bd2Is92DYAARxg2jog2aL91hxQ2rI9Aw8wADbp2t+C1C9AL6XjzwO9BBvQ ATJw2RemsoKswsWVxvSFWdM8zC0g3ES9MhC9BAqA2ynQAbU9nNGbtWM63gh7mjCA0hld3dRdBZdD 009w3DBA/gB/HCxcjCoqpiCV+0+AK4DneV5/InxcjNPmDNCWI8zrrMxZgzDR/NLK3DkLvjoM3jnA LWaxbdv62yZD4pP0rZWQ6txQtuElokSC4jYXjc+L89P4DM303DaJM87u7M6t09L33DNAnQK3/QJV feFdciijMiTgxyqrJ4LRjWBaciiIg85IAzg/czgCHswovdB9w9KiAzYljuQ14N0vYNU6TuTBcmld zuEp/ONJ8irUVFL9eOTpnOQKgzUxzeaHo86eYzFV0+aZgzrv/NA4oOUuMNdbXkdA/k8+Hil//h20 6uclVeZ3EzYNPd1rPuDQzOIsLdCKTuefA+OJXuVpXgN6/t4CHZDangzoOCXkgp6viSLoH95XRCji 1oHmJI4zwzw4hCPMEj7pPVPrSJ7NGu03ee7pnM7rzFGiKiKx9JHfJ9VPRxKxJPqoduTfv4zpkuPi zfzM0o7dRVPS1W45NN3PSmPpN7DpLNDprfHlQ5vBwV3jujHhJ+DtKwDuc5i/UkvuLoDutJHdMaDu KsDuuSPv897O9e7r6+7vua0D9t7dAB/wu/4C+G7wAl/wKJDwCn/wLuDw5A3e4Q3KCIte4pglj1iy C4/wDE+FFS/e427J15nxIP9COzDwDf/xkTKCrXKmMM/ATLV5wtdUIn4mL98kSWQmO64ktYKvZkoq orIk/ilk318CISpk80pPK/aN7D4f6lgSuyOg8icg8ariJLPakSjV46O0a8FO5JlSSsGuJGKP6HoZ gB1C9Bke4lxfTTLi5xASKBTr7gBA9SZg9ew7KGROR/i6kqsSbkiP4f9t6GYfIzwfKJpi6mUf6Jem KYROKZLrcifG8yxg9yWA92I+9Itf7E4f5hIL+GAP95D/KVxu+Kp+XmSe9zJ/pn/O+cy+9KF16APC +veNJpS/ApZPArnf+GE/+AP45W3fXSs2+bJ/JMYPI8MvJbHl+yDY48vv9sZv7HkfJZXP8iVw2BzE 41EW+I2/+ameIaBP+GR66tPx9JEffnCS+cWPR6BO/v6TAujS/+Ppf+/fjQKSnf2Swvrd5iBp1/k9 /6ggIAAiUJqjQJLnyKYrmrZsK8/le65wbvYzDCfa+WxEHcqnswl3zOKx5lTRbipmsGriPLRaBcEr HpPL5jOalk2z29q12xWf08Vw2oOT7mzq/j+gUuDg2B2dIWEiktlGRxqEgqLkJGWl5SUmmkLXXl/m J2io6ChoY1seJ6nqKmurq8nDQFgbhN7rLW6ubt1DB8RcB9fuMHExsYLn3IawcbPzM+YD8h/EQDI0 drY2G8HyLyBBMMTsdrl5ybVzt0IHeWAXh+/5PD0xRAd7quLDMkc834aAAgcSLGjwIMKEChcybOjw PyHEiBInUqz4sEMwfxvcWXoAAYLFkCJHkixp8iRKkh/11Wvp8iXMmDJn0qxp8ybOnDp38uzp8yfQ oEKHEtUZAgA7 ------=_NextPart_7F8_DA09_5B6FC6A5.C5526C55-- From sip-bounces@ietf.org Tue Mar 20 13:05:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThks-0000ds-8c; Tue, 20 Mar 2007 13:04:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThkq-0000ae-3o for sip@ietf.org; Tue, 20 Mar 2007 13:04:12 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HThko-0008N1-Ns for sip@ietf.org; Tue, 20 Mar 2007 13:04:12 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2KH45u3071750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 11:04:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45FBBB87.9060005@nostrum.com> Date: Sat, 17 Mar 2007 09:57:27 +0000 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU - what is there to talk about? References: <45F85073.7040009@cisco.com> In-Reply-To: <45F85073.7040009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > The problem that was raised on the list by Paul K. some time back, is > that you might run into problems when the server forcefully terminates > the registration. The client will re-register, but how does it > synchronize its set of temporary GRUU with those the registrar has? > The solution was to use reg-event (necessary anyway if the server is > forcefully de-registering users). So, the client would use reg-event, > and if it sees the server expire its registration in the reg-event > notify, it discards its temp-gruu. I can see what you're getting at here, but (unless I missed something) the intention is far less than clear in the current draft. As far as I can tell, there are only two sections of text that address this: In cases where registrars forcefully shorten registration intervals, the registration event package, RFC 3860 [23] is used by user agents to learn of these changes. A user agent implementing both RFC 3680 and GRUU MUST also implement the extensions to RFC 3680 for conveying information on GRUU [24], as these are necessary to keep the set of temporary GRUU synchronized between the UA and the registrar. ...and... RFC 3680 [23] defines an event package that allows a client to learn about registration events at the registrar. This package allows registrars to alter registrations forcefully (for example, shortening them to force a re-registration). If a registrar is supporting RFC 3680 and GRUU, it MUST also support [24]. With the context provided by your email on the topic, it's pretty easy to figure out what these passages are intended to mean. However, I fear that the chance that an average developer has much hope of doing the right thing with this information is very slim unless they happen to come digging through this mailing list. In other words, I believe that we need more clearly defined procedures for client handling of NOTIFY messages for regevent when they contain revised GRUU information. I imagine this would primarily consist of a more formal version of your email on the topic. --- And, since I have an email open on the topic, two nits: Section 5.4: "Once a temporary GRUU is constructed, it MUST be considered valid for the duration that the AOR itself is valid." I believe that should say "Once a _PUBLIC_ GRUU is constructed..." Section 4.4: "...the SUBSCRIBE [5] request, its 2xx response or with a To tag..." Either I don't understand what is meant here, or there is a spurious "or" in that phrase. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 13:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThnh-0003QF-Lf; Tue, 20 Mar 2007 13:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThnZ-0003Lz-Dm for sip@ietf.org; Tue, 20 Mar 2007 13:07:01 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThkx-0004ua-Le for sip@ietf.org; Tue, 20 Mar 2007 13:04:20 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2KH4ATa071754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 11:04:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45FBBD80.10403@nostrum.com> Date: Sat, 17 Mar 2007 10:05:52 +0000 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> In-Reply-To: <45F84AFE.2040502@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > So, Jeroen, I'm unsure if this is a criticism (we need to do something > different for temp gruu), or just a statement of fact you think we > should mention more clearly in the document. I'm personally fine with > this; if the size bothers an implementation it can use a stateful > technique and the size can be shorter. Not really. The problem is that, with the new way that temporary GRUUs work, any registrar that manages this statefully is required to maintain that that grows potentially without bound. For example, I have a SIP phone on my desk that has been diligently registering about once an hour for over 200 days now. It has had no reason to rotate its call ID during that time period. So, while I don't have an easy way to verify this, I suspect that it has kept a continuous registration going that entire time with the same Call ID. If my registrar used a stateful technique (and my phone supported GRUU), I would have on the order of 5,000 valid temporary GRUUs for this single phone, any my registar would be required to remember each and every one of them until my phone finally went offline. That's probably okay for an enterprise environment (for sufficiently small enterprises), but you take that and multiply it by the number of subscribers a typical cable company might sell their VoIP solution to, and it quickly becomes unmanagable. So, we either need to commit to forcing implementations out there to playing nice with 300-plus-byte URIs (and basically say "registrars must do this statefully"), or come up with some other way to handle temporary GRUUs that won't require stateful implementations to keep unbounded quantities of state. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 13:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi8A-0003RL-Gq; Tue, 20 Mar 2007 13:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi89-0003RC-OP for sip@ietf.org; Tue, 20 Mar 2007 13:28:17 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTi7p-0000gP-Ug for sip@ietf.org; Tue, 20 Mar 2007 13:28:17 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KHRTwF023100; Tue, 20 Mar 2007 19:27:55 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 19:27:51 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 19:27:51 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 19:27:51 +0200 Received: from [10.162.252.145] (essapo-nirac252145.europe.nokia.com [10.162.252.145]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KHRnsj002525; Tue, 20 Mar 2007 19:27:49 +0200 Message-ID: <46001994.8070002@nokia.com> Date: Tue, 20 Mar 2007 18:27:48 +0100 From: Aki Niemi User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ext EKR Subject: Re: [Sip] Review of draft-ietf-sip-outbound-08 References: <20070317161250.C08AC1CC29@delta.rtfm.com> In-Reply-To: <20070317161250.C08AC1CC29@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 17:27:51.0121 (UTC) FILETIME=[16043C10:01C76B15] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070320192756-51971BB0-33201D2C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext EKR wrote: > $Id: draft-ietf-sip-outbound-08-rev.txt,v 1.1 2007/03/11 05:53:17 ekr Exp $ > > This draft seemed to be in pretty good shape as of -07. The major > change in this draft appears to be that the STUN-based keepalive > system has been replaced with something rather more complicated, > namely: > > - STUN for UDP > - CRLF or TCP keepalive for TCP > - Indications in the URL for which kind of keepalive you > support > - A probing scheme to detect whether or not STUN is supported > > I'm having a hard time seeing why any of this is necessary. > Given that implementations need to support UDP and therefore > need to support STUN, it's really unclear to me why it's an > asset to have to support several different methods. STUN will > work perfectly well over TCP and the demuxers you need > are more or less the same. This is just asking for > interop problems. I think your assumption isn't entirely correct. Yes, implementations need to support UDP in general, but there is no requirement to support UDP with outbound. In fact, most deployments that use UDP today already do some sort of poor-man's outbound and work just fine. The don't necessarily need outbound. Where outbound comes in extremely handy is with TCP that doesn't work without outbound, and there it just makes no sense to require use of STUN, since most of the extra features provided by STUN compared to the CRLF method are not useful (e.g., learning the new binding after a NAT reboot). So I agree having several methods is asking for trouble in interop, but that problem is easily solved by not specifying UDP procedures in outbound at all. > I don't understand why the probing in S 8 is required. > If someone advertises that they support STUN, let's just > assume that they do. Any SIP implementation which blows up when > it sees STUN deserves what it gets. I agree there. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 13:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiFA-00017E-Pj; Tue, 20 Mar 2007 13:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiF7-00015J-Sc for sip@ietf.org; Tue, 20 Mar 2007 13:35:30 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTiF1-00020c-9T for sip@ietf.org; Tue, 20 Mar 2007 13:35:29 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 0253CAC27A; Tue, 20 Mar 2007 19:35:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17920.6999.963288.62617@harjus.tutpro.com> Date: Tue, 20 Mar 2007 19:35:19 +0200 To: Aki Niemi Subject: Re: [Sip] Review of draft-ietf-sip-outbound-08 In-Reply-To: <46001994.8070002@nokia.com> References: <20070317161250.C08AC1CC29@delta.rtfm.com> <46001994.8070002@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi writes: > In fact, most deployments that use UDP today already > do some sort of poor-man's outbound and work just fine. The don't > necessarily need outbound. that is correct. > Where outbound comes in extremely handy is with TCP that doesn't work > without outbound, and there it just makes no sense to require use of > STUN, since most of the extra features provided by STUN compared to the > CRLF method are not useful (e.g., learning the new binding after a NAT > reboot). exactly. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 13:42:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiKf-0005tC-Uj; Tue, 20 Mar 2007 13:41:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiKe-0005t3-Bu for sip@ietf.org; Tue, 20 Mar 2007 13:41:12 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTiKT-00037Y-Uj for sip@ietf.org; Tue, 20 Mar 2007 13:41:12 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 63890AC27A; Tue, 20 Mar 2007 19:41:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17920.7341.266448.476150@harjus.tutpro.com> Date: Tue, 20 Mar 2007 19:41:01 +0200 To: Adam Roach Subject: Re: [Sip] size of temporary GRUUs In-Reply-To: <45FBBD80.10403@nostrum.com> References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam Roach writes: > If my registrar used a stateful technique (and my phone supported GRUU), > I would have on the order of 5,000 valid temporary GRUUs for this single > phone, any my registar would be required to remember each and every one > of them until my phone finally went offline. this sounds VERY scary and completely un-scalable. what other implementation mines the i-d contains? it would be nice to hear about them 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 Maxwell@paragonpub.com Tue Mar 20 14:47:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjMX-0002n4-8n for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 14:47:13 -0400 Received: from host151-52-dynamic.10-87-r.retail.telecomitalia.it ([87.10.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTjMH-0005cH-Cv for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 14:47:13 -0400 Message-ID: <001301c76b20$21c93b30$00000000@casailvpugwl33> From: "twotime" To: sip-archive@lists.ietf.org Subject: Messenger Melissa Joan Hart Date: Tue, 20 Mar 2007 19:46:55 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C76B28.838DA330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee ------=_NextPart_000_000F_01C76B28.838DA330 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C76B28.838DA330" ------=_NextPart_001_0010_01C76B28.838DA330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hasebe yunjin yvon jaspers, yvonne catterfeld! Listing businesses = services specials packages. Bathroom driveway week, fit cool. Elenoire casalegno eleonora benfatto di miele elin grindemyr elisa. Lima anne hudgens farmer lessa tavares anderson. Wake morning, streeter = hid parkins. Now flood with out soldiers so. Nurses bus, lotto cas, emt. Soldier allotted three, liters bottled water = forces recruiting center. Visit having chance sooooo yeahlet give break needs. Sandra ramirez sara paxton sarah chalke parker? Sun rise set dj career = off flirting djimon kinda. Netscape favorites setas homepage actors movies. Thanked pizza, then, = car. Cherokee gamma rock butt pudge knockedup nick. Sitemap manage account upgrade lj. Ophelie winter orlaith mcallister pamela? Deaths iraqus wounded iraqiraqi civilian minexcess excess? Hanged quotit = was not march camp. Lafayette, napa palo alto, san bernardino diego = francisco jose! Cattrall raver kirsten dunst kristanna. Yu hasebe yunjin = yvon jaspers yvonne catterfeld, zdenka podkapova! Hill, famke janssen, farrah summerford, federica ridolfi fernanda. Tn memphis austin tx dallas pasadena plano. Include airport breezed = right. My, former vice president hanged quotit. Loved watching video = old! Tanning shopping snuck byrons series quick. Fabiana tambosi faith = hill famke. Room trouble, paid seat hate hurry dawdle. Hellip welcome happy other, foot its easy! Muster couldnt list should, studied closer great. Sykes melinda juhasz = messenger melissa. Billhere have mixture of different icons like. Laughton rocio guirao, rosa rosamund pike rosario dawson rose. Eliza = dushku elizabeth banks berkley hurley! Sc clemson sioux falls sd = knoxville tn! Las most privileged pm seen. Michael moore thanks address nation. Takes = minister across usa thought offer complete. ------=_NextPart_001_0010_01C76B28.838DA330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hasebe yunjin yvon jaspers, yvonne = catterfeld!=20 Listing businesses services specials packages. Bathroom driveway week, = fit cool.
Elenoire casalegno eleonora benfatto di = miele elin=20 grindemyr elisa.
Lima anne hudgens farmer lessa tavares = anderson.=20 Wake morning, streeter hid parkins. Now flood with out soldiers = so.
Nurses bus, lotto cas, emt. Soldier = allotted three,=20 liters bottled water forces recruiting center.
Visit having chance sooooo yeahlet give = break needs.
Sandra ramirez sara paxton sarah chalke = parker? Sun=20 rise set dj career off flirting djimon kinda.
Netscape favorites setas homepage = actors movies.=20 Thanked pizza, then, car. Cherokee gamma rock butt pudge knockedup = nick.
Sitemap manage account upgrade = lj.
Ophelie winter orlaith mcallister = pamela?
Deaths iraqus wounded iraqiraqi = civilian minexcess=20 excess? Hanged quotit was not march camp. Lafayette, napa palo alto, san = bernardino diego francisco jose! Cattrall raver kirsten dunst kristanna. = Yu=20 hasebe yunjin yvon jaspers yvonne catterfeld, zdenka = podkapova!
Hill, famke janssen, farrah summerford, = federica=20 ridolfi fernanda.
Tn memphis austin tx dallas pasadena = plano. Include=20 airport breezed right. My, former vice president hanged quotit. Loved = watching=20 video old! Tanning shopping snuck byrons series quick. Fabiana tambosi = faith=20 hill famke.
Room trouble, paid seat hate hurry = dawdle.
Hellip welcome happy other, foot its = easy!
Muster couldnt list should, studied = closer great.=20 Sykes melinda juhasz messenger melissa.
Billhere have mixture of different = icons like.
Laughton rocio guirao, rosa rosamund = pike rosario=20 dawson rose. Eliza dushku elizabeth banks berkley hurley! Sc clemson = sioux falls=20 sd knoxville tn!
Las most privileged pm seen. Michael = moore thanks=20 address nation. Takes minister across usa thought offer=20 complete.
------=_NextPart_001_0010_01C76B28.838DA330-- ------=_NextPart_000_000F_01C76B28.838DA330 Content-Type: image/gif; name="Gamma.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c76b20$21c93b30$00000000@casailvpugwl33> R0lGODlhdAEAAoekAAAAAIYAAAx1B4OBAAAAeY0BgQCFfMO8usrbxZ287koRAGAeAHweCpsiAMQk AO0pAA0zACVJCTxKCF07AHQ2AKA0AbU5CdE+AwNfABNjAkxZDlVYAIFjAJtUALtkAN1iAAd0ACSG BDiBAFN3AHRxA66ODbN/DemGCwWrCB+eAD6TAGCaAHejAJajALuRDdyoAAC6ABm5BDfKCWXGAIXI AKPIBcu3AOWyCQniACboBU7eAGvlDYfrAK7gALjXA+HfBgkATSQFMT4ARmsOSoINQqcAS8AAPeQH OQAWQRMXTUoWSWssTHoZTa0hNbkYSdQlRwA7OhY2QkA3TF1HPIpGN6Y8O8E1R+I+RwBjPihZMjdp S25tPY1oBJ5rQs5pON9TSACDOCyAPjJzNGOKPnaFSJOJNMaGPOiKMgqgPhOhSUekQlSrP3OtNqyf Ss2XM+eqQADMQRu2QEe7NFW6Mnm4OZ+4MsjBR9/BQADTNxjtMkLsNlbpNYjfSZLfQ8rjPdjfOQAA iyIFcTMAfFoAiHYAjK0AfL0AhOELdgAbdykXek0ogmQjf3IqjqkdibERgNYjcQBHhx4xcjI1d2tE g31IcaQ0eMtHiOpHhgpughtUeTReiFZpgHRohKFgcb5Yc9JoewZzdCCJejSJdF53eIB2hZp/ebGJ cdF6fgiliiymfDaTc26afoqsdJGWcr+VhN2agwC9exTFfk22clS1i3eyiJG2eczJg+rOgQPpjCXp fknUf2LZhI3YhpzShcThiNjTdAAAzR4DyDkAyG4AwIgHxpsAwMkAwu4AsgAtxRwVtTcSy1wsx3sn yZ0hzsEdwuUayQBDvyU4x0JAuGdAzHpLtJ8xwclGsttEygBezBVnw0ZnwFJZwnxSu55RscJnx95g yQuKtixywDSMxliIxHaIx5d2w8iIwOp/yQeRtiKYzUqZtFeUwHymyqGWvsestN+RtADLshvLwkHM ulTGtnK6va6/uvTy5KumsHl4f/8ADAz2APH/AAUA9/oA/wL7//71/yH5BABtyf4ALAAAAAB0AQAC Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPqjcjPYV+E/P7uHZxSMCnDJwX3RZxwsUHGfgdCfhyY sGXDk0cizlxwMmeFnxtbHoxZYOC/ik1X7rza8eHVrxdXdn2a8mzVsl0fjq149u3YuDeP3nu6NkHd yI9Lfm16eenmyZdD3y2d+u7Uz687rx56+Nvnxafz/8Ycvnft7I6Lo7+eurl47dytR+/u3W3p9rQB d67uvn96/e/9Jt+A62EnHX31sXVffP4pF+B28UXX4IITQljhgwkS52B4/QHHGmrHwWbcbajBJtl5 HpInYIklUjfigRnGKOOMNNZo44045qjjjmsh+JCPkfEoZIcMAdmQkUUeOWSGPiK5kJOgKblkfZuJ 2FqHHHoII3tWgsiibe6NKOKUVDoIn3bCYRjmg9iBiOV261lH5mVmJmfihXL+Z2d5JxoXXHrmXTnn aAXCuZ+aaJ6pW4MHpckcY1AOqlah4lEq54AEWtgenopK6h2Hfr7IqIt3YoqfoLiByWWf/Hnq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimqy5QANTU7rpgASBvu++CVO9D9Dp0L7xK7btvR/8yFHBCA/NL1L/z1jvv QAuTkjDD8kJMb8QENfywwxhf7DDFGBvcr0EKdyyyQPmSLHLJJhcU8soZM3xyyh4jhbDLCb/78Mo3 h6wyzTyjPLHFMSc1s8n+8kz0QREP3fLRPo8Mc9BGFX301EtXfS/KLlOdb9M6Q93vwjo3vHHSYlvM McckU8xy02Nn7XVXBb9tY9xy12333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eacd+55tP1g1E/oE5GeEd0aoc736KOTYjpBob9uEOuyC2R67bTX7vpGqmOksMZp m937uLrPvlDxA92OEPLISzR8RTc3xDa/uNve+u6ksw777Ndrr31Br39Pe/LXS2x+1kB37O/ZaBvt NNIwP/9t9dvHvvtB4id///7g47+//QrBmvtKZjOECHBnv2tfxc5nMPqNz37l85/ylOc/8rVugrrL GchetjWnaZBgCgxY1+TnrepN8H/FAyD29FfB/7nQeguM39U42LIZypBgHoRf/GImOxVCcHsS1B8F /41nOyGysIhus6HWdhjDkRWsgynr2st46D3rXRB7EXTd97SYPdjRz4qxE18Wx/aznbWNiRUDmwKD l8AkqmyNnxNaHM1Cwjna8Y7i0oc+SrLHktTxbX0kxR4DeRE96pEhhHxIIh2ySHttEGRqA966AtnI ilByIZX8SCY5orEQuu1pkxzIIAViSFGWcpSCPCRBLonKUqayj658JSkPCUtVGpKStiQJ1g4oxT92 q5UFQaUgU2kQQrISlqIcJimTacxVKnOYl3TmJlM3RaUp0WDAfKUwhanNVboymtA05SlxycxyLrOb 00xdJMWGRl/+UpnbfGY8z0lPerIymcUkZzzvuf/MdFLzmu30Gj/D2U98PvOg8jRnQg0azoHuM6AQ nSICm1jAKAISn7ecJS29qcp6HvSbHNWoSOGZy3NmtI8jdGNE2WjGk51tcP6MV+ViuRZ34vGmOAVd 8xSyU5jYlIdG1Mj4iMg/MOqupy9RWkvfNsSM7LSpQGzhTTopwp/OL6hbfOD9tohEL2bvgmMMX/ey OkaV7PJ9oPQaAHvowrCCr3tBLeoR6xdXn1bTgHdbKxjb6tUU8rWr/bOgD7U4E+Gt0apX7eIJizhE vy5Wrl197O2Q6kcn4jWvcR1sY5f3V8i+cIWAJV1KIzpaiS5QiQBlKguHqlXB9tWCof0iF8M4VtP/ lfa2KjUtGVvaRsNR9iuI3RtX1RLcnBr3uDyKqViKy6+THoSbxJXYYW0myVAi8i3Rw6EOm1vMkbay o2SZ3iPHy91gmneUyt2Kz9jJ0iaW15nohGZ6tcLeHKIRm929JznRIkCp6fa9BS1oMymaW9yStsAI PvB9e4Y+JjL3Ws6N7yDBq2CJGtjCCcZwhdfHvhG+FLlRA7F6RUziEnvuwdQbrkSYV1emXC2E1YXa by0CVReD7ZNoVS33vlq+/K01gosl6xV5nJMD2hdvX9SsEBXL2S7SlbGypUl/EVZfGVtxtpptLWiN 52Qtq3C2RfbkZeUWvqI+NrKe1atkPztjsx6Z/7w63rKSGdviqM5Zziy8sJ4zLEKrWTStahWjk7cK VySqmIKsraJrNczoPS+Yqh5GceTaXFgTP0TFP5G0pTfN6bppGl0ZzYt/39hbj82XLRc77ABjtshv 0hKXp55Kfxci3uaWlKDIhO9y3/xGBkLtofDUaKylwk661drUCc31PMP734kCmrv8RGY0Hd1oPlt7 w7k97Scr6mdTxxKkwe5mtbFN7nGbW4q7DV4SO9xpnny63XaFt7znPaWjEjtxueuIvaPy4oElEI7w onRD9v2U7L5P1WrFam0Je+W9chGwLkZrn5catMly2dD9W7PAe8LLMeMYqLG94lb3qnF+o+2JFP+v +BGDTOeW43njPiFgAFMOcjaP/OWZvR+1d35tc2tbqalVecj1SujaElnnPed5uUvb3prJEN30lnLU m/LuqVv96tWqernSC92yjDrHhtW6sU497Kqk+sXb/bq5Egnuhm60lmWXGa8nblnr2jPZ8mw1V2bt 3myLfewczaW0GRpq9Z6c5unO8dZ1bc5lg3PE6Db2x8814IUS1PIoTbrml755Z7/Zv38/VqhpGs2N ijPznE/9uXve3jO6/nd9x3pKQi97R9b+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/ +dCPvvSnT/3qW/9ztPddkc8VY4HdeIO9Y9n/7CESsHyYPx8DOT/6BWJ+gqx/5swN+q6gTmvp1T/b KHnev95PCvTz3//sF4AC8xHypyvi121pRV0FpIDuJX5lc2MMSGqtJ0lnF4EHAYDp138CyH+QlDTq dkbpkzHC82wGGILipVQ1JHHOVjQ4A2er1ksvuBAYGIDrN4NpVzV152cHqHi5coALmHIK2EEdlmrq w1I7SIHfh4AcZHAXKIAbWIPsx4E09GE75IM5+CtWiIMHN4UQ03cyZ4VMB4bb5j7P1n5OqIEFgYEc 6INntURHKCxZqILaxjQNOF5cs2pPI4Z5GIMGwYH/l4YbyFuWhVo0RDXEAmn0t1tBWEPtY01N/5eE iWeE6MNeFdiFGQiIl3iJUEhqW8Nur5eE1EWCxpJ9+HISvaN+Zqh+mBiFfkOKtAZwnASL1zeLtFiL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0JhTVad29zeA0BNv2MJ0SAOJ PKiNcDY9fDeA+jd55Agw1OQr3uiF5Id/38hosedx+lKOPMg759gro0WJnEg0+OhgarM0BueAI5iP UPSAZXSC6ySIIMhg0nU+asRArjgcQvho/UiHoBSRS7hEKfiDGFmFG8ORbgSD96WHIiiIDoiRDzka Ful08LM2OJaSfFiEA7mExaaQZNSGMImQOf/EbXdIkkazgESIhSk4jzqoWy7phg0WkztIYLVGiFqo jTJnlDw5NRr5jgaYYZ4HRVsYUHGYUnHIhR65UmCJYUlZiP64kcHSS41ogiKIcE40kepTNipViQLZ lr3lgYB2kORFkB0XRRNZUXD5LSeZVNcYOYHpEr5UmNGYmIpZjz2YiK1XjRMxM6FHd+NIEcU1PIh5 F1R4g9ZojoI5fiuRmXbxlPvIl20UkDZJQB5YZemmmnW5mmvJgBFIgR84gXgplUPIhRbYfbTyhWP4 kmIJejhoZB+pk1fYjyJ5gnI4lL1GlnfolsdmKz8IklCplSupj2Rohy7VkHtYnTs5iI44lv//9p1Y 6XSOOSvT+ZvVKZbX6VJaGJUSl5rOOZ/rppTZSZQxGHnyKCuwR53GyZTvGZLDCZ8wSIjJaVrXJJII JoZcuZ+xAnuu95gEmTYf6G8005fc1nRptJt2GZtdOJtjWJoc2oC5qYh0uZCBQ43adzCZg4KMGRSi uZgyOqM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqREWqRGeqRImqRKuqRMio2WGTfEuY7SyY4m8Ucq wiqq0SpsREKseZ1cKo4rOnNkko6VJRFjwiZrAo/xKIoEFhGoE6WlCJlDco8w1qEgOpuo6YmHkimV cilLZVgUxzZAU5AteZsVSpcaqZfVRDYW/5gjRZmDS9mRV8meabUp8+EmY9aVLNiSQYmg9/lzSvmf wHmeNZKSwJOFTPiP28moCmSpmHIgkNGg3YmH0XNWwllVsPmRurqeEMojj0qg9MmcvLanBkIk+YGT yjmHQ2mr8KmrBrqrwupBMQo3VnmgsoqAx+aqm+IiREKpRyaqdKh24kmTwUqeV8imMoKWVLZOi9hv gsqh/xIqXUKssbqhj+lrFTiQ9BeCG4qVrWmvj4iXjDp/e9eZg0mAgCmL9+Z9FqFp09qkEBuxEjux FFuxFnuxGJuxGruxHNuxHvuxIBuyIjuyJFuyJnuyKJuyKms36pGltqEirVEllDGz6lEeLf8bIjUb KZljJczRKORxIj2rJSFCs55hHkDbbnciG4DRG/sRs0VLtEs7tC7LaaUytaxhtUPrJzN7tVUbtEHb tSLWtWLbIj6rtVubtU97tF5raWMbtWvbJ5+Rs+cht18LszcLYm3rs1gLt5xRKr6xtFmytyWWt1vb tmYrtWjrtkmrs51DuFf7ti57uHv7t3prtWAbtsJBuElbt5Dht0pbuVpyuXjLs5pLulf6uIkLuinC uJ9zszkbHDgbsx+CukArt5/LKra7srq7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veBcG77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AHMACPMAEXMAGfMAInMAKvMAM3MAO/MAQHMESPMEUXMEWfMEYnMEavMEd ERAAOw== ------=_NextPart_000_000F_01C76B28.838DA330-- From Tree@overwet.com Tue Mar 20 16:19:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTkoG-0001HX-83 for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 16:19:56 -0400 Received: from adsl-ull-201-122.47-151.net24.it ([151.47.122.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTknt-0006lW-HW for sip-archive@lists.ietf.org; Tue, 20 Mar 2007 16:19:56 -0400 Message-ID: <000f01c76b2d$0f221260$c97a2f97@tiba> From: "week ABC" To: sip-archive@lists.ietf.org Subject: community Date: Tue, 20 Mar 2007 21:19:27 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C76B35.70E67A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 ------=_NextPart_000_000B_01C76B35.70E67A60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C76B35.70E67A60" ------=_NextPart_001_000C_01C76B35.70E67A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Niptuck there are two types. Kari whitman pm we thu, college years. Privacy terms use copyright policy. Ekeouts memo senator kerry bring level. Tony winner newlhewed alan cumming, has joined cast. Niptuck there are, = two types dream, sequences first is. Instead putting spoiling it those. Moore natalia livingston halle berry donna murphy angelina jolie? Buddytvcom, videos partner pageant clip windows mediamiss, mediabest. Miss america host show series available big awards. Anna nicole life = also, on popular. An encore emmitt cheryl do mambo karina freestyle. Whitman, pm, we thu college years fri. Views tvguide todays our. Strange or, exotic people maybe but does. More, dancing with, fave mean. Faq privacy terms use copyright policy, = gemstar. Announced roster new season admit cur dtwts intrigued. Your ratings, log = in favorites, blog. Insider, capricorn dec jan interested impossibly. Fri credits year, type video miss america? Fave mean voters dancer, will, insider. Maybe but does answer lie good = who? ------=_NextPart_001_000C_01C76B35.70E67A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Niptuck there are two types. Kari = whitman pm we=20 thu, college years.
Privacy terms use copyright = policy.
Ekeouts memo senator kerry bring = level.
Tony winner newlhewed alan cumming, has = joined=20 cast. Niptuck there are, two types dream, sequences first is. Instead = putting=20 spoiling it those.
Moore natalia livingston halle berry = donna murphy=20 angelina jolie?
Buddytvcom, videos partner pageant clip = windows=20 mediamiss, mediabest.
Miss america host show series available = big awards.=20 Anna nicole life also, on popular. An encore emmitt cheryl do mambo = karina freestyle.
Whitman, pm, we thu college years fri. = Views=20 tvguide todays our.
Strange or, exotic people maybe but = does.
More, dancing with, fave mean. Faq = privacy terms=20 use copyright policy, gemstar.
Announced roster new season admit cur = dtwts=20 intrigued. Your ratings, log in favorites, blog.
Insider, capricorn dec jan interested = impossibly.
Fri credits year, type video miss = america?
Fave mean voters dancer, will, insider. = Maybe but=20 does answer lie good who?
------=_NextPart_001_000C_01C76B35.70E67A60-- ------=_NextPart_000_000B_01C76B35.70E67A60 Content-Type: image/gif; name="but does.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c76b2d$0f221260$c97a2f97@tiba> R0lGODlhUAEAAoekAAAEBXgGBACAAIyDAQAOenIChACAf7zMwrrYtq/Q7j8lAFgqBnQTB5IcALwg AOsnAAg/ABo2AEs5DFlNAHExAaI/ALs9AOpJAABuACJuAENUAF9iAHNXAJZaALxoB+5hBgB9BBKC ADR+AGCIDoV0AJ+EAMmDAN5/BQGYACidAEynAGqZBHumAKWaALupB+eXBwDCACjJBEG7AGK/AHGz AK3EB8zHCdyyAADgABTVADHbAFTUAIXXCqzqCLzrDenZAAAANhcAQjQBTlkKR3cAO5kAQrMASNUD NwAqNhkSN0gWN2srOYUgOJwVOLYiStwVNAFHRCMzO043TFVNTYU4SJFINMxCPNY5SwBsPxdbSkBW M1pfRXteEJNmRLpYQ9VbQgCINRZ7Okd+NVZ6OX2LMp10M7l/Puh3MgCpPB6SPkycNWyjQISdNaau QM6XOeygOgDKShu0QD7BSmPOR4XMN6DJQb29OOjHPADsOBzjQjPVQV3TM3HhM5ToQb3VROLcSAAH hRIAfkQAiGwAcoAKeacMgcsJi+IAfwAjgiMgh0ciiGImcnEYhqEtf8MbgessgQY1fBQ5cjw9jFtO cXsxc642dck9jOZJdwBVdxlmdDVmflFjjIhVcqxriMZRhNdehAKBfCCBdz2DjFF8h4B6fpGIcciB jOp1cwCffRiafTmtgGyrdYarcZaUgsmkid6iigSydSa1jTa2il+5d4iyd6rHfMy+cuHJfgDthyLS hkfYdVHUgYzrhKTpfLXai+XbjQAAsi0AyksAwmYAt3EGvKsBybIBw+0GzQ0auyotuDMgtFcTxYsX tJgfsbMusdYZtAA7vyJAtj5HvmtMzoZMs55IzcZLwek4wwBdzRlotkFsvmJuzY1cyK1at7tovdRc uQh/yxuHwUl8yFN1u39xw6uBv7d7ttV8vQCtyBelwDuXzG6gtoyWt6uRxcqcx9mZuAnOzCi7yEi6 vVjLtIS0xJGzyP//8JSkpIR8ifoGCQX/A/P/BwMA/P8A/wz2//T69iH5BAD//4kALAAAAABQAQAC Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWS/BxmRchv69WvTb2S EnvSa1ayCc8aRKt1INu1XcHKJSn27Uiydgu+zauQb9q5gD/WFdh1q1nCcfUmVjs2ceOzcRkXhhsZ MWTGYx+bjVz5sWW8gUNvLDyZIObTpt02Jqx6MGvUql9njj0782HXtlvT9iu6N0PXpGVrrht882Tc akkjt32YtfDcu2vD5u27OtfUzSVfT+2ctnToa3Uj//7+HPP327GpW1/vHTb52uejL3cfX3x98Pfp s9//m3vw7p4pZphpjpVWmWGOuXVcgMR1NpuBki2WHn8UVmjhhRhmqOGGHHbo4YcgsqTeQyO2FeKJ FI1YYkMr9uciijDC9+JoHvHWYoz74VWghPD9F+CEzO04IIJoGWjZkQDiCOJ8uoFWnn9P3jYggOgt J6OSHjL5WpH2DZbcecUpWNpnyRnHI5ZLcgfel2rS9yVqTl6Z5GZX3oimb1pCl2ecU675Xp5+3nni f2Ma2V12CR6qKIMEFilhoQUKKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9AuC0BN00ZLFQDYTlstSNs+ pK1D3VrrU7jhdlQuQ+cmlK64OJWb7bbZDhQvKe/Ki6292t5L0Lz10utvv/Tq6y+74xoE78AIC/St wggvzHBBB0f8r7wNP0wwT+5S/G619Ubc8cEQayyyw/nye3FPGTNMrsgqH3RvyhO3THLCFp+s08ot 5xzzzt06TLHO384Mss3jxgvyvAG/jDS/AgussL4Sz5z0z0RHtW7Vd16N9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPf/7fffgAcu+OCED9sPRv0cPpHiGWmtkeMnJ544 KYwTdHjlBkmOuUCMb6755pRvBDlG8AL8NNOj9wp65gutPlDnCLnuukSpV9RxQ1If6znnk4euuOSW Z9478MAXVHnxmr/eO77M/2zywOQ27TTLNLtsce257h785aEfhPzr3YdvvPfhc6+Qz9QvzDFC6Idc +vT7No+s9slzvzz5sMNOvvKT5w/6xwarWNBoBkB1we9cQ8MernaXv/Ktzny+A9/+ykdB3sXvej0T 4MQyiEF1EdB611MW5iBov+DhD3z6Yx3nUCjBFVKNg0AL4QUTtq4BPmxoFRMh8XjXP9/dj3LFA+Lv /yynPR5eDnk/TFrJQjY1Ge7LaPA73fteCLEoFg5lV5SLArPIxS7ySh/6KEkYS7JFZ42RFGE840XA CEaGqPEhb3RIHLkVQINBzXTFOuMcK6LHhezxI3/kCMAOSLWa5XEgaRQIGxG5yESisY0E6aMjF/nI MVKykopsoyUhyUY9cpIkPmsfDst4q0kWxJFofKRB1ChJSyIylYp8JSsjCctU9pGWgXxcDmEGQ2SZ spKoRCUwI0nJW9qSkY30pCyXGcth5vJxd0SaE0lZSlgGs5bXbKY2tSnJV65SmdfsZiyfqcteTrNZ 4jzmOL1Zy3Zik5nvZOcx0xnOc9ozh+6b4fpuaP9Gb3Yyk5okJiS32c5iChSgCLXmJ5v5zzEmkIr3 lCITG9a0rpGzN9Ss2iUvlFEvevSjqkqiQ2YXk44mq4EaSZ4KxWdE0JEUJjCbqLNSmBGS0tSEE7zJ IBFo0gWyUIj8KyFQcco/Hg6VqEhcXhBbEsrqGbJZ5hshBZM4wuH9lKUt3N5VYbpL9lkrqkacKhFF GsEV3jSr9UPhS0+Cuij21KdDRGlZK8g6uT6whSRUnkyaCsJo2VWsLsSqWa9618DmVYIPvWdi8Rk/ GJpzphJUaVqDOtbOWVWv46OsZJe32M5ClLFKnOgUwbZWjL5tqRZ6K0hXy1oMXbQ6qj1WQw8izNT/ 4sutHMPjId24odt5sK/GiuMmXTlc/uSujsiV7SpPOU/bvs9d0nTqsIQL0ESm8bVzie4HnejL5XZT mRRCH85Aq1xcLnOW+vysZxWr3vayl7sjc54MYxur2TrTlgN1Lz7Xu1/98ve/VZReAiva2psV+Cn0 PbCCF4y1BBtLpRWR3VaZ0rMD6pZZpb3IWZfi2+2Ky6XDC+L3ono/lIp4h78ja0mdOt6vrjSv/hvs CVkK4yJSi4DQtaIIjfq5qU52ruMbohBhXNmcaLeGftUqTiFoWMGWlcgypqtOPZxcyEYZynNlcmaz DNgKAvi9/X3qBuVLXqgmtclD1R9qK7jZHlI2/8xw/jJodzpgB6stwzdmsFGJYmc9+/nPz+pzsP4Z oxY/cbTJwm6G+uXW9ClLuJzUpCcVfS0qWw+Hsl2oOl1JS+uI14DyY1Y9rVld9khTa8d99Ds5nc31 pDqAmE70qhkaTznb2r+4BjMCGbtPnj36kgYl9TDjnGti67rYi5Xo6V4oYEBz1dlFETS0p01tp7hU KtIGVo85cm2rHdqrUsx2qvD8kG4j2GiFfBpwdyzjMyv13SEWslPax+IqsxuIdXWhVP9K7p+IEtwz xDBad9i9FLuZy/32t9OQHHCBo/nJV+6ylpuivvPJ1OF0BSvCCdu9Wx/743BubPV6Ke5V0XSyQv9u s8Fd6HFju1zOyt4YBmNdbbbWPCglv7nOd76qnO8Ku7U19cXT1Vafc4rSlL4KoyvcV0MD643BnmdA iwuYTzecu0Y/eqfV2dxMLje7lt51zbK+KVYS2pTGHHZ2F37x26ZbWOg1L9eNmXQOz3khNH/61uke z1oj++8gb7nIDWnOvD+9mPm9ZUCR6VDAv9zxgg/tsidP0avzXJCXx1jmN8/5znv+86APvehHT/rS m/70qE+96lfP+ta7/vWwj73sZ0/72tv+9rjPve4jQnbbGTlYF0YXumENLurZ3FsHyYfy8zGQ5TNf IMonyPMtHtvHWsrwALe49uF7/OIXZPqkYD7/+MUP/fKj6yPWr5TEYvj23K7P/QFf/9LQDf8AK1vy bm+idpsffun3///gZ0cvM3moE0JL12uZwmiO1n75RG8rg4C+RkiXtoAGaHzJ93/l93zk91tjVkjr F4GWp34LaHUXdDv5clsms08dFkrRtYK8pjEddoEYCIAaCH0BqEEEVoExlH6U8oHv13ZCU3npVnE+ GHJFOEoWmC7RZ35MyH81mF6lQ0OO9oHS1YMUKHZTKIUMuINXCIUUqEE6439i2IQASIZUyFcgGIad Qmd551sm2ERbCD1tRUMtOHxyOD0HaC9jyH98yIdPeGhB02xw6IIBI2ai0nvnZxKj43xL6Hzf/yd9 NyguiMg+OiZIlbh7mJiJmriJnNiJnviJoBiKojiKpFiKpniKqJiKqriKrNiKrviKsBiLsjiLtNh5 0uZ0eOd9FDGJVdhzn0WJAxiCEbVuuUOCuVg72JdtPcWLSveLVYaMzviMIfd22aeLV6OMuoQpidWC AfZ+3DhfUBMzhCiOBdiNHTh/S3Rc5QhRz9OB91eAgtiLWXOOQxiOMjOE9KgyP8hPNhSEYzcyvYaG 6viLRwiDogWG+wg9mjJA7mdFQYhpDKmDvjZmCVkybHeP4aaFCjleEKmQXHiQ8qeP7XgpESmPINiR /ZiF/CiOYIhcNkRlR+NhKCmR//aRCUmNVv84jFkYa55VhOfkkxX4UI4VhzxJRVRIkx75atrogXjY joHYaGNnj3e4Xnlojiw4WsHIYvUnU+hYk3fIT19piLLCjCxBSmS5K2epEmZZi2zZlimRllCRgy6z f+vGe8TXfemFfLuIebo4KXLpkriDfs+GEmQHlwiWlHhYgs1WjgL5lUs0l+G4lfC4QZOpf994auhI eeT4XDgYlvjnlxvpgYO3M/2VmBiphiAZkBpZiGnYmhmEhf74REgZNaqJfTjyg0iokj85gf9ylCCJ gqypkbE5nI3FSy3JbHb4kMBpm4V2miR3nELJm1FIb0ZJjVnZksSZm8GJnSOHj1zYkWKpJNP/KZpg SZrR2XQiV3hdaHwF+ZGrOZS+eZ4nWZ3heZt6CIf3N4h3RIAA95i5RXgjuY7JiX/B6JTFyZGUd5EJ OodXmX8N1naNE21zE1OiI6FueaEYmqEauqEc2qEe+qEgGqIiOqIkWqImeqIomqIquqIs2qIu+qIw Kp4XUYnUCRGGmRTJRpgp0ihioiDeAZy8d4npSTvn11GOc6M7kaN4SSLN4SdTYhdbxJzcl4jURzpU 2lvsaGFZWX/qE01cGo9t0iUPIidM2ZBDt0uROTUQGU32Z54puKBbumzrWCElqZ2pdoL5xH4TGaZP shpkupv/OJoPuKfwWaXwWZu6WWbhdY6m/+OTMeiCz2WR5dKk+oEg6KmnH3Q09CeFCMpTA1ios8me 94khddqf3Cmfd9oX8vGj2nGQmDqo38mpv/mboHqqoiqbpKpftqqnxImpixIoztEn7QWeHjmfThef 8UWfu2qe9mZcZSqAZhpaFRanrJmZAtKjSLIbbDGt+RlqB9iPNDeSbneVCNiVMbefdCmjYJeLMxoS SNpbQuptwmcRdvauMXqv+Jqv+rqv/Nqv/vqvABuwAjuwBFuwBnuwCJuwCruwDNuwDvuwEEswyjEe lNEgi6EjcJGxylEcE9soG9tFO+KnGeuj4yEkB5Eoq4GyFPsjKstFiQIZXEEn2EEkMauxe/9BHCT7 US27s5Z6speRFo4isopBIDnrUTxbs0LrsXmBspyBtCvbsld0tD67sgLCFxvLsVcrsglytVDrN1I7 sjw7JlM7tGErtkkLsjeLtEdrtkRLtmmbtF1LOF87tGdLsWxLtSX7tkIbt3ILGl/7slqrskwLs2PL snaiN5BSt4FLJ1s7uDbrtAxyuHvTsVmrGUqLt2bruFxLuD26uRH7uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veA3G77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AHMACfDIBAQA7 ------=_NextPart_000_000B_01C76B35.70E67A60-- From sip-bounces@ietf.org Tue Mar 20 17:50:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTm9G-0002U4-BA; Tue, 20 Mar 2007 17:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTm9E-0002Tj-Kc for sip@ietf.org; Tue, 20 Mar 2007 17:45:40 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTm9C-0004An-UV for sip@ietf.org; Tue, 20 Mar 2007 17:45:40 -0400 Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id B00756C01D; Tue, 20 Mar 2007 16:44:54 -0500 (EST) Subject: Re: [Sip] Jabber Experiment From: Scott Lawrence To: Dean Willis In-Reply-To: <3DF69CFD-E444-43C8-A4AF-7AF71E763E6A@softarmor.com> References: <45FF6FA0.5050909@isoc.org> <3DF69CFD-E444-43C8-A4AF-7AF71E763E6A@softarmor.com> Content-Type: text/plain Organization: Pingtel Corp. Date: Tue, 20 Mar 2007 22:45:24 +0100 Message-Id: <1174427124.3528.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2007-03-20 at 09:55 +0100, Dean Willis wrote: > We hope to simulcast a type transcription of today's meeting on > Jabber. This will be in a different Jabber chat than that used for > meeting discussion. > > The transcription will be in: sipscribe@jabber.ietf.org > > We will also use sip@jabber.ietf.org for support of remote > participants and for some discourse in the meeting. > > This raises the question: We need a volunteer to monitor > sip@jabber.ietf.org and bring questions to the mike as needed? It > would also help if you can put in some occasional "synchronization > guides", like changes of topic and possibly slide numbers. Anyone not > volunteering, please take three steps back. Vijay and I took some questions about the domain-certs work to the PKIX working group session today (more on the results at the next SIP WG), which conflicted with todays SIP session. I put up both of the jabber chats, and was able to do quite well following what was going on (modulo the many places where the transcriptionist was forced to resort to "(Several people talking at once)"). We should consider making this a regular feature, I think (as well as having a SIP conference bridge that people can call in to). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 20:55:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTp46-0004H9-8L; Tue, 20 Mar 2007 20:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTp44-0004DB-Ei for sip@ietf.org; Tue, 20 Mar 2007 20:52:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTp40-0002ce-A1 for sip@ietf.org; Tue, 20 Mar 2007 20:52:32 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 01:52:27 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2L0qRpO028869 for ; Wed, 21 Mar 2007 01:52:27 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L0qRlZ018346 for ; Wed, 21 Mar 2007 00:52:27 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 01:52:27 +0100 Received: from [130.129.19.212] ([10.58.48.31]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 01:52:26 +0100 Message-ID: <460081CA.20800@cisco.com> Date: Tue, 20 Mar 2007 20:52:26 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 00:52:26.0974 (UTC) FILETIME=[32105FE0:01C76B53] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7440; t=1174438347; x=1175302347; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20some=20comments=20on=20draft-ietf-sip-sips |Sender:=20; bh=CArosPiGkN266a304+qC1Af9Yv+UXmrhZnABpvzybaM=; b=Wbc5fKRVlLnIEvto7KDoi8fdg0RBjKxZ9rcaNJQnoEDZF5Q5tllrCLOEsylrl93ws07q/IhH LNMjhDhAQ+1ikijT2TP0k+kvINUWhZL/0MWWh1m+DG5FRecldCmf5nct; Authentication-Results: ams-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Sip] some comments on draft-ietf-sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In a separate thread, we've been discussing whether we can make this draft normative and finally go about 'fixing' the things that make SIPS broken. Besides the last hop exception problem, there is another bit which is very problematic: > The presence of a SIPS Request-URI does not necessarily indicate that > the request was sent securely on each hop. As described in > [RFC3261]/26.4.4, a proxy may legitimately retarget a request from > SIP to SIPS. Therefore, a UAS MUST NOT assume on the basis of the > Request-URI alone that SIPS was used for the entire request path. Retargeting from sips to sip is a lot like the last hop exception rule, and it really ruins the ability for the UAS to verify the main security property provided by SIPS. Instead of the ad-hoc algorithms suggested as ways to actually verify this, can we change this rule? Proxy MUST NOT retarget a sips URI to sip. I think I've suggested tihs in the past that I think we need to outright forbid up and downgrades. Section 4.2 - does this evaporate if we can make this change to not change sip to sips? Indeed I think this document becomes oodles simpler when we eliminate these two exceptions. I think the doc is still pretty complicated since there are so many exceptions and variations. I want it to be, you ar eeither sips, in which case EVERYTHING is sips, or you are sip, in which case NOTHING is sips. Really easy that way, and it gives us the security property we need. > The USC registers either a SIPS or a SIP AOR. From a routing > perspective, it does not matter which one is used for registration as > they identify the same resource. > > If all the Contacts are SIPS, a SIPS AOR MUST also be used by the > UAC. If at least one of the Contacts is SIP or is neither SIP nor > SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by > the UAC. isn't this a contradiction? The first paragraph says that it doesn't matter whether you use sip or sips. Then the next says why you pick a sip or sips aor. Also I tihnk the text should be restructured a bit to say that, a UA can operate in one of three modes - sips only, sip only or either. And then based on that, how do you set each of the parameters in the REGISTER (To, from, contact, r-uri). The current text is inverted and you have to work backwards in some places to sort it out. I don't really see why the AOR in the To is relevant at all (sip vs. sips). > A registrar MUST only accept a binding to a SIPS Contact if all the > appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the > AOR (i.e., To header), the From header, the Contacts and all the Path > headers. If the URIs are not of the proper SIPS scheme, it must > reject the REGISTER with a 403 "Forbidden". I don't see why the To and From are relevant. Indeed I think a sips contact can be accepted as long as the r-uri was sips. For path, its really a double check since they should have been sips based on other rules, should probably make that clear. > SIPS in a Dialog > > There MUST be only one Contact in any request resulting in the > establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). This is a basic 3261 requirement having nothing to do with sips; might want to merely state this as fact. > As mandated by [RFC3261]/8.1.1.8, in a request, if the Request-URI or > top Route header field value contains a SIPS URI, the Contact header > field MUST contain a SIPS URI as well. Furthermore, as mandated by > [RFC3261]/12.1.1, if the request that initiated the dialog contained > a SIPS URI in the Request-URI or in the top Record-Route header field > value, if there was any, or the Contact header field if there was no > Record-Route header f There are three statemenets in the or condition. However, if the first is true, and we eliminate the last hop exception and retarget exception, unless there is a protocol error the others will be true too. This is one of many places where sips is just way simpler if we do that. > be careful about what to use in the Contact (in case Record-Route is > not used for this hop). If the Contact was a SIPS URI, it would mean > that it would only accept mid-dialog requests that are over secure > transport end-to-end. Since the Request-URI is in this case a SIP > URI, it is quite possible that the UA sending a request to that URI > may not be able to send requests to SIPS URIs. It is therefore > RECOMMENDED that in this case, the Contact be a SIP URI, even if the > request is sent over a secure transport (e.g., the first hop could be > re-using a TLS connection to the proxy as would be the case with > [I-D.ietf-sip-outbound]). why is this just RECOMMENDED and not MUST? > When a target refresh occurs within a dialog (e.g., re-INVITE, > UPDATE), unless there is a need to change it, the UAC SHOULD include > a Contact header with a SIPS URI if the original request used a SIPS > Request-URI. why not MUST? > Sessions, dialogs and transactions may be "derived" from existings > ones. > > As a general principle, derived dialogs and transactions SHOULD NOT > result in an effective downgrading of SIPS to SIP, without the > explicit authorization of the entities involved. unless you formally define 'derived' this is a meaningless requirement. > However, for backward compatibility, if a "transport=tls" parameter > is received, it should be interpreted as per the following > guidelines: > > o [RFC3261]/16.7 states the transport parameter (e.g., with tcp or > udp) SHOULD NOT be used in Record-Route unless it has knowledge > that the next upstream element that will be in the path of > subsequent supports this transport. Generally, it is recommended > that the transport parameter never be used in a Record-Route, > Route or Path header. Since the transport=tls URI parameter has > been deprecated, it MUST NOT be used in Route, Record-Route or > Path headers, and MUST be ignored. > o In a Contact in a dialog, it MAY be interpreted as a request to > send incoming mid-dialog requests using TLS. Note that this would > only have a significance if [I-D.ietf-sip-outbound] and Record- > Route are not used, and if that URI is nevertheless reachable with > TLS which is extremely unlikely. If it was the case that it was > reachable with TLS, say because there is an active TLS connection, the first paragraph says that what follows will be what to do if you receive transport=tls, but the first bullet is about sending it. In that paragraph you say its 'recommneded' not to be used in RR, Route or Path, and then next sentence is MUST NOT. So which is it? If this is normative do we need to carry forward text on transport=tls beyond saying don't send and ignore on receive? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 20 21:34:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTpgY-00036s-9O; Tue, 20 Mar 2007 21:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTpgX-00036k-3u for sip@ietf.org; Tue, 20 Mar 2007 21:32:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTpgU-0003bF-I3 for sip@ietf.org; Tue, 20 Mar 2007 21:32:17 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 02:32:14 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2L1WDZC001156 for ; Wed, 21 Mar 2007 02:32:13 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L1WDlZ022744 for ; Wed, 21 Mar 2007 01:32:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 02:32:13 +0100 Received: from [130.129.19.212] ([10.58.48.31]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 02:32:12 +0100 Message-ID: <46008B1B.5050607@cisco.com> Date: Tue, 20 Mar 2007 21:32:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 01:32:12.0878 (UTC) FILETIME=[C02C6EE0:01C76B58] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4447; t=1174440733; x=1175304733; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-munakata-sip-privacy-clarified-00 |Sender:=20; bh=Do4M4Zk/yaPQeg4/cTsBRRlMhQZpDdE+DjGOxN7yPhw=; b=Y4kIuRhncaYRwf2wlIUNjm0Lx43GpoQRMjtTkKRvGhvTqWMW3XEfOZMdShEyhe0XPvzodVL9 SXl9Z9T244rkKdGOYh6rEoHgZXgi2Jkt6lAwCTsKrYG8Y0bEKfp1NaJE; Authentication-Results: ams-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Sip] comments on draft-munakata-sip-privacy-clarified-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for putting this together. I think this is a big improvement from the previous version. Some additional work is needed I think to progress it to the next step. My main comments here are: 1. The draft is similar to rfc3323 in that it is using the privacy header field as a flag to be used by b2bua to provide additional privacy services. I think we need to really separate the cases where b2bua is required and where it is not. In particular, I see two cases: CASE 1: A UA can meet the UA requiremets in this spec (use GRUU, TURN, etc.) and can construct a request which is totally anonymous to start with. Thus, all we need is to signal to the network that the call is anonymous so that the network does not ADD additional identification information, or if it does, it removes it. My suggestion at the last meeting is that this be done with a single value of the Privacy header field (namely 'id' for backwards compatibility) and thats it. There are still multiple values for Privacy and I do not see why that is needed. Furthermore, an entity that 'obeys' the privacy header field is NOT a privacy service; it is merely removing what it had already inserted. That is different from the b2bua function that literally rewrites headers and acts completely like a UA. CASE 2: A UA cannot for some reason meet these requirements, or it has requirements around not even having its originating domain be identified. So, it routes the request to a privacy service which is really the TARGET of the request, which then re-initiates that request towards the called party. The privacy 'service' in the network is just a standin for the UA and behaves *exactly* like a UA would behave had it implemented this spec. If you do it this way, the spec ONLY needs to describe how a UA constructs an anonymous request, and those rules would be followed by either a UA or this privacy server acting like a UA. So, the only rules we need to specify here on request construction are how a *UA* constructs a request. 2. I do not advise using the Privacy header field to target a request to a privacy service. Indeed I think since you need to think of the privacy service as the target that will re-initiate, really the r-uri identifies the privacy service. This is how you can guarantee a privacy service gets used without Proxy-Require or something which was kind of a weakness in RFC3323. So for example: INVITE sip:anon+joe%40example.com@privacy-services.com This is using the concepts of rfc3087 again for how we would invoke privacy services. Your document in some places suggests that the privacy service is invoked when Privacy is 'all' and other places suggests Route header. My suggestion above is closer to Route, but I think its better to use rfc3087 techniques. 3. The draft suggests that Via is constructed by the UA using TURN *and* the network removes it. You don't need both, and using TURN is problematic for the Via header field. Signaling addresses should be constructed using non-TURN techniques (Contact and From are temp-gruu), and Via contains the hosts IP address but it is removed the proxy when privacy: ID is present. 4. I think its also really important to note that the best we can do in the absence of a privacy service in a trusted third party domain is, that the anonymization function doesn't reveal the identity of the user but will still reveal the identity of the domain of the originator. So just because a header reveals the domain of the originator, does not mean it needs to be fixed or removed. Indeed, for this reason, history-info which is inserted by the network, and even record-routes, are not revealing information about the *user*, only the identity of their *network*. A user doesn't care if an INVITE says that the call passed through proxies edge.example.com and home.example.com. How does that say anything about the identity of the *user*? It doesn't. So these have no user privacy implications and do not need to be removed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 01:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTtb6-0004zL-HT; Wed, 21 Mar 2007 01:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTtb4-0004zF-4M for sip@ietf.org; Wed, 21 Mar 2007 01:42:54 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTtb1-0007Np-Fw for sip@ietf.org; Wed, 21 Mar 2007 01:42:53 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id C6850AC278; Wed, 21 Mar 2007 07:42:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17920.50633.665604.355955@harjus.tutpro.com> Date: Wed, 21 Mar 2007 07:42:33 +0200 To: Jonathan Rosenberg Subject: [Sip] some comments on draft-ietf-sip-sips In-Reply-To: <460081CA.20800@cisco.com> References: <460081CA.20800@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > Proxy MUST NOT > retarget a sips URI to sip. I think I've suggested tihs in the past that > I think we need to outright forbid up and downgrades. yes, this was discussed before and i support the proposal. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From keelboatykuse@commufa.jp Wed Mar 21 02:58:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTulo-0001Cq-D2; Wed, 21 Mar 2007 02:58:04 -0400 Received: from r-124-18-198-4.commufa.jp ([124.18.198.4] helo=commufa.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTulk-0005P7-W4; Wed, 21 Mar 2007 02:58:04 -0400 Message-ID: Reply-To: "Jillian Bryant" From: "Jillian Bryant" To: "Suzanna" Cc: "Wendy Hayes" , "Matt Meyer" , "Enriqueta Collins" , "Rhoda Baker" Subject: Can't wait anymore Date: Wed, 21 Mar 2007 03:41:33 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_9B0_F077_C523F91C.DD841D54" 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 X-Spam-Score: 0.9 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 This is a multi-part message in MIME format. ------=_NextPart_9B0_F077_C523F91C.DD841D54 Content-Type: multipart/alternative; boundary="----=_NextPart_81F_95A9_85D44827.94EBE481" ------=_NextPart_81F_95A9_85D44827.94EBE481 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Patience, madame, I attraction fry monkey am jealous coming to it." "Ye= t I expand collar gotten think alert I hear her piano." right "Sir, i= ce adjustment check you alarm me.""It rail polish is Mademoiselle card Lo= uise d'Armilly, humor who is playi "Ah, understood yes; what spun histrionic island could I say?" "True,= approve ground we must caught be quick, flat for we have scarcely ten t= hrust "Ma foi," tame post frowning said Maximilian, in consternation. = "That an silk rejoice money unfaithful tutor, tame bought over by the ene= m "That's fortunate.""Well," harbor said yearly Madame stretch tug Danglars= , "come and undress me"Nonsense.""Madame," said Lucien, play playing tick= le with wipe concentrate a little dog, "By the Corsinari?" wonder whine "Yes, you are right; I am cerebric cause= but a poor friend to you man "Well, what welcome does it strung pig sig= nify, Valentine, so long as   "Precisely. fat Had stolen away this cast brain child, doubtful in order = t "In April spell you went to dine head ornament argument at the minister's= Youedge "True," said Madame profit Danglars; division need "yet I think= this wi"Sir, lose boat you pass bless are tempting me?"lupine sand "To a= sk offer for an engagement hastily at the Opera. Really, I "Hum!" arrest drop try dreamt said the major. part outstanding cork "I = do not think blown that is the case." "However it may rhythm be, country= Valentine, you easily must bulb not be ala "Some one point night has told you the swept heart secret; or, perhaps, y= o self thought "Sir, call let short me see my right-hand correspond= ent." "Ah, yes, ripe consist it was just after check root this that you spoiled= "Go, took Cornelie," said sun Madame Danglars, chin bound "I do not reimp= ress rightfully "On say the contrary, do not look at him, asinine but at = this.Cornelie education obeyed, inquisitive and shoed the lovely next min= ute Madame Dangla store trouble shrug "That sling who was here?" "You girl think to reassu= re me cart offer when ramal you say that, Maxim "Pardon me, knot report = you are right. I power am expansion a brute. But I was "Really, rudely your possess dive boil manner of speaking"--deep nut road= "Nothing," find answered the baroness."What is it?"And yet, copy power a= s she could scarcely breathe, before bleach she rose a rule breed pump "Your history child--your son--your Andrea!""Well?" "Mon= sieur list Franz is lay inquisitive his protest friend, you know." paste "I scratch did hurt guess it," after replied the major with the gre= at page comfort "It expresses my thought meaning, and bury that is all I wan= t.Probably the sleep baroness taste made regret thought this unexpected v= isiplug "What? Do you not know judge grew these pocket bits of paper?"Deb= ray was start stop petrified, not compare hammer only to hear Danglars sp= "He is," said Monte test Cristo; family "when the stride lay valet de cha= "What then?" "Monsieur country explain de Morcerf burnt plant has= received a letter from Fr   "Ah, dance ice noise very well, very well," said explain the major, clutc= hfit "M. Lucien," said the asinine baroness, work across "I assure you I = ha ------=_NextPart_81F_95A9_85D44827.94EBE481 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"Patience, madame, I attraction fry monkey am jealous coming to it."&= nbsp; "Yet I expand collar gotten think alert I hear her piano."&nbs= p;    right "Sir, ice adjustment check you alarm me."= "It rail polish is Mademoiselle card Louise d'Armilly, humor who is playi=  
"Ah, understood yes; what spun histrionic island could I say?"  = ;   "True, approve ground we must caught be quick, flat fo= r we have scarcely ten  thrust "Ma foi," tame post frowning sai= d Maximilian, in consternation.      "That an silk rejoice money unfaithful tutor, tame bought over by the ene= m    

"That's fortunate.""Well," harbor said yearly Madame stretch tug Dang= lars, "come and undress me"Nonsense.""Madame," said Lucien, play playing = tickle with wipe concentrate a little dog,  "By the Corsinari?" wonder whine "Yes, you are right; I am cerebric = cause but a poor friend to you  man "Well, what welcome does it= strung pig signify, Valentine, so long as    
"Precisely. fat Had stolen away this cast brain child, doubtful in order = t 
"In April spell you went to dine head ornament argument at the minist= er's. Youedge "True," said Madame profit Danglars; division need "yet I t= hink this wi"Sir, lose boat you pass bless are tempting me?"lupine sand "= To ask offer for an engagement hastily at the Opera. Really, I  = ;    
"Hum!" arrest drop try dreamt said the major.   part outst= anding cork "I do not think blown that is the case."  "However = it may rhythm be, country Valentine, you easily must bulb not be ala = ;      
"Some one point night has told you the swept heart secret; or, perhaps, y= o       self thought "Sir, call let sh= ort me see my right-hand correspondent."     
"Ah, yes, ripe consist it was just after check root this that you spo= iled"Go, took Cornelie," said sun Madame Danglars, chin bound "I do not r= eimpress rightfully "On say the contrary, do not look at him, asinine but= at this.Cornelie education obeyed, inquisitive and shoed the lovely next= minute Madame Dangla  store trouble shrug "That sling who was here?"  "You girl think= to reassure me cart offer when ramal you say that, Maxim  "Par= don me, knot report you are right. I power am expansion a brute. But I wa= s 
"Really, rudely your possess dive boil manner of speaking"--deep nut road= "Nothing," find answered the baroness."What is it?"And yet, copy power a= s she could scarcely breathe, before bleach she rose a   &= nbsp;
rule breed pump "Your history child--your son--your Andrea!""Well?" =  "Monsieur list Franz is lay inquisitive his protest friend, you kno= w."   
paste "I scratch did hurt guess it," after replied the major with the gre= at   

page comfort "It expresses my thought meaning, and bury that is all I= want.Probably the sleep baroness taste made regret thought this unexpect= ed visiplug "What? Do you not know judge grew these pocket bits of paper?= "Debray was start stop petrified, not compare hammer only to hear Danglar= s sp  
"He is," said Monte test Cristo; family "when the stride lay valet de cha=      "What then?"    "Monsie= ur country explain de Morcerf burnt plant has received a letter from Fr&n= bsp;         
"Ah, dance ice noise very well, very well," said explain the major, clutc= hfit "M. Lucien," said the asinine baroness, work across "I assure you I = ha        
------=_NextPart_81F_95A9_85D44827.94EBE481-- ------=_NextPart_9B0_F077_C523F91C.DD841D54 Content-Type: image/gif; name="fydazovo.gif" Content-Transfer-Encoding: base64 Content-ID: <161f601c76b6a9d228999055dc9fc3@keelboatykuse> R0lGODdhQQEuAYQAAP///wCZ/wAAAP8AAOfp7dzZ3L/G3Zqr32ZmZnKK0z6EvswzADVxripjoYyY vqysrO7bxeO8itCzh86UWq6KW5xxTv/hm//MZpRgKjorO1pSWuiMjNxSUuFrawAAAAAAACwAAAAA QQEuAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvPzIB6HTCtve0V+02io1vzOMxuv8/yaiV9WIMngHoAhX6ChzF8gYt/kImTcIpukH2X kWwjnS+bkaCVj4iUg3mGnyJ0moGfqSmwk4CYq6eUdW2dqHO2pZ6VjKbAt8DBu663ZcrIur6stcjQ uNXRsbEoraXUp9Tdh9/S19Dbps/EtOPWyuLZzKTqeubk19P2+M3swqrv9NrybNW7xC1fJn7OhiXU Z62auTihLCE65i3duYQOD1o0iHDYsn/oAirE9dEdwGQX/jHW4/hM5b9waCg2rKhyZEaIwl52tCmw ocZ5/HQCXTlTVy4VvSZqbImPZcVlYgo2BUnxoT1jS5vK2gnyZk2v+3AqBUp2J9FVXWVSNTsGJsZ1 jaahhZuV5taUYMnNPSdUbjusbPUC1qq2rlt473xCTfxUYc663pByhUxSJNO0rx6XDCy4J0N9f/GK Gk2aZ+nTqBGLTs269ZWIrmPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMr5yKgeXMeAlhEBzDd RHUV121kH7J9eZfr3WmEFxF9PPkW5rOk934l+3TnJ8qDf06dPgn770fg14/CefX89tXXHYDu8Ufe fudR/qfgffXx9x59/xkIn377lceeeCVYmOB9+S244HYdhphgh/15+OCIBjLYoIcmbkjiiRmG+GKL 50VIY4AXylCgjSp+KKF1GaLIYHoApjhjkDQ6aKSLG/Z4pI8WkrgkiznqGCSPU9oIIpJSCrhCkUwK iKOPTSrI45ED/hhmlCbi51+ZVcKwY4pZqtmjkAVSyWWSXe5ZpoY32ulkmFCaCaSe68VZop1bCkmm iiKS2eegFDraKJZNailopY+eOSWicCqK3psUpumim9ZpeuCSIEI45HymYkrlhAe6CiSCtVKaa6mf iroIkXfukKivxKKHHZLQFavsssw26+yz0EYr7bTU/lY77QAD9JCtCNsSge233WI7grjW3kZuCeHG kG4R55LbbrdMwFtuEueOu229LKzLbrj8AoCvEv/Oa4S47oL7LbfZFkxCuu3aqy+449prwrsL1wsx whj7m3C/Fh+MsMHyatyxwgELrMLBCmvssMoWR1zwvS9/DDPME/e7csYpx6wzzSr37LPEPlPsscku 5Mxzz/8+vPHGLBNMM8ohizz0xzcDbTTOPKf8M9ZAIx010ShcHfTREXMrccJN+6s2yWtHrTXVDtss 9txHJ1233F+DXTPXY2e8cNlSBw7xxYNP3bXQ8npMN99ib+314WTrncLiVDtt9uUrDw01vJv73Xff /lcrbrnIj5deutaI5y251XhjnDPgflPsuewdV/z5xa4/zTHnmvM+du1nq766DCWXZncTxQ9PvPCi uM28tl0rf0Pyox1Pr+HSZ6/99tx37/334Icv/vjkl2/GsNGib/5s/rXv/vvwxy///PTXb//9+Oev //7892+/mP7jH3fWpyj1zcCABAQOAmOwwAT2poEvQB8BCkBBAjhwNxB0QaImWAACeLCCF8RNBo2V ggIAoAAGoKAKKWgAA1gwhLQZoXRUUIAD2PCGOLyhAWqAgBL0UAQ/hGF7BoiCAiTgiApIogKOmAAl HnGHMwgiECMBK16FYQF+kOGXUnCAJDKAAQpo/kADktiAL4JxiS+UQRCluEYEsLGHP4QjEN34BFwB SosrWIAe89gCPWJxBH48QSABuUch/PGQ8SHiCbpYRgaI8YsKMOMZE2DCKI6AjVPMZBw3mUkASDEJ d1RSpsQUIz2p4I8AQKUgWYDFVopgj4UkZCoP2UpVBgGRhwrCeAjgAEl6UZKQfEAaY7BGEnzSk52M 4wmOCUpW0ek5aEKfLWkZS1ymsgSuNEEsX1lLbs5Sm9/kJiqzCchwXvOctgxVslJAgAeEUYzwhCcD EiBMG8jRmJd0ozI1aUx91tGZo+wUnfhIAmvicpzYHOQrzenNQsIynQ49JzohetCFSjRYPkgP/gEM kIB4yjMBULQnMvE50pFysqTFdIKnsBSpJLESmxZFZznTOcttbrOhtGRoTGs5SJoiVKYXHWhGVcBB Azigo49MgANSOEwaHHOfdDTpU+f4Tyax1FKrcsE0d8pVml5znD7t5jdvGlSIrtKiFc0lEHaJwhS2 8AEOcMADWpjCDt5gqlRto0n7WVImVHFXapqPKVPwU4laM6gLzeZNHxpOxiY0seVEbGPRGlOM9mCX HsysZjfrQSYwkzUGVKhhK+tVhfrRodQsKFm/CtbCFtScaUXWWsWgz8+WhlRD8Kpkc6BbglpJCHgU 4m5zS4PeHgu4wgVDcNWaguUmMrnIce6t/gJI3epa97rYhR8As8vd7lpXkdAtjnRlG97hjNey5f3N eYWaXvWCt70KfC98fbNedc5XN/Ud7AggwN/+QqCp9yVNfncZgQJL4MAFLvB/AXxf43phwCgggIEn cOAKV1jBDMavm/JL2NW+lpU2Xa1pRfuD2LJ3nSaAQAQkQGELH5jCLZZABCBgz6h20gT7HGKNTmzI yKLAwa7M6WLF6ljiIhbCJpAwi11c4Qk4OcYSoLElb5wC2w5RVq/CETRhsNWa/tS1XxXkNIks1tdW s5plhS1lyTvUJLMYyk9+8pJfHIEpXzKZNs6xP60QyuZqSEvq6/KXuapasg65sWWWZZjR/krRNR/W vjroDgFYTIEnV3oCl46zkykgATv7MJn8RGkVnvTcJwUapqMdbVhDrE0y61TVp62sjx+dTiSb4AFO rgAFMp3pTe/aAZUkJgrwClUseKq5WIU0OD88aMiuEqxiRvSrEWrWZQP10fqNNAoMsGtNx3nXul5q hlnw2TZGVc82jgJ4eCwpCYV21pFVpU8XfWjHFlnR5MT2ZK/N3DYn+QEU0PWuwV2BcD/Arjz89F5D jVcotA+wi5LSlmMg2mbLmpCtRa04C/3s1vrYzM2utXxH0M6Cm7zgFJhrsO96Z4YXW9SgLYJuHVzc mv9WlylQsQQewHOeI7i/44bBnvG8/nBzowa3PVYCzc/KwJEDgAD+jbrU+Rv0AIfB1iWA+tS3TnWr 3wHrJOCs2MXudTSAvewi5I531872trv97XCP+9nRbpu50z2GTr+7bOyu99jwve+t+TvgUyP4wZ+m 8IZH9Rn+PvbGs/wFDZ/CX5Xu4Y93WN4iDvHSa2BiZQeh8aCvugru2QIrS8GOSre84glL70SPVcib twG27d74Do6dgk7tKzLPrcw857OY6R7gsUuE9AadmtmmJfRMo61aaSO2zMnfKpqBil5hnUCzK1zh B1X4wZAK+5O8n+K5Qy1VKisSy5WKJpdRHXLLx/qxzde4oRH55Ubz+8gjx372K8hB/v6j0M6YBGop pWegdgTDV2qEcnzxtoDOllCs9ljyV22s1VNMl1Yih1xJZnuht1ktFEW1RVKiNoBztGcpZQQHeCim tn7MxoCLBk7Q1mrSZmjLt3rwdn/Vp21JVlf7t4MsdHAACILA13I51nK6d37s1lIw8gKFZXGSFWTe FH+uNn8NqG8RZYPslgPhgUI9t4VcyIXeB3kKB3O793IiaH4YCHEIyCITx2U2xYK7NWI9lVoY13Fz eHGsxYAXiHMRRld82Id8uHJCF4YlKEe+N4JEaHoPJnOsV2I213Rn6D3FBwSxtwOTqHoktFYclnh8 lneaeFuc2ImjgXigmEWfOIq//lKKpvh1aid3rAh329WKsOhdr7h2qJiKi1eLtlgGopiLZLCLvCgG vviLyoWK26d9wqgen9h/PCh6x6gEjMeDK9RCzNiMJph3G0VX0NhW04hjYcg9lahjepiDBnAALUSO 41iO6JhCCWeGujgFJGZtp6R5YoZ536iCs+d0NXQASnUADmBD/ZhDdLWNgthPwPdGBKhSmdhHisZ0 rKdYrmdvrieJF2d345hDFmmRAvlpAVh+C7dXiCh8VlJ8a6iQyDd9YEZOzQeFOOWCHteAidV+bHZZ 23aRNHlDGYlPG3lSB0l6fpVtxEcrq6KAjGaS7teEYxaDZnVm1AZTRIl/j0hy/hV5kXFlkQ5wkyDI jWIohEW4BAg0cYCmgqoXW2MmhSr5ejDYgjkFf0Q2kU5nVHH1lkp1VHE5lUplleLnQyR4iEP3kUXQ lcnmkzRoUF01j5gHgxFobTxVhYpngf0mkydQAEf1lpHJRJJ5RA+wjmK4k1rJl7gYWL3yUiu4Zi3I lAtZlvc2mDRIaJ0HmDcQHu3ERLBJmXF1RFWJmQOomZ7Ue+r2W+oHlktIWs82URAYhfaXb3ZYhavJ d68Zm8ypVIAYiEB4T4NIiETYBH75KMYnAxXnhqWllBpXUxzHknXYhGpGfVeIA+bxmgjQnJZplzmS iTMnkTPwjc8IV80pVy4k/i2RyIipN58HZI0q9FZb2EIrRI2n53TKmI3cZ6AOh6AbyFkMWlXhGKHn 05lUkJDpNWCxuKEc2qEe+qFvEowUCo6zNaIV+pQmenUWmqIXuqIseqAo+qLf4aI8UFslKGwiNaFm UI+jZqFjl6Pkh6PA8Y6pOY9nCX9exqMkeY8xKgIW8Jj714G5t5kGeWe8t0lBCEc6OYYEGUEQgnT7 SYmWOKZmdlHveKZKqoRs2aRPegIQsINzNaWa9HIcSac6uaVaSn4feVU3qAOClnypNoMzNZZHKZ4b 55J36GiNiWJhZwGO+qiP+gAV4AAVYKOciZd7qZV6uqmZaaUwd6OXqIaJ/gSmgEKSLCiWDihvOvWQ YTWFT5iSB4WSntea13cBtnqrt4oBGbCrvLqrGmCVzHSbeelyw9qpPDmCwYcd68YhAeKVIyKU1CeY qxarzPeqi5mkx4mHa6qjIkAAuPqtuqoB4jquGYAAwLpMmgqEQVqAIfipNYB+gSJQahqa0fqGE/V+ KWmtHzaa2aqoTsmtTydj32qrFTCuBqsBDiCn6uquDJeug7h7DuuI5qEqpGaqv2mmwVltZ5avaplq rXp/eViiJlAAUFZhlWqpwKawh/h7K5ubhsiuWaqXfKkquhIpSaiEbSiab0iWG1uaIDee89aUIfsD rlkATLZzXThX7nlb/qgHcUhYqre0iD5Qj/TJiWL3pju4tMvBYWnaiBT3n03KTo73LGHqHSIqow0a tmhrbDS6tj2ptm7bo3Abt5K3iiD6P3ebt3q7t+7DmtpBtzM6t4CbtgA7uC0quE/nX1pruBFUihPU ZAi2uIy7RXCrZHNmYVI2uURrtUxWspmruYy6uSkQAQFXaU22axVmXsw6PMopARQgV7jGYhXgcyz2 nGB4lSR1qXV0gmPQtbsZthDgZPXkuhggTJPGYpepsuWmorybZe4BtX1UeXbYavRopOMpn0xauAAQ vJjWaQQQcBb0ZikHpEbXsPwUfir1maXUm/M6XO4LWbA3nCtJBNkr/rIjO3AUYEH/BwEDN7vkW4B2 SlUuu5UGqL6QkoBgOZQWJ33VOr+nmajgiajQp7Oz+rcowL/glrxPNwEChwEJa5tYGcCdap0G7JmE YqqiiaqFZn+ydJgdW39nyZgxGbphF3AmJwEUxMEmhwFfqEZ99YFFF7HsWI0njIJrAq2CqWqEybEO HJHU9n7z5q9D628nIAEYcMUYcHJXXAFZbLuB+LBBzKkETMRoaMRqCL2nxH6naq8vKL9mea0SuK8y 3KfoSVRcjMV4fMUaoMFAWqecCsai8G7Kd1hBK5wq6cKw6rHMN8fnSasq8AB5jMcIK7ngJ514Nn7s anZAibOqqrPd/plxaVlxIgZb08eUMEnHjhxhEkCpeSyus/u5whWf/KmdYKu928tfq0ypkypXBfCm kis9vkvL/nlz9pt1nMV/mfVfoOuYtqxZ3ZpGzrzM1oe40kzGxVzN6UvN2Ny2GrTNv2vL3mzNRMu3 5FzO5nzO4ZzO6rzO7NzO7vzO8BzP8jzP9FzP9iw1z4M86mI4U9PPKQoy+QwwAY3P/CI6aoM5Iyo7 MjM7Be08rIM9MjMzeUM59wI7FFoyIPM5BL03WIM7FbM5EH06WYM0MhrSuRM7NmM7jPM1MeM4cYPS cDPQv8jPBmM6AM3RaeM5Kq3Q6NI70XM5Jm2gtMMwvjM5raPT/qzz0yuN1E+T0CmNOvjC07czMycw 1A4t0hMD1E5d0xFd0D3t0V0t0RgN0mNNOGB90G1jolwdPEodOFU9OqMTNi+jOh6NPbwj0+9MPfeM BXq911bQ134d2II92IRd2IZ92Iid2OIDdRGwAY792JAd2ZI92ZRd2ZZ92Zid2Zq92Zzd2Z792aAd 2qL92TP2yy4AARvAARzQAaw92q792rAd27I927Rd27LdARywABywAaaNAhGA2xsAy4qdcx2g23Xm AxCg2sc93DEQAQvQAcJtAxEwAMvN3DOQ2tVtA6kd3dYNA8m9ATiA27093Lst3RzQ3TuQ3Nn9Askd 3RhKzxAw/gBWWd7KAtgwoC9BkNEwjRob0AEy4NzKuskWfFymclwzNMP7XNUW3QL4DQRD3dZIgNfa yd0p0AHrfSd4tB4TO82onC8h8zYMvuA/oNBxHS8SHgP9DQMEYFx54iVXUkUCjiBJiH7RJB+woinN OiZwfdM5HdUuozQNAzdoDTw/088+/TiI89ENfdZu3eQlnnXnzd5RjmwH/CdICCrtZrNUHiFcfivu 9peVkzVe/eREHdOiQ9WkU+QpneZY7TVMQzqU49KN0zSqwwEUbgKNTbmMgiwz0ig/MidbLkpCBSbx SiVxDuKYsztv7jRMw+hbo99VQ9NL3eZQXTNivtOqY+Ev/uDYeg7mhQ69eQK1Al7lH2IrB3xsD4fp fGM6f5PoaLPor542r544kWPkD07pl+7qb73qrG4CnO4Cq93p8lonO0ZehO4oZjwrWN5n2NnTk97r if7SZs3oS1Ptzg7TUU3Rud44ATPniE4Cv94CHQDeBs4nfG5VZgwmLZXsoeTngjXsk/4ujf4wX83m cC7vaV7poHPpZ+7muJ7Uz07nKhDuLDDuXyKSY3ImX5oqgbVSuUQqqMIho5Tj26HvJFM3Fs3TJH7U tWPVvnPxbP3SDK3mUv3kJUDwK2DwZreojljBM2DfaGA9Jj7w5C7uNX+ijXzgOf/yJz4GMn8Ea+7r N5/y/kMvMDB/Bj8P9EENACivAiqP3j/Q9BVe9FCvA1KPAk9f9Txw9SeQ9Vpv9VSP9WGP4N3c4WWP heP13oE+Bga0XFxvAl5fzMuV4eBMxGrP4WefA29fAnGPgGPi4kEZ+IYC+IC/yfKxuoO/ukCp8A6/ I+pu6oA2eaC+ZRRfI1tSIU67YanC5TZuRaLubsxO8y/Q9yjYJRT7ZzBCs6FvK5z/8MqebK1fSmbS 5wAlr39f6lhl6lmV+nvOp7if+LFf5f8Br+A+9nBv/HsecYKegq/v+lfyXIm//L0P/cxeJH/m/OOB JtJPKag+w6pv7mnS+C6w9yRA+n6CKBPS5ZaCW7Ri/vhGAh8FDurm3iLxP/9sMvz4r/vn/yDwP1Cq z/4gIAgAKY5kaZ4nMLKqi8omCre3nMvbpvsk75db1YZF3O1VOv5YSyZx6YQii8qncvpMUrkxY3Wr i+Km1+7ZZ56NrUzxkSwV5oJ0WaRzx77L5G8ZmpuYCF8LINtcm6DiENEZJGNg09YfkllU5OWmJGCW muHkHkBHxCgJBMeopeMlzWFh1WvKS6yVUyHiTKxW2CysrpTcbxqxrVwKJ2yl0fEu7rFtjbPwNDLz MhwdB8QpyQKBt/g4ebl52Hm6ea+6dvv7ObtO6nhHDzx+vrq8fj86PD9/At392KBHXIQFAxcybOjw wCHEiD8WdKt3TyLGjBo3cmRosFyqih1HkixpkiSEAeHKRVB18iXMmDLbQSiVrgO3mTp38ty54OK5 DTl7Ei1qFCKEn/AiDAB69CnUqOMICDWFjwDOCCulcu3KleqCDlvz1eRg0yvatDrzhBUpEIJQDmbt 8ahr9y7evHr38u3r9y/gwIIHEy5s+DDiwR1wyt0w1iGECBESU65s+TLmzJo3X5bsVi3o0KJHky5t +jTq1KpXs27t+jXs2LJn065t+3brEAA7 ------=_NextPart_9B0_F077_C523F91C.DD841D54-- From sip-bounces@ietf.org Wed Mar 21 04:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwQ0-0003MG-Uh; Wed, 21 Mar 2007 04:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwPz-0003LA-4N for sip@ietf.org; Wed, 21 Mar 2007 04:43:39 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwPw-0005tR-OF for sip@ietf.org; Wed, 21 Mar 2007 04:43:39 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 09:43:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2L8hYwx022210; Wed, 21 Mar 2007 09:43:34 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L8hHmB025522; Wed, 21 Mar 2007 08:43:29 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 09:43:28 +0100 Received: from [10.61.65.65] ([10.61.65.65]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 09:43:28 +0100 Message-ID: <4600F02F.10406@cisco.com> Date: Wed, 21 Mar 2007 04:43:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Michael Procter Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 08:43:28.0236 (UTC) FILETIME=[FF16BAC0:01C76B94] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3069; t=1174466614; x=1175330614; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20; bh=Hdw29oIhw6cb0DMlA7Gr54WjSnz7TyNANqHHVD1Lzwc=; b=gENZAD8YNZX9WV2vgxp6XcVbi+ExTj47gZKMCVqllAPJnv8KNy97KFy5Bm6AFj+33NbOS+o9 dplJO8jq+e2O/V2aRCuur5k0jjpLG61KepLI0W6ayt5uk2UCFI+0Dlar; Authentication-Results: ams-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Is this discussion moot at this time? Paul Michael Procter wrote: > Paul Kyzivat wrote: >> Michael, >> >> There are more cases for this. A fundamental problem is that saying >> "Supported:gruu" says "I support the gruu option". Its at least a bit >> weird to try to make it mean "I want you to assign gruus for the >> contacts in this request." > > If a REGISTER message that includes 'Supported:gruu', means 'I support > the GRUU option', then I don't think it is particularly weird to read in > the additional meaning 'and if you also support GRUUs, please perform > the appropriate action'. > >> Suppose it meant the latter. And suppose there are UAs X and Y both >> registering for the same AOR. X registers first, and indicates support >> for gruu, and provides a contact with an instance id. So it gets a > gruu >> back for its contact. Then Y registers, indicates support for gruu and >> provides a contact with instance id. The response to Y's register will >> contain contacts for both X and Y. And it will contain the gruus for >> both X and Y. But it didn't cause the assignment of a a gruu for X. So > > This paragraph appears truncated. I think I agree with what is written > above, but you may not have reached the punch line! > >> Then consider a similar scenario, only X didn't support gruu. Now the >> response to X's register doesn't contain a gruu. But does the response >> to Y's register contain a gruu for X's contact? > > I don't think it should contain a GRUU for X's contact, because I don't > think a GRUU should be created for X if X doesn't support using it > properly. > >> As written, the registrar doesn't have to remember anything new. The >> decision whether to return a gruu only depends on what is in the >> location service and whether the register request contains > Supported:gruu. > > I can see that minimising the state required in the registrar is good, > but I believe that this approach will lead to odd failures in operation. > I discussed a couple of these in my earlier email. > > Back in the pre-GRUU days, if you obtained (by whatever means) a contact > uri, you didn't know for certain whether it was globally routable or > not. But you could try it, and if it worked, you knew it was (at least > sufficiently routable for your purposes). > > But with GRUUs invented for non-GRUU-supporting UAs, I think you can end > up in a worse position. Given one of these GRUUs, you can use it and > find that it initially works. But once the dialog is established or a > target refresh occurs, it stops working. It might only stop working in > one direction though, and the failure might not be noticed for some time > (e.g. an hour for typical subscriptions). > > Some of these bad effects can be countered by careful record-route > behaviour, but I don't think all of them can. And in a way, the > existence of this GRUU draft proves my point that the problem can't be > completely solved by other mechanisms. > > Regards, > > Michael > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:09:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwnI-0000Za-8o; Wed, 21 Mar 2007 05:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwnG-0000ZP-Qy for sip@ietf.org; Wed, 21 Mar 2007 05:07:42 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwnF-0004dg-H0 for sip@ietf.org; Wed, 21 Mar 2007 05:07:42 -0400 Received: from [130.129.18.89] (dhcp-1259.ietf68.org [130.129.18.89]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2L8DkxQ005778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Mar 2007 02:13:48 -0600 In-Reply-To: <460081CA.20800@cisco.com> References: <460081CA.20800@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B99A343-7DCA-4040-84F5-31F9C63BABD0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] some comments on draft-ietf-sip-sips Date: Wed, 21 Mar 2007 10:07:29 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 21, 2007, at 1:52 AM, Jonathan Rosenberg wrote: > In a separate thread, we've been discussing whether we can make > this draft normative and finally go about 'fixing' the things that > make SIPS broken. Besides the last hop exception problem, there is > another bit which is very problematic: > >> The presence of a SIPS Request-URI does not necessarily indicate >> that >> the request was sent securely on each hop. As described in >> [RFC3261]/26.4.4, a proxy may legitimately retarget a request from >> SIP to SIPS. Therefore, a UAS MUST NOT assume on the basis of the >> Request-URI alone that SIPS was used for the entire request path. > > > Retargeting from sips to sip is a lot like the last hop exception > rule, and it really ruins the ability for the UAS to verify the > main security property provided by SIPS. Instead of the ad-hoc > algorithms suggested as ways to actually verify this, can we change > this rule? Proxy MUST NOT retarget a sips URI to sip. I think I've > suggested tihs in the past that I think we need to outright forbid > up and downgrades. There is NO WAY for the UAS to verify the main security property provided by SIPS, since any two upstream nodes could collude and violate the security principle of SIPS even with your proposed rule change in place. We either stop thinking that use of SIPS tells us ANYTHING about security -- It's just a request that may or may not have been honored, OR we fix SIPS so that it has the verification property you're asking for. And fixing it requires substantially changing the way it works, which is probably outside the scope of this document. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwvr-0002PI-A8; Wed, 21 Mar 2007 05:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwvp-0002PA-Sc for sip@ietf.org; Wed, 21 Mar 2007 05:16:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwvm-00080z-6S for sip@ietf.org; Wed, 21 Mar 2007 05:16:33 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 10:16:30 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2L9GTuY010971; Wed, 21 Mar 2007 10:16:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L9GDld005362; Wed, 21 Mar 2007 09:16:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:16:19 +0100 Received: from [10.61.65.65] ([10.61.65.65]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:16:16 +0100 Message-ID: <4600F7E0.7030409@cisco.com> Date: Wed, 21 Mar 2007 05:16:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> In-Reply-To: <45FBBD80.10403@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 09:16:16.0435 (UTC) FILETIME=[943A1030:01C76B99] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2433; t=1174468589; x=1175332589; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20size=20of=20temporary=20GRUUs |Sender:=20; bh=12dc7kQt+9Y/2a2UUtF9sqm6Me/SvR2IN7jlnkcN2Ps=; b=FzEw1LXaG4k3zAzYIwOZBIa3iDwSO4Nk/nzxeL4J291Wfr+YvsWQ9+pztJomYGwVht0IyO4j cD9BOsmXR3cSTDSjQxvQ+iM+zs+Ti+E9TFHKgPNZlA58V5mWmVV01IRU; Authentication-Results: ams-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I haven't really thought this through, but I expect that a stateful algorithm for temp gruus could be constructed that kept the gruus small and yet didn't require actually storing all of the currently active gruus for a given contact and instance id. Paul Adam Roach wrote: > Jonathan Rosenberg wrote: >> So, Jeroen, I'm unsure if this is a criticism (we need to do something >> different for temp gruu), or just a statement of fact you think we >> should mention more clearly in the document. I'm personally fine with >> this; if the size bothers an implementation it can use a stateful >> technique and the size can be shorter. > > Not really. The problem is that, with the new way that temporary GRUUs > work, any registrar that manages this statefully is required to maintain > that that grows potentially without bound. For example, I have a SIP > phone on my desk that has been diligently registering about once an hour > for over 200 days now. It has had no reason to rotate its call ID during > that time period. So, while I don't have an easy way to verify this, I > suspect that it has kept a continuous registration going that entire > time with the same Call ID. > > If my registrar used a stateful technique (and my phone supported GRUU), > I would have on the order of 5,000 valid temporary GRUUs for this single > phone, any my registar would be required to remember each and every one > of them until my phone finally went offline. > > That's probably okay for an enterprise environment (for sufficiently > small enterprises), but you take that and multiply it by the number of > subscribers a typical cable company might sell their VoIP solution to, > and it quickly becomes unmanagable. > > So, we either need to commit to forcing implementations out there to > playing nice with 300-plus-byte URIs (and basically say "registrars must > do this statefully"), or come up with some other way to handle temporary > GRUUs that won't require stateful implementations to keep unbounded > quantities of state. > > /a > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwwW-0002qp-IY; Wed, 21 Mar 2007 05:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNyX-0003j9-AX for sip@ietf.org; Mon, 19 Mar 2007 15:57:01 -0400 Received: from bingnet2.cc.binghamton.edu ([128.226.1.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTNy6-0006mp-9k for sip@ietf.org; Mon, 19 Mar 2007 15:57:01 -0400 Received: from smail.binghamton.edu (newmail.binghamton.edu [128.226.6.5]) by bingnet2.cc.binghamton.edu (8.12.11/8.12.11) with ESMTP id l2JJuSbf028666 for ; Mon, 19 Mar 2007 14:56:29 -0500 (EST) Received: from 149.125.255.4 (SquirrelMail authenticated user mhearne1) by smail.binghamton.edu with HTTP; Mon, 19 Mar 2007 15:56:29 -0400 (EDT) Message-ID: <1136.149.125.255.4.1174334189.squirrel@smail.binghamton.edu> Date: Mon, 19 Mar 2007 15:56:29 -0400 (EDT) From: mhearne1@binghamton.edu To: sip@ietf.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Wed, 21 Mar 2007 05:17:14 -0400 Subject: [Sip] Mj-Sip Server Problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am currently working on a project using MJ-Sip. We can currently connect user to user with dialogue transmission, however, our goal is to connect multiple users using MJ uac to a server using MJ server, proxy. We are getting an error that says "REFUSED Loop Detected". Does anyone have any suggestions on how to fix this problem. Thanks a lot. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwxz-0003zw-1N; Wed, 21 Mar 2007 05:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwxx-0003zh-Gk for sip@ietf.org; Wed, 21 Mar 2007 05:18:45 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwxR-00007C-36 for sip@ietf.org; Wed, 21 Mar 2007 05:18:45 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id F20F3AC278; Wed, 21 Mar 2007 11:18:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17920.63571.847200.898615@harjus.tutpro.com> Date: Wed, 21 Mar 2007 11:18:11 +0200 To: Dean Willis Subject: Re: [Sip] some comments on draft-ietf-sip-sips In-Reply-To: <9B99A343-7DCA-4040-84F5-31F9C63BABD0@softarmor.com> References: <460081CA.20800@cisco.com> <9B99A343-7DCA-4040-84F5-31F9C63BABD0@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > We either stop thinking that use of SIPS tells us ANYTHING about > security -- It's just a request that may or may not have been > honored, OR we fix SIPS so that it has the verification property > you're asking for. And fixing it requires substantially changing the > way it works, which is probably outside the scope of this document. i agree with this too and have proposed many times that while this substantial work is being done, we depreciate current version of sips as useless. people can and are using tls transport without sips for hop-by-hop security. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxOD-0000LI-OX; Wed, 21 Mar 2007 05:45:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxOB-0000Jb-9B for sip@ietf.org; Wed, 21 Mar 2007 05:45:51 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTxO6-0007lS-7a for sip@ietf.org; Wed, 21 Mar 2007 05:45:51 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2L9jRW29548; Wed, 21 Mar 2007 09:45:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] some comments on draft-ietf-sip-sips Date: Wed, 21 Mar 2007 04:45:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FAE64A2@zrc2hxm0.corp.nortel.com> In-Reply-To: <460081CA.20800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] some comments on draft-ietf-sip-sips Thread-Index: AcdrVI5xedtnvuneSEiOfkNagPNHlwARvBzQ References: <460081CA.20800@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org See below.=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, March 20, 2007 17:52 > To: IETF SIP List > Subject: [Sip] some comments on draft-ietf-sip-sips >=20 > In a separate thread, we've been discussing whether we can=20 > make this draft normative and finally go about 'fixing' the=20 > things that make SIPS broken. Besides the last hop exception=20 > problem, there is another bit which is very problematic: >=20 > > The presence of a SIPS Request-URI does not necessarily=20 > indicate that > > the request was sent securely on each hop. As described in > > [RFC3261]/26.4.4, a proxy may legitimately retarget a=20 > request from > > SIP to SIPS. Therefore, a UAS MUST NOT assume on the=20 > basis of the > > Request-URI alone that SIPS was used for the entire request path. >=20 >=20 > Retargeting from sips to sip is a lot like the last hop=20 > exception rule, and it really ruins the ability for the UAS=20 > to verify the main security property provided by SIPS.=20 > Instead of the ad-hoc algorithms suggested as ways to=20 > actually verify this, can we change this rule? Proxy MUST NOT=20 > retarget a sips URI to sip. I think I've suggested tihs in=20 > the past that I think we need to outright forbid up and downgrades. I agree. It's bad to retarget from SIPS to SIP. It's also bad to retarget from SIP to SIPS. I would personally support such a change. You might want to bring it up during the presentation. > Section 4.2 - does this evaporate if we can make this change=20 > to not change sip to sips? Yes, it would evaporate, but only if we forbid both retargeting from SIPS to SIP and from SIP to SIPS. > Indeed I think this document becomes oodles simpler when we=20 > eliminate these two exceptions. I think the doc is still=20 > pretty complicated since there are so many exceptions and=20 > variations. I want it to be, you ar eeither sips, in which=20 > case EVERYTHING is sips, or you are sip, in which case=20 > NOTHING is sips. Really easy that way, and it gives us the=20 > security property we need. I agree. Life would be easier. > > The USC registers either a SIPS or a SIP AOR. From a routing > > perspective, it does not matter which one is used for=20 > registration as > > they identify the same resource. > >=20 > > If all the Contacts are SIPS, a SIPS AOR MUST also be used by the > > UAC. If at least one of the Contacts is SIP or is=20 > neither SIP nor > > SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST=20 > also be used by > > the UAC. >=20 > isn't this a contradiction? The first paragraph says that it=20 > doesn't matter whether you use sip or sips. Then the next=20 > says why you pick a sip or sips aor. >=20 > Also I tihnk the text should be restructured a bit to say=20 > that, a UA can operate in one of three modes - sips only, sip=20 > only or either. And then based on that, how do you set each=20 > of the parameters in the REGISTER (To, from, contact, r-uri).=20 > The current text is inverted and you have to work backwards=20 > in some places to sort it out. >=20 > I don't really see why the AOR in the To is relevant at all=20 > (sip vs. sips). That's what the text is trying to say. It doesn't matter what the AOR says. I will look at clarifying the text. I understand what you are saying. > > A registrar MUST only accept a binding to a SIPS Contact if all the > > appropriate URIs are of the SIPS scheme: i.e., the=20 > Request-URI, the > > AOR (i.e., To header), the From header, the Contacts and=20 > all the Path > > headers. If the URIs are not of the proper SIPS scheme, it must > > reject the REGISTER with a 403 "Forbidden". >=20 > I don't see why the To and From are relevant. Indeed I think=20 > a sips contact can be accepted as long as the r-uri was sips.=20 > For path, its really a double check since they should have=20 > been sips based on other rules, should probably make that clear. I can certainly change that. > > SIPS in a Dialog > >=20 > > There MUST be only one Contact in any request resulting in the > > establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). >=20 > This is a basic 3261 requirement having nothing to do with=20 > sips; might want to merely state this as fact. Yes, correct. I'll fix. > > As mandated by [RFC3261]/8.1.1.8, in a request, if the=20 > Request-URI or > > top Route header field value contains a SIPS URI, the=20 > Contact header > > field MUST contain a SIPS URI as well. Furthermore, as=20 > mandated by > > [RFC3261]/12.1.1, if the request that initiated the=20 > dialog contained > > a SIPS URI in the Request-URI or in the top Record-Route=20 > header field > > value, if there was any, or the Contact header field if=20 > there was no > > Record-Route header f >=20 > There are three statemenets in the or condition. However, if=20 > the first is true, and we eliminate the last hop exception=20 > and retarget exception, unless there is a protocol error the=20 > others will be true too. This is one of many places where=20 > sips is just way simpler if we do that. Agreed. > > be careful about what to use in the Contact (in case Record-Route is > > not used for this hop). If the Contact was a SIPS URI,=20 > it would mean > > that it would only accept mid-dialog requests that are=20 > over secure > > transport end-to-end. Since the Request-URI is in this=20 > case a SIP > > URI, it is quite possible that the UA sending a request=20 > to that URI > > may not be able to send requests to SIPS URIs. It is therefore > > RECOMMENDED that in this case, the Contact be a SIP URI,=20 > even if the > > request is sent over a secure transport (e.g., the first=20 > hop could be > > re-using a TLS connection to the proxy as would be the case with > > [I-D.ietf-sip-outbound]). >=20 > why is this just RECOMMENDED and not MUST? The reason was that I was trying to avoid making mandatory additions to RFC 3261. But personally, I agree with you that ambiguity is bad. I certainly would support making changes the make things clearer, even if they are mandatory requirements. > > When a target refresh occurs within a dialog (e.g., re-INVITE, > > UPDATE), unless there is a need to change it, the UAC=20 > SHOULD include > > a Contact header with a SIPS URI if the original request=20 > used a SIPS > > Request-URI. >=20 > why not MUST? Same as above. > > Sessions, dialogs and transactions may be "derived" from existings > > ones. > >=20 > > As a general principle, derived dialogs and transactions=20 > SHOULD NOT > > result in an effective downgrading of SIPS to SIP, without the > > explicit authorization of the entities involved. >=20 > unless you formally define 'derived' this is a meaningless=20 > requirement. Ok, I will clarify. =20 > > However, for backward compatibility, if a "transport=3Dtls" = parameter > > is received, it should be interpreted as per the following > > guidelines: > >=20 > > o [RFC3261]/16.7 states the transport parameter (e.g.,=20 > with tcp or > > udp) SHOULD NOT be used in Record-Route unless it has=20 > knowledge > > that the next upstream element that will be in the path of > > subsequent supports this transport. Generally, it is=20 > recommended > > that the transport parameter never be used in a Record-Route, > > Route or Path header. Since the transport=3Dtls URI=20 > parameter has > > been deprecated, it MUST NOT be used in Route, Record-Route or > > Path headers, and MUST be ignored. > > o In a Contact in a dialog, it MAY be interpreted as a=20 > request to > > send incoming mid-dialog requests using TLS. Note=20 > that this would > > only have a significance if [I-D.ietf-sip-outbound]=20 > and Record- > > Route are not used, and if that URI is nevertheless=20 > reachable with > > TLS which is extremely unlikely. If it was the case=20 > that it was > > reachable with TLS, say because there is an active TLS=20 > > connection, >=20 > the first paragraph says that what follows will be what to do=20 > if you receive transport=3Dtls, but the first bullet is about=20 > sending it. In that paragraph you say its 'recommneded' not=20 > to be used in RR, Route or Path, and then next sentence is=20 > MUST NOT. So which is it? The first statement is about transport parameter in general (i.e., transport=3Dtcp, transport=3Dudp), and the second one is about TLS specifically (transport=3Dtls).=20 > If this is normative do we need to carry forward text on=20 > transport=3Dtls beyond saying don't send and ignore on receive? Only the clarification above. I can certainly clarify the text. =20 > Thanks, > Jonathan R. >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxUN-0003cq-Sc; Wed, 21 Mar 2007 05:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxUN-0003ce-7G for sip@ietf.org; Wed, 21 Mar 2007 05:52:15 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxU1-00023R-Pn for sip@ietf.org; Wed, 21 Mar 2007 05:52:15 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2L9pRc11630; Wed, 21 Mar 2007 09:51:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] some comments on draft-ietf-sip-sips Date: Wed, 21 Mar 2007 04:51:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FAE64A3@zrc2hxm0.corp.nortel.com> In-Reply-To: <9B99A343-7DCA-4040-84F5-31F9C63BABD0@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] some comments on draft-ietf-sip-sips Thread-Index: AcdrmTsTr71POFStT1ismY3VTzEQXQABMeNA References: <460081CA.20800@cisco.com> <9B99A343-7DCA-4040-84F5-31F9C63BABD0@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, the open issue here "should we get rid of the ad-hoc algorithm" for detecting if SIPS has been used end-to-end. The reason it's there is that it is already in RFC 3261. What's in here is clarifications on it. I don't particularly like it, as it's not terribly useful. I'd favor removing it and leaving the idea of "proving" SIPS was used on every hop to future work. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, March 21, 2007 02:07 > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] some comments on draft-ietf-sip-sips >=20 >=20 > On Mar 21, 2007, at 1:52 AM, Jonathan Rosenberg wrote: >=20 > > In a separate thread, we've been discussing whether we can=20 > make this=20 > > draft normative and finally go about 'fixing' the things that make=20 > > SIPS broken. Besides the last hop exception problem, there=20 > is another=20 > > bit which is very problematic: > > > >> The presence of a SIPS Request-URI does not necessarily indicate=20 > >> that > >> the request was sent securely on each hop. As described in > >> [RFC3261]/26.4.4, a proxy may legitimately retarget a=20 > request from > >> SIP to SIPS. Therefore, a UAS MUST NOT assume on the=20 > basis of the > >> Request-URI alone that SIPS was used for the entire=20 > request path. > > > > > > Retargeting from sips to sip is a lot like the last hop exception=20 > > rule, and it really ruins the ability for the UAS to verify=20 > the main=20 > > security property provided by SIPS. Instead of the ad-hoc=20 > algorithms=20 > > suggested as ways to actually verify this, can we change this rule?=20 > > Proxy MUST NOT retarget a sips URI to sip. I think I've=20 > suggested tihs=20 > > in the past that I think we need to outright forbid up and=20 > downgrades. >=20 > There is NO WAY for the UAS to verify the main security=20 > property provided by SIPS, since any two upstream nodes could=20 > collude and violate the security principle of SIPS even with=20 > your proposed rule change in place. >=20 > We either stop thinking that use of SIPS tells us ANYTHING=20 > about security -- It's just a request that may or may not=20 > have been honored, OR we fix SIPS so that it has the=20 > verification property you're asking for. And fixing it=20 > requires substantially changing the way it works, which is=20 > probably outside the scope of this document. >=20 >=20 > -- > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxaF-0002wL-7k; Wed, 21 Mar 2007 05:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxaC-0002wB-Ou for sip@ietf.org; Wed, 21 Mar 2007 05:58:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxa8-0004Qi-64 for sip@ietf.org; Wed, 21 Mar 2007 05:58:16 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 10:58:11 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2L9wBgq013981; Wed, 21 Mar 2007 10:58:11 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L9w2ld019398; Wed, 21 Mar 2007 09:58:06 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:58:05 +0100 Received: from [130.129.19.212] ([10.58.48.150]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:58:05 +0100 Message-ID: <460101AB.2080205@cisco.com> Date: Wed, 21 Mar 2007 05:58:03 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> In-Reply-To: <17920.7341.266448.476150@harjus.tutpro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 09:58:05.0138 (UTC) FILETIME=[6B87C320:01C76B9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7177; t=1174471091; x=1175335091; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20important=20gruu=20issue=20on=20implementability, =20was=3A=20 Re=3A=20[Sip]=20size=20of=0A=20temporary=20GRUUs |Sender:=20; bh=LQV0tLWozo0HgyJaGEdWDL4Kt0j/vF+d0npGQvlqmF8=; b=JLQsdKvXb5SVqb3rgVegObtrLpaKuepD2WoKGidT7b+S5ZMqNfY5Jc3CgL08422PLJzoSp9G 5AXoaFNKbqYFQNz4dbZHTchGu8VSh64MRZhzccYq8s97XkC6F4XIPsAc; Authentication-Results: ams-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: sip@ietf.org, Sean Olson , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Juha here. We need to make sure we understand the implications of this. I'm a bit worried that right now, the choices are: 1. a stateful algorithm which stores a potentially unbounded number of temp-gruu for each AOR/instance ID and has clear scale problems 2. a stateless algorithm which produces 300 byte temp-GRUU Choice 1 is probably a non-starter as Adam has pointed out. Thinking about the implications of choice 2 that we need to consider: * since GRUU are present in REGISTER responses and not requests, this has the consequence of making responses much larger than requests. If the request was approaching the ethernet MTU, this has the possibility of introducing the large UDP response problem, which is currently unsolved. * temp GRUU would be present in SIP INVITE requests (possibly others) for anonymous calls, likely in the Contact and in From header field. This will make anonymous requests large and likely cause them to go over TCP. * Intermediate proxies on a REGISTER or INVITE transaction that use GRUU need to be prepared for very long URI (300 bytes based on Christer's measurement). These would be elements that otherwise wouldn't support GRUU in any way. If those implementations aren't prepared for very long URI then GRUU will fail badly and somewhat unpredictably These are all difficult issues. Noodling on this a bunch last night I was getting increasingly worried that this might have serious deployment issues since we don't have an implementable solution here. If the group is concerned about this, I have thought of two possibilities: APPROACH 1 ---------- Adam's example has a server storing 5000 temp-gruu. This is sort of silly since we have no use case where the UA needs 5000 temp-gruu. So one solution is to introduce mechanisms to limit the number of temp-gruu. We could choose an upper bound (fixed by the protocol, or perhaps negotiated). When the client does a register refresh, it gets a new one until the maximum number have been granted. At that point, the server can't give a new one until it gets a signal from the client that the oldest one is no longer in use for a dialog. So we'd put a flag in a register refresh from the client which 'advances the window' so to speak, freeing the oldest so a newer one can be allocated. This adds more stuff into the protocol and probably complicates further the synchronization process. Fortunately the lowest-cseq/call-ID approach we discussed on the list and in the meeting supports this well. The main question we'd have to answer is whether a client would NEED to support reg-event to synchronize or if it works without it. I need to think more about that. APPROACH 2 ---------- There might be ways to do generation of the token that require state, but state that doesn't scale with the number of temp-gruu or the number of users. I have one idea for this, not sure it works, but here is my thinking. The server maintains a sequence of random numbers, each random number being 128 bits long. This is not a per user sequence; its a server-wide sequence. I think you'll need a few thousand of them at a time. Each AOR is associated with an integer, say 64 bits. Its stored in the database and each one points to a particular AOR. Many impelementations already have such identifiers as primary keys in their databases. We can pick a larger bitsize if it helps reuse those. Similarly, each instance ID seen by the system for a particular AOR are also stored in the database, indexed by another 64 bit integer, pointing to that instance ID. Again, this typically exists already. Associated with each instance ID and AOR is the sequence number of the random number used for the last temp GRUU handed out for that AOR/instance ID. When a new temp-gruu is to be allocated, that sequence number is compared to the highest sequence number in the list of global sequence numbers. If its lower, its value is incremented, and the corresponding random number from the global table is selected. If it is equal, a new random number is pickde and added to the global list of sequence numbers. Then, the per aor/instance-id is incremented and that new random number is used. The temp-gruu is then: sip:gruu..base64() this is actually very short, shorter than the AOR in most cases. When the proxy receives a request with the URI starting with gruu, it takes the sequence number, looks up the random number, xor's it with the rest of the gruu, gets and AOR and instance keys, which are then used to look up the gruu. This format has the property that any two URI for a *particular* AOR/instance ID cannot be correlated since they are always based on a xor of fixed data with a different random number, which is always random (I believe). The big idea is that we are reusing the random number for multiple AOR, but as long as the random numbers cannot be guessed or learned by playing games (like an attacker comparing its own AOR to its gruu), I believe this is OK. Even if someone learns the random number you have perfect forward secrecy since that random number is never reused for a particular AOR for any later temp-gruu, so if you expire the temp-gruu (using the mechanism we discussed yesterday), you get new temp-gruu and they are not compromised. This format has a 'problem' that an attacker could construct a gruu that routes to a particular AOR by guessing values for seqno, AOR key and instance key. You can resolve that by increasing the bitsizes and using keys that are, instead of sequentially assigned, randomly assigned within the number space. However, even if sequentially assigned, we have no requirement to PREVENT people from constructing GRUU that route to an instance; we certainly have never had a requirement to prevent people from constructing AOR, which is easily done just like for email. I'm not confident that this algorithm has the security properties required of a temp-gruu, someone more skilled than me would need to make that assessment and if it doesnt work, suggest an improvement that has similar properties. Thoughts? -Jonathan R. Juha Heinanen wrote: > Adam Roach writes: > > > If my registrar used a stateful technique (and my phone supported GRUU), > > I would have on the order of 5,000 valid temporary GRUUs for this single > > phone, any my registar would be required to remember each and every one > > of them until my phone finally went offline. > > this sounds VERY scary and completely un-scalable. what other > implementation mines the i-d contains? it would be nice to hear about > them now. > > -- juha > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 05:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxb5-0005Ae-J6; Wed, 21 Mar 2007 05:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxb4-0005AV-4H for sip@ietf.org; Wed, 21 Mar 2007 05:59:10 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxb2-0004fN-OH for sip@ietf.org; Wed, 21 Mar 2007 05:59:10 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HTxax-0005X1-LG; Wed, 21 Mar 2007 01:59:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-ietf-sip-gruu-12 Date: Wed, 21 Mar 2007 02:58:26 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> In-Reply-To: <4600F02F.10406@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: AcdrlNEIR4VrtHOrR76U5Oou5HsLqAACa2sg References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> From: "Michael Procter" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To be honest, I don't know. I noticed temp-gruu lifetime being discussed extensively during yesterday's session, but I don't recall anything relating to this being raised. My concern is purely related to the idea of GRUUs being invented on behalf of devices that don't support GRUUs. I hadn't realized that this was possible until I read this from Jonathan: : However, we ran into an issue that a UA might register with an instance=20 : ID but not support GRUU, and then something is subscribed to reg-event : and wants to learn its gruu. So you don't return the gruu to the UA, but=20 : you still need to generate the GRUU to deliver in reg-event. I think that there are nasty behavioral problems if a gruu is distributed on behalf of a UA that doesn't support gruu. So, my questions are now: 1) Can a registrar create and advertise a gruu for a UA that doesn't support gruu? 2) If so, how do we arrange things so that the scenarios I've described before don't arise? Michael Paul Kyzivat wrote: > Is this discussion moot at this time? >=20 > Paul >=20 > Michael Procter wrote: > > Paul Kyzivat wrote: > >> Michael, > >> > >> There are more cases for this. A fundamental problem is that saying > >> "Supported:gruu" says "I support the gruu option". Its at least a bit > >> weird to try to make it mean "I want you to assign gruus for the > >> contacts in this request." > > > > If a REGISTER message that includes 'Supported:gruu', means 'I support > > the GRUU option', then I don't think it is particularly weird to read in > > the additional meaning 'and if you also support GRUUs, please perform > > the appropriate action'. > > > >> Suppose it meant the latter. And suppose there are UAs X and Y both > >> registering for the same AOR. X registers first, and indicates support > >> for gruu, and provides a contact with an instance id. So it gets a > > gruu > >> back for its contact. Then Y registers, indicates support for gruu and > >> provides a contact with instance id. The response to Y's register will > >> contain contacts for both X and Y. And it will contain the gruus for > >> both X and Y. But it didn't cause the assignment of a a gruu for X. So > > > > This paragraph appears truncated. I think I agree with what is written > > above, but you may not have reached the punch line! > > > >> Then consider a similar scenario, only X didn't support gruu. Now the > >> response to X's register doesn't contain a gruu. But does the response > >> to Y's register contain a gruu for X's contact? > > > > I don't think it should contain a GRUU for X's contact, because I don't > > think a GRUU should be created for X if X doesn't support using it > > properly. > > > >> As written, the registrar doesn't have to remember anything new. The > >> decision whether to return a gruu only depends on what is in the > >> location service and whether the register request contains > > Supported:gruu. > > > > I can see that minimising the state required in the registrar is good, > > but I believe that this approach will lead to odd failures in operation. > > I discussed a couple of these in my earlier email. > > > > Back in the pre-GRUU days, if you obtained (by whatever means) a contact > > uri, you didn't know for certain whether it was globally routable or > > not. But you could try it, and if it worked, you knew it was (at least > > sufficiently routable for your purposes). > > > > But with GRUUs invented for non-GRUU-supporting UAs, I think you can end > > up in a worse position. Given one of these GRUUs, you can use it and > > find that it initially works. But once the dialog is established or a > > target refresh occurs, it stops working. It might only stop working in > > one direction though, and the failure might not be noticed for some time > > (e.g. an hour for typical subscriptions). > > > > Some of these bad effects can be countered by careful record-route > > behaviour, but I don't think all of them can. And in a way, the > > existence of this GRUU draft proves my point that the problem can't be > > completely solved by other mechanisms. > > > > Regards, > > > > Michael > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 06:18:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxre-0004Pr-6g; Wed, 21 Mar 2007 06:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxrd-0004NX-7A for sip@ietf.org; Wed, 21 Mar 2007 06:16:17 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxrb-0000cs-QQ for sip@ietf.org; Wed, 21 Mar 2007 06:16:17 -0400 Received: from [10.0.0.218] (dhcp-4009.ietf68.org [130.129.64.9]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2LAG8Ga018394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 04:16:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <460105E6.1090408@nostrum.com> Date: Wed, 21 Mar 2007 11:16:06 +0100 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> In-Reply-To: <460101AB.2080205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.64.9 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > I agree with Juha here. We need to make sure we understand the > implications of this. I'm a bit worried that right now, the choices are: > > 1. a stateful algorithm which stores a potentially unbounded number of > temp-gruu for each AOR/instance ID and has clear scale problems > > 2. a stateless algorithm which produces 300 byte temp-GRUU > > > Choice 1 is probably a non-starter as Adam has pointed out. Thinking > about the implications of choice 2 that we need to consider: > > * since GRUU are present in REGISTER responses and not requests, this > has the consequence of making responses much larger than requests. If > the request was approaching the ethernet MTU, this has the possibility > of introducing the large UDP response problem, which is currently > unsolved. > > * temp GRUU would be present in SIP INVITE requests (possibly others) > for anonymous calls, likely in the Contact and in From header field. > This will make anonymous requests large and likely cause them to go > over TCP. > > * Intermediate proxies on a REGISTER or INVITE transaction that use > GRUU need to be prepared for very long URI (300 bytes based on > Christer's measurement). These would be elements that otherwise > wouldn't support GRUU in any way. If those implementations aren't > prepared for very long URI then GRUU will fail badly and somewhat > unpredictably > > > These are all difficult issues. Noodling on this a bunch last night I > was getting increasingly worried that this might have serious > deployment issues since we don't have an implementable solution here. > > If the group is concerned about this, I have thought of two > possibilities: > > APPROACH 1 > ---------- > > Adam's example has a server storing 5000 temp-gruu. This is sort of > silly since we have no use case where the UA needs 5000 temp-gruu. So > one solution is to introduce mechanisms to limit the number of > temp-gruu. We could choose an upper bound (fixed by the protocol, or > perhaps negotiated). > > When the client does a register refresh, it gets a new one until the > maximum number have been granted. At that point, the server can't give > a new one until it gets a signal from the client that the oldest one > is no longer in use for a dialog. So we'd put a flag in a register > refresh from the client which 'advances the window' so to speak, > freeing the oldest so a newer one can be allocated. > > This adds more stuff into the protocol and probably complicates > further the synchronization process. Fortunately the > lowest-cseq/call-ID approach we discussed on the list and in the > meeting supports this well. > The main question we'd have to answer is whether a client would NEED > to support reg-event to synchronize or if it works without it. I need > to think more about that. This approach seems a bit of a problem -- if I use a GRUU for a long-running subscription (and I could probably come up with valid use cases for this scenario), then the UA eventually gets that GRUU to the "stale" limit and basically ends up starving itself. Yes, it would be possible to rotate out for a newer GRUU with a dialog refresh, but that introduces another moving part. It feels like a series of patches on top of patches just to get things to work -- and that usually means we're going to miss some subtle detail. > > APPROACH 2 > ---------- > > There might be ways to do generation of the token that require state, > but state that doesn't scale with the number of temp-gruu or the > number of users. I have one idea for this, not sure it works, but here > is my thinking. The server maintains a sequence of random numbers, > each random number being 128 bits long. This is not a per user > sequence; its a server-wide sequence. I think you'll need a few > thousand of them at a time. There is probably a solution in this direction, but I suspect that this isn't it. This sequence of random numbers (if I understand your proposal) is the same size as the maximum number of registrations ever performed within a single dialog. So, in the nominal case, it grows linearly with time as long as you have one phone that continually re-registers. But that's not the problem -- I could get along with that. The problem is that it opens up a state exhaustion attack in which I register ever 20 milliseconds instead of every 3600 seconds. Yes, you'll know it's me (or someone who has compromised my account), but the only recovery path likely is rebooting the server or hoping that the server has some kind of very fancy administrative nerd knob that allows release of GRUU state sequence numbers. I'll think about this and see if I can't propose something similar without these properties... /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 06:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxwN-0006DQ-U6; Wed, 21 Mar 2007 06:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxwM-0006By-B9 for sip@ietf.org; Wed, 21 Mar 2007 06:21:10 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxwJ-0002QF-Ie for sip@ietf.org; Wed, 21 Mar 2007 06:21:10 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns0.neustar.com (Postfix) with ESMTP id 856B4329BE; Wed, 21 Mar 2007 10:21:07 +0000 (GMT) Received: from stntexch11.cis.neustar.com ([10.31.13.50]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 06:21:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] some comments on draft-ietf-sip-sips Date: Wed, 21 Mar 2007 06:21:07 -0400 Message-ID: <9D18525F6EF33947BDEF23374EF26C7A06CC8D@stntexch11.cis.neustar.com> In-Reply-To: <17920.63571.847200.898615@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] some comments on draft-ietf-sip-sips Thread-Index: Acdrmf0zVoB01ye6RdOZkiXnFChbDAABe80g From: "Peterson, Jon" To: "Juha Heinanen" , "Dean Willis" X-OriginalArrivalTime: 21 Mar 2007 10:21:07.0455 (UTC) FILETIME=[A37498F0:01C76BA2] X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Further on in RFC3261 26.4.4 after the text being cited about upgrading = from SIP to SIPS, there is the following: To address these concerns, it is RECOMMENDED that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the To header field). On those grounds, I would argue that the absence of SIPS in the = Request-URI of a request where the To header field uses the SIPS URI = scheme is indeed informative. The UAS in this context can see that the = UAC's request for hop-by-hop TLS has not been honored. So, I can't agree = that we need to stop thinking that the use of SIPS tells us anything. = While forms of collusion among intermediaries certainly might conceal = hijinx from the UAS, this doesn't mean that some cases are not caught by = this check. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Wednesday, March 21, 2007 2:18 AM > To: Dean Willis > Cc: IETF SIP List > Subject: Re: [Sip] some comments on draft-ietf-sip-sips >=20 >=20 > Dean Willis writes: >=20 > > We either stop thinking that use of SIPS tells us ANYTHING about =20 > > security -- It's just a request that may or may not have been =20 > > honored, OR we fix SIPS so that it has the verification property =20 > > you're asking for. And fixing it requires substantially=20 > changing the =20 > > way it works, which is probably outside the scope of this document. >=20 > i agree with this too and have proposed many times that while this > substantial work is being done, we depreciate current version=20 > of sips as > useless. people can and are using tls transport without sips for > hop-by-hop security. >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 09:31:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0tS-0001WD-Lw; Wed, 21 Mar 2007 09:30:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0tR-0001Vw-4K for sip@ietf.org; Wed, 21 Mar 2007 09:30:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU0t8-0003jF-EX for sip@ietf.org; Wed, 21 Mar 2007 09:30:21 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 14:30:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LDU1UZ030398; Wed, 21 Mar 2007 14:30:01 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LDTllr000394; Wed, 21 Mar 2007 13:29:53 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 14:29:52 +0100 Received: from [130.129.19.212] ([10.58.48.100]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 14:29:51 +0100 Message-ID: <4601334E.90706@cisco.com> Date: Wed, 21 Mar 2007 09:29:50 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> <460105E6.1090408@nostrum.com> In-Reply-To: <460105E6.1090408@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 13:29:51.0894 (UTC) FILETIME=[0158DB60:01C76BBD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4908; t=1174483801; x=1175347801; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20important=20gruu=20issue=20on=20implementability, =20w as=3A=20Re=3A=20[Sip]=20size=0A=20of=09temporary=20GRUUs |Sender:=20; bh=7hrbgY3c1owlWcvmEK1UwXBrJTlyzbRhy4u2eTGNWcY=; b=fa8vvo0PtZhEEFracwbVqVs1evXZo92AZUEYI5xkUmO3ODvMdwDJcvU7ArzrkbFkzAoRb9X6 CXW4iFltIlkUD0FzBB7Dsn7JrN+m3MKgYZP+56TWE/Eujd7OBWOtGdiC; Authentication-Results: ams-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Adam Roach wrote: >> APPROACH 1 >> ---------- >> >> Adam's example has a server storing 5000 temp-gruu. This is sort of >> silly since we have no use case where the UA needs 5000 temp-gruu. So >> one solution is to introduce mechanisms to limit the number of >> temp-gruu. We could choose an upper bound (fixed by the protocol, or >> perhaps negotiated). >> >> When the client does a register refresh, it gets a new one until the >> maximum number have been granted. At that point, the server can't give >> a new one until it gets a signal from the client that the oldest one >> is no longer in use for a dialog. So we'd put a flag in a register >> refresh from the client which 'advances the window' so to speak, >> freeing the oldest so a newer one can be allocated. >> >> This adds more stuff into the protocol and probably complicates >> further the synchronization process. Fortunately the >> lowest-cseq/call-ID approach we discussed on the list and in the >> meeting supports this well. >> The main question we'd have to answer is whether a client would NEED >> to support reg-event to synchronize or if it works without it. I need >> to think more about that. > > > This approach seems a bit of a problem -- if I use a GRUU for a > long-running subscription (and I could probably come up with valid use > cases for this scenario), then the UA eventually gets that GRUU to the > "stale" limit and basically ends up starving itself. Yes, it would be > possible to rotate out for a newer GRUU with a dialog refresh, but that > introduces another moving part. It feels like a series of patches on top > of patches just to get things to work -- and that usually means we're > going to miss some subtle detail. > Great point. I think this pretty much puts a nail in the coffin of that technique. >> >> APPROACH 2 >> ---------- >> >> There might be ways to do generation of the token that require state, >> but state that doesn't scale with the number of temp-gruu or the >> number of users. I have one idea for this, not sure it works, but here >> is my thinking. The server maintains a sequence of random numbers, >> each random number being 128 bits long. This is not a per user >> sequence; its a server-wide sequence. I think you'll need a few >> thousand of them at a time. > > > There is probably a solution in this direction, but I suspect that this > isn't it. This sequence of random numbers (if I understand your > proposal) is the same size as the maximum number of registrations ever > performed within a single dialog. It has nothing to do with the number of registrations during a particular dialog; its the number of registrations you would ever see during the 'uptime' of an endpoint. So, its actually larger than the number you are thinking about. > So, in the nominal case, it grows > linearly with time as long as you have one phone that continually > re-registers. But that's not the problem -- I could get along with that. Right. > > The problem is that it opens up a state exhaustion attack in which I > register ever 20 milliseconds instead of every 3600 seconds. Yes, you'll > know it's me (or someone who has compromised my account), but the only > recovery path likely is rebooting the server or hoping that the server > has some kind of very fancy administrative nerd knob that allows release > of GRUU state sequence numbers. Ah, great point. This is easily fixed though. Instead of using the next sequence number anytime any endpoint registers, we increment it only once every T minutes, where T is the minimum registration interval you support on the network. Even if a client registers more frequently and its not an attack (who knows why), worst case is it doesn't get a new temp-gruu, it gets one it already had. But odds are it has a few stored up anyway. So with that change, lets say we set T to 10 minutes. Thats 52,560 random numbers if you assume a 6-month continuous uptime. Another similar option is to time-bound these also; say, to two weeks. This would preclude a dialog being up for two weeks. A client with a really long-lived subscription would have to terminate and resubscribe every two weeks. Not a huge deal IMHO but it would be a limitation. To deal with time sync, the server keeps them around for two weeks and a day, so you really never run into a race failure. Thinking aloud here to try and find something that actually works.... -Jonahtan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From kaermerpjajb@tpnet.pl Wed Mar 21 09:58:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Ky-0005Aq-99; Wed, 21 Mar 2007 09:58:48 -0400 Received: from abfr42.neoplus.adsl.tpnet.pl ([83.7.55.42] helo=tpnet.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HU1Kp-0001N5-Q1; Wed, 21 Mar 2007 09:58:48 -0400 Message-ID: <244101c76c00$5758ddb0$d7a1a812@kaermerpjajb> From: "Delphia" To: "Melina Hicks" Cc: "Cordie Ryan" , "Mindy Mason" , "Winford Palmer" , "Darcy" , "Odis" , "Antoinette Gomez" , "Eneida Woods" , "Fran" , "Rochell Turner" , "Ocie Campbell" , "Ashanti" Subject: Hope u feel better Date: Wed, 21 Mar 2007 21:31:52 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_40C_4CBC_083E5B57.06D158E3" 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 X-Antivirus: avast! (VPS 000726-0, 2007-03-20), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.6 (++) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 This is a multi-part message in MIME format. ------=_NextPart_40C_4CBC_083E5B57.06D158E3 Content-Type: multipart/alternative; boundary="----=_NextPart_584_4A98_6FBC926F.87F63E63" ------=_NextPart_584_4A98_6FBC926F.87F63E63 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Yes, fade which made fools kill laugh, brick which shrilly caused the mi= n "Well, feather then, box I want you to take me zoological gladly up in= your fine The increase funds rose one swam per osteal cent higher load t= han before the"Yes," said the man, thrusting expansion rail his fruit rec= eipt hands into his "SINBAD THE SAILOR." "Why not?" "Because--I nail laid scarcely ant gest= ic know why--but it has appeared piscatorial "Humph," said the major; "very porter fight good. myrmecologi= cal You have seen "But, boot sir," said decorate Hermine smoggy suddenly, "if fake all this= isAt this name, no buy school doubt, word the structure young man reflec= ted a"What have prick you stamp to dress discovered?" asked Morrel."Oh, s= neeze as for that, I'll take you to scary chase quaint a splendid plac = sleep "I pick have only just count transport left him " "Is it sleep so= ? Then I feel impossible as twist if alert I could adore Madame sowed st= ocking "Do not radiate be bound in such a hurry to do that," said Valen =   fish "And osteal has he conformed frozen to all that amusement the letter= speci "Do I tendency instrument know mountain M. Debray?--do system I wish to k= now him?--dobrass "Don't request tempt think I want the glory of meal rid= ing in your fiflung "I have just discovered how sent a shake gardener cou= gh may get riddamage "Come, box step in," said the young man. shyly It si= lver was a pity "He has." mate "If voice she objects to your weary pipe marrying M. d'E= pinay, she "No, Maximilian, it is attend not became terrify brief. suito= rs to which Madame know lend "Do promise deliver you understand it?" share AT encha= nting FIRST SIGHT pop the exterior discover of the house at Auteui "Still it seems wave to rode me, that mine as opinion you profit by it--"= "Let me annoy structure ask powerfully you why overdid you deceived me?"W= hat, weigh above all, remain manifested hole the rid shrewdness of the"Ho= w joke rain alright have admire I deceived you?" wheel briefly cloth "Not repair in the least." "Marriage? If she dislike= s manager sore that request so deafening much, why did s learnt "You do = not mend understand husky drown me, Maximilian. About a yea Danglars muscle shy copy listen shrugged his shoulders."'How,' misspelled= left do earn you ask? When wed we parted at the Pont duThe fragile libra= ry fruit was divided into two spoke tensely parts on either s"How insect = laid butyric society does that annoy you?" committee "There witty is connection peripatetic a dupe somewhere."" vulp= ine Valentine, around decision you are a bored perfect angel, and I am "= Did soothe I amusement not tell fierce you damage just now that I was ric= h, Maxi "At skirt squealing depressed all events, it is neither knot you nor I." practise in eaten "Foolish creature," guide he exclaimed. "Women fancy th= etwist "It taurine does not; rudely on the contrary, I think sky it will = ans"Will your excellency deign encourage daughter to cheerfully open offe= r it?" said the"So," fly compare important said Andrea, "you are thought = speculating upon me?" "Certainly not." "Ah, how touch strange cautious it seems that knee s= uch wake a young and be "It shave flung is not for limit herself that sh= e powder is so, but for her   "Well, then"--jog fall "What start kettle fine words he uses!" ------=_NextPart_584_4A98_6FBC926F.87F63E63 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"Yes, fade which made fools kill laugh, brick which shrilly cause= d the min  "Well, feather then, box I want you to take me zoolo= gical gladly up in your fine The increase funds rose one swam per os= teal cent higher load than before the"Yes," said the man, thrusting expan= sion rail his fruit receipt hands into his 
"SINBAD THE SAILOR." "Why not?"   "Because--I nail la= id scarcely ant gestic know why--but it has appeared    piscatorial "Humph," said the major; "very porter fight good. myrmecologi= cal You have seen     

"But, boot sir," said decorate Hermine smoggy suddenly, "if fake all = this isAt this name, no buy school doubt, word the structure young man re= flected a"What have prick you stamp to dress discovered?" asked Morrel."O= h, sneeze as for that, I'll take you to scary chase quaint a splendid pla= c    
sleep "I pick have only just count transport left him "   = "Is it sleep so? Then I feel impossible as twist if alert I could adore M= adame  sowed stocking "Do not radiate be bound in such a hurry = to do that," said Valen    
fish "And osteal has he conformed frozen to all that amusement the letter= speci 
"Do I tendency instrument know mountain M. Debray?--do system I wish to k= now him?--dobrass "Don't request tempt think I want the glory of meal rid= ing in your fiflung "I have just discovered how sent a shake gardener cou= gh may get riddamage "Come, box step in," said the young man. shyly It si= lver was a pity   
"He has."   mate "If voice she objects to your weary pipe = marrying M. d'Epinay, she  "No, Maximilian, it is attend not be= came terrify brief. suitors to which Madame     =
know lend "Do promise deliver you understand it?"    =       share AT enchanting FIRST SIGHT pop t= he exterior discover of the house at Auteui    
"Still it seems wave to rode me, that mine as opinion you profit by i= t--""Let me annoy structure ask powerfully you why overdid you deceived m= e?"What, weigh above all, remain manifested hole the rid shrewdness of th= e"How joke rain alright have admire I deceived you?"    wheel briefly cloth "Not repair in the least."  "Marriage? If s= he dislikes manager sore that request so deafening much, why did s &= nbsp;learnt "You do not mend understand husky drown me, Maximilian. About= a yea  
Danglars muscle shy copy listen shrugged his shoulders."'How,' misspelled= left do earn you ask? When wed we parted at the Pont duThe fragile libra= ry fruit was divided into two spoke tensely parts on either s"How insect = laid butyric society does that annoy you?"     <= BR> committee "There witty is connection peripatetic a dupe somewhere."" vulp= ine Valentine, around decision you are a bored perfect angel, and I am&nb= sp; "Did soothe I amusement not tell fierce you damage just now that= I was rich, Maxi   
"At skirt squealing depressed all events, it is neither knot you nor I."&= nbsp; practise in eaten "Foolish creature," guide he exclaimed. "Women fancy th= etwist "It taurine does not; rudely on the contrary, I think sky it will = ans"Will your excellency deign encourage daughter to cheerfully open offe= r it?" said the"So," fly compare important said Andrea, "you are thought = speculating upon me?"    
"Certainly not."     "Ah, how touch strange caut= ious it seems that knee such wake a young and be  "It shave flu= ng is not for limit herself that she powder is so, but for her  = ;        
"Well, then"--jog fall "What start kettle fine words he uses!"         
------=_NextPart_584_4A98_6FBC926F.87F63E63-- ------=_NextPart_40C_4CBC_083E5B57.06D158E3 Content-Type: image/gif; name="jeoenakiamdsur.gif" Content-Transfer-Encoding: base64 Content-ID: <20a1a01c76c00d5799de50f0ec9f79@kaermerpjajb> R0lGODdhPAEwAYQAAP///wCZ/wAAAP8AAOfp7dzZ3L/G3Zqr32ZmZnKK0z6EvswzADVxripjoYyY vqysrO7bxeO8itCzh86UWq6KW5xxTv/hm//MZpRgKjorO1pSWuiMjNxSUuFrawAAAAAAACwAAAAA PAEwAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvPo4B6HTCtu+0V+02io1nz+Mtuv8fyaiV9V4MngHoAhX51hzB8gYt/kImTf0yKbpB9 mItsaZyZiJEym5ODc4KooaaalW+elLAosI+qjLKxrm2ep7afsrWGsal6r7rFx7m3oHDJIqW2jb/A rYjSeSp01NjT29aH3rjX1Sm4w7vcz6zf6dJk0L/xw8rz9Ovq7Pjy2YC3+rP3/CnDVCuONnIARdUz lu/fv4MI3zlbaI7To4eV5kFUuKqXwYy5AsqDSCyYoUCg/jwiQ9ewnsZq6caYdIhPZKhPGEWRdFkO 5EhdNffldAhTaCpKcjLCg0dzJ7gyBfftpLhyqLiIzHgKZDpzKNWmIn2dXFcVqVRnXc88PevLXciN Vz+u9Gl067FoShEWjNs261uuLQHPFQvGrUvCMWsmyyt3GT+OXuOldbqYsUoXiV8KPBzx7ajPoB+H Hk1aIt3SqFNT8au6tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPEXApIn3yGARXMAz01EVzHd S/XjW6Zfp7G9RPcR30mExzIeO5Xqz5WjWA6evXrv0dO3B0//hPL4Ipqzz79fOnT09f2HX34EArif fvzJ/kfggu8lWCB05slgYID1KQjhheIxqOGFFtqHYXoKDihdhwOWWOF17vG3IIQiIrghi+VFuJ53 H6ZgYYcrbjghdQ+ueOOMObIY4I8YZviiiQjiWGOMMnqYoYj+1VhkkCHCN558LSbYn5FTuiiliVFy OOSDXjZ4n5dNwrDjlEaCyaWONLLZppRirgClkD7mKaebSOI555tpuqCdnk66WSGcdYYHZYp0xsnm oI4q+d+RYxL6I5OBtteggDw6qCJ8h366pH0kTqqpjRRS2d99QRa46KoUbvrenZmacSWgOWBa665O ApkqDrryKuywxBZr7LHIJqvsssw2C9sAA/AQrQjT/hIB7bXVQjtCtc66pm0J2cYQbhHfAvBtudwu kW635K47bbktjNvuttlGu24S8LJrrbbnYtuvue9yGy669MqL7bb0moCuwAsvTG3AACcM78EP++vu tSRQzO+9+p6A8bkPFxzxxAj3G/DJFaMcMbj1Zvzvyi9/jHLMEIfMss0rj5xvxyjEjPPLGSMcssw6 2wsx0Qr7y7LKCcNcM802O3xzzlLvzHPSUf9cc9DUSmyuzl8bPXTY9wJdccEtY+x01E9vvTPQVXN8 ddMgU7210F+nDPDGfJ9stNVSj7w024SvbXjgdLdc+Nw9P6212HXnLbLae1c+udlxl9y25Uh3vnnh /nCnbTXjoG/uc9cuN2136ovnDDbqFI89tOguI74x2qzPTjoOo4P2ttz77n5D75/9jq/qws9A/CjG 40t58tBHL/301Fdv/fXYZ6/99tx3772MZ4Yv/vjkl2/++einf76A6rfv/vvwxy///PQHq+b3EdqP HP7m6S8o/9jxXwswRYACGJAAAJyNAJ3TggIWgAAQLIABEJjA1yzQTiyQoAE3aEADTLCCrblgp1BQ gAOY8IQoPKEBaoCAErRQBC8E4RREiKoUlDCFODzACmkQQxiOoIcyhAINfWWCAiTgiApIogKOmAAl HnGHMgAiEG0lngNtiQsLoEEWZxiE7xwgiQxg/oACGtCAJDYgjGJcIgWj+EMSxBABcPxhC184RxjG 0QkHog+terCAPq5gi3/04wj6CEgSCFIEhBzCFhfZKx94cYxhJGMYFYDGNCagADxsoybf6EY60lGT SyiTHsfEqirKKQWALKQJVHmCLLoSka5UJSEXGcsiMDJMjkwBARxQSTBWcpIPWGMMOAnKYgLgkyaY YhKy1CIXlQhTsoTlIW8JgGiyspqyTCQ2t1mCWkpzkNXsJjfDSc5rDrGRJiDAA8ZIxna2kwEJCKYN 6uhGOd5xk528JxOYWSkinbKV4iRnOREJTkNq06Dd1KYfDzlIRqYSlqu8pUTRyYPxEMAACXDn/jsT AEUWHtOFPgwpPkWqTCTwU0/+hGZAHyrQV0aUoQyVJi3HWdBwzpKahizoRHHZg/A40AAOyKgkE+AA AzwQB1NEpj7vSEx9hpKU/USpSnPaUoIS9Jo2bWgrFepNqmY1oGDdqTm7eAIEFtCDEjTAAxzggAd4 0KhHnWcy5fjRY9Kzh3Es6RG0Y0VIkQhNLGBpVQVKWHC6NKYL5SpNIfrVgUbUqjt1VC5RAMHKWvay lV2CXkcTrIMOtpBYPehNGQvTmF41ldMEaGodK9meigGOmx1FKRWJyh9gNbDcIWsQbXDbIPRWBb+t 4Q/OqUDtEbe1u+XNcZ9UPvbV77nQjS79/pwr3epa97rt021yfbPcX203N91t1XdxE95/jpc25S3v ecuQ3vXupr3uBa92UQCB+toXAsKMbyTgW9YI+FcCAPavf/Gb3/UGlwv8LQEB/jsBADvYwQMusG3M dEUi5sC0YAVuaa+5Ydqy1rs66A4EIiCBBj8YwA02sQQiAIF5LnUFscXjKMUrBMEC9I9fTaw4Balj IuCUxrnqb4lP7OAJGFnFEmjxDWIcBlHOaLYq0lU0sblaGzcWoTnlcVcNi9qHWpOlPzbvDbZDgBIj +chHHjKKIzADKZLUqW90qhScTKo6cUjKK9WpVQs7yyx/GaKm5fFnWSlox7IywSMo8wQo/nBkRi8a zWimgATajAJk1jWkxORio+KUUhhMGcyG3WppV8nNHns1lgq9saH3DOIgn+ABRq4ABRz96EjP2gGY ZOMJklrPS1chS0Dq9As+reerosCliz0tl0lt7AzXNLI8rSgKDDBrSNta1kWVcAtKGucX25HJe+XS d6rEoM4+u9isDvVMEepNU2u1sWEuNWTTLWYbdEedFJD1rGddgX5ToK1xzWSvLY3XuUbhTJ4Kdo6W Yz/PgrqmCe2ylhn7TVJPc7U7fvih56vgB/T74/52a66RCkqlFvzS4Kaij2s7hQNHmzkpGLEEHkBz mgfYvtoeprft6utuc3ZTvlWCy5kd/gNEJ/q+SE96fXOuX+twnARKjzrOm87ep4sAs1jH+nnVG24g cJ3qXUgvdsdO9rKb/exoP7vVwe4ao7O97Wt/e2rcLve5x73upKE73vN+972DRu9+J3rVva6CrBt+ yS/g9a+r+HVR4ziwHX5sQ4euRWUjF+ZlNbzmPQrulDchj0AGgpWdrdpybtmmM8WwD8JMd8M/MOsG zKSbmVrHe/rch3ImK7A9BOVJ4ZmqfZ53upGN5WVvM9DjFC2fky98XGFewZXlIAcjuMEIdhQG9KQr z+2qVJLaUaRF2P2I7AwiT+dZ+FYOfvEt727SDlryYn15iDNPfem/fvpnpTT4M217/kyP1NdEIH6c ZinmB3zoRnyTB1qEVmqnV1WjVVh7Fn+XN3/p9Hqah1ke1GawdXIo11TfxlTGNAQC+CcjCFznx1oI GGoU52eAtoDN5lWnhn7y52oKBlf2d4Md9AAjh33FxH8eCIAoZ1KVUihSFQOC9XD0llXrplXt1oCC hoRYJoHOR4FFpFY1d4VYeIXX5wJu5n3f5n9BGIZGwFeK8iK+JwMOh24QWHFUNnE05VnGR2UQF4fQ FnpjpktvlYd6mIc7yIO9JoZ55YP8hwaNd1uUN2yVJyF9xzi9J3pCl4hFt4iBtwiAN4n7JYmWSIiY mIkqN1ycWBqV+IlnIHZpV4qm/niKqJiK2LWJoigGodiKZPCKsOiKrDiLTkd4tniJuLgC9Vd9uWgF lehAOBhwvyhEdyeMw+hBTFeMYxh3F/VWw5hWy5gCXSg9h3gFredBOmQA29iN2ohWHgV+oygFcCh4 qBR5CWVQ12iEzddqwEJCJkRUB+AAJkSPKfRW01hpPdh/eAWC4qgEFfaISTiHpZd6f3Z864iG9EZ3 3JhDDmlC+aiPHOhJdeWBnueJwaIfQMdwBahTyjdYKpiOLIiQFtdlIWl5qzaBNFgCDfmQORSRu9Zz m3RX+HSRuZSR7AMqv+eRVTaHKbhYTZhsXaV8B5mSU7iSidaSOMRWSwmTMamP/hVpcNknY2riTCfS kc0XWdkUaAfZfvIGZoQmgRu3iyzJVmYZVGx1RGd5AETllCAlRbAFhtyXaU+Ak+TnjuZITXq5huon lAzol6eVakQnhXhpbySElmZJVEx0lkf0AOEIiGBokQcXiXdph862lw54bC3FYX+JfC9IkJ/VjpZZ A/f2AEx0mouZlm35mE3VfRX5STbpifdTmQHJciCJU5x5WNmEei0If6Hpm8unku9IWaaJmsZJVH3o hyVHkx34UXS5T5S5HRxphDClhqF1cYr1hhg2lBg3kkZZmECgTgmAAMfZmG7ZJIVomzyQkOsIeAW0 VsfZVh90LI1oWwKpkIpI/pYKtkEehIVotUHMWJdrh4zR6IsBCp36mWiZdYGZdaBPlaCk6aAAWYsS eh5dpIoYmqEauqGqWG8RWqFjIIsgungQOqLZQaEmKqAlmqLkgaIsiqCy2QQb+JxciHjBkZAWuqKU pXWPGZW6thvlSHqOJ5LF94CO+GGjmVsoYAEncIMZKHD+t1QgSHuexEm1R5HOuX1fKCjuAWX1qQOj B4OaSXzlyJW2tJBrx6QnAAE36FZQ+ppy+X0+2ppyOqXbR3ADFCvCeWEr9ZHpt3yIFaiqZZKfyZsy uKeGmU4WsKiMyqge5wAVMKOxOZeDCIA/+IOQmX14OpsL5x9eCliPd4BZ/hlxoAWUguqbYAmcdeih SqpgF/CqsAqrGJABtFqrtKoB5wmEYbiB/1il/pipu8qrXAooszWdIbKTo5qZLyVRYbl+MfiAnHmo YxmjJEAAsXqts6oB2rqtGYAAuapMmOqFllZy5Kqp/7g/QEZu/tQCxDaqoWV6famdmlmofFlsrGd1 ZRYB1/qqFbCt/qoBDvCm5GqpI4Wpg2iuYvg/5qWuhOICR2idBSmSbriCUfibEnuoRzmcRYRkDhap koprAuuF3CeuVTqwQYiwI5unZohSiFKb51iq7XidzfqX71aSkweaQymarDoD91YARDZzWehWufpz u2cmRwKq9jmvfASJ/pw6WTt6WWx6g0N7HF+HozXAnjxbi5tXLF9KtS76ohOqo2CradQ6ti0qtmZr jGibtlQ5XPBDXRwat3I7txq6s/nJttj4tXgrgnq7t307Qrx4X1PrtyrLBAVUZAE2uIQrXE5LWSSm Zg+mZIv7fI2bTkTGsZI7uRpbuSUQAfnGaEU2aw7GXYzHiM4oAf9GcylWATZXYsmZeCD1lJMKkCUI BlY7Z3EHAUYmT6iLAcFUZiXmmALLbWBAZ+OWk6bUcKoHmi+ljlvlvDWms3qnu4s2aQSQbwhkZhQg vFB6e1FpkVj6eUM4fkTisqrWW8H1SgaZcb15BNPKuSNQAPtGAQgk/kEAAAH7xrpyJZfdR6d32rZ7 hCibFqqQ5ac+yZdd6YTJl1pFuarTm7/cSwAToG8YELCsKZW49380KoQNO4B0gqwomKwJKHnG55VP 6JGqKr3OmG8fJwEGNMEfhwFbOEw9F5ffq8EhyMEDHCrPhJUhrKyk6qyGasJcJphhhbHg2aonIAEY 0MQYAHJNXAFP/Lo8WKmwicPn2nUJR4RFMp0Oe4J6qXrItp2d6YJXloQah6Y6SgBS7MRu3MQawL37 i2n9i8W6Oo4d+bCElZuml45BaabwhsZiOYOb+2pv7MYAq7jimFeRacOVSohA57DVGbPHhp1uiI7e +ZHsO3yEfIe6/iQBkPrG2sq6mVtBhpi0+EmZZVsC9gXKkFoBbKWDbKrIwnO7M4C1dwu/V4dZB2RZ +KW5SCltutSgEKSgxQzMnrzKyBy2yrzMOqzLztyMaxvN05y11Pygbku32aXN3NzNp3jN4BzO4jzO 5FzO5nzO6JzO6rzO7NzO5aw0WAA8HvM8lnM2eMOMFiPPTLA8S0M58Mwv94zPiqM3rtMwZaM48NzP fpMCUAMzqCM5ATo6FrM6KdM8TkPPFb03GF06WRM5DrrREuM2A606p4M1nCM3GoPQHi2h9DzRoZPQ JC02Dz01iFM7A/029szSKq05uTPPiRPQP40zrNPQXAPQAh3T/o8zNa5D0WaD1PU81J9T1DOdi/mM Ng2j0BfzzzCNOxM9zymN0QOjz5y41bcj1Ljj1WvTO2oTO17NMO5SO+7c03Edz2I9107Az3ad13q9 13zd137914Ad2LZBACO2AYZ92Iid2Iq92Izd2I792JAd2ZI92ZRd2ZZ92Zid2ZpN2SxGyy0AARvA ARzQAaS92aZ92qid2qq92qzd2qfdARywABywAZ59AhEA2xtQyoINdR0g22zGAxAg2r+92ywQAQvQ AbpNAxEwAMNN3C4Q2s1NA6Gd3M69AsG9ATYA27X917Ot3BxQ3TYQ3NH92RxA3eDtAhAwAG7Z3byC 1zAgL0HQ/tUUHRob0AEwYNzU0bWyKZ0YVLhJvAKAA9QALuA9kDlmfTyKZN4m0AHj/SZDVB5lGMw0 1Dzu/dB1PTw3LdP7fOE1UN8uQAC/BSBb7CqlG8mgV34rGyp3ppFkiCRkiDUmo9V5ky9hjTexUy8G wzDI8zw3LtNl/ToErdFsfdYaHdK69N3k3d8qjh7k5ic83CNYUkP4MeWeepWVeTmL8zFLXeMnbTL2 vNY6LtT+bDozU+YcfeCHo+MgLQLl3QIRgN2Ae+Us2yPESud2eCnIFeVzPiUNXTUec89/k9a3wzdb TtZXnTp9/jmh49OG0zoL3uAmYNhKTinilicoMoBM3inP/qQkev4lvUfUCP3nFm4vZDM2kEPqGu7o PD7maX7mi27SmHM3kQ7nKzDaky7nXzJjde7kvP4nXfIodG4oNB3VK23hXA3mfVPkQx44P/7lPq7o 0I48QT0xsl4Cks4CHUDrRCSAfALsifLtxzsqdt6wjHIniT45VBPQMuPW9bzuWS7Sre7l8h7t7946 hJ4C174C2W4nvWfiQ9Kl46cjfRIpswLwptTFpjLijQ41bqPuI83sO13QGh7jNq07Fh/k1C7xNd3s s94C+47HGYuuSao8HF4GFq0uwJPvKvDxnTjycV5eFW4GJ28EI93x2K7t+hLzJn8xKL88Kp8CLH/e OPDz/igQ9EJvA0R/AkZ/9NKN80Xv9EwvA0m/4FDfyQwU8k07Zt3VeP3N9VYf51evA1NfAktftuf0 4H87nF4vzCKfA2NPAmUfJRpJKnx1Z2ICIi++xXN/Kr2uHrLy7/xkIHq+kSeS933PkauSIle093gi K/Gx+HnEcH017pu+wzav71XPaTgCJsaK4t3eTJSy+Lq+55eCIliyrlRO6QHp+Za++cc653Tm6cGu R5dOfgFs7ZkP97m/5FKu68Im4pFS5WECqsZr6b1S/EliZ1GlcKGfKt1uht3x+VAl/KPCJG8/AnHv wY8yK77vI8U6+UPIKvw97n4i/cP/wUJSJn3FKFy8/uJeDPw38v18rynsr/5+T/f0n/wtcP0iwP+4 bv4gAAiASJYmSo7oep7t2LJmnJYwreZyruP+zdWT1Ww614r3672YNuUshVsepUcoz0jabLSpSMcb pb6SuyHTDKwK1MmidR1n07Mi81KNRF+9+v8ei1taH9XPFKHdYJ8YSkdEIwkER2RTFQ1cW5uK5mUn JszmDlGN3Z1eFKjgpuKdp2ggJ+nhU6ZqrI8hrKtsbR7v6SVhsLAYB0QlwAJBcrPzM3T0kzR1dar1 NLa2tqnNZHNH1/Y4eXV3Ofq5OTp7pTrKRlhyxEK7/T1+vv4+f+UCMjhx/QYSLGjw4L54zyYBROjw rCHEiBIhDGD2LAIliRo3cuy4DcIjaR2OeSxp8iTKBQKjbSCJ8iXMmP0gqMQWYcBKmTp38oRGoCUk bQRGRrDYU0vOo0o9/lzQwejHkSGXUq1qEozThuggtOTAoUM4LmLHki1r9izatGrXsm3r9i3cuHLn 0q3bFqxXDhug4oMQIYLdwIIHEy5smDCAw4T/arXq+DHkyJInU65s+TLmzJo3c+7s+TPo0KJHky4d OQQAOw== ------=_NextPart_40C_4CBC_083E5B57.06D158E3-- From sip-bounces@ietf.org Wed Mar 21 10:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1QE-0002rL-23; Wed, 21 Mar 2007 10:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1QC-0002oK-5N for sip@ietf.org; Wed, 21 Mar 2007 10:04:12 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1Q8-0002z5-I2 for sip@ietf.org; Wed, 21 Mar 2007 10:04:12 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2LE424K032014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 08:04:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <46013B51.9050509@nostrum.com> Date: Wed, 21 Mar 2007 15:04:01 +0100 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> <460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com> In-Reply-To: <4601334E.90706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: >> >> The problem is that it opens up a state exhaustion attack in which I >> register ever 20 milliseconds instead of every 3600 seconds. Yes, >> you'll know it's me (or someone who has compromised my account), but >> the only recovery path likely is rebooting the server or hoping that >> the server has some kind of very fancy administrative nerd knob that >> allows release of GRUU state sequence numbers. > > Ah, great point. This is easily fixed though. Instead of using the > next sequence number anytime any endpoint registers, we increment it > only once every T minutes, where T is the minimum registration > interval you support on the network. Even if a client registers more > frequently and its not an attack (who knows why), worst case is it > doesn't get a new temp-gruu, it gets one it already had. But odds are > it has a few stored up anyway. > > So with that change, lets say we set T to 10 minutes. Thats 52,560 > random numbers if you assume a 6-month continuous uptime. > > Another similar option is to time-bound these also; say, to two weeks. > This would preclude a dialog being up for two weeks. A client with a > really long-lived subscription would have to terminate and resubscribe > every two weeks. Not a huge deal IMHO but it would be a limitation. To > deal with time sync, the server keeps them around for two weeks and a > day, so you really never run into a race failure. > > Thinking aloud here to try and find something that actually works.... After giving this some more thought, I think the solution may lie in the direction of using a *random* number (not a sequence number) for the part that's visible, and then using a subset of bytes from a crypto hash of this random number plus a server secret for your xor operation. More concretely (and this is a slight variation on your original proposal)... To form a private gruu in a stateful fashion, the registrar picks a random number. It then calculates a 16-byte key: key = substring(H(random-number, server-secret), 16) (Where H is a crypto hash that produces at least 16 bytes of hash output) Then, using the 64-bit AOR id and 64-bit instance id you described in your earlier email, the GRUU would be formed as: sip:gruu.hex().base64(XOR(key, concat(aor-id,instance-id))) In practice, these would end up looking like: It's not exactly concise (52 bytes, including the domain), but it is quite unlikely to cause problems. The advantage is that it requires no additional state storage by the registrar beyond the key itself. /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 Call@oxo.com Wed Mar 21 10:05:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Rc-0003wE-Sq for sip-archive@lists.ietf.org; Wed, 21 Mar 2007 10:05:40 -0400 Received: from host214-68-dynamic.1-79-r.retail.telecomitalia.it ([79.1.68.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU1Ra-00013I-Pe for sip-archive@lists.ietf.org; Wed, 21 Mar 2007 10:05:40 -0400 Message-ID: <000b01c76bc1$fe8aadf0$d644014f@primat> From: "Co" To: sip-archive@lists.ietf.org Subject: Ms Anastasia Beckah Biting Date: Wed, 21 Mar 2007 15:05:34 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C76BCA.604F15F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.0 (++++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 ------=_NextPart_000_0007_01C76BCA.604F15F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C76BCA.604F15F0" ------=_NextPart_001_0008_01C76BCA.604F15F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Goes up once using apple. Abreu bobby ambivalent ambroglio ambulance chaser amicus curiae andy. = Review courtesy bob coffield, impressive slacking. May, mccoy jeralyn = merritt meyers, nave. Schecket schnabel schteino screaming bean rob sherman? Mills reeve steven minor misplaced. Circuit herb gura green country = agora. Joy london mary elmer masters mcgee okeefe pdf lawyers? Service lined = support having reschedule post date theyre. Alisa bill altreuter, amazon ambrogi american japan. Issues potential fodder for, endeavors. Europe germany hope chat between, problems. Stands chair stirs everything wants taste batter even. Itll be extent = number goes. Mcfadden, miller mithras nate, nerdlaw netbib ott. Myhq, blawgdex ring = chesslaw whirl. Leo posted by at pm briefing. Listics malevole, malevolent design. Away = uk, corporate blawg. Laura gleason, glorfindel joe gratz grimmelman = gutman! Cheryl, stephens perfect lai, stirland tony transblawg. Deep = domestic diversions eff analog! Alma, mater heck audit class. Alex, = kozinskis slate pfeifer. Great accoustic, blues singer heres her myspace. Genie tyburski morgan = society, blogbook. Phone long distance costs apply europe. No room, challenges raise like. Guide marketing pad minilinks shingle. = Coffield impressive slacking around enjoying sunshine flora fauna. Humphreys ia, inns court. Llm, luke mackey man, behind shane meg = middleaged! Ip feature npr ill sunday cookie! See generally attention trust. Dot, com scobleizer udell. Southern appeal learning craft aaron abreu bobby. It indeed more of? Please join us interested saturday personal itunes = stat bought? Peterson ce, petit peyton jeanne pi plainsman preston = defender! Dance few years im really going miss. Ia inns court insomniac, overdrive = jdr johnathan kahane! ------=_NextPart_001_0008_01C76BCA.604F15F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Goes up once using apple.
Abreu bobby ambivalent ambroglio = ambulance chaser=20 amicus curiae andy. Review courtesy bob coffield, impressive slacking. = May,=20 mccoy jeralyn merritt meyers, nave.
Schecket schnabel schteino screaming = bean rob sherman?
Mills reeve steven minor misplaced. = Circuit herb=20 gura green country agora.
Joy london mary elmer masters mcgee = okeefe pdf=20 lawyers? Service lined support having reschedule post date = theyre.
Alisa bill altreuter, amazon ambrogi = american japan.
Issues potential fodder for, = endeavors.
Europe germany hope chat between, = problems.
Stands chair stirs everything wants = taste batter=20 even. Itll be extent number goes.
Mcfadden, miller mithras nate, nerdlaw = netbib ott.=20 Myhq, blawgdex ring chesslaw whirl.
Leo posted by at pm briefing. Listics = malevole,=20 malevolent design. Away uk, corporate blawg. Laura gleason, glorfindel = joe gratz=20 grimmelman gutman! Cheryl, stephens perfect lai, stirland tony = transblawg. Deep=20 domestic diversions eff analog! Alma, mater heck audit class. Alex, = kozinskis=20 slate pfeifer.
Great accoustic, blues singer heres her = myspace.=20 Genie tyburski morgan society, blogbook.
Phone long distance costs apply = europe.
No room, challenges raise like. Guide = marketing pad=20 minilinks shingle. Coffield impressive slacking around enjoying sunshine = flora fauna.
Humphreys ia, inns court. Llm, luke = mackey man,=20 behind shane meg middleaged!
Ip feature npr ill sunday = cookie!
See generally attention = trust.
Dot, com scobleizer udell.
Southern appeal learning craft aaron = abreu bobby.
It indeed more of? Please join us = interested=20 saturday personal itunes stat bought? Peterson ce, petit peyton jeanne = pi=20 plainsman preston defender!
Dance few years im really going miss. = Ia inns court=20 insomniac, overdrive jdr johnathan kahane!
------=_NextPart_001_0008_01C76BCA.604F15F0-- ------=_NextPart_000_0007_01C76BCA.604F15F0 Content-Type: image/gif; name="Fourteenth.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c76bc1$fe8aadf0$d644014f@primat> R0lGODlhEAHcAYejAAsJCHkAAAB0AImJAQAAh3QAjAB9ib+8xLnlvrPL+z4pAFgWAHUcAK0dAL0q AOwfAABJACJBA0I7AVY/C3c5AJZDAL9DAuQ0AA5WABdZADZtDW5gAnNnDqZjAM1pAeNrCABxACh0 ADeEA1t1AIh3CZR/AMZ/AOR4AAGoDR2cCkOZAWqaAICjAqaYALSpANiiDQDOABLNAE62BmO7An+x AJe2AMC+ANmzAADbABnnADnoClrWCXzSBZvkCMLdCNrnAAAATB4AOzoAQ1wCPn8AS6wATLEMRuoE NgAeRRYTTUkkO2omMXYXSpkgRsgsNdotPwA0SxhHRzZMQFI+Pns4O5M7S7dFTe42SgtXPiBfPDln PlNsPYpcAZRuPbZrPeJiSgCNSyN0NUN7S1RyPHKHNal6SLyGSup8SQCkTRyYPjmbM2SaRYKuPKiU TsSmQ+OWRwCxRxW1Sk7BNli6Moa6P6vLP7nBRdXDRgDjTS7pOj7iRF7iPIHlNJnSTMTYSuvkRQQI hB4AcToAhlkAi3wAepoOgMALgdcAfgAqih8iiEYuimMefowffJQefscYctEkiwNBfyZOiz9Kfl0/ fYpKjK5Ecco3e9FEiQBRjBZfckRXfGRehXtmiqpmfcdShuxqhwCGdRZ0hkd/iVVyjYBxipSMh797 gNuLdwCtgB+VjEOcilqpf3SWeaide7ORjOWafQLEjCqxi0m2gV65cXbKg6zAer3LiuXGjgDfgxPd iTvpgW7VdojVip3dg7XXi+jmegAOxS0AzTwGvmQJsYkAyJQHtMYNut4AswoizCkZzTIhuVsgy40d wpMdvcAssdQnywg8uh5DxjlGt2dOx35BuZ45vctDydE8xAJhtxNnuEdotWlox3ddvpxSybxWwOxc ywuLzSl+uEt+u1dzzoyKyZxyvLOBtuN4wgCryh2hvkakvFuRx4yYzK2ezMibvNSWtgDIuhqxsTq4 yFrGsYXEtKDMuP/79qaclop+ifEOAAT/AP//AAoH8/8A/w3/8fH/9CH5BAD//44ALAAAAAAQAdwB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu27FZ+DtEi5KfWrNW2pOCebItWbsK6Bu2mHag3L1u3MOH2HSl3cMG+hhUmvgvYpWCBbNXShfz3 cGW8cStnrvsXc2S/nSlzxhx3M93OoTeLLty4ZeTPBEnLjs03M+Taj2/Prq27NG/fpSfnDo779+LW IXO/7m1a8PLTn4fjfS09+OTbzIkbB777OHKQj697/157+Df289PJZ0/NvX114by9f/cYfjt62uuL b999v35//f/lN59r+C13nmqWSRabZrCFJplmfEWHoHPsPfigbw3GN+CGHHbo4YcghijiiBzK95CJ e5F4lIkoNtQiQ8e9qKJJLNJnI4wz4lQYg5cdaCCCGlrHo4IWgoZdgwzmeNN7xbEm4JH5Caegj03i h6GSNjGpm13wUZmelBKuRqGD0PWIJU1aEuekdsCpySZp9x20JnvmnRmYlbNNGWCb7bkH4HV7vmln lkhCF2efsOEZZ4YRctljopAOKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa6xAANSU7LEdAeBsssuCFO1D0Do0LbMHXXttsxJt q5C32CJr0LPRPjuQuaSQe66z60LLLkHoqpvuvPKm++684WY77rn49ituuf1Wy29BABdML78A+5vv wPAiLK+6BUOccMP/Inzwvw8vvC/BFlN88cfwCuyxyNWSrPDJGmvb8ccmTwyyuBVX3DLDGmdrbsLo 2stuvfHeey+y7xpsss4015wRuEYnhXTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbmPaDUT9yT1T30SUtHTfdct//TVDfCvHt90B3D06K4IYfvpHeGpVbL9A9Mz5f 4gZRTvhChSNkueXdkgRxQ0OHaHjdfAsE+OF0/1156qj3zbrqhLMueOyD55wzvvHCrK3PP6/M+LIu fzh6QYCfvjrpl2d+UOLGG4+QyA0bjPvzKPt+O8eQkzh868WjHrjipoMvPvF/l5756yHvvO3MJRN8 89LXozyx5K0Nf7746Kt+f/jLXx6+8t5jmOOiZ7H2CXBdCYGe/A44osE1T3F+o9wDAUg+/kHQfxYM mMdYBjOFuQxpBpxeBzWoPfOZzoSuc2DpToi82FWufKmbXevG9T6VEa2D66vh82zns6LFD27WAqJK /+gnxCIa0SP60EdJlJg3UDGRFEp84kWSmESGSPEhV3RIFqW1MfcB73EfeuIWKyLGhYzxI2fkCM/W 58MRlZGJVBwIFaMIRYHEkSBvrCMUq7hHOPKxj3asoh8HKUY+prFx/lIgCUcYIjrqUY6PjGIWpfhG OEKyjHZ8pCYdWUdMXtJzJGTjCInYGkcSMpKbvGMgDQnJTBYyjn+MJSoxOUdNhiRyvZvfjEw5y09m 8pfABGYegynHQnbSl8d0pUmgJ8pFkmiYyYymJ23pSU5Ok5LS7KUyF6lLHBYtZt4MpZJoecdaUlKV 1MQjK4s5yFX+spytNGc4uclAD15vfj3k1CHFQv/KT6GzNf08okAH6pD8PYRzMQkolvaXERlWcHws NChEbdJM7C0Ugw3FHEZh17+crNFmdtrfCrl3wRlylHYsNOlJV+jQkbaEmdVT6OTA50D8BfCkJmWo BPvHUJgMDVwy/c7pSGfC/8FwpzrV3FFtKlGW4NJbQUXOUJmaPAwitaoZ5GhSTygTmOprUEnd6kSN Stax2rSsEZxnN+mpVn1N64OSUp4MZxdBl7ZUduV7Ie1SSNS7rfWv9QweGPEZ1RkhlJ+vcilACcpY IO6TLIXdJSwPwknkOO6HQQNjGBvyWH7e7FvUE9Ek3ZnMfyI2eBtM7WYLckU6VtYsJIvfYJ9pkFP/ urazXJGtRVG7Wjz20piAUaANnSla1v7WtyMLrHLbyly2Ohew+/ppOCNLFnn20bWA3O1yn7td6HK3 ubvjHWG/2dgulpdb502verNCXcMqViKbw6pT3to7ndXXsCWhYFM+x8j2NoZ5shspS0tqV6wKGIUp xYkiPUip7ZX0wa4rK/laKN8IP1RZ9qThfVXUV+5NkK7ynTD/QCxhh1K0viAMqf4e6jyq8hStLj6r ghkc2jOFtcIx1iuEY6w87/q4u24VJ3GVNFe8jtjINDWoXFla1IiCF8hP7i8Px4utw85Yau/9iX/X y+Uue1RUtVTRcL3YLhXhdkAPg6rvaMtaQwry/5VlEe5CQifadZaWmGemipx3WOZxatOS143zz/RG Z9oO05LTPC15CchIN/55m3r8cZS/S2lJD5mDA5Ne9TgU5uwC+pSVhnKoJ23p8F5WgOL1cqNV3TlW u5ptzJPKlkWEuI7EOir0BWq7NgwiK8O3o0/h78nuO+uviDTAFlZpkSm83wWad9W0dqGIaTrtHfta KIrUtUXxm0ESt5DE1sb1oBO4bW7LeKrhhvG1hyIw+JWbw1Y1sLpxXLdSi9rezSVgRd+q4m4X9dtM Rjb/8D3qgq8Vcl/MXfagrd5ip9fhr464xLkYqjO/Ns7lBmpmf/idPNsSsj0L2Vdp3KHW2vm22P/N 7lb2TF649labxwQucrXC8lW73EPnhCeiW7lKjy/ldmNOH28HhE3j7lyYPF85cQm96PkUHZWQriap 7031qc+T0SQnOcStEmZ0kjOVfCS42KtOaYT3+YYB4/d6t95Ytk/87XCPu9znTve62/3ueM+73vfO 9777/e+AD7zgB0/4whv+8IhPvOIp4naPNL4ij1eKZkH32egGEZwnIaW38sH5fAyk854XCOcJEnrQ zlrtSBk6uRnC9HqmRPMGKT0pPC972ov+9qz/COqPomk6izJ3Cd+g9KZsQNlu/LKmXjjHZ8/8zzc/ 9LLXcLs3rnyHUX/TQckYOHff34OpmdEqi9j/s9d885kpxPbOh37zaxzCRJJ/ZdgHSu8xP2yzlwz5 wNdd5UE22P373vo7c364h3uj93zRp0HuQjPzp2nxp2Vr9jJsJDQI1EbAg4AP6H7b50wMWD0FuH4e eHvql1wDhHrmx3+Sd4Hf936710wlGDokaIGj9H6xVxC1R4MEqF389oILGGzEt2j89TnuEnShhEuJ dE/+Z3ZCt3D2Qnoz6HxM+HzSRy+phnbC9kUMN19ftkwOAXoFCHo2+HkHKCmRBxHLp0a8tnhomIZq uIZs2IZu+IZwGIdyOId0WId2eId4mId6uId82Id++IeAGIiQBUqqNWeXx3g+hVhXZzMBWIjb/1Vj GUh/9LNgq4d9j9deY0hxl9ZG1OJ6IxeJzpZ7EaF6DYg3plgU3XRPXlSBszVdQXMxVdgxaZZDATh9 p/ZZH3R9DKRw3peEyqc+Z5eJXFR8PvSKMkOBsOgwkdg+rHiBFmiMJgiKzgWDHJRLMtiMupN6vWhf uiaB3UeMGYgz29gyj+ON3IiB0zNcgiVC1dhF5seK2mcUzHiF4bh04yiD6ZiMG3hAhfaCEOiJ7YaP /CiL9FeKPOFdHGOOLDiQoKhL8zeQDplcjXZwbbWPO5iP9Jh9CphLvHh/xLaRFah/+TSEurhr/DeF jSg/wWdePbiQNxSSK2mQNNcVQSWMHmKTM/9Rk4K4k6+Gk0dDipP3ia2GdU3kjmQIeWrUiewGlE3n iBfhk055S05FFAGJdjFIheqzkl4Fi7W4YRkTk5HTi7OIO8eHPUA3ZUrIlcj3jGS5luyGkejYjspl jccIf0YJjVu5hHK5lzk4ciU4gRfpfSGJadhWl3H5lxFpeVJolzi4awl4lXxJjTm4kBbpmJLJMrH4 ltt4mNRIT2o2mLUIWtKIQDqIj/8HNCLImOtYj6spkxiGmuXnTf74Mq7Xfuo4jVvZgpepgKlZkInZ jr8JlU8JmBw5aCiplez3kqhpT9D4kqkWMbzTllcXhNqFlcInXglnm9jJKUJ4ioUpKxW1OKj/yJPk WZ7meZ7omZ7quZ7s2Z7u+Z7wGZ/yOZ/0WZ/2eZ/4mZ/62SGFdYaUeJQ+QZGZRxEU0igRUicIF1Bl mJCumZH/qZSimYiLOKASkSRRAiWQCKGT2JQZGmTDaYgJtYsodoTKqZVhiZXeAih5kh2fSISp9VOv SJ2CVZIl6ou2aJI4k5VpiRLzqIHOuJgM2pBDpqKIoid+6Yzhh4wu2JvUk5t6GZhO6hI9Si6lKZLM dIT4d47lsSdOAiFzyZtYl52b+Y8FaV/RSJi6SYLCOaXJCaWm+W6K8iTMYRfB+aKXaZtaV3+GuZuR yX1nOBII6aZ1Wqdb6idUciXVSZjTpYJZ/yebd4mOSxqYeroSuUiLYmqmuQajShg/kDIkheqlo1SW GmajuLicKjmYSXilzdmDZuqcVumASgeiFrF1wulRfyprlDerUrmfvNqrvvqrwBqswjqsxFqsxnqs yJqsyrqszNqszvqs0Bqt0lo11EEZcpIozWGtC+IX3Eodz1GtC+KtMlIrPGIb17qt1uqp3GoZ5rqu QAKq2OKlnLEWp1EelwGv7Xqg+Aoh5aox+4oYF3Ku2Mqu7Pqv6Jqv4WKw54qwjYKv2rqtCvuwDlss EUuw/zqxzVGt4ooaB9qw4EqxAEuvD5sgEwuqHHutPzKyCRuyC2uwA3uw+sqy8jquuVKx6J6qsC+r srYRsfxKszXLGjwLtIbirjErsqLRsf5arkFbrz3rKN3KskfLsPkCruK6GuF6rwlCsBC7sQgbHVw7 rWAbtmI7tmRbtmZ7tmibtmq7tmzbtm77tnAbt3I7t3Rbt3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuUgREAA7 ------=_NextPart_000_0007_01C76BCA.604F15F0-- From sip-bounces@ietf.org Wed Mar 21 12:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3iL-0003Xe-1Z; Wed, 21 Mar 2007 12:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3iJ-0003U6-38 for sip@ietf.org; Wed, 21 Mar 2007 12:31:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU3iE-00062V-9h for sip@ietf.org; Wed, 21 Mar 2007 12:31:03 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2007 09:30:59 -0700 Received: from [64.142.29.214] ([10.21.82.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l2LG9QDm020644; Wed, 21 Mar 2007 08:09:26 -0800 Message-ID: <46015E4A.8020500@cisco.com> Date: Wed, 21 Mar 2007 09:33:14 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] some comments on draft-ietf-sip-sips References: <9D18525F6EF33947BDEF23374EF26C7A06CC8D@stntexch11.cis.neustar.com> In-Reply-To: <9D18525F6EF33947BDEF23374EF26C7A06CC8D@stntexch11.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1326; t=1174493366; x=1175357366; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20some=20comments=20on=20draft-ietf-sip-sips |Sender:=20 |To:=20=22Peterson,=20Jon=22=20; bh=hxm5sPcp+e0XJViiNrG/4Jy5dH4k647qruKtabE7bCE=; b=diLnCqO7ssPd1wjtVV3YeLNVl8Yscdrh3U0iY1EHG+OwF7wxnJzUpNCu/WBl6tjWWcuR4egr Jc9W+4sE1NkSQw3+uUftYeJ5s8TdqV7ZsXkEp07e19HdKazJNYxl1cDi; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF SIP List , Juha Heinanen , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Peterson, Jon wrote: > Further on in RFC3261 26.4.4 after the text being cited about upgrading from SIP to SIPS, there is the following: > > To address these concerns, it is RECOMMENDED that recipients of a > request whose Request-URI contains a SIP or SIPS URI inspect the To > header field value to see if it contains a SIPS URI (though note that > it does not constitute a breach of security if this URI has the same > scheme but is not equivalent to the URI in the To header field). > > On those grounds, I would argue that the absence of SIPS in the Request-URI of a request where the To header field uses the SIPS URI scheme is indeed informative. The UAS in this context can see that the UAC's request for hop-by-hop TLS has not been honored. So, I can't agree that we need to stop thinking that the use of SIPS tells us anything. While forms of collusion among intermediaries certainly might conceal hijinx from the UAS, this doesn't mean that some cases are not caught by this check. > So let me get this straight: I'm just a dumb old proxy programmer and I managed to figure out that somebody was misspelling SIP in the To: headers so I fix it for them and viola, everything works. Am I a colluding hijinxster or just a regular joe-lunchbox with a job to get done? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 12:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3ya-00055M-Qz; Wed, 21 Mar 2007 12:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3yZ-00053Q-JG for sip@ietf.org; Wed, 21 Mar 2007 12:47:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU3yO-0003gh-Oa for sip@ietf.org; Wed, 21 Mar 2007 12:47:51 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 17:47:40 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LGlehv019408; Wed, 21 Mar 2007 17:47:40 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LGldlZ006692; Wed, 21 Mar 2007 16:47:39 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:47:39 +0100 Received: from [10.61.66.129] ([10.61.66.129]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:47:38 +0100 Message-ID: <460161AB.6050800@cisco.com> Date: Wed, 21 Mar 2007 12:47:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Adam Roach Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> <460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com> <46013B51.9050509@nostrum.com> In-Reply-To: <46013B51.9050509@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 16:47:38.0566 (UTC) FILETIME=[A26F4E60:01C76BD8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3340; t=1174495660; x=1175359660; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20important=20gruu=20issue=20on=20implementability, =20w as=3A=20Re=3A=20[Sip]=20size=0A=20of=09temporary=20GRUUs |Sender:=20; bh=zCeuS4szG7IVzn7iWZVZqspizTCMmYnP9/wgY2kyfV0=; b=NGNZiQd15eaznu7LNpBqQ7mZfVOLVuEIiZ5lG9jerim1oCbG26ib4BPAkgrl43RajMehq3pH K39KMymgUkBrm6uEWVoF2u95jVts5qLQR+mGMKhTgwinJeEVDaX8Gl70; Authentication-Results: ams-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Modulo odds and ends this looks workable to me. And it only needs to be an existence proof. There could be alternative implementations that are more space and/or time efficient. Paul Adam Roach wrote: > Jonathan Rosenberg wrote: >>> >>> The problem is that it opens up a state exhaustion attack in which I >>> register ever 20 milliseconds instead of every 3600 seconds. Yes, >>> you'll know it's me (or someone who has compromised my account), but >>> the only recovery path likely is rebooting the server or hoping that >>> the server has some kind of very fancy administrative nerd knob that >>> allows release of GRUU state sequence numbers. >> >> Ah, great point. This is easily fixed though. Instead of using the >> next sequence number anytime any endpoint registers, we increment it >> only once every T minutes, where T is the minimum registration >> interval you support on the network. Even if a client registers more >> frequently and its not an attack (who knows why), worst case is it >> doesn't get a new temp-gruu, it gets one it already had. But odds are >> it has a few stored up anyway. >> >> So with that change, lets say we set T to 10 minutes. Thats 52,560 >> random numbers if you assume a 6-month continuous uptime. >> >> Another similar option is to time-bound these also; say, to two weeks. >> This would preclude a dialog being up for two weeks. A client with a >> really long-lived subscription would have to terminate and resubscribe >> every two weeks. Not a huge deal IMHO but it would be a limitation. To >> deal with time sync, the server keeps them around for two weeks and a >> day, so you really never run into a race failure. >> >> Thinking aloud here to try and find something that actually works.... > > After giving this some more thought, I think the solution may lie in the > direction of using a *random* number (not a sequence number) for the > part that's visible, and then using a subset of bytes from a crypto hash > of this random number plus a server secret for your xor operation. > > More concretely (and this is a slight variation on your original > proposal)... > > To form a private gruu in a stateful fashion, the registrar picks a > random number. It then calculates a 16-byte key: > > key = substring(H(random-number, server-secret), 16) > > (Where H is a crypto hash that produces at least 16 bytes of hash output) > > Then, using the 64-bit AOR id and 64-bit instance id you described in > your earlier email, the GRUU would be formed as: > > sip:gruu.hex().base64(XOR(key, concat(aor-id,instance-id))) > > In practice, these would end up looking like: > > > > It's not exactly concise (52 bytes, including the domain), but it is > quite unlikely to cause problems. The advantage is that it requires no > additional state storage by the registrar beyond the key itself. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 13:39:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4ls-0004j2-Rg; Wed, 21 Mar 2007 13:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4lq-0004in-L5 for sip@ietf.org; Wed, 21 Mar 2007 13:38:46 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4ln-0007gC-1G for sip@ietf.org; Wed, 21 Mar 2007 13:38:46 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 18:38:43 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LHcgXm012065; Wed, 21 Mar 2007 18:38:42 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LHcglZ021801; Wed, 21 Mar 2007 17:38:42 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 18:38:42 +0100 Received: from [130.129.23.206] ([10.58.48.99]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 18:38:41 +0100 Message-ID: <46016DA0.8020904@cisco.com> Date: Wed, 21 Mar 2007 13:38:40 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> <460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com> <46013B51.9050509@nostrum.com> In-Reply-To: <46013B51.9050509@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 17:38:41.0470 (UTC) FILETIME=[C4115DE0:01C76BDF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4571; t=1174498722; x=1175362722; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20important=20gruu=20issue=20on=20implementability, =20w as=3A=20Re=3A=20[Sip]=20size=0A=20of=09temporary=20GRUUs |Sender:=20; bh=0+OqxTV9SuJZuqf3AR1iWTuQJBLGuSk/TGOhzBydCsI=; b=ia9jZQz3kso4XCc/zd0X50cllcTyx70JN7ScRcrpt/NWeWQoZyRCUGGFir+TnmksSrpTJydx ggb3TZTUDwISP38D4ggPhRRvbAi75R6FNeLRYV3REN1FL2mBeHMx61Kg; Authentication-Results: ams-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is an excellent idea, Adam. I think this works. One more thing we need. We need to be able to invalidate temp-GRUU when the call-ID changes or the registration lapses. My proposal for that is that the server maintains, for each AOR and instance ID, a sequence number. This sequence number increments by one when a brand new registration is made for that AOR and instance ID, and when the call-ID changes for that AOR and instance ID. I'm not sure how many bits we need for this; it needs to be big enough that a very old GRUU can't be reused in the future by waiting for the counter to cycle. So, if you presume a rotation every half day, 16 bits is more than enough. A malicious user that rotates it more often just hurts themself, not anyone else. You'd include this 16 bit seqno into the XOR, adding three more characters to the GRUU. When you receive a GRUU, extract the seqno. If it matches the current stored value, the GRUU is valid. If older, its invalid. The drawback to this is that the registrar needs to store the instance IDs it has seen even after the registration for that instance ID expires. If a registrar can't validate instance IDs, this opens up a DoS attack where I send lots of registers to fill up the table with instance IDs. Easiest way to handle this is to limit the number of instance IDs for a particular user. -Jonathan R. Adam Roach wrote: > Jonathan Rosenberg wrote: > >>> >>> The problem is that it opens up a state exhaustion attack in which I >>> register ever 20 milliseconds instead of every 3600 seconds. Yes, >>> you'll know it's me (or someone who has compromised my account), but >>> the only recovery path likely is rebooting the server or hoping that >>> the server has some kind of very fancy administrative nerd knob that >>> allows release of GRUU state sequence numbers. >> >> >> Ah, great point. This is easily fixed though. Instead of using the >> next sequence number anytime any endpoint registers, we increment it >> only once every T minutes, where T is the minimum registration >> interval you support on the network. Even if a client registers more >> frequently and its not an attack (who knows why), worst case is it >> doesn't get a new temp-gruu, it gets one it already had. But odds are >> it has a few stored up anyway. >> >> So with that change, lets say we set T to 10 minutes. Thats 52,560 >> random numbers if you assume a 6-month continuous uptime. >> >> Another similar option is to time-bound these also; say, to two weeks. >> This would preclude a dialog being up for two weeks. A client with a >> really long-lived subscription would have to terminate and resubscribe >> every two weeks. Not a huge deal IMHO but it would be a limitation. To >> deal with time sync, the server keeps them around for two weeks and a >> day, so you really never run into a race failure. >> >> Thinking aloud here to try and find something that actually works.... > > > After giving this some more thought, I think the solution may lie in the > direction of using a *random* number (not a sequence number) for the > part that's visible, and then using a subset of bytes from a crypto hash > of this random number plus a server secret for your xor operation. > > More concretely (and this is a slight variation on your original > proposal)... > > To form a private gruu in a stateful fashion, the registrar picks a > random number. It then calculates a 16-byte key: > > key = substring(H(random-number, server-secret), 16) > > (Where H is a crypto hash that produces at least 16 bytes of hash output) > > Then, using the 64-bit AOR id and 64-bit instance id you described in > your earlier email, the GRUU would be formed as: > > sip:gruu.hex().base64(XOR(key, concat(aor-id,instance-id))) > > In practice, these would end up looking like: > > > > It's not exactly concise (52 bytes, including the domain), but it is > quite unlikely to cause problems. The advantage is that it requires no > additional state storage by the registrar beyond the key itself. > > /a > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 13:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4qC-00088q-79; Wed, 21 Mar 2007 13:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4qA-00087C-Sa for sip@ietf.org; Wed, 21 Mar 2007 13:43:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4q9-0000XW-JK for sip@ietf.org; Wed, 21 Mar 2007 13:43:14 -0400 Received: from [130.129.18.89] (dhcp-1259.ietf68.org [130.129.18.89]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2LGnO20009266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Mar 2007 10:49:26 -0600 In-Reply-To: <9D18525F6EF33947BDEF23374EF26C7A06CC8D@stntexch11.cis.neustar.com> References: <9D18525F6EF33947BDEF23374EF26C7A06CC8D@stntexch11.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] some comments on draft-ietf-sip-sips Date: Wed, 21 Mar 2007 18:43:06 +0100 To: "Peterson, Jon" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 21, 2007, at 11:21 AM, Peterson, Jon wrote: > > > Further on in RFC3261 26.4.4 after the text being cited about > upgrading from SIP to SIPS, there is the following: > > To address these concerns, it is RECOMMENDED that recipients of a > request whose Request-URI contains a SIP or SIPS URI inspect the To > header field value to see if it contains a SIPS URI (though note > that > it does not constitute a breach of security if this URI has the > same > scheme but is not equivalent to the URI in the To header field). > > On those grounds, I would argue that the absence of SIPS in the > Request-URI of a request where the To header field uses the SIPS > URI scheme is indeed informative. The UAS in this context can see > that the UAC's request for hop-by-hop TLS has not been honored. So, > I can't agree that we need to stop thinking that the use of SIPS > tells us anything. While forms of collusion among intermediaries > certainly might conceal hijinx from the UAS, this doesn't mean that > some cases are not caught by this check. > It would seem to me that one of the "evil proxies" here could easily change the URI in the To: to sip: and keep this heuristic from working. True, it has to patch it both directions, but unless we're running RFC 4474 or something similar, nobody will know. Once again, SIPS tells us only that we asked the proxies to use comply, and that we can value the efficacy of this request only to the extent that we trust every one of those proxies. The above heuristic might be useful for catching simple configuration errors. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 14:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU55z-00016r-EK; Wed, 21 Mar 2007 13:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU55y-00016m-G7 for sip@ietf.org; Wed, 21 Mar 2007 13:59:34 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU55v-0006qN-20 for sip@ietf.org; Wed, 21 Mar 2007 13:59:34 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2LHxOML099260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 11:59:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4601727C.6010407@nostrum.com> Date: Wed, 21 Mar 2007 18:59:24 +0100 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> <460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com> <46013B51.9050509@nostrum.com> <46016DA0.8020904@cisco.com> In-Reply-To: <46016DA0.8020904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Okay, so you're proposing something like: sip:gruu.base64(concat(random-number,sequence-number,XOR(key, concat(aor-id,instance-id)))) With an example of: sip:gruuRNGBTJA/McBVMV/YKP42ALY6Zy3eyg==@example.org (assuming 32-bit random numbers and 16-bit serial numbers) That's still 52 characters (with the savings from moving the sequence number into the base-64, at Paul Kyzivat's suggestion)... /a Jonathan Rosenberg wrote: > This is an excellent idea, Adam. I think this works. > > One more thing we need. We need to be able to invalidate temp-GRUU > when the call-ID changes or the registration lapses. My proposal for > that is that the server maintains, for each AOR and instance ID, a > sequence number. This sequence number increments by one when a brand > new registration is made for that AOR and instance ID, and when the > call-ID changes for that AOR and instance ID. I'm not sure how many > bits we need for this; it needs to be big enough that a very old GRUU > can't be reused in the future by waiting for the counter to cycle. So, > if you presume a rotation every half day, 16 bits is more than enough. > A malicious user that rotates it more often just hurts themself, not > anyone else. > > You'd include this 16 bit seqno into the XOR, adding three more > characters to the GRUU. When you receive a GRUU, extract the seqno. If > it matches the current stored value, the GRUU is valid. If older, its > invalid. > > The drawback to this is that the registrar needs to store the instance > IDs it has seen even after the registration for that instance ID > expires. If a registrar can't validate instance IDs, this opens up a > DoS attack where I send lots of registers to fill up the table with > instance IDs. Easiest way to handle this is to limit the number of > instance IDs for a particular user. > > -Jonathan R. > > Adam Roach wrote: > >> Jonathan Rosenberg wrote: >> >>>> >>>> The problem is that it opens up a state exhaustion attack in which >>>> I register ever 20 milliseconds instead of every 3600 seconds. Yes, >>>> you'll know it's me (or someone who has compromised my account), >>>> but the only recovery path likely is rebooting the server or hoping >>>> that the server has some kind of very fancy administrative nerd >>>> knob that allows release of GRUU state sequence numbers. >>> >>> >>> Ah, great point. This is easily fixed though. Instead of using the >>> next sequence number anytime any endpoint registers, we increment it >>> only once every T minutes, where T is the minimum registration >>> interval you support on the network. Even if a client registers more >>> frequently and its not an attack (who knows why), worst case is it >>> doesn't get a new temp-gruu, it gets one it already had. But odds >>> are it has a few stored up anyway. >>> >>> So with that change, lets say we set T to 10 minutes. Thats 52,560 >>> random numbers if you assume a 6-month continuous uptime. >>> >>> Another similar option is to time-bound these also; say, to two >>> weeks. This would preclude a dialog being up for two weeks. A client >>> with a really long-lived subscription would have to terminate and >>> resubscribe every two weeks. Not a huge deal IMHO but it would be a >>> limitation. To deal with time sync, the server keeps them around for >>> two weeks and a day, so you really never run into a race failure. >>> >>> Thinking aloud here to try and find something that actually works.... >> >> >> After giving this some more thought, I think the solution may lie in >> the direction of using a *random* number (not a sequence number) for >> the part that's visible, and then using a subset of bytes from a >> crypto hash of this random number plus a server secret for your xor >> operation. >> >> More concretely (and this is a slight variation on your original >> proposal)... >> >> To form a private gruu in a stateful fashion, the registrar picks a >> random number. It then calculates a 16-byte key: >> >> key = substring(H(random-number, server-secret), 16) >> >> (Where H is a crypto hash that produces at least 16 bytes of hash >> output) >> >> Then, using the 64-bit AOR id and 64-bit instance id you described in >> your earlier email, the GRUU would be formed as: >> >> sip:gruu.hex().base64(XOR(key, >> concat(aor-id,instance-id))) >> >> In practice, these would end up looking like: >> >> >> >> It's not exactly concise (52 bytes, including the domain), but it is >> quite unlikely to cause problems. The advantage is that it requires >> no additional state storage by the registrar beyond the key itself. >> >> /a >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 14:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5GM-0005rQ-Th; Wed, 21 Mar 2007 14:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5GI-0005pR-92 for sip@ietf.org; Wed, 21 Mar 2007 14:10:14 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5El-0001TH-3R for sip@ietf.org; Wed, 21 Mar 2007 14:08:40 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 3CE263BED1 for ; Wed, 21 Mar 2007 19:08:24 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31738-01-68 for ; Wed, 21 Mar 2007 19:08:24 +0100 (CET) Received: from [130.129.20.199] (dhcp-14c7.ietf68.org [130.129.20.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id D18193BE64 for ; Wed, 21 Mar 2007 19:08:23 +0100 (CET) Message-ID: <46017459.1080608@it.su.se> Date: Wed, 21 Mar 2007 19:07:21 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.253 tagged_above=-99 required=7 tests=[AWL=0.059, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] outbound algorithm X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi For those who were not on the SIP meeting today, the SIP session today concluded that only one of the two algorithms an edge proxy could compute a flow identifier using should be present in the next version of the outbound draft. As a pre-WGLC item for outbound, I would like to request that the security problems the remaining algorithm is supposed to address be explicitly specified in the draft, since I think there will still be scenarios where an attacker can hijack another user's incoming calls, even when the remaining algorithm is used. Thanks /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 14:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5La-0006gN-BZ; Wed, 21 Mar 2007 14:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5LZ-0006eL-5t for sip@ietf.org; Wed, 21 Mar 2007 14:15:41 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5LX-0004K7-SO for sip@ietf.org; Wed, 21 Mar 2007 14:15:41 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2LIFYmM000204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 12:15:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <46017645.3030108@nostrum.com> Date: Wed, 21 Mar 2007 19:15:33 +0100 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: important gruu issue on implementability, was: Re: [Sip] size of temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com> <460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com> <46013B51.9050509@nostrum.com> <46016DA0.8020904@cisco.com> In-Reply-To: <46016DA0.8020904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > The drawback to this is that the registrar needs to store the instance > IDs it has seen even after the registration for that instance ID > expires. If a registrar can't validate instance IDs, this opens up a > DoS attack where I send lots of registers to fill up the table with > instance IDs. Easiest way to handle this is to limit the number of > instance IDs for a particular user. This seems to be a serious drawback. Can't we avoid this (with a probability of 1:65536) by selecting the starting serial number for a new instance at a random number instead of 0? If those odds aren't good enough, making the seqno 32-bits long would *certainly* be good enough (and add only three more characters, for a total of 55 in my example). Something else to keep in mind is that we probably need to describe this approach in an *exemplary* fashion, not a normative one -- we should allow implementations to have variations on the theme where it makes sense for them (e.g., 32-bit identifiers where they make sense, variations in hash algorithms, etc.) /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 14:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5o5-0005oe-V9; Wed, 21 Mar 2007 14:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5o3-0005oW-Sp for sip@ietf.org; Wed, 21 Mar 2007 14:45:07 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5o1-0003di-M6 for sip@ietf.org; Wed, 21 Mar 2007 14:45:07 -0400 Received: (qmail 28965 invoked by uid 0); 21 Mar 2007 18:44:43 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 Mar 2007 18:44:43 -0000 Message-ID: <002201c76be8$f8717bc0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Adam Roach" , "Jonathan Rosenberg" References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com><460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com><46013B51.9050509@nostrum.com> <46016DA0.8020904@cisco.com> <46017645.3030108@nostrum.com> Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs Date: Wed, 21 Mar 2007 19:44:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, Sean Olson , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This whole discussion is exactly following my line of thought, with one difference I was thinking to mix in a hash of the call-id (say 32 bits), rather than a sequence number. This avoids having to maintain extra state, and gets what you want: the temp GRUU is valid exactly as long as the call-id associated with the registration is valid. The latter needs to be stored already anyway Regards, Jeroen Adam Roach wrote: > Jonathan Rosenberg wrote: >> The drawback to this is that the registrar needs to store the >> instance IDs it has seen even after the registration for that >> instance ID expires. If a registrar can't validate instance IDs, >> this opens up a DoS attack where I send lots of registers to fill up >> the table with instance IDs. Easiest way to handle this is to limit >> the number of instance IDs for a particular user. > > This seems to be a serious drawback. Can't we avoid this (with a > probability of 1:65536) by selecting the starting serial number for a > new instance at a random number instead of 0? If those odds aren't > good enough, making the seqno 32-bits long would *certainly* be good > enough (and add only three more characters, for a total of 55 in my > example). > Something else to keep in mind is that we probably need to describe > this approach in an *exemplary* fashion, not a normative one -- we > should allow implementations to have variations on the theme where it > makes sense for them (e.g., 32-bit identifiers where they make sense, > variations in hash algorithms, etc.) > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 16:25:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7LF-00055f-HM; Wed, 21 Mar 2007 16:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7LD-00053Z-S5 for sip@ietf.org; Wed, 21 Mar 2007 16:23:27 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU7LB-0005Tu-KN for sip@ietf.org; Wed, 21 Mar 2007 16:23:27 -0400 Received: from [130.129.55.115] (dhcp-3773.ietf68.org [130.129.55.115]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2LKNJKk012347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Mar 2007 16:23:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0B710C80-F46C-4C35-B00A-A24811FCDD7A@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Henning Schulzrinne Date: Wed, 21 Mar 2007 16:23:19 -0400 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] DNS-SD: use cases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Since there was a request for describing use cases during today's discussion: http://tools.ietf.org/html/draft-bryan-sipping-p2p-usecases-00 highlights several that relate to a local discovery/p2p protocol. Having been involved in the long run-up to the P2PSIP effort, I assumed these to be known, which was obviously a mistake on my part. (As a side note, use of non-host names seems common in SD PTR announcemens, with _presence._tcp (aka iChat) and _sip._udp (for announcing phones, apparently by sipphone.com = Gizmo) using these. This says nothing about legality, although one would hope that the iChat developers would have talked to their colleague.) Today's discussion about sips and verifying the identity of the other side directly relates to this and the larger P2P effort. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 21:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUCKQ-00039a-7F; Wed, 21 Mar 2007 21:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUCKM-00039I-3O for sip@ietf.org; Wed, 21 Mar 2007 21:42:54 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUCKK-0005Ol-TO for sip@ietf.org; Wed, 21 Mar 2007 21:42:54 -0400 Received: from dragon.ariadne.com (failure[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007032201423201300p1vb2e>; Thu, 22 Mar 2007 01:42:52 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2M1fqLv016755 for ; Wed, 21 Mar 2007 20:41:52 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2M1fqq0016751; Wed, 21 Mar 2007 20:41:52 -0500 Date: Wed, 21 Mar 2007 20:41:52 -0500 Message-Id: <200703220141.l2M1fqq0016751@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1136.149.125.255.4.1174334189.squirrel@smail.binghamton.edu> (mhearne1@binghamton.edu) Subject: Re: [Sip] Mj-Sip Server Problem References: <1136.149.125.255.4.1174334189.squirrel@smail.binghamton.edu> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: mhearne1@binghamton.edu I am currently working on a project using MJ-Sip. We can currently connect user to user with dialogue transmission, however, our goal is to connect multiple users using MJ uac to a server using MJ server, proxy. We are getting an error that says "REFUSED Loop Detected". Does anyone have any suggestions on how to fix this problem. Thanks a lot. First check if that message means that a request received a 482 response. If so, do a detailed audit of the SIP message flow to determine what device is producing a 482 and why. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 21 23:59:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUEOE-0007dh-4z; Wed, 21 Mar 2007 23:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUEOC-0007Vz-6c for sip@ietf.org; Wed, 21 Mar 2007 23:55:00 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUEO8-0003OY-UF for sip@ietf.org; Wed, 21 Mar 2007 23:55:00 -0400 Received: from dragon.ariadne.com (failure[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007032203543801300p1bp2e>; Thu, 22 Mar 2007 03:54:54 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2M1xfLv018114; Wed, 21 Mar 2007 20:59:41 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2M1xf5K018110; Wed, 21 Mar 2007 20:59:41 -0500 Date: Wed, 21 Mar 2007 20:59:41 -0500 Message-Id: <200703220159.l2M1xf5K018110@dragon.ariadne.com> To: slawrence@pingtel.com, dean.willis@softarmor.com, sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1174427124.3528.21.camel@localhost.localdomain> (slawrence@pingtel.com) Subject: Re: [Sip] Jabber Experiment References: <45FF6FA0.5050909@isoc.org> <3DF69CFD-E444-43C8-A4AF-7AF71E763E6A@softarmor.com> <1174427124.3528.21.camel@localhost.localdomain> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Scott Lawrence We should consider making this a regular feature, I think (as well as having a SIP conference bridge that people can call in to). I would expect that the transcription is a *major* aid to people with low bandwidth connections (i.e., the entire Third World), hearing imparment, or weak English skills, and provides us with an archival copy of the proceedings. As for providing a SIP conference bridge: (1) I expect we can get some conference bridge manufacturer to pay for it as a marketing ploy. (2) The cobbler's children, etc. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 22 04:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ3m-0000TT-UP; Thu, 22 Mar 2007 04:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ3l-0000Sk-Oa for sip@ietf.org; Thu, 22 Mar 2007 04:54:13 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJ3W-0002q0-1i for sip@ietf.org; Thu, 22 Mar 2007 04:54:13 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2007 09:53:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2M8rvao028138; Thu, 22 Mar 2007 09:53:57 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2M8rqlZ013727; Thu, 22 Mar 2007 08:53:52 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 09:53:52 +0100 Received: from [130.129.19.212] ([10.58.48.201]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 09:53:51 +0100 Message-ID: <4602441E.8030304@cisco.com> Date: Thu, 22 Mar 2007 04:53:50 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs References: <013701c7665e$83d323c0$0601a8c0@BEMBUSTER> <4C1596FBF66C67478BCFE7B3F81FC1E01788144B6F@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <016b01c76660$655d85f0$0601a8c0@BEMBUSTER> <86odmv7hjt.fsf@raman.networkresonance.com> <45F84AFE.2040502@cisco.com> <45FBBD80.10403@nostrum.com> <17920.7341.266448.476150@harjus.tutpro.com> <460101AB.2080205@cisco.com><460105E6.1090408@nostrum.com> <4601334E.90706@cisco.com><46013B51.9050509@nostrum.com> <46016DA0.8020904@cisco.com> <46017645.3030108@nostrum.com> <002201c76be8$f8717bc0$0601a8c0@BEMBUSTER> In-Reply-To: <002201c76be8$f8717bc0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 08:53:51.0844 (UTC) FILETIME=[9D338240:01C76C5F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4249; t=1174553637; x=1175417637; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20important=20gruu=20issue=20on=20implementability, =20w as=3A=20Re=3A=20[Sip]=20sizeof=0A=20temporary=20GRUUs |Sender:=20; bh=AiopezvmUm7l+PLA3O4RIb4Codls4JhmXby75vpBadw=; b=EYrckf3725gtgcAT0I6A00aNB2ziZFwRqjgh70F3tjruKSAOjQDyBiKOo7+TOW4tWdbXNHs9 XgPrWj79k2UKaeAqwiE5R/Dg3M2vuDU039yvYGo23PEpWPTjg9Gzs/5L; Authentication-Results: ams-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, Sean Olson , Juha Heinanen , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I talked to Ekr about this after the plenary, and he had a better, much simpler approach that I think works very well. The idea is that, for each registration for a particular AOR and instance that is currently active, the server will have a hashkey. The hashkey is some number of bits, say 64. You hash this hashkey into a hashtable and it gives you the current AOR and instance ID and/or its registration contents. When the call-id changes, you pick a new hashkey. When the registration expires, you remove the hashkey from the hashtable. A temp-gruu is constructed as: sip:gruu. So when the proxy receives a request with the gruu prefix, it decrypts the rest, and gets the hashkey, discarding the random number. If it exists in the hashtable, it is a valid temp gruu, and it is bound to the AOR/instance ID that comes out of the hash table. If its not in the hashtable, the temp-gruu is invalid. This approach doesn't constrain the number of temp-gruu in any way, or require the registrar to store or limit the set of instance IDs, or remember past instance IDs, past call-ids, or whatever. Most likely this is easily done by adding another column to tables that existing registrars already have. Ekr agreed to propose a specific 'encrypt' function, so we can measure how big the resulting gruu are. The good news is that the hashkey can probably be something like 64 bits, random number around 64, and I'm hopeful there is something that can encrypt a 128 bit value without much expansion. The main thing is that this is a 'real' encryption algorithm with the property that you can't correlate two pieces of ciphertext to each other as having similar plaintext. A lot of our complexity in the previous proposals was the problem that XOR as an encryption technology doesn't have this property. Comments? -Jonathan R. Jeroen van Bemmel wrote: > This whole discussion is exactly following my line of thought, with one > difference > > I was thinking to mix in a hash of the call-id (say 32 bits), rather > than a sequence number. This avoids having to maintain extra state, and > gets what you want: the temp GRUU is valid exactly as long as the > call-id associated with the registration is valid. The latter needs to > be stored already anyway > > Regards, > Jeroen > > Adam Roach wrote: > >> Jonathan Rosenberg wrote: >> >>> The drawback to this is that the registrar needs to store the >>> instance IDs it has seen even after the registration for that >>> instance ID expires. If a registrar can't validate instance IDs, >>> this opens up a DoS attack where I send lots of registers to fill up >>> the table with instance IDs. Easiest way to handle this is to limit >>> the number of instance IDs for a particular user. >> >> >> This seems to be a serious drawback. Can't we avoid this (with a >> probability of 1:65536) by selecting the starting serial number for a >> new instance at a random number instead of 0? If those odds aren't >> good enough, making the seqno 32-bits long would *certainly* be good >> enough (and add only three more characters, for a total of 55 in my >> example). >> Something else to keep in mind is that we probably need to describe >> this approach in an *exemplary* fashion, not a normative one -- we >> should allow implementations to have variations on the theme where it >> makes sense for them (e.g., 32-bit identifiers where they make sense, >> variations in hash algorithms, etc.) >> >> /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. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 22 06:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKOr-0006QH-9I; Thu, 22 Mar 2007 06:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKOp-0006Oo-28 for sip@ietf.org; Thu, 22 Mar 2007 06:20:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKOl-0001A3-57 for sip@ietf.org; Thu, 22 Mar 2007 06:20:03 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2007 11:19:59 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MAJwQv013236; Thu, 22 Mar 2007 11:19:58 +0100 Received: from [130.129.20.115] (ams3-vpn-dhcp4578.cisco.com [10.61.81.225]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2MAJela011582; Thu, 22 Mar 2007 10:19:51 GMT In-Reply-To: <94799C7B-1B0F-4A19-8960-40629DD60B44@nostrum.com> References: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> <5D1A7985295922448D5550C94DE29180E98300@DEEXC1U01.de.lucent.com> <94799C7B-1B0F-4A19-8960-40629DD60B44@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17D5986C-F59A-45B8-AAE1-4B9F64A9EA04@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] RE: Current status of WG slides posted for review with IETF 68 Date: Thu, 22 Mar 2007 11:19:50 +0100 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4130; t=1174558798; x=1175422798; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Current=20status=20of=20WG=20slides=2 0posted=20for=20review=20with=20IETF=2068 |Sender:=20; bh=m3+ti2fjAofUfdCsu9TmzHj0rAJYB7tIoecztLM+0/U=; b=X+xuNK2iOi728R8zWayR0brzaaYt3E3CCdSNR67PjWUYsoLft0Pycft7EE1O/eCeK4E94c9P 3T3lcgPbK3IL4hHUXlztfV8c2pIct2Qly5C3pqhzq3NXS+uoe344v/ZX; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: SIP IETF , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay and Scott went and presented in pkix and got that WG's advice on some of the certificates issues. I'm sure they will report back and update their draft based on this but from what they old me, it sounded like all the advice they got was consistent with the current document robert is working on. Anyways - I am fine with these slides as they are - we will just keep moving it along and change the examples if we find out we need too. On Mar 20, 2007, at 2:25 PM, Robert Sparks wrote: > And where the sip-sips discussion has gone, I don't think the outcome > will change the existing examples in the secflows draft at all. > > The problem spots I was watching have moved into other documents > (specifically, > what gets put into SubjectAltName of the certs involved). > > RjS > > On Mar 20, 2007, at 2:06 PM, Drage, Keith ((Keith)) wrote: > > >>> if sips changes sips: usage, it will certainly impact the > >> example call > >>> flows that use sips:. > >> I sort of doubt this - the example just show the basic setup > >> of the crypto stuff and don't deal with the type of stuff > >> sips covers but again, sure, we can see what the examples > >> look like when done. > >> > >> > > On this point, this is what we got from the editor (Robert) at the > > last > > meeting. He said he was going to wait on updating the document > because > > he needed to see if these documents did any change. > > > > Hopefully we can unravel this when we have finished the sip-sips > > discussion. > > > > Keith > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Monday, March 19, 2007 10:27 AM > >> To: Dean Willis > >> Cc: SIP IETF; Drage, Keith (Keith) > >> Subject: Re: Current status of WG slides posted for review > >> with IETF 68 > >> > >> > >> On Mar 19, 2007, at 10:29 AM, Dean Willis wrote: > >> > >>> > >>> I'm almost windering if we're looking at different versions of the > >>> slides. I'm going to post a new one anyhow, but . . . > >>> > >>> On Mar 16, 2007, at 11:06 PM, Cullen Jennings wrote: > >>> > >>>> On slide 4 > >>>> > >>>> e2m is waiting for resoltuion of issues with author and sec > review > >>> > >>> yeah, that's what it says. > >> > >> hmm - did I review the wrong slides? - if so my appolgies - > >> all these notes were for the slide 4 summary not later notes > >>> > >>>> > >>>> conncted-id is in rfc ed q > >>>> > >>>> > >>> > >>> thanks. > >>> > >>>> All the list URI messages are waiting for consent before we start > >>>> processing them > >>> > >>> The status slides say "waiting on publication request for > >> draft-ietf- > >>> sip-consent-framework". Is this unclear? > >>> > >>>> > >>> > >>>> ACR cod is in pub requested > >>>> > >>> > >>> yeah, that's what is says on page 4. > >>> > >>>> > >>>> Slide 15: > >>>> "how UPD is supported" is not an open issue from my read > >> of the list > >>>> traffic . Do we change to CRLF keep alive for TCP and > >> STUN for UDP > >>>> is the topic that we agree to discuss. > >>>> > >>>> > >>> Right. > >>> > >>>> > >>>> Skude 17 - I am unaware of what part of this is waiting > >> for sips or > >>>> domain-certs. Please let me know. > >>>> > >>> > >>> sips may or may not depend on domain certs. > >> Seems very unlikely to me but sure, whatever, is fine with > >> me, we will see > >>> > >>> if sips changes sips: usage, it will certainly impact the > >> example call > >>> flows that use sips:. > >> I sort of doubt this - the example just show the basic setup > >> of the crypto stuff and don't deal with the type of stuff > >> sips covers but again, sure, we can see what the examples > >> look like when 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 22 08:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULxz-0001vl-T2; Thu, 22 Mar 2007 08:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULxw-0001nV-96 for sip@ietf.org; Thu, 22 Mar 2007 08:00:24 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULxr-0002N3-BU for sip@ietf.org; Thu, 22 Mar 2007 08:00:24 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l2MC0FVx006785; Thu, 22 Mar 2007 07:00:16 -0500 (CDT) Received: from [135.244.2.210] (vkg.lra.lucent.com [135.244.2.210]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2MC0FM17098; Thu, 22 Mar 2007 07:00:15 -0500 (CDT) Message-ID: <46026FCE.5050007@alcatel-lucent.com> Date: Thu, 22 Mar 2007 07:00:14 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] RE: Current status of WG slides posted for review with IETF 68 References: <1977F26A-6018-4DA0-9F53-51D966212866@cisco.com> <5D1A7985295922448D5550C94DE29180E98300@DEEXC1U01.de.lucent.com> <94799C7B-1B0F-4A19-8960-40629DD60B44@nostrum.com> <17D5986C-F59A-45B8-AAE1-4B9F64A9EA04@cisco.com> In-Reply-To: <17D5986C-F59A-45B8-AAE1-4B9F64A9EA04@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > Vijay and Scott went and presented in pkix and got that WG's advice on > some of the certificates issues. I'm sure they will report back and > update their draft based on this but from what they old me, it sounded > like all the advice they got was consistent with the current document > robert is working on. Cullen: domain-certs was presented at pkix on Tuesday by Scott. pkix was fine with the use of EKU OIDs, though we still need to vet the exact wording and semantics on the pkix mailing list by Chicago. Other guidance, such as the use of SIP URIs in SAN, multiple names in SAN, and not inserting hostnames in the CN matches the general sipwg guidelines that we have talked about in context of domain-certs. We plan to rev up domain-certs to normatively capture this guidance relatively soon after Prague and socialize the rev'd draft on pkix as well as sip wg list. We also need to sync up with Francois to see if this affects sip-sips and RjS for sec-flows. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From kbizzellaamec@askltg.com Thu Mar 22 11:27:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPCa-0005iX-Nl; Thu, 22 Mar 2007 11:27:44 -0400 Received: from [124.60.249.98] (helo=askltg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUPCG-00029I-Aq; Thu, 22 Mar 2007 11:27:44 -0400 Message-ID: <83ee01c76cb4$17cd1da0$629d7d28@kbizzellaamec> Reply-To: "Debbra" From: "Debbra" To: "Viva" Cc: "Charline" , "Beverley Andrews" , "Velvet" , "Cristobal" , "Lory Garcia" , "Adam" , "Dorthea Knight" , "Nikita Perry" , "Johnny Burns" , "Sherrie Morris" , "Ulrike" Subject: Did she ask u Date: Thu, 22 Mar 2007 18:58:35 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_479_1317_486ADE42.5CC88914" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 X-Spam-Score: 2.4 (++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 This is a multi-part message in MIME format. ------=_NextPart_479_1317_486ADE42.5CC88914 Content-Type: multipart/alternative; boundary="----=_NextPart_CCA_CCCA_2B3116DC.247DD25B" ------=_NextPart_CCA_CCCA_2B3116DC.247DD25B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable prose "Why not? discover Who analyse ever heard of such paste an occurren= ce as "It politely is certainly search ten years feather teaching sin= ce the house had bee "Oh, heavens!""It is bottle stealthily probable,"= bump mouth stammered out Villefort, trying (Signed) "I understand; star tactic you cloud are grate displeased at t= he silence I rejoice "What is it, then?" move asked come the shock young= girl. "Perhaps "ABB BUSONI." face branch place "Sir," said the baroness front humbly, "are you not awa= r"There was, try word picture existence above all, one room," continued M= onte"Come, take bucket them," please and rail crime Monte Cristo forced t= he bannuptial art "Why so?" bathe said warm Danglars; "why dramatic?" destruction fax "It sheep delicious is the same." "No." "They son tol= d room you, then, noise that M. chalk d'Epinay consented t   "I was going to say that long I linen born received greedily a letter alm= os "But, boot sir," said spent Hermine smoggy suddenly, "if fake all this is= "And grubby then," eye damage said Monte Cristo, powerfully "this is not = all.""Nothing very difficult.""What is manager there more?" expansion mea= t said Debray, cerotic who had not fai "Yes." "Yes." "You do relax not knit like M. skin politely Franz?" T= he eyes repeated seve "No." "To trouble box escape request repeat these signs." Monte Cristo = took a paper Danglars cerebric tomorrow rot obediently shrugged his shoulders.sin "Wha= t alert lavatorial a wicked-looking, crooked knot staircase," said C"Yes;= but"--"I snore do not neatly process genethliac know whether the wine of= Chios produces "And of whom you support ornament have hemic no adorable more knowledge t= han I of glove At these edge words there art beset appeared in Noirtier'= s eye an minute sew shore "Yes." Noirtier test raised his eyes, it was th= e sign a strung powerful rid "Foolish creature," end he exclaimed. "Women fancy th= e"It is very evident what is letter above steel the scribble matter with = her,"bolt wing meat "Yes," replied the man, "but daughter at what a price= !"past "Yes," said sail wine trick Villefort, "really, count, you frighte= embarrassed "You have use dive shut seen him, then?""What is milk it cup = you attraction scratch want, grandpapa?" said Valent rubbery hum "Yes, = yes, bolt daughter yes," said the old man's eye. "Where?" thumb "I mean that bulb carry M. de zoic Nargonne, your first husband, bd= amage operation promise "Will you let come into the garden?" said Debray,= adva"Has your interfere handle warm husband any insect Spanish bonds?" h= e asked of"Are you rat really leave church frightened, madame?" slip said= Monte Cr "Ah, that is just jump what whisper I cannot tell you; examine fled if I = did "You start would guide wish a fit notary to be sent eager for then= ?" sai "Yes."   "Read it.""Ah, yes," said Monte bruise Cristo blastous meant at smiling; = "it is all a ------=_NextPart_CCA_CCCA_2B3116DC.247DD25B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



prose "Why not? discover Who analyse ever heard of such paste an = occurrence as     "It politely is certainly sear= ch ten years feather teaching since the house had bee   &n= bsp;"Oh, heavens!""It is bottle stealthily probable," bump mouth stammere= d out Villefort, trying     
(Signed)   "I understand; star tactic you cloud are grate = displeased at the silence I  rejoice "What is it, then?" move a= sked come the shock young girl. "Perhaps      "ABB BUSONI."     
face branch place "Sir," said the baroness front humbly, "are you not= awar"There was, try word picture existence above all, one room," continu= ed Monte"Come, take bucket them," please and rail crime Monte Cristo forc= ed the bannuptial art "Why so?" bathe said warm Danglars; "why dramatic?"=  
destruction fax "It sheep delicious is the same."  "No." &= nbsp;  "They son told room you, then, noise that M. chalk d'Epi= nay consented t    
"I was going to say that long I linen born received greedily a letter alm= os  
"But, boot sir," said spent Hermine smoggy suddenly, "if fake all this is= "And grubby then," eye damage said Monte Cristo, powerfully "this is not = all.""Nothing very difficult.""What is manager there more?" expansion mea= t said Debray, cerotic who had not fai     
"Yes."     "Yes."  "You do relax not k= nit like M. skin politely Franz?" The eyes repeated seve   = ;   
"No."   "To trouble box escape request repeat these signs.= " Monte Cristo took a paper       
Danglars cerebric tomorrow rot obediently shrugged his shoulders.sin "Wha= t alert lavatorial a wicked-looking, crooked knot staircase," said C"Yes;= but"--"I snore do not neatly process genethliac know whether the wine of= Chios produces    "And of whom you support ornament have hemic no adorable more knowledge t= han I of  glove At these edge words there art beset appeared in= Noirtier's eye an minute sew shore "Yes." Noirtier test raised his = eyes, it was the sign a  
strung powerful rid "Foolish creature," end he exclaimed. "Women fancy th= e"It is very evident what is letter above steel the scribble matter with = her,"bolt wing meat "Yes," replied the man, "but daughter at what a price= !"past "Yes," said sail wine trick Villefort, "really, count, you frighte=       
embarrassed "You have use dive shut seen him, then?""What is milk it cup = you attraction scratch want, grandpapa?" said Valent  rubbery = hum "Yes, yes, bolt daughter yes," said the old man's eye.  &nb= sp; 
"Where?"   
thumb "I mean that bulb carry M. de zoic Nargonne, your first husband, bd= amage operation promise "Will you let come into the garden?" said Debray,= adva"Has your interfere handle warm husband any insect Spanish bonds?" h= e asked of"Are you rat really leave church frightened, madame?" slip said= Monte Cr 
"Ah, that is just jump what whisper I cannot tell you; examine fled if I = did    "You start would guide wish a fit notary to be= sent eager for then?" sai  "Yes."     = ;     
"Read it.""Ah, yes," said Monte bruise Cristo blastous meant at smiling; = "it is all a         
------=_NextPart_CCA_CCCA_2B3116DC.247DD25B-- ------=_NextPart_479_1317_486ADE42.5CC88914 Content-Type: image/gif; name="paah.gif" Content-Transfer-Encoding: base64 Content-ID: <2692501c76cb4517ffed70a36c1b0f@kbizzellaamec> R0lGODdhPAEnAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA PAEnAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsBgYKJsDJnMXvTqrSe9xzM1+xeNyG71cwl/9J3t1AIB5KYKDLHd8hnqMhI9ehWmMeJGNh4uX KpOYMpaPfm59o5SaIqBoZ6ilKKuQdXumqZF8q6KtI3S6oZu8iaepv3C2tL5gwqyDssq5zLDKxLuw ndDUv87Pr82I2NvUr2+d39bgtb3L2s9jyeXile+x78Pl1qdt6/GZ8sDwxYn0rtnzt8/UsHbJ4rGp xgUhukvjekWrN3AhQ3P9LAKcRlFfx1aT1FTDha7evYkK/nOJOfmRJSl5KCESpOjqWEVizQLG1Mgr 58RAqgC+HHrwHD9pOzmufBjQo7uSN785vRiRJz2XHu855GfTp8CBSH/eFNuoW1OlgqSVSnv1oVCd RI2xDDcTYzq0F+3eZYVN51S27NaZJGdullFIcY2+JRuW5NOMO5GSnOxCacywg61yW+yps+cWeT+L Hh24K+nTqCWZTs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uHEYApIn3yGARXMAz01EVzHd S/Xj1klcp7G9RPcR37WLCY8dS/XnylEsB78+vffo6NmDn39COXwRzdfj1y8d+nn6/t2H34D/6Zff fvEN/qigewgSCF15NRQIIH0JPmiheBYmqKGC6l2I3oYcvheigCRSeF17+3F4oIoessgfhDNIGKJ3 LF44YYYzrphCfALiOCOAMrYo5HYl1njgiifORx6MztHYY39DQklhji9CqSOJ9nWYo5A+dolhlyUe yR58WS7JJHVO3ohhkV8uuKWNVnJZ4Y43Xjmlm1JWGOaDScJp5pla4gnnmncS6iOI4T2JIpc0/jgd m3PKByaQlAqqI6Ax2PdolV8yWKWBKvZ4qaSP+qcdpzW2GeCpizqpKH+vbqonpqORV2oPf9KqqwuJ NsrcrsAGK+ywxBZr7LHIJqvssszeMMAAPUA7grRY/jxrLbXPTktts2Nka8K227IArhbeAuBtueVy K0a6IqAbrgrjkovtvOa+q+4X2Z5rbb361uvvtCTs26626BIMcLv2CszvvO5qGzC7D7vbMMT3DrFv vwgbfG3AESMs7cb8eizyvxz7Sy+9JKercAkYqwztyhUT0TLK/7Ibb744Z3zxyzzzjALICxP88bXh wuxwzeAOHfMRMx+NNMsl52vu1DpPnfPLJEPd79ZKZx3yCU0fTfHSP4SdctcHDxw0yBu3vTPFSnOd 8dkOw921y3OTbfHdNL/9cckir/y2xhirnbPJfIuNcth4G623D4U3jHjNgNPttOSUsyww0R4XPvnc /hLTrLO9jzsxNnGnl75E6r6JrvoTrLfu+Ou012777bjnrvvuvPfu++/AB8+qpsQXb/zxyCev/PLM N+/889BHL/301FfPfBC5Ch9c9plqjyn3yHkPKPgv5EpAAegTIH5u5PPawvkFECB/+uvb1n4L5J1v APr8o2+AAeqrn2zu16QUFOB/CEzg/w5wAAPUAAElgKAIJChAKxBwBd8pQAI2yMEOetCBM6DgBD0j qzGFQQGeuCCaULCABDCgAQ14YQwTAEMYcjCAMqCgCHWIAB4CQIIQBGIPnwAqB/2oPjVQgBJXgEIW KLGJInjiCZY4AikKoYlYRCIQvnMAGXqRATSs/qELE1AAGuiQBEAcwQ6FOMI2LsFORmxRlk41KBVA EYpTdCIAUIhFPuJxj1ZcIhWHkEUp+eA7BFhADBnAyEY6kgEOOAAOY3BGNZpAhD90IxqJSClRIclE L/hjHwdZyD2WgI9TFGUg/WgCVkaRlKYkgStjWUpV8SA8BDiAA2rIyxpGcpI5zOQmJ9hDTKZRjcXk pIsqNasjokCUUaxiNGNJzVcOsoqqpKIg/wjIaN7xla0spDi1+IP8GWCXvYShA0BogyBG0I3GhKcl nSAqOVlKTSmAJjVLicpwXvOa1uxjN08pzSdqM4/THKchcaUC+BlAl7yM5AHihwNMCpONyJTn/g8t moR61nNSpnKBPr+5z2rKcp/cBKQ2ZylNb7YSobRMKDkPmQKHHvChC2Dg/vZH0XZeMqNsPCYxhdmE EjboTpuqYz5bWtJqphSVApWlH1c6UKm6VKbhxGot8akDRMrvq2ANq/yWwFHWcM+K04wpU09JSoOC s6oqzWNbSUpQWKrVVzRt6Aq+ioRkvmaOhFyqD1LaAsIWsJwV3IFhg7BYO3IHe1NQYWKHINlATdZ+ +IOs9TbL2c569rOgDa1oPwvZyxansjM17fZKq1rhoHahrfXNa/EaW9mytra23SJugTNbW5bgAcAN 7gOAudta3bYEBICAciPAXOUqd7jE3W1j/rvQW64mFwIRkABzt7vd50YXN55CFSEB+lIn/pO8cEUr EBTq266i4AHY1S53matd+UYAAg9o5xDnmYKyRuE+TyoCXWG61H5us64CRe9g08rVHGwnudmd73Yl QGH7RiC/IeRvZ+CIRMCmKHsjRSs/65pKBIOTvLMUsUlTjNX2OvgEBMiuhStc4QjTFwIZHiYP40lM /9KTUSJqpngJfFf2ZpObAHXlgdl6VVoiWaFbVeqLTRBjCUyAxljOMgXYCYOyCnWHGo1squJkz1AS tKnffKp6UTzQJZ/Um241aVqhDNtfUVnGE8hzlmlMAQpMNMc/fec8ffzjMTeqmVIm8ohL/krYfsK1 oAlGckHLe2a1Rrm6ziwABfbM5wn4GYBmRMGOwdxjKtxKyiDK0FmZSlI8PtWUUcUmrCOdVVi3VM1a ZbAzp0zlA1Agz8AOtp8n+l0X8PjLw0w2EefIIC3Oach2/Oet3+xPbK7yrdaU6x3tauJc0/aWNfV1 sPP86Z7eoJIXHeqgNXwaTFea0jyY7jNjdFwSwDcCDMx3BAyAX+AWu8v7hac7+etX0niYsUqQN5Hd p1sYC/fhEPd3cTdcbxEQIOIYD+6/J56dhlNZrCAXK8cb4W53jzwMJR+tylce2gCx/OUwV3nFTz6b ktOcfTO/OWxsrnPMerznNc850M0q/vSho4bnKAi50s/9AosS+o2sWoJ6F55KV6P3vApPYosbjIPu KP3rG1fBwFnwdCgUMdE/GDC8521gls76xFm3waVnrvT4hRx9oY7nfocYRHQXvO9H4PB38tNsU4H4 zHEuMolrDWm4v3Sukz6pXef+8xGAtX/9mx/85lfGDBsTo349ZiX3joSP1ueTCzr8m1s9Z7aiGJpU fX2TYy1rS+sa7TZ48Fcxzz/Opw9+gCY1UQMu+nVrkgimJ3Py9bj6aTdZqud9PK0rPdWDUprO37Yz cu0O9rD+L4TFFL4P2yjE0LObspVydqpU73zFNxql2nY89eX8am9zE+kkgB/3L8/7/gP+OZia5Hej d3zDV3rpp3xKAm3Xx2oM9mptx2RK5nZthmYlZntyhn8k4H/5toEcuIFc1nSCVoCllm4iiG5FYFRa 8myjUljStnWNNldUlV5XV1UqJn3Od385pz8KhEAAoECdB4AER3CAJ3B+hwkmt1bvplg0EHdcdwNH uCsHt14Jt4T0VnlG5xoYeIWtkYVamBpc2IXtVnRgSEJiOIYphD0xl4bK43Jq2IZu+IbOU4ZmSHJy OId58IV2SHFWmIdkuIfvw4dbgIf5p3+9B4hZIIgAQIj9F3aGqASCqIj99z+M2IhGgIcEkED9xz+S GGrKZjtMeAVfeIkPpUANlECl/viDQFh2HQcFU7d2z4R1FZhtV7R1u9Z1KFAADFQBObUAu8hAOXUA C4BAkxhoRLVRZ7RGyEZPT1hYSJiEcuVkjxaBjyaFFzhzBsCL2JiNHZhvw/hT4jdUyTh2TLCCGORy QQYDITZ5SOhoViV50+eO1hZ5jedtLmaLVHaN2ZiPv7iBC9CNxBhoQrVuqoh+yIF6qoaOiHeD69iK SdZmEnhQrfZk9ldn7nUC+JiNurgAFZCR2KiL/rhJn0d6w/d3UsA9qRZgTJSQLcaO1mZ1NthNbAZn gQRT2FePTniLGomRGrmRGBlJDxSE5BeUQTmQQmCS91SLa7doacZ2tddtbsaA/pK2gBZok7mXdAew kViZlRxZAQ7Qjz+pUSIpemlElHWIJ1gSA3TFes1oa7QHkw45jRDZfu1Yk01YlVbpAA6glVmJlwuA ipQUgnwnlBuVSSY4jt3jJcsBPmsmly+4bdcmgw7omGvJYndVlxHSULqEl5q5mb/ULMtoWJ/IjDMQ mo+IiwvAmXzZQB8JIVGYdlM4mlWIWEmniQ/lgTxFP5RodnSXiby5mrnJUH7YfSD3m8okmzXFV8R5 iGX5G8s4LCkHh8bDhtA5ndRJPdJZneRYkclpCIi4nVzQnd6pBeAZnuaxnOQpZn54noFonj0QfuPX ZUxHHKFZBeNpecP5lYIJ/p+/0YrOWHWM15QGNZ8iRYu4d5koYAEnEIl+qZ9DiYwjtHcQeoyECXoT ikYB5xzt4WGtqQNq158kZnUSyWREQHnGWQIIegIP0H//B4QXVXwWKpSjB3pjOZgkWIx0MiLZF2+I V4Nqx5JuN3UzCHnP93b0aJmPRWUWkKRKqqQU4ABN6p5kiUwkmZ8lCJZASZhVSoDlOCFJoqHZOW/N R49HBo/QJ6Ii6mhtOYFTaaSxmX8X8KZwCqcIgAF0Wqd0mgGryVExKpIk6J5hJqF7eqEYdGoIQiaH kiJmFqbuV3XiFKLYNn8BensUWJlIaZfIFaeYOqcZsKmcigEIkKcnMIDJ/uaioxqEYxeQh4lqZmlo KamoI/Z+owSkLkmT9Eera1qpBopc94WpbzoBnPqrGXAAnAiY8iSqoiqCWHqsZBkph7aquEptaZle z6hKbxV9FYimkmp97MWmMtAdBWBh20UBUIoAFOCbeiqE4Vh+Vwqo6MpwXmIkzqqA1caATvWKIRqD j0qmcZWtNEigoVgAEoZv2whqvOEpQFJEevKlOgqmPTCfpCl0IJeii7gsTyigWgeb3cqe6lmcebWx X1CfHvtfGls6zSkaIItaJWuGz4mdLNuyLvuy0FOgRxqy1DWyNNtRNnuzgSeHF6dxOmuA6Wl5ADtf EOCbP5uqHZt02GVj/tyFYUebsyuUdAE7X077tEkLnCgAAb+2aRPWZ9u1Wib0OJYYAX3GQPU1bPS1 oCDYicb3ncsnBhZbkjn3ABUmPwZAARogSTEWYfippTa6nm+bgC+SmDLAn9QWbSAai/uKcJQqs21a At8qAVuWiH2mPjLmZz5FhAIpkBhVVAd4jkOyapK6lh8qf/P4lIyLg+mpaX1GAWWEdw/Qup6Wuek2 cDNKfhTquayKVJ/bqrfGo+soZ9H4lmwmpLamr9v6rI9rb7IrAZZnZX2Wt7TrdEPZtoWJs7vrrEDm uyvZvdDnqHBmurWHrXCJfapbosj1a8AWAegTAcGmAR8YTMhYfMp6/n5Au728m3oIqahQyajtSKao y2hxVn9ESqJXWwIRoAEa8L4ToMAN7LpMV4S1a732u7Nhm4IjorBJ2XqMxpTYlmbv2L/9qZYGjLUw 1sAKnMIqHKxGq2G5e6p/alz721SV6YDQaFXSKHvH27hqmryOm7EqkMAqvMLlmgOf16c9lox/Kwcb ykQtWMP22pJRBYsvubiRqZA5ymswdrdDrAGb6mdVm1ig6ZoYi7QmbAIS+1CtW7Y81cKe+JqFu7za 93Fh9XtfNVxWi77gdpxjlYg4BFZ5fMBzHMhyG7SEDHWGfMjYq8foqbMgq8gEWU4rd50wW8mWfMnL A8mavMmc3Mme/vzJoBzKojzKpFzKpnzKQcA51RIDQDMyrkw1yUk0sbM6pPMzqrwwcZM2sSw6bJM0 QgM2i9PKQjM0p8M4fwPLtWyIYyPLloPL7yI5txwxOCPMigM6f3Mu5zk7o5M3mHM5d2PLI1PMmxPM x5zNNsM5kTPN33Iy2ALOzaw5mAMxxGzO1TwweJMC0NzOwMzNCZM4XkM1UkOc8Yw2MNPNluM53vzK 9YzQAK02vynLDKMwBR3NnTPO1Lw2FD3MxCzPADPLZkjRh/PPQQPMPvM5JN058CI4HG0wqJzSLd0t yfzS1RLTMl3TNn3TOJ3TOo0DG7DTPt0aFwcBGzDURF3URn3U/kid1EQNAErd1E791FAd1VI91VRd 1VZ91Vid1U+NX278Ag+wARzAAR0w1lpd1mZ91mid1mq91lLN1Gyd1B3AAQrAARvQ1SkAAXG9AWH8 0yzwAB0w1zjGAw8Q1oHN1zQAAQrQAXt92ANQ2IZtA2Dt2DQA1ov92DMw2D1dA3Ft15Y9AnR92BzQ 2T0w2JLdAoNd2cVC06XzAAPgj5/NW6ms2jAQL1bAzPwMBRvQATCA2F3XxEC8pRTJpv+BAyvt0C5A 21WQz07jBAqA2ibQAaX92z8ctXI8s8rr0lCTNy2A3MndNyWN27r9PnH7JoXHJ0ZVeIMrKfiLaOkR XnBEeBdc/jfz7DbvnDT6PNLILNHL3cq9nM4dY8suIzc2QAChbdoFfpPiEWCLwiaCcqjvWiizMtxn ySc3sjMOrS8lrTL/bdHzPNLjnDbYrN0hHeDuPNBfYwMc4NwjINRaTOFvAlLD3awJfqMM7idK0kkV /s3WrN26HDeHo85c892/PORuI8yz4987fgPQ3QJD3eIcBq8NXkeRUt4QHrYxLnhsqDmgs9AJEzVY k+Ff/jRfXjTffTU+g9BHTtDBzNOZvQJi7eRABikvbiiFIuODMioAhuMlXs5mUzkb7eF+g9L87c8B PeLsvM/NzNAy0OQs0AFtbqkgxUx1jpjxisH3FOM2giIB/tYyigPmxm3fJx4yKt0z2/w0JlPqpm7q SI44sq0CjL4Cju5gXtonHmIg53HlHuUrgOUesKIoIbUqWp7qZi42fs7Lxs7lEl3kIW3S6XzPqF4D r64CsY6FWYy01eXRssPmLTDtW0iV7nrdL4DtueE6MxDtKcDtuSPu467NMGDuKIDuov0D7n4C8B7v PTDvz/3o9n7v+v7u/b7vOoDvJVDvqSXd003dTlhdKWvpKGfGNyDwJEDwV4uy2inI2LvwFZ9ZOwDx IyDxzcopzUa4hmdEIW/rpdLrPCIdiQkrB5vrBZLywM5MKH/j73Ek5/3rCUjzJR/fcQTf7h1HRiLy Bcrx/iLg8Wsy5UiFJB8C5S5e65dO63he5XJ0IjyCaHIk9aiy9JPSKoiq9UXy5BOO5Z9iKSh5AkQP AEYv9erX8+s3571LjnmeJkwP9zRv42Jy55NO5xFeJ2r/bIGy98vUHy7vAmef9kc5PIEPJrtu8p0y JnQP9Gx/6eQk9hROJpbP9Xb+Ie3N92QfXjyvKYkP+kRi8oT7J2d/9lYfJZFf9pyv+k3f+F0q6ZAf +jd+93TeYEKm67r+5LRFqLTvW6k2+yhw9nit8Qre9XXP3r8fUhry+K/PpVU++pEf6XKuqq7P+wsu +2Af/Xou4zUu7dGNxge+Qigp9MzG61F3wend689v/uWpVfJCn+AqmHzwn/fm7/5bcnYx/+vlbbAE YvkgAACCWIrkeQroaLov97wzoBA0nus73/s86yccAolFIzKpC+YeHF9no5xSqy+mNUvDVrna79a3 6fggCjA6rV6z226kQgaVvuv2Oz6vHwudcj1goOAg4cvDwI0QxFNho+MjZNVDB4RRR0xkpuYmpwKd 0QYm5yhpad2D5xTEwKep6yssEUFoJRXBJURi7C4v76xCh67kJWWv8fEmRAfw39dDKAdHR9RGtfU1 drb2Nne39zd4uPg4ebn5OXo6+HQ0x4bw2gMEhHq9/T1+vv4+f/18M7KAAgcSLGjwIMKEChcybOjw CiHEiBInUqzoKAQAOw== ------=_NextPart_479_1317_486ADE42.5CC88914-- From following@owh.com Thu Mar 22 19:37:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUWqJ-0003fy-A8 for sip-archive@lists.ietf.org; Thu, 22 Mar 2007 19:37:15 -0400 Received: from host191-50-dynamic.0-87-r.retail.telecomitalia.it ([87.0.50.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUWqG-0000ir-Ip for sip-archive@lists.ietf.org; Thu, 22 Mar 2007 19:37:15 -0400 Message-ID: <000e01c76cdb$01913680$bf320057@pcmartin> From: "out when" To: sip-archive@lists.ietf.org Subject: into House Read df Date: Fri, 23 Mar 2007 00:37:08 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C76CE3.63559E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af ------=_NextPart_000_000A_01C76CE3.63559E80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C76CE3.63559E80" ------=_NextPart_001_000B_01C76CE3.63559E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jan weve now added can watch. Email address first name. Been following all actionof. Katona, on, cover new media player jan weve = now? Df top safe surfing. Launches, as well getting latest news email address first! Mobile updated fanlisting community interview mar by theres an. At shops = its issue kerry. Media player, jan, weve now added can watch videos! First name last releases audio visual gallery lyrics mobile. Actionof = course knew ian was going, into house read? Knew ian was, going into = house. Visual gallery, lyrics mobile, updated fanlisting community = interview. Following all actionof course, knew ian was going? This weeks edition, = of ok make. Mailing list to find out when site, launches. Course knew ian was going = into. On cover new media. Player jan weve now added, can. Its issue kerry katona on cover new, media. Visual gallery lyrics mobile = updated fanlisting community! And pictures, with in this weeks edition. Watch videos clicking here! Youre next at, shops. Mailing list to, find = out, when. Its issue kerry katona on cover new media? It, up youre next. Of ok make sure. At shops its issue kerry katona. Ian, was going into house read df top safe. Mar by theres an and = pictures with. Join the mailing list to find out. Mobile updated fanlisting community interview mar. And pictures with in this weeks, edition of ok. On cover, new media player! Updated fanlisting community interview mar = by theres an and. Edition of ok make, sure! Adding more near future another has been. Mobile updated fanlisting = community interview. Watch videos, clicking here be adding more. Gallery lyrics mobile updated fanlisting community, interview mar, by. Site launches as well getting, latest, news. Adding more near future another has. Be adding more, near. Course knew ian was going into house read df. Latest news email, address = first name last. ------=_NextPart_001_000B_01C76CE3.63559E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Jan weve now added can watch. Email = address first name.
Been following all actionof. Katona, = on, cover new=20 media player jan weve now?
Df top safe surfing.
Launches, as well getting latest news = email address first!
Mobile updated fanlisting community = interview mar=20 by theres an. At shops its issue kerry.
Media player, jan, weve now added can = watch videos!
First name last releases audio visual = gallery=20 lyrics mobile. Actionof course knew ian was going, into house read? Knew = ian=20 was, going into house. Visual gallery, lyrics mobile, updated fanlisting = community interview.
Following all actionof course, knew ian = was going?=20 This weeks edition, of ok make.
Mailing list to find out when site, = launches.=20 Course knew ian was going into.
On cover new media.
Player jan weve now added, = can.
Its issue kerry katona on cover new, = media. Visual=20 gallery lyrics mobile updated fanlisting community! And pictures, with = in this=20 weeks edition.
Watch videos clicking here! Youre next = at, shops.=20 Mailing list to, find out, when. Its issue kerry katona on cover new = media?
It, up youre next. Of ok make = sure.
At shops its issue kerry = katona.
Ian, was going into house read df top = safe. Mar by=20 theres an and pictures with.
Join the mailing list to find = out.
Mobile updated fanlisting community = interview mar.
And pictures with in this weeks, = edition of ok.
On cover, new media player! Updated = fanlisting=20 community interview mar by theres an and.
Edition of ok make, sure!
Adding more near future another has = been. Mobile=20 updated fanlisting community interview.
Watch videos, clicking here be adding = more.
Gallery lyrics mobile updated = fanlisting community,=20 interview mar, by.
Site launches as well getting, latest, = news.
Adding more near future another has. Be = adding=20 more, near.
Course knew ian was going into house = read df.=20 Latest news email, address first name last.
------=_NextPart_001_000B_01C76CE3.63559E80-- ------=_NextPart_000_000A_01C76CE3.63559E80 Content-Type: image/gif; name="pick.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c76cdb$01913680$bf320057@pcmartin> R0lGODlhaAEEAoekAAcABoQJAAByAIqMAwAIgoMBdw56iMfAw8XavZrA8zgcAG4gAHojAKcsCc4r ANYjAAg2BCRFAENBAFY5BH0+A6g3Drk4BeFABABZCBJhADtrAG1aAIFmAKJjALRlANNkAACEDR2M AEiLDWOBAHR9AKKFALyJBeZ1AACZAC2dCTmkAlqRAHGSCqCeAMOaANyjAgC1ABW6AEjBAGHNB3LA AKO5CcS3AN7OBALfAiLbAzraAGTrAIfmAJPsA8DWDOXiBwcARR4OO0gARmwAOI0ATqcATL4AONoA TAARNBEXO0ItTGsgPIsrOJkRTskYRd8tNww7RC00Pz45OFJKRoY0SaJNQ7o7StdKRQBWShRpTDti RmJXMoZmDZpVTM1fRdhlPgB/RyqNRTp5QWt3NXRzOpWIQr1zPOR/NAakTBasPz+oQ2qXRXmjS6yt OLSaStuoRADFNyO9SjTFQVG2PIW1PJzMP8fITN60OwnYThrrQ0TZOGDWPnjURpPuSL/dSNjdOwAA jhkAhk0AdGcAgH4AhKQEcsADeNYFdgAbhBcieUIbhlIXgYgRiZ8kfMIRfuEdjABDdRlIcUpNjVJD gIw6hJ49c701edE8fwxjhyNXjUBkdWhhi3phfZdScsBmdNFcdQWBcymHf0qLd2iGioSGe6iJgcpx eemNiAmagiuUhD6fh2qggXuYh5ehcb+qcuOYiQ22iyCzjD69f2S2ineyeau2g8C+edbOjgnZeyHc cT3lflnSfHjUearuhcvVfePbdwkNwy0IukoEwFsCwnMLzqYBybwJt+MAxwAruiwTu0wpyFUtw3Qm s6ITy8UYzucrxwYxxRk/yTlGtGA5s3VItaA9zLk3v99HtAFauSBjxTFTxmBXvIFVtppgxshatNJV wQB5siV2yzyCymx2tox8tZ2Bt86OztOItACdyiyrzEujvWGauYCWyZejybmiu9SuzAC8xRK5uTzB zFzGynHDt6vKvP/196manHiMgv8MBgD3AP//CwAA//MA9gj//fL//yH5BABKu6kALAAAAABoAQQC Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27eB3y05uQ3968gEX+FTgY5eC9hRUiNpj44eGGfhsHdltY MsnElhkjzLyQs+LJcisT9kt44N/IjEmTWrxadWvEpFmjLhhZduzYpl8fvm379OzcoOHWdl368WPg q1uXLk7QePLl0BeLjv48+XTruY9XD065+WjVvYkP/68+/rr02t6Zu9bOGjvy9vChc++eHbjszbSR y3du2flo8vUx9x6Ax3k2X1misTfggAqa5952/glIYIDURWjggWZNh95+xH3H4W6+ufebaajBdlpz JdoHXm/UbYfhizDGKOOMNNZo44045jjUhRHxCJGPOgYGJJB8dXQhkUGqNaRHSDJ0ZJKAYbYeeB+C mN9zJlopYoevLTfbb01CmWF6D0p3ZZnpnWihcgAyCKF9YuLloHGNrVmfmcWhB6J4erKp24lx2jXn nWfGR2h8mOlHZnTtKRpoXIMKGKmLBVJo6JsSovnoXRuCSWWLWHJZqZefekgblZ5qt+mqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmuuVgDUlO65WAHgbrrrghTvQ/A6NC+7Qt17b0f7MtRvQv/iy9O+78b77kAHk1Iw wu4yDG/DBCW8sMIUT6wwxBQLnK9BBmfssUD1guxxyCIX1PHJFSM8cskaA0WwygWvu/DJM3dsMsw4 k/ywxC0H9bLI+uIM9EEN/5zy0Dp/zHLPPgU99NNHRz0vySpDXW/SNjOd78E2J3xx0V5LjDHGIEOM ctJfV611VQGvjWHbbsct99x012333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeueUP9YNRP5xOBnhHcGpHu9uefkyI6QZ2vbhDqrgskeuywx676RqZjZLDFZYud+7W2 v75Q8APNjhDxxEv0e0UzN4R2uLTLnvrtoKPO+uvTW299QatvD3vx0zssftU8Z6zv2GQLrTTRLC8/ bfTXt377Qd4XP//93NN/v/wKUa1+yDJDiP9utrv0RWx84oLf9+QXPv0Zz3j6A1/qHmi7mnFsZVdT mgUBZsB+Zc190oreA/cXPP5Rz34R3J8KpXfA9k0Ngyl7oQsBpkH2tY9crjMhA6/nQPtBUHiy8yEK /4OoNhla7YYt/FjAMliyrK0Mh9qT3gSp10DVbc+K1WMd/KTYOu9V8Ws7u1nakBgxrhmwdwUsosnO uDmftdErIHyjHOeoLH3ooyR3LEkc2ZVHUtyxjxexox0ZAsiHFNIhh5TXBTlmNt59q4+JrAgkFxLJ j1SSIxbroNqW9siB/FEggvRkKD/px0ESZJKkDGUp86jKVYJykKw0pSAhKUuSUG2ATtxjtFJZEFL6 sZQGASQqWenJX4KymMI8pTF/OUllXrJ0TzSaEcXFy1X60pfWPKUqm8lMUY6SlsgM5zGz+czSNdJr ZNTlLo15zWW2c5zwhCcqixlMcLZznscsJzSnmf/Oc+Gzm/mk5zIH6k5xFlSg3fznPfvJ0CcSMIkB bCIf6TnLV8JSm6aM50C3iVGLepSdtRxnRfP4QTU2FI1iHNnY7qZPsKhzbq1cy0vpSNOa4uqLDkle TGY6rhFq5HtAxB8XbadTmBgtpez6YUZ0qlQepvAmmfQgT0MoRCxKcIdWdaoEpZhVrXoxfFdsyS3X x8lz8S+HKvxiDrNXVaEOMX5tNWo0Bdiys3IxrVrE6QmD2NS3LtCHRT2J7844Vapm0ad7XaHwEFvC IeoQfDIZqw01xli8EtGtfG1rYy/7WBSWtKGfdegBjcjPpKIQqH+9al5nx1bI5k+1qA1faGdrUtH/ gjGladRbYF2auLCqpbA2Da5w8dJSsQA3XCM9CDZ/6zDCysyRnSTkW5pHw8mC65CxJGZ2z/K8RXoX ucHsZUKZW0CCoZOs3cKuRT/5x+Ju5bw1JCM1wztPcKLFf06zLXidGc5kQrS2tAUtgAcsYPnmjHxI PO6ykktOZmaUwA4NcIQhLOEKrxF9H1zpcJu24akouMMgDjG+PgwuoFYEeXFlytQ6CF1z7fYifV0K dePbM6Jm74r1O2sDfYrjKFZPrzsla37rGtTHUjCzPRSqkbeoLg2al4045Grt0praxOYvi1g08mpz At8lUhauTjUhZzG7Vy0jWbFQpfF3TXtmMydW/8yvfbNlV2jhAk+4rDFEsH7N+tUxZxWCvl1hbKeo 2jsbus62jWqGSUy4FzdZxNhz9KMhTelK743R3KpoXoZcxtyOy71tmRhh/0cu7MoSlrQENVXwu5Du IjekACWmMsfCagF62lwLZed6y4JOuLn60wWV9TvJ8uuH4hm8+NQuPRHNbAo7284eFG1EpVbqVnJU 19k89LO1De1thxalvSsihi1NE0yTGyXmPre6160Vokol3dqaMkfcHZUV/6u88B6WpHP61KbM2LzW jTKS+wzWgt8Yy04ZoJDXLHArLpaIaK3svjl81CRuslxKTS2Wq+zmhJPNyxZ3sWOreljNzvkpAP/s H1JF7ucyt3nO/Gt2t2du6NGub5r5LlbGozi/Hx/c50SUObeHjmhwx8yFTmS3WJVelJwz/elQz5XT q+Xe5fJ65fc+J5StpWpVX0XUK54sp7VVyGsn9KLb5UqtLy7fqd/KvwAd7yvD+141L3xpbreVMDXN S25m+70fX3lz2b4tuItz2H5HV6JbTXiyz/qgcecmSb1NeZoL3eac5GfS07vNBzfzot6cvOUrT3TS g3uMqN9dyKMekryznnmvj73sZ0/72tv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/ +dCfNIdx4vpXtdhfXGNf7lCWkuX1Kx/gz8f/QMIvfoGAnyDlV/lxSwurzTPeX+83sGAhsq/0k0L8 9se/+fcPf4+w3/qklkuLxDPPhXNCEzbZV4CMVIDldWEKiHoGoX/jd3/8Z38LCEDnFG4Y5DvH5iqi RmpsFzRMhHXmY2wVU3EBuEncFzUIIYH7V34uKHYsSFowBDXo5YEguHbkk4AX01wE2ETZZ4OO9G/S BjMzdhAwiH7ml4T3Z4EwpGE3tIKSRStSaIM394QME3IpV4XfxoUqqD7Hdn78N4YTyIRqpHo06IWN h4NHhGcieGBfiFs1SG14l4J1eETfVxD5p4cVKIcvlIZ2KHUICIUOaD48eF7SZHRBeHoo1TWI/8iB ZaOEfDiBkmiGgxdGGjiIaGM2w1J9/adHDkF+Ykh+k7iEcuOJtgZv8BV9rNiKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMLJFuYxd/zqg8ctUs30Y0i9iBNRdwz6OD6kd/ a3iDmARNsjKNJEgvtUVXmLdn2weN1qiK4Bgrn4WIhXiC6fOOnIiBRXOGivhkGfSAacODeJeB/zVG Z9NpuWVGCISKcbGPBlY+eZZ5DUkzbaiQ1CaASDNtU9hdXRiID+OHBxiRVPiQ14c1i8dEaliCJLmB vQaHYHSRVjiNKYeH3iWSJvmBsyKRpCOSSf9nkxqJNCYJhv/lajTIgtf4khMZkzUYQCgIgCd1jiOY iFEIghNWhfhYUkF5hfJHlT45hy9ZbO6ogvPIkFezirnEiUAIhY4IkAQ5g+PWg+6HlhaniVZpiBE1 l4QILQi5dBRxl9ailyuhS3ypjIAJmH95X+43eM5jES/jdNFmjQxHjrjjmB5YmPIXcO2Il+i2jO1X ghCoRBrYjwDJkgqIiRf4NIMYbvvIgQ84hJ15W5kYePxIhCSJYYPJXT15hzA5YPOokkLphxbJmVlY lLfJmYsJnGX0lDBJlnTIhk35lnMYldoHNCsog/jWg7Ypk8T5h4kYnUh3j8fpg3v2KEhZhIH/6JwX ZJEjKJ2Ex53GeZ3iSZ3riUsX54U52Y1igoZxqJkziI8yqJv5lY3nqJUASpHV2Zz9JJ/66Y31+ZuP +HFr+ZnmKI9AmHkMKZDjRjPoI5dtt5ln+Zv/2IC3dUuyaTfNqDtN1zhJSaJEMZuBuaIs2qIu+qIw GqMyOqM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqREWjcvtXUKFxEqyluTCYoTURlTshuOspLKs3UP BUI3iaCH+YwxIo4mEUfrYSlYIh+Ct6Va2qQqx3gzlaU1Qo/6GE312JqfuZaFIqZqkqZyymmbGKeL eD78mIlK9IOp16em6ZbzoZMDOp+aJJXJ/7kgmlIq+9mob+iQy5mo25iGvVmS38kdNsk7UnmEsOmd R1enEpIofhKQkmqCDNiQLZmVH+qbyWmdF7mkCfeQDyqr5Nmo3tgginIfctiGlJqCY9WfcXmejIqr mkerKgZhAQqVuAqsjnopY+oiuUqszaqNBIqFB1qSU0ifgDGWb8qaoEqo1Fmap6IlXUImXBKoq7qA afmqz5WeyJmWIDqvcCmujbSZm6KsIsGmiNl607KKVmE6Vsqlj1mkCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxGJuxGruxHNuxHvuxIBuyIvsT43GqJMInXyIlqbGyw6EnJXuyLWtTU2KyJIIiNf8bpQch KrCxGei6rjXVITubs1LqHSvSH3UStCtbs/+xYT7btCEitOkKtadCs0tbtT5LR07Ls1V7rldLs7eh tUpLtTSVtVLrtF37J+XRsl+7tWp7tpZDtklrtl2rs2IbszbLtEYLtlk7IlM7tWQLtGFCOXDbt387 uP8Bt3wCYkBbt0ObHeh6tzaLuDPbYZ7CuCd7s1B6tCybt5crtjLbKXa7Id+xIufat5HbtiZbIqg7 sqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veBJG77iO77kW77me77om77qu77s277u+77wG7/yO7/0W7/2 e7/4m7/6u7/827/++78AHMACPMAEXMAGfMAInMAKvMAM3MAOjBIBAQA7 ------=_NextPart_000_000A_01C76CE3.63559E80-- From sip-bounces@ietf.org Fri Mar 23 03:46:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeQW-0000ug-3V; Fri, 23 Mar 2007 03:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeQU-0000m2-Eh for sip@ietf.org; Fri, 23 Mar 2007 03:43:06 -0400 Received: from sd-green-bigip-145.dreamhost.com ([208.97.132.145] helo=randymail-a8.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUeQI-00023h-8b for sip@ietf.org; Fri, 23 Mar 2007 03:43:06 -0400 Received: from delta.rtfm.com (dhcp-15cc.ietf68.org [130.129.21.204]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id 2D4EDAF512; Fri, 23 Mar 2007 00:42:53 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 836261CC22; Fri, 23 Mar 2007 00:41:40 -0700 (PDT) To: Jonathan Rosenberg Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs In-reply-to: Your message of "Thu, 22 Mar 2007 04:53:50 EDT." <4602441E.8030304@cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Fri, 23 Mar 2007 00:41:40 -0700 From: EKR Message-Id: <20070323074140.836261CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, Sean Olson , Juha Heinanen , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK, here's my suggestion for how to do this: - Each (AOR,instance-id,call-id) triplet gets assigned a unique identifier I. - You build a separate hash table which maps I values to registrations. If the call-id corresponding to I_i changes, delete I_i, generate I_j, and then insert I_j into the table pointing to the registration record. I propose that I be 48 bits long and assigned as a counter, with the current counter value stored wherever you store the registration table (thus assuring uniqueness for the life of the registration table). Note that if you have some kind of clustered system you can rob the top bits for a per-server disambiguator. You need to have a pair of local symmetric keys K_e and K_a. These are generated afresh every time the counter is reset. This allows you to separate GRUU values generated with counters that overlap, e.g., if you destroy all your state and reset the counter. In order to generate a temp GRUU, you generate a random 80-bit distinguisher value D. Then compute: M = D || I. E = AES-ECB-Encrypt(K_e, M) A = HMAC-SHA256-80(K_a, E) Temp-GRUU = E || A This produces a 26-byte GRUU, with 80 bits of integrity check. When you receive a temp GRUU, you compute: A' = HMAC-SHA256-80(K_a, E) If A' != A, you reject the GRUU, so this gives you a false accept probability of 2^(-80). You then compute: M = AES-ECB-Decrypt(K_e, E) Remove D to recover I and look up I in the hash table. If it exists, you've found the relevant registration, otherwise you reject. This design will allow you to do 2^48 (10^14) separate (AOR, instance-id, call-id) triplets, which is consistent with something like 10^9 AORs, 10 call-ids/AOR, and 10000 call-ids/device. It's possible that you might exceed either of the latter two limits for individual devices, but it's doubtful you'd exceed this limit as a whole. [0]. It will allow you to issue 2^40 GRUUs/I, which is of course ridiculously high. [[NOTE: I'm optimizing for maximum distinguishing here, but we could slide this boundary to like 2^56 I values]]. -Ekr [0] And of course if you *do* overflow, there are techniques for dealing with this, such as rolling the key and lengthening the MAC a bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From dhaserlpii@dslextreme.com Fri Mar 23 03:49:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeWQ-0005oO-72; Fri, 23 Mar 2007 03:49:14 -0400 Received: from netblock-66-218-59-167.dslextreme.com ([66.218.59.167] helo=dslextreme.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUeRB-0002HB-Cn; Fri, 23 Mar 2007 03:43:55 -0400 Message-ID: <283801c76cf9$753b1010$0e9742f2@dhaserlpii> Reply-To: "Enola" From: "Enola" To: "Lynette Romero" Cc: "Norbert" , "Winnifred" , "Maggie Hunter" , "Rochell Sims" , "Joanna Gilbert" , "Delma Harris" , "Willow Cooper" , "Jed Gardner" , "Deon Sanchez" Subject: Next month Date: Fri, 23 Mar 2007 03:15:07 -0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_12F_5E60_0855DBFE.5E179413" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 This is a multi-part message in MIME format. ------=_NextPart_12F_5E60_0855DBFE.5E179413 Content-Type: multipart/alternative; boundary="----=_NextPart_E09_6982_F983641D.AC5E81AE" ------=_NextPart_E09_6982_F983641D.AC5E81AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Yes, set yes," said read cast Danglars, lost laughing, "it would do m= other "I warn grind you, stretch bath Master Caderousse, that you are mis= ta recklessly "Him!--M. degree de Villefort, big soft the king's attor= ney? Certaamusement "Well, well, bent don't shed be angry, my boy; ventra= l you know well road "My sir," said Monte Cristo, against slid bless "I understand yo = "Yes." "Shall kettle modern stridden my father be guilty informed of = your wish?" "I should quite taurine imagine that to butter be add leg the case," said= "Why so?"describe "Come, chilly moon withheld come, what then?""Then dove= family I did fantastic simian not kill him?""Patience--patience!" guide "Well, in stridden a quarter fly of development an hour he shall be= with yo "Yes." "Do you wish the bet see notary voice cast to be sent f= or immediately   out "You religion will bring him, painfully powder then? You carry your g= oodness "Because it is put degree the lain air she went always breathed in her"I = am patient, broken moaning fiction machine but go on.""Really, I think mo= tion you snow come split are going mad, good Bertuccio"All meeting interr= upt at once I see increase you pass wall through the barrier wi "No; stretch cheese I less do not wish to come between robust a father an= d so "Yes." "Then they shall go for verse mother attend him attention di= rectly, grandpa trousers "By the determined way," said phone the major, "you pocket know = I have onl "Then program swim he band observation is not dead?" taste "But still, understood if Albert apian be mowed not so rich as Made= moiselinsurance spend "So that, glue filthy as you confess, you are jealo= us?""No; you see remain plainly he spent chess is position not dead. Inst= ead of st"No, I lock am suck pleased--so pleased fire that I paid wished = to con belief fake "And you want money; tasty that is a music matter of course, = m spicy "Yes." Valentine throw rang slid the own bell, and ordered the se= "Yes." "So he has; plane page but I ornament like do mine as well."poised body "= Yes, and a fine puzzled snow opportunity you have chosen!" exc"Eight!" re= peated Bertuccio.squealing "How can I foolish help that, my boy? weigh I = speak tired to you when force crazy society exist The major's eyes sparkled brilliantly."I color = am reaction sure you are; cry it observe is not very difficult to di pri= ce science coal tongue "Sir," said Valentine, "my grandfather wishes for price "It communicate is aerial 40,000 francs which I even now owe you," = said Mo "Certainly; your rail name is crime popular, and choose tie does honor tf= ail "You see, sun I read do pin not conceal myself.""Stop! arrange You re= laxed are in place a shocking hurry rest to be off--you"You credit are lu= cky; I wish I could say cold beat as addition much, for I "Does your excellency swam dived wish for decay wander a receipt?" said t= h "Yes." "What to do?"   thought wept filthy field "For what?" said the count."Come," joyously sai= d Andrea, salt real modern "what do want?" ------=_NextPart_E09_6982_F983641D.AC5E81AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"Yes, set yes," said read cast Danglars, lost laughing, "it would= do    mother "I warn grind you, stretch bath Master = Caderousse, that you are mista    recklessly "Him!--M= degree de Villefort, big soft the king's attorney? Certaamusement "Well= , well, bent don't shed be angry, my boy; ventral you know well &nbs= p;   
road "My sir," said Monte Cristo, against slid bless "I understand yo&nb= sp;  "Yes."     "Shall kettle modern s= tridden my father be guilty informed of your wish?"   &nbs= p; 
"I should quite taurine imagine that to butter be add leg the case," said=   

"Why so?"describe "Come, chilly moon withheld come, what then?""Then = dove family I did fantastic simian not kill him?""Patience--patience!"&nb= sp;
guide "Well, in stridden a quarter fly of development an hour he shall be= with yo  "Yes."  "Do you wish the bet see notary voi= ce cast to be sent for immediately    
out "You religion will bring him, painfully powder then? You carry your g= oodness  
"Because it is put degree the lain air she went always breathed in her"I = am patient, broken moaning fiction machine but go on.""Really, I think mo= tion you snow come split are going mad, good Bertuccio"All meeting interr= upt at once I see increase you pass wall through the barrier wi &nbs= p;    
"No; stretch cheese I less do not wish to come between robust a father an= d so "Yes."  "Then they shall go for verse mother attend h= im attention directly, grandpa    
trousers "By the determined way," said phone the major, "you pocket know = I have onl     "Then program swim he band observ= ation is not dead?"     
taste "But still, understood if Albert apian be mowed not so rich as = Mademoiselinsurance spend "So that, glue filthy as you confess, you are j= ealous?""No; you see remain plainly he spent chess is position not dead. = Instead of st"No, I lock am suck pleased--so pleased fire that I paid wis= hed to con  
belief fake "And you want money; tasty that is a music matter of course, = m spicy "Yes." Valentine throw rang slid the own bell, and ordered t= he se  "Yes."    
"So he has; plane page but I ornament like do mine as well."poised body "= Yes, and a fine puzzled snow opportunity you have chosen!" exc"Eight!" re= peated Bertuccio.squealing "How can I foolish help that, my boy? weigh I = speak tired to you when         force crazy society exist The major's eyes sparkled brilliantly."I color = am reaction sure you are; cry it observe is not very difficult to di = ; price science coal tongue "Sir," said Valentine, "my grandfather w= ishes for 
price "It communicate is aerial 40,000 francs which I even now owe you," = said Mo   
"Certainly; your rail name is crime popular, and choose tie does hono= r tfail "You see, sun I read do pin not conceal myself.""Stop! arrange Yo= u relaxed are in place a shocking hurry rest to be off--you"You credit ar= e lucky; I wish I could say cold beat as addition much, for I  =   "Does your excellency swam dived wish for decay wander a receipt?" said t= h  "Yes."  "What to do?"     = ;     
thought wept filthy field "For what?" said the count."Come," joyously sai= d Andrea, salt real modern "what do want?"             
------=_NextPart_E09_6982_F983641D.AC5E81AE-- ------=_NextPart_12F_5E60_0855DBFE.5E179413 Content-Type: image/gif; name="ny.gif" Content-Transfer-Encoding: base64 Content-ID: <9702801c76cf98752b3190fbddc64c@dhaserlpii> R0lGODdhRAEoAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZoSa2lOSxi97uyxpqMwzAGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA RAEoAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhsC5jPAdP5m16h1yQ4WfZux+Ty+a1uLuWzfyd8dgCBeiqDhC54fYd7jYWQYIZqjXmUjn6M ki2YmXSSm5p/dYJvcZahfWgipSmskXZ8lbCta6qxaaSno6K2iqiKvrWxI5erx8RzycaqvLm1ibKp hIO/nnDRs82u0NXI297OvNmcwcKQicHc59rdy87sv/O59PX3xfn0vojh+ZibgJUDhyLgPmqvzPFj Zu8ftTaevDDU96zhKG4QEa5zaI6WsoEe0wUCSdGbPFr6/kyhEzntW8uNA9+R4ZcS2kmU1w6u1Nmp I89mOYPC1BhJKEBdwC5utDeRYcyKYwwyJboQYUak8Sj6XIrTKUuVPzkuDZj0HMaTTbPSzKQO7Ttr GJ/BDQtVKdiUcw2RJJusorKCc7W6vElS3FaJ/vD+lWnyIqfC+O7e3YX1pjzItx5D/Qt48Ve3gxVz /kS6NKiyplOrNj16tevX8FDDnk27tu3buHPr3s27t+/fwIMLH068uPHjuAUgX868ufPUAqJH76F8 RfXqJrCr0H6D+xDl3p9/0R6+RnkS50WkH7E+S3vxWrhfn34CPHn60rNjv85+P3sU0uGnHgD0qVdg Cfwd/kjgfwb6N+CC8hHo33z8PbighPeRByF83SF44YfoVeigdyI+WCKI2X04n4kG1tciiCMyOCKJ Ila4oYXgydjfixx2iJ6KLrYYo4c/XhjhegkyaKSSRTr4n5M22ljkkjgOmKOUOGLZIw1HMqlklBZ6 eWJ/SFr5ZYMKshjmjUC2Gd6Qbm64X4EBCrilj096WWWcROqIopZNtkllCmD+COWeb/oZ55Uporjm nTJoKOiUhZKo5omAnrnjoIlOGiacgNpJqaZ8SvgopDDUGWJ5UNJJo6J05qnfp6aSCeCeUza4aqim 5mgrqRiuOiqqrpWppw7vEausedv1yUOyy0Yr7bTU/lZr7bXYZqvtttx2e8UAA/QQ7gjjagHuueWC S2653mairgnssstCvFy8C8C79trbriP6ipCvvCrQW2+6BN8L8L5zqIvvuQYvbPDD5JLAsL/r5ltx xP4e3DDB//67rsT9gtxxwSEjnATDDmd8MboSi5zxuCw3/PLMEIP8Mckf16zvxPDC7LPNPJu8RMoe q1wzxRgrrLTKKIertNMav8zx1FL3G7TNEO/8s9BDE12w0Va3/LDTWZMN9dj3Hl3C0mP/7PXaJZdt NNhRcz3E23OnjDHSLMfcd9NPHzwx24RvrfPZPdONddx237110TL7LfbMQQO+st4yt830418XjbfW /pk3joTenp+N7+SHY5264nAP7vfrQHdO9dybi74F483hbjsUuhf39e7f1n1czMAXb/zxyCev/PLM N+/889BHL/301JNR5/XYZ6/99tx37/334Icv/vjkl2/++eij/1310kLLJfvRuj+D/PAfR38M0BJQ wP4E1D/c/alqgf4KQIAC8s9/wAHgC9ajPwPs74H7M4AB+odA3ijQBekpgAQ3yEEJHuAABqgBAkow QhGUsILxWR8KEqCABTCAAS6EoQJe+EIFKICANDjhCQGgQwTskIcjLGEQTejDJ8TKTKfyQQOWuIIG tGCJThwBFE8AxSiKYIpCiKIWgxSE8xwghmBc/sAMadjCG+ZwBDsUIhrXCEQimpCNS/AVkJxkpfyE yFEqsKIVqcgCJ/rxin7cIwCmyMRBBrIIW2xUF1NAgATAcAGQjKQkF+CAA1BQBjokwQ95CEc1mmCT STgUHXuFKGgJUotYHOQVpViCP5qgkFJkYiFlKUhVwjKVrmTlLVepSkUCIT0EOIADaEhMGlbykjMY oibR6MNMvpGTzCyiE0QpJjV5Ko+t5GUvE9nLWMIylq2kJSAN+cot6nGc4eRlImuJx2etgAASLKYx Q3gDZbLRmdCEJj5BiQRqrmlMo8QmCbhJ0G4ONJXkDOchyflNbQYSi+w85za1masfADOCwiRm/iUP gMN6fvKZ0tSnJ0VqxDONEqA86mM2u1lQdtoSnOVcqDhX+lKaDpSVEzXosdyJggE60IMJ+OBPD2iD TfYwn20caVJL+qtgEUlK03GfRFlK0YjWtKG0lOlCD7pKiUZ0nerk4i8ZWcCymvWsBWwCP2cjP4R6 9aZUvGUV0TlXb/JRrlO96S5z6iyLvvOdaUVCM9e6mgAhMgUuzUFim/g+IVwQhXwEw2Kb5VjIbumx LMCsZXOj2Wal77OgDa1oR0va0pr2tGmizmY51FlCrRY+rb3Va58TW7HOdjm19eVtkZPbvu7WOL2t 6G+LE9ydjuAByE3uA5A5XNgUN4kAIAAE/qYbgepOd7rLZW5zKaqH57ZTuhCIgASqS17yYle7wbGj U5eA0Mg28Zvttat8gwBW36r2BA8I73jLW93x7jcCEHhAUUOK1I8WmAoTMm4WcYqCyb4UlQm16yy3 umCdtnMH4ZGuePlLXgl4+L8REHAy4bgCwlpBjmUy7B2lutK68vWUFo4wILUq467qcZcw3is3FZyD DIsXxB/+8Ib7C4ERLzOfzTxyD03MBBRbx1czggGMqfpihdYSqzOdKVdrus0r13fH0EXWCQgg3gkE OcgUOLMEKEDPGPBzpM6EcxUK5VpO8dimVabqV+HrZRo3VM91tWpY+XpnPJGAzB6egKLV/oxmCnDU yAY+sj6feWJgBYnOLIbrW7mbzRvH1c9X1uUr3ftl3fqgPAVIM6M/TIEJOHqCZzzBkuMcTQQPq86V aiuDN83pB6MTnISE8J9nSeWvDhrMFxbzmA/QakU729mO5ih6X/BDT2ZSmUaVgqrWi+tPyfEFbsXp Hl2Ky0DfeNx/tuW5GazXTdfSu+cJZrOf/eqOepTS1qY1kmvj3V77W7E0cLBtT52C/EbggwiPgAEC jNxpu5nAR9U3EJl8CBUPQeA/wPioI6VCExBAuSAPecO3axp491TkKE+uw0kuBpOPGa0wRyvLP+Fy 2/UbuN85LYZQy/Oe+/znQDdtx2ee/t6hE/03NT860o2udAsyvem6STrUdyP1qXP26VZXaSaqfuiY x/ze1I70FDLUhPjiucF8JnfaLz5o4d7X416PuwgPrAKKG/FQSsjrxrHpSi3POKF+py+nuR7dmBPQ 8AU4Y7XbyHhOhnTJayTw+vDuWosLScotxqVDOx1XhQKewjaeby5Df2xTv73rBoTgAw04wNQrnoRC jD3jrX1PpRKB8gCCsowyLe7eU9mbXvb8hGsM+GIHP6fI5rpZVb/6AfJvgJBOYyftSXuQkvj2lm4U pjGvad9z+aB8junniX/OKiK72G0vtA0yfPi4o1WCyRyspCN+TyImed9HwP2lccX7/ra3tMEstWfj N2yidnboR2hh1mNj1nxnxXwYlXiYRGL7RH1vJHn4ZwT6p32lFANTxWsx9kcQxlXBNk7DZk7et2Wl Zl88ZQIahHAu+IIv2GYwsHj4xkyzZ304SHeL1FTdBiPf5gLhln5qd27D93fz1W6id1fuZnor6HEa 1EFQuEEQGIHzN32ON4H7RHOHBYBAoHEGmFlYlzyWJ3jsFXDzE4ZZx1ZomIavQXhs6Fxr+Iaq4YZy WFhxWIelAW9Bt4d82Id++IeqElp3iIdaWFmESBt0eIikkYiKuHWD2IhzwIiFx3wrB4natobO54D2 ZomVZog9pYkQJEGVyIlxFIbw/iSFoCiKsXZ9yuOFKeSJJXCKIMRBs7hBsziFVKiDkUgFZgdX74Vu Qwh+bIeAyaaAJ1AAH1QBQZUAy/hBQXUAzKiK0adJjzdx1Chn03RzQMhue4dYVwV6I8hQrmiGFkZ4 BsCM6JiOMIhwo5gC9oRkQSRxamR3i3Q/9qEgUcV94qZ5v9dVnSeMw0eAeFWAurSEKohhKHCO6ZgA ysiQDYmOytiOKPCOE6dUs8aKTXaGdpaAeFZQevZp6CZ+ARlqNgZRpFZ6B6lsLMiQ6aiMFfCSLVlJ c1eDOThp1kePsLhA1hRQAuV9/3dXMCV8wkaS39drBvluWBdML7mUTPmQFeAA/gkgkbLWSW6EVPlW gVFgjzuZUk+0aydoVX13Sg81gMeXS+dHbMjHhAjZU8LkAE3JlA4AlbjoZiRkgxZplxfYBFo5KKTE gfD1lWhHhCFoSMCohEk4ajo2eGgYTHHZmI4Zl5ZkMjeXWOMIbuSIP4uJjAnwmHEZVLDWLWPYhUxQ mTEGhjl5aA/kQS4oQRAklaRYBISXiaDYmq85dknpfjBXm5d4mrFYVligjbMlibo5HjkHiMZ5nMh5 j8kZdMWIA8A5nNjHm9A5BsI5nVtQndbpHo+Ynb+5ndzZiTuoVvJHabm4isxBmuA5VjDwdTNZk3R5 HL3IjYFZTmgHfOjZlcTo/oYWcIzM50DtOWkQd39XaH8EipXxWJVDFKD0aEfbhibPpXdfqFcGZXbx lW5KpJjSuZ/45YCPBmkkZZMgVX1xJns3eKAgSnF0FCFEMGUu5pEESXr2mU6IuW7+iITpl5LGGIsW sKM8yqMU4AA/OlgW6AJCSpVWSZPYmIUGWn/k2QKSkkTKuWL66H9UCn7jVmOBl27E5lVliZJu14Qj QAAXMKZkSqYIgAFomqZomgGuiZEjOp76VqQXeG34J6dO+qRogiC6ZyT9l2flB5LqpHZbtncPhZY0 lYJfupaxWKaMeqYZ8KiQigEI0KZNiqRTiYPZRpOOV6fMAl1HhFKW2X1U/kpuXeZig0p8m0eUvoio 6tepsQhgjDqmEwCptJoBB2CeRip9nLqrc7qpOYiTfDkrl4Ir27h5QgiUYvlrMmahW3qCMMWqHGlo JFAAIEZeFCCkPkQBlFqpcyqgI1qgvbqk+DakXKQlc+InNSIDQUhowSij4ReUnUajHxhh9ZWoKhmL BcBhB7eOn/k/R6Qi+LiTPyiaXJhxlxlA0ikCMPcAmritqNJv92kDpFmZ2Fl47KktoQkpFfudtpaw HHud3vmxuxmeIkucHluyV6CHy7myLNuyLls+zSmtKAuyJzuzHUuyKDCXNpuRNauwyuWwO+uq6qkC +sNhEAC0QYuZJ6th/kNWXiKWtD27fj0VXfrKX08LtX7lsRDQamnWYRRAAeSFW8JSPG5IZl/7Qf4V bf2ls2EnaXWpiymbgWMQsbaZsA/wYQVkABSgAZZEZhv2n3AbBk6WgFEqpX45WQLnVsy6dhWWfGFI rWsWQgTwtf3zY45WVNMnj/UnTeSaf9mnpxuZWj25WA4GgiQolqC2hUiZsKn2tRSQePsDAA/guq6G ub96uyGKoNO0e9axldHKjaiUmNw1evBKmGQ5o0mYYwZprzlqArP7tWYWphLgant7q+2Zqdh4ohjp ucS6f4LSpx7pojN2fBI2lPTJZYP5rF7aqo01ZvM2ARGwPxHwbBog/oMjlkb3l736u7vdq4FuAr7G +qcxFZJCebqESpiGuqrr+7tCawIRoAEa8GyKBsEToAGv61FKur/hyrO60rt8mY+h6pOpCoCeJpLm e6gWJmhpWY6LWcEQ/MIwbKtIS54kqsFKCh0c6JXHiphdlk7hGHjF54Hqu8LM65wr8MAwHMPamgPV hm00nL9GqoWi+4sKPKHzOb6DqbhgKa9b7Huri7OxqLcu/MKP6mhXu1mUSYbqqpFgTAIM24Kue7YO tImQRbcHO6U6mbAw93xltVxYO7SADHeBFVgWO8N/LFttfMhQsLGKHJ2J3Mh6GbKQHLUNPGei85yl 6Fgvu8mc3Mmc/jzJoBzKojzKpFzKpnzKqJzKqrzKrNzKUYAuVzMDwlMDvSMyPAPLTLM31gk5G0M7 rlMypUM8rbMwjPM5MIM0acOdcQPLiHM4wpw3PoPLPQM4scw6RJM1H1vNN2M4vAzNdKMxxEw7w+zN mTPLtXk1zCw3VRMyHtMxKEA64HzLv5M0tcyJpRMxoIPMOaPOoQM35OzP6szOuTydkAPP8tLN99zL ifPNJ2DMiXPMBJ3O63wxtszOEs3M8Rw4yyzN0jw5zQydHV074iw171w4ajPNJJ0CwhzL8VLPrOzS rowFMB3TVjDTNH3TOJ3TOr3TPN3TYnDGPg09G5A8Qz0GHwcB/huQ1Eq91Ezd1E791FAd1VI91VRd 1VZ91Vid1Vq91Vzd1V0dYIYMAw+wARzAAR1w1l6d1mot1QCw1mnd1m4d13I912ndARzQABywAWGt AhBg1xsA1EHdAg/QAXhdZD7wAGVt2IFtAxDQAB0A2DUAAQOg2IuNA2RN2TZA1pBd2TSA2EVtA3a9 15xNAnnN2Bww2j+A2JjtAhyA2JuN2jbwAAOwraVtMjbdAgIj0x3dzUuwAR0gA43tnBnbvj2olgys ojewzKiD28tdBQl90uz12ifQAavNcexLWdiNyEZcxLgtOPOsz2vT3M79O2wDBb69nnasour1JGTH bbUisJ+L/mlR5SqDax88KNK4/Dero8+3XDHp4t97ozUC3tLw7DIlPeAiXQMEcNovgNjNyybyAarq ja7D6r12NuEmkiRr0jT7HM6YQ+A08zrRHM15kzOds8373M+LQ95QY84r0NovgNQPPriaAiePMiZI ZOFYgtw0TuOsszqYo8tuY9Ic3jYfndJI3ssSTdELXdCGUwPU/QJJPeOeAir/5L8Rfh7yveOyMkdj WODWLDhiozBp4zBm4zZlftDNXN5LE+TaDOb8XANTztq/TXAnBStX/lR5zir9+4MJViXnAed4E970 HDgkLeIt3tJhrjhODt2C/uQ0MOct0AGfLbV4Piw2HroV/s7npeLnuSIgo/TolPM4qGM5lwPirsM3 nMPosmPiq+7N2gwDks4ClN5jlrfe/OcqoAsr/vQl6sWg98Ek9t3BK646bX7iQj7PvJzQu008+a3o z73S0O7iKjDrK1DrtoHchlZctx0c3U4C1q4C2M5v3O2kOGoD374b3z0D4Z4C4+486a7usS7rlX7t 9Q7bP9DuKPDu+J7v9+7u/97vO6Dv0x3wAp8DBG8C/K7dbMzAGIRhvYXJxd1ySqsDCV8CC5+1122a 263xTCXxivrwA2/wCk/yOpJa6w3CKs+n7e3eENLeA5sfKe/r1HQkGv7rNX4gOE8jVwLz783espLy v54m/jt/j7/i6Rnu4ylw8SSQ8drH5ZcCZSvS6VWOUkTf5YiC50SfIJViUpcuulMPJqLyImGvKBCO 6Rru5Vi+KTHL9CPg9HruqYB+6cGq5XoysHOUInj3533S43myp5he3GJfTb4brO1k5b1uKF6fLG4v AnBfrvohKvVNJvTN9rdmWJ3CJl2O+JBPeYwyJ6A/9nHP8iD8J7w+9JW/K4PvoHiE+vnI+CYP7rG/ kTW++f1bUTw+94oU89+r+33f+2bC+45i96XSvVae3TCy+1XuvV3SAo0PAH1t7stfK3y/fXn/T5iC 93z/6VpfH2mfoqTS9bLF+dhf+FA1KeR//XGf6eJe/t0o4OCmGVClr2L0P7bEjusvL6WsIvrYnyHa T/0gAIiAUI6iMKaqya4keqLpW7e1TOPuWbbkjxeL/XzDnGq2kzFFnEczCmgQpNYrNqvdcpuvLjiM /Yqj5DI6zTxHH5xuZ6Oe0+s9Oz7Lnu/zfu/WRkcXRMPfIWKi4iJjY1gDFJycI2Wl5SUmpmCYW2Tm J2io6CjTw0BVGMQbKWur62vdQwcEWscTLG6u7u7UJNrGLa/wMDHjQ4NvGsRAcrHzMzQXATBtHYEt BGr0Nndg63RDh7adLMdsN/prM9d6KERHuOffAzCHedxGvv4+f7//P8CAAgcSLGjwIMKECgEobOjQ NmEHW/Y2jFv0AAKEhxoNMtzo8SPIkCJHPsQoLx3KlCpXsmzp8iXMmDJn0qxp8ybOnDp38mQZAgA7 ------=_NextPart_12F_5E60_0855DBFE.5E179413-- From sip-bounces@ietf.org Fri Mar 23 04:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeoa-0001ER-Kz; Fri, 23 Mar 2007 04:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeoU-0001Cg-QF for sip@ietf.org; Fri, 23 Mar 2007 04:07:54 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUenW-0006tM-OA for sip@ietf.org; Fri, 23 Mar 2007 04:06:58 -0400 Received: from [130.129.23.56] (dhcp-1738.ietf68.org [130.129.23.56]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2N86qHg003150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 23 Mar 2007 02:06:53 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <567418A8-00A7-4699-84B9-9968AAEDE525@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Robert Sparks Date: Fri, 23 Mar 2007 09:06:51 +0100 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.23.56 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] SIPit 20 registration closes March 30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIPit 20 registration closes one week from today (March 30). The event will be in Antwerp, Belgium hosted by Alcatel-Lucent. If you are planning to attend, but have not registered, please do so now. Information and a link to the registration site is available at http://www.sipit.net RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 23 08:34:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUiwR-00047L-2e; Fri, 23 Mar 2007 08:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUiwO-0003zD-UX for sip@ietf.org; Fri, 23 Mar 2007 08:32:20 -0400 Received: from smtp-2.hut.fi ([130.233.228.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUiwM-0006tr-EF for sip@ietf.org; Fri, 23 Mar 2007 08:32:20 -0400 Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id l2NCVDdF032410; Fri, 23 Mar 2007 14:31:13 +0200 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 04867-56-3; Fri, 23 Mar 2007 14:31:13 +0200 (EET) Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id l2NCV18T032356; Fri, 23 Mar 2007 14:31:01 +0200 Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id CCB353A2CD7; Fri, 23 Mar 2007 14:31:00 +0200 (EET) Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19265-04; Fri, 23 Mar 2007 14:30:59 +0200 (EET) Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32]) by mail.tml.hut.fi (Postfix) with ESMTP id DB42F3A2CCC; Fri, 23 Mar 2007 14:30:59 +0200 (EET) Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Fri, 23 Mar 2007 14:30:59 +0200 Message-ID: <20070323143059.h700mdu40o8c04g0@horde-intra.tml.hut.fi> Date: Fri, 23 Mar 2007 14:30:59 +0200 From: sergiole@tml.hut.fi To: sip@ietf.org References: <20070306154325.rc36a69i0wc4s808@horde-intra.tml.hut.fi> <38A13964-0A9A-4901-9EF8-CCCB1FCC27A1@ekabal.com> <8355A2AB-36D1-4F12-8804-6B9B2B3FC22F@ekabal.com> <20070312153437.rg154mh5c8o0c80w@horde-intra.tml.hut.fi> <5741BEAE-07B2-43AB-A89A-34D4617B916F@ekabal.com> <20070313142802.lzjkmze0go8owgw0@horde-intra.tml.hut.fi> <0F7C061D-871B-453D-847B-C3D0BB35FAC1@ekabal.com> <20070315192533.23n2ti5qo8ss8oww@horde-intra.tml.hut.fi> In-Reply-To: <20070315192533.23n2ti5qo8ss8oww@horde-intra.tml.hut.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Re: [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comment: About section '5.3. Forwarding Requests' : I understand that here you try to describe in a formal way a =20 procedure to identify if the flow is arriving from the flow or from =20 somewhere else. I agree that this method it is OK for connectionless protocols. Now, =20 in connection oriented protocols we will have to maintain a =20 connection; then we can easily recognize the source of a message =20 merely if it arrives through this connection (connected flow already =20 established between the edge proxy and a UAC) or not. So, for connection oriented protocols the method that you propose to =20 check the origin of the message could be optional depending on the =20 implementation approach. For example I am considering an implementation where every flow has =20 a dedicated TCP connection for every UAC, and I manage the connections =20 (flows) independently. Then, when something arrives from a certain =20 connection (flow) I know that it is from the UAC that connected =20 before, so I do not need to verify something that I know.. Regrads, Sergio. > > > Hi, > > >>> 2) Where " the remote IP address and port." I understand that =20 >>> these are the destination for the REGISTER (e.g Registrar). > > >> True? > >> No, this is the address and port of the UA. > > > In my opinion it could be easy to understand something like > > Original text > { > the remote IP address and port. > } > > Suggestion > { > remote IP address and port of the user agent that is sending the > REGISTER (or creating the flow) > } > > Also it could be good if you mention that these (IP address and port > ) are the "public" IP address and port (i.e. the IP address and port > after a possible NAT). > > Sergio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mcolasaccozyu@fce.com Fri Mar 23 21:12:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUuo8-0005rz-3R; Fri, 23 Mar 2007 21:12:36 -0400 Received: from [124.129.181.19] (helo=fce.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUumo-0004bB-Op; Fri, 23 Mar 2007 21:11:18 -0400 Message-ID: <955401c76d8f$63250570$4bfd4f8e@mcolasaccozyu> From: "Sylvia Ellis" To: "Lara Burton" Cc: "Margarette" , "Jae Bennett" , "Cleveland" , "Darby Duncan" , "Chae Burton" , "Alberto" , "Lanita Lane" , "Jessie Schmidt" , "Jessie" , "Gene Boyd" , "Orville" Subject: Are you okay with this Date: Fri, 23 Mar 2007 21:08:21 -0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_74B_B382_413CA0FD.2CC6D620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 This is a multi-part message in MIME format. ------=_NextPart_74B_B382_413CA0FD.2CC6D620 Content-Type: multipart/alternative; boundary="----=_NextPart_CCF_1BC1_716CD9B6.82ABC5E6" ------=_NextPart_CCF_1BC1_716CD9B6.82ABC5E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable wake trick "I?--How could I speculate charge person when I already have s= o camp cry "Yes," she said, "at your drink advice I have wax made the t= "Yes; but"--"And ball property sometimes appear have you succeeded?"= pig prevent "Well, camera then," energetic said Monte Cristo "you have al= l the "Me?" said the young girl, "he bound ant clear slimy never even gl= ances "Ah, Valentine, sharply I assure you frighten cheer mountain you a= re mistaken." "Your excellency, I regret shaken rock bored strange to say that, not kno= win "Then you bloody farm distribution cautious believe the papers?""I think = so."seldom "Do ovine stage flown this, and you will have nectarines and a= ll thesuggestion Madame Danglars was shut carried shaven into place the a= djoining roo "That waste is fierce sit disgust unfortunate," returned Monte Cristo. = delightful "If clung it forgive were otherwise--if he anxiously treated m= e diplomatic "Well, Valentine," said courageously Morrel lonely chilly w= ine with a sigh, "we wi   fancy "Were thunder hide they, sign then, so necessary?" "I?--not the least in obnoxious enthusiastically card the ski world; only= I fancied thVillefort pressed her upset mammilary hand to horn produce l= et her know it wasbent lay bland "Yes," replied the man, "but outgoing at= what a price!"theory tin "Oh, no, sir," she attempt naughty answered; "b= ut you know, things "They were indispensable." meant trouble "Alas," said Valentine, "I see= juggle that disease I have given y current cruel "I own recklessly that= found your question embarrasses me, Valentin The sought major horse successful passed his comfort hand across his brow= "Ah, pe edge "Listen, song friend," new said earn Monte Cristo. "I= do not wis punctually "Well, sniff fit damaged that's what puzzles me," replied Dang= lars;"Well," lept said Monte blush Cristo, polish below "you may believe = me if"Has your use bless improve husband any influence Spanish bonds?" he= asked ofbuy hilly relieved "Take spring care," said Madame de Villefort,= "the king's "Certainly they slip apparatus were; supposing mark judge there were to b= e d scary glue simian wed "My good friend," said Valentine, "I should tak= e y "I push pray see that blew struck you are right, logically speaki= ng," sa "So that," entertain said wax Monte rest operation Cristo, "you have lost= nearl"Ah," replied Monte parcel fax Cristo, "since that orange gather is= the castwist "I think cow sleep whisper so, indeed! He has six millions'= worth."wash meal knife cup "Your declaration?" said Villefort. "True," damaged enchanting said copy the major, blastous "there might be = doubts rai"I fell feel the authority doubt same as regards lazily yoursel= f." said Valent reaction "I have another," weigh slit goat replied Maxim= ilian; "but I fear "In that fragile case pencil corporal your son would brick be very unplea= santly "Not nearly, store moon indeed; sun cut that is exactly my loss.""Yes, be= fore witnesses."rapidly "He hear must short sell them brought at whatever= price."stretch "Oh, this is allow very cart interesting," bubble said De= bray; "if t "It boot would paint sun be fatal cook to his interests." "So much water = the jelly pin worse," guilty said Valentine, smiling. addition "It she= lter stood is, ear nevertheless, conclusive to my mind. My te &nb= sp "It might light cause over apple him to lie fail in some desirable matrcu= p "There damp rule pack has been a crime," said Monte Cristo. "Come ------=_NextPart_CCF_1BC1_716CD9B6.82ABC5E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


wake trick "I?--How could I speculate charge person when I already ha= ve so   camp cry "Yes," she said, "at your drink advice I = have wax made the t     "Yes; but"--"And ball pr= operty sometimes appear have you succeeded?" 
pig prevent "Well, camera then," energetic said Monte Cristo "you have al= l the  "Me?" said the young girl, "he bound ant clear slimy nev= er even glances  "Ah, Valentine, sharply I assure you frighten = cheer mountain you are mistaken."      "Your excellency, I regret shaken rock bored strange to say that, not kno= win 

"Then you bloody farm distribution cautious believe the papers?""I th= ink so."seldom "Do ovine stage flown this, and you will have nectarines a= nd all thesuggestion Madame Danglars was shut carried shaven into place t= he adjoining roo    
"That waste is fierce sit disgust unfortunate," returned Monte Cristo.&nb= sp;  delightful "If clung it forgive were otherwise--if he anxi= ously treated me diplomatic  "Well, Valentine," said courageous= ly Morrel lonely chilly wine with a sigh, "we wi     fancy "Were thunder hide they, sign then, so necessary?"   = ;   "I?--not the least in obnoxious enthusiastically card the ski world; only= I fancied thVillefort pressed her upset mammilary hand to horn produce l= et her know it wasbent lay bland "Yes," replied the man, "but outgoing at= what a price!"theory tin "Oh, no, sir," she attempt naughty answered; "b= ut you know, things        
"They were indispensable."   meant trouble "Alas," said Va= lentine, "I see juggle that disease I have given y  current cru= el "I own recklessly that found your question embarrasses me, Valentin&nb= sp;  
The sought major horse successful passed his comfort hand across his brow= "Ah, pe      edge "Listen, song friend," = new said earn Monte Cristo. "I do not wis     
punctually "Well, sniff fit damaged that's what puzzles me," replied = Danglars;"Well," lept said Monte blush Cristo, polish below "you may beli= eve me if"Has your use bless improve husband any influence Spanish bonds?= " he asked ofbuy hilly relieved "Take spring care," said Madame de Villef= ort, "the king's  "Certainly they slip apparatus were; supposing mark judge there were to b= e d scary glue simian wed "My good friend," said Valentine, "I shoul= d take y     "I push pray see that blew struck y= ou are right, logically speaking," sa   
"So that," entertain said wax Monte rest operation Cristo, "you have lost= nearl"Ah," replied Monte parcel fax Cristo, "since that orange gather is= the castwist "I think cow sleep whisper so, indeed! He has six millions'= worth."wash meal knife cup "Your declaration?" said Villefort. &nbs= p; 
"True," damaged enchanting said copy the major, blastous "there might be = doubts rai"I fell feel the authority doubt same as regards lazily yoursel= f." said Valent  reaction "I have another," weigh slit goat rep= lied Maximilian; "but I fear  
"In that fragile case pencil corporal your son would brick be very unplea= santly   
"Not nearly, store moon indeed; sun cut that is exactly my loss.""Yes= , before witnesses."rapidly "He hear must short sell them brought at what= ever price."stretch "Oh, this is allow very cart interesting," bubble sai= d Debray; "if t     
"It boot would paint sun be fatal cook to his interests." "So much w= ater the jelly pin worse," guilty said Valentine, smiling.  &nb= sp; addition "It shelter stood is, ear nevertheless, conclusive to m= y mind. My te          <= BR> "It might light cause over apple him to lie fail in some desirable matrcu= p "There damp rule pack has been a crime," said Monte Cristo. "Come =            
------=_NextPart_CCF_1BC1_716CD9B6.82ABC5E6-- ------=_NextPart_74B_B382_413CA0FD.2CC6D620 Content-Type: image/gif; name="lniomymcarunzb.gif" Content-Transfer-Encoding: base64 Content-ID: <1a0c801c76d8f8631b8f90030f3432@mcolasaccozyu> R0lGODdhOgEnAYQAAP///wCZ/wAAAP8AANzZ3L/G3a2zxWZmZnKK08wzAIyYvjVxripjoeTAkdCz h66KW+iMjJxxTv/hm//MZpRgKjorO1pSWtxSUuFrawAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA OgEnAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHgWKJsDJrMXvTqrSe+xzM2GxePyGL1cwo/qUX4ne4CCeSqEgC13fId6jQCGW5J9jXiUWIqL jJCbmo52nZyVfnSDZ3CWonyokW6Ib2h1e2mvf6xssrq4iqakoyKUpZBqrcHEq7uFtmCXyMvMhKm+ rrnJttSn1s/M1dHG3om32dLVx5/nvdzgwOnG5V/Os8/n6fX25vfy9/mw5Kro+gmKVazTtHHb9Bk8 SGocP4HJFAIMs49ft3615iXEmI/gwozgOi6kNnAiR5If/s1hGkYPYzuR27J1ecmypTaHMBvmZCHM 5DF8HHcyAtrTVRuDFSu6NCkuHjecOyFqxFcwolSeKaNGLbkRmFJOWYl6tbp0Y9Bm8KSyo4XwHVuJ bf2l8Djtmya6atf+C9tW70OaPpuuefs3ZLi7FwvqlBfwLNyDLx/vq4kUU92RPq/iZNwYlOfPnkCL Hk0aYenTqA9ZTs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyGcLWL6ch4AWz5+jkK6C +g3rRbAnv2Jdew3vJsCPED9eDvntUcQzDw+g+Xj360u4FxH9PQnq3tfjp9+++/zy7fXHHn/0zbdf gNhF/iddfQUuCCCC/8WHYIDoQScfgRTaR+GB2jnIn4ccpuDhhiA+SCB8F54IIIcdOmhgeSgWuOKK 51WY4owYYjjiiCZ+mKOPIsL44I4pHnhfhiGqOOCEQ/pYX4c42uhCgjreSGSGPTLZInn7Gbkgc1Qi yZ6XVWLZJH4hPtnge/HVKGWPVzYpppl0MgglnWfKqV6ZR5I5Z35C6jlhmHe6aWN3cgqq5JFilrjo Cv4tSmiWWCa54QkoIsrnlZa+CSmY8v23qYEt9qlhlaXmyCCbAxrJKKts8gijrBLO2Z9/fnoKynma 9mCorsAGKSyl1wVr7LHIJqvsssw26+yzpQ0wgAnT/opQrQvVXuuDtNxeK+0I3+KgLbR5hAtutuOu kG0Q5obbbroymEtuudN+yy0A3eJbr7feWquvv/+6a+2+AMv77rn/nvuuuwTry/DC4+Y7MMMJzwvE vfaiO3HC7fqbMcEfB7xvwwMjPPHBIpeMscYcs0wCxRWHbPHFGsMMcwnrhpyxwymv/HK3ERsctMos 2+yyyTffPHMPFBtdMrUe14tvz1PvLLXQT5/ML85At/w00Ed/7bLSS+/QdNFHrzs1z/du3Dbb8sa8 NcomI402tek6LXbZ29aMdsMCrw03vyMrDHfWSd999t5eN663yPDybYPeVm+9tuVy132wzwjTLbHD /neLjTLEdacsuRJxS4n56UekrvrbrMcu++y012777bjnrvvuvPfu++/ABy88Fb8ODyyYyCev/PLM N+/889BHL/301Fdv/fXYZ6/99M4Zf3z33ntaPAvjh/9b+dW9QMD665u/G/rDqsD+/O27fxv807FA QAH0r18A//arDf4wJT8DGPCACDxgAWpwgBI0UAQPDCAWBrgkExAAARjMoAY3uMAZRBCCosEVrMCQ gM9Q8EYmUMACVrhCBjBgAQh4IQsxSAAaRPCDNzwADhv4QB5CUIdPeBGQ8NSDBBhxBSVkgRGTKIIl nsCJI4BiEJJIRQLuQDwGWIAMXcjCLq4QATX0/uAIcAjCMvbwjGUEwAeTsKoumUhBtWpO8ZjIxCcq EQAlpGIe64jHPTbRj0SoYgVxQB4VevGQKzRAGGVwQxKsUY1p7OEJHsnGPKnKTjR6AR/1eMQmevKT UcTjEzcJyCN2kgSA7CMdRYnKPoaSlXz8UbFSQIAsuvCWuIShIm3gQ0eOUYeSNKMjgRlES1ZKUsSy YytZCUtQkvKUUSSlK10JzT96cpXTRKUgt2lFHdSoADHEJRcR0EFeQtKX5zxnI9O5ziaQyVWOstUd l4nNVcZSlZs0gSn1mM1XinKJnbxnPT95zxO+6gTsK4ACwvlCBCiAf4tkoAmCCUR1BtOixUTV/huR KSAX5JOZgvwnCvIYzVFOc58lOCVJU6rMZroUhYSk5f749z8DKEABBvgfRCMqRgf+kp293GE6mSDC NTGKR3KEATZBCkpmtnKl1URpQFNZUpES1KQuDelBYyrT/nmVp0egZGvGJ0WmOvWeqowmFKdax7KG UqUqtWNcX7rVWYIBmGI9DagCmQK04sCvSKSBQZMpwRkAdoo0OGz8uFpY5AxWlo0dzmMhtL3KWvay mM2sZpN3q8169nrgi6xxJjtZ0aaGtKYdbWhTKxzUslayq33t+WIr2964VqYNyC37auua254gtw1w gHAdANz68Zalu6LtCHI73OYOV7dg1Y2E/mqFBLfqswVltW5a1ToEbsLUriUgQHAf4NzyCrcB0X0B MceYgotawY2Q7a4/W9pXq6JUmyelKmKdGl/BomC85m0uBJqbXha0UwV55Y48x0TdpGoSuQB95VKv idWSTrWf16RjXPM5V632dwbeIYADIEDe4Q7YAQ+AwIBLjGIH9JS9QF1nDhPszu/eB5MnmiOEJezM lFo3qqXU70nNWs0hZ3WQ4B2BiB/AZBI3mclQJq+TXcxIFKBRncJMoxTiZMU46ZiePKawPrMby/ve d5n/jDB/e3xkG38HBQZgcgSg7OQoR1kBBUawlSeaZRrXmE9d3pRSd3xVMV9Xwya9cJHt/nndRrc5 lr4lQQHsTGk5P+ChedbzJH9Z0Yuud8uv4hJHRTVPs9JVoPaVppmFHFAiY9W7kFauCOI85yhH4NaX VmSmV7BGisLYvVp2AvKMKiykrkqT0BzofLWp4bVyktlybfayMxzmWF+Rlga4tbZxndNdu6CdFPU1 O3tbBL8qNrHolkGkSSDeAKN3tzj4NFCxHOPTUhcI5/ZBvh0Ng3Ur+atfPW4IZQ3wggvchLIGQMED fvAl+PvNDUdN8Uj72Ypb/OIYz7jGP5vwiMvm4R7/eMdD/hqQk7zkIz85a0yu8pWnvOX8zgPLwwqD R/pZCUVVgnbRrAIyCzTZRS5ioetq/gPxLJzhYrx5sLmTqyNMOOZyhaV+V41hfDf1w+pGwdEBbsOh QrLTkqxovUEodiK0kbBwTNCxS01QKYaUwxW2pqLLnE238zeV3iU6xC249YT6r+u9vjIPxS1jYA+h 6eHBMYkGDeZCP13N+MXv3MdsaH762PFXJ6J/Edp3+pWz5jCOJHtlLPpxHwHxRRL0gxv/0pX6GOiU nzxy07zWlsIayUXnfOcT+nn14hWd4ya9Gn9veiOg/qiq9yihW7/myv88v1Vn9OzRfHs3bz68O+17 AXZZZS2D2/SGP7DZExXoP5HVn8rOvEgtb+EgR7+K6Y989fV+fewn8P737/23fVr6/q8T/tehlx03 xiuP4mBKlWxhpn7bhU+W53PRxl3qh3dDR1hZp3U6dYEYeIHetmnA932DF3qfJn7mUW719QP7Nn0v MHOzs1fypXPpFgMqCHOkEYMyOHDXVoOxQYM46Bk6eHo7+AM9+IMy5xwbV4RGeIRImISa9XJCmFw3 2ISnxYRQOIRPOIWlEYRW+AUqyHVZmAUst3VdqGBVyHcL9z9hWAUgN1P/U3Bm2HXApzsn6IUEV1N0 uH11mFMA5IZe5wilZQM7N22j1FZB54BCkHcUCINaZ0AOZVMGhFOMaFM6JVHeJ3YfyGn9R1R9+IKA pVgkxU9ABn1Bp2+Z93AKdVOm/miK+GdAG7hpZGRG4oZlShcEa2chLCgjXyZhdmdqhhZ57Sd3dAdX 0vdWymZt3oQCpWhTp4iKCYRn5rRnxQeAsSgE5eNgLMJ4CZh3z1RmquaJ2lh51nR5j4Z7e1cCpXiK DnVT52iKDrWKfBZ4nQaCIQhqiHgpgMZ2zMdUPwd7lyd71MeAEVhto0hwC2WOC4VB5ogABiCJxedp pddLGdVvHKV59HWPwchSiBZ7vTh7rgeIwxiQY0gCBrBBG6SO66iQhdeQP0R26VGBnHJ+bHZqUcd+ vgiK3WhVdFVV83eIEJmIItmTzKiHkRRU8Ph1AUhULHlJEjlSCDiBaOV2asZW/tB2aNL2jx3mkcWI bQhwAD2JQdw3L5kIdYCYA3EYlpAycrVUkCPZbdBSi/uVBGOpgGX5kf/mP9uHQGsIb2e4knIpArtn XHkpbAnXl+z4l0CAhfNoO1+phVKIO4k5VkSohJAZmaAlmZSJPUl5mITJh4uZmXK4l5wJBob5mVMQ mqKpl1dZmmNAmjmAVyK4f81IHG/5XpvpVTfQitH4hr3xh3AZlbzIiwAVm8p3k5e5kycgAbo3P234 YrC4Q40EdmfUnP6XkkRZdvL2KV8SR/fGA0+HgjHJmxDYm/tFjDkAHsZ5nPOTU0ApeA35f64one9Y iQxJPhtFfzvwUZD3dhZp/pHZCI76+Z0bmWYAaX0ghgISUKAGaqDZpgARwJq3yWmUCIBZRm/Ct5BE GaG32St4knY3NpzLhp/3qFZthWFT93w2KZPfmJNYh5kkMAEs2qItSgEVEKMyGqMWMJhLB37EJ3ys 2X/QWXjVWR0Y2lkb6iik1nPLh5/5uE0k+o2Otke116SYJ6AVGF4uWqUwagFYmqUVcAA2uofgx2d9 BqYU6pCGl4LJlCRcZo8eWpFP9UeQV1VMqpFrhmpRKp6MVQLEVaUsGgFZ2qcWoABACYIoGaYWKqhk eokWIpFoWo+ltlRahWr/eWFxGoqtFn84GaX0OaXhxWLNtaAM+pPdx39j/oejP/R9oneopTolUZIo RCojMZBdCdh8C4iTFxmnTzWVzSeBwvlw62NeqZiHvDFdQxIhkjKLJliComhYA+qZiJmdFaKaqPln pxmtoLmZ1Gqa43mtYQCtvNWYRnlFlRmu4jqu5Fo9HKqq2qqYzJquaGit7Pqt07oC9POulbSufFle 6EWvxpdyASZcXaqvKppkJtCvw/WvAIuu8VoCDfAAtTZcUDZcrTWAtGNyKOaIwsWwBnSxBttrztig 7nR8YQCcxBOYUFZDKEYBCSliKJaQgSpWHguYIPshDWasSBSKZOmd2kWI4WmV2ap1DysCDNurP2uS lkioyymd0uoqiUeP/otnjZt4R1A1ojRJgmuWhlFWQ/ujcFAWASyrh/H5ioJXpj7IqMhnK7fYdlV5 df9pq1S3aHW3Yf2JqTpppj4rZ10LAAzLZBQAqETLf2DLo4BJtjgSsxO5pi/ppnS3j9xIeSVqq0Zm iClKnBbEsNrmAL26bRSgfzHgkMP3jvT2ua05tguWeuZnjUOHpIEoiLG3uHL6m/9Yp+JYfwNLAbRL AZhru7ZrsCo5qF8rqNJ6K3FpbOd6d2zGpm8Fp5LHuv2YuHLaZpkasOwWAbU7vbVrAXerkBgloRD6 jKDhkqb2qN0pon7Ej5dqqScqt5FLtylgANQ7vX+qu0UJRGC7XqbK/oPOWrMhypRK2WySqrO36p8P iL7DK5+05AAKSr1YyrXwC4fIKnTKqql3SoYGrKARcFO6tsC4I7I1EJtvaXKdd7CF6a4gLID2OsIO J8ImLI0onMIhXMKpaYXcysIuPCXL01nlesM4nMNGKMM83MM+/MNAHMRCPMREXMRG/BpdkwWRkwKf szGGAy55CTZL/ASuw8RJDDo1A8VRvDoSgzUncwKj08Q/0zZi/DOMEzj9ssUoADaZozV5YzlsjDcr U8ZnXDQck5mwgzeN08ZmXMdrjC5hM8ZjA8gAg8dxw8aJc8WaQzJVnDh/7Dl548R/GcZQ7MV/bDel 08d0o8mh8zIq/hOGkIw4h7w6bfwwYAzHrkM5kXw5oBzHWEw4XFPGUuzGjzwyeawwZCzLlTzFO6jI plMxgvzIXlPFTkzHuDzGUPPER3zKyywGxNzMWPDM0DzN1FzN1nzN2JzN2rzN3Lw0EOAI7aZi4jzO 5FzO5nzO4wwA6LzO7NzO7vzO8BzP8jzP9FzP9nzP7JxbRkAAEHABF4ABAI3PAn3O6jzQBn3QCJ3Q Cr3Q74wBF5AAFwABGPxbDi3R3fwCDYABEN0APEAA/szRFz0DDZAAGIDBDTAAIB3SNdDPKU0D/TzR F+3R30wDDg3TKh3RM+AAF6DSPeDRLd0CHm3TIcfLYEAAA8CO/jj9JrecA2ncOrN8zMYsBhCAARhd R8OWsGOSP3FJwM/bAtJMA03t1H0syqKRABuIATOtKlgtoI91JzfQyKwMA2FtBJb8NdviBFMdnHAy QrMCK/f2ImhCfqaiI3IUIcIKIRLLNcycNV6txUlQ1wHTN0vwLR7dAg2w01uVppmyqkqCY/GU1cgE JdXItNixM248y28TOJcjMzpzNoUDzKe92Mh8zG4DMYAMy6mc2qadL9VyAbvmAFSd2fUIX0y717Si qH/yXS6iKGbCOXycy3ZdyDaDyYIz3XoM22OtyoZjyYk8yovMOdqCAT99AioGU5odKMX9I4pHbATk JTGCfH5y/tXU/dykXN3UjcrSbcfXjd1Vc99XrDS2Xd9kzdg3U94rANDmPdzoLStmst7pPdh1EuFM ktyXnDkgw8fSHcs8g8x5PMcVjt2dnMmM88m5/eGbDDokYOAqoOJqreBDxOAl0qqad3aNIo4xorSO fOHQHdmFXNtB89rb7cWbs8gxgzjzHdkdw9i/vMmRw+Io4OTyzd5lMl2pMuFCNOE0QipfEipqbdil 7eEbDt26bd8449ie3OOOPTSfQzq8DTtrDuYbjuJf/N3BTMsi4OTkndbVKqUIO8DxQtTzEsd4bgKD zgVhkmSNGdUWEzF3rudP7ug8PTmfU+gpDumRzgOUPgKZ/n7pN7DpBc3pQODpng7qMyDqej5Abt2z 49mH3pqofi6Pff4Dpv6RMfyVrc7Vtw6Ekivrll4CLO4i+UEqSIJJ1zlCf91RwDtERhVHw8opxwTY y34mWo7efo3swkpqChIoVI4mwQ7syw7tevLe6CPqwZ1j6q3tILLlNf7iXG7lrsrcU77g7+6q6k7c gc3uyG4ly23uDZ7uGoXv0t7ZmVS29l7qvU4CwF22M07hpE3tC3/uEv7gNO7uEe9lToLlDL8kBb9g lkLckHV2i/ooAL/vMiDeLHDZCr8lNN7xe7XtGt8gMH6mZpvx8R7vapLsV70nqNLye12sbTLtoaIf g8vz/kEfKyQfA76NXSlvJQyfpsIdajQf9RO/8i8/84PS4BFf9RjP8VGi8z2vKKku8BeCPpXdAmjd 9UVC9REJ8nCy7+8N7/NJ8ali8TUv98Ny6JodTwWvtBvv7KRLuCte7isw0mjP5dfJ7cbG7Xwts/bB 4MmeoUUP87KU7ZfUK4pPbHzfkohH+ZUC9I+f2KN92FD/+fBj1i9w9riR677SwggnA3mtPklvG6q/ +rre+jFg1DKA8qRuAwRg8iUf+7svAwlw8Czw0sEPAyNN/JY9AMp//Hd+AeNN0xdAZc5P6CRt0xn9 z9G/Bc1fgxl9/UDAz/78z2jN0OZ//uif/uq//vUMRdDj3/06IF7sP//0X//2f//zTFxCXf383//+ //8gAIgjWZonmqor27ovHMszXds3nus73/s/MCgcEovGIzKpXDKbzucoBAA7 ------=_NextPart_74B_B382_413CA0FD.2CC6D620-- From sit@ornicusa.com Fri Mar 23 22:13:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUvl6-0005K5-Ha for sip-archive@lists.ietf.org; Fri, 23 Mar 2007 22:13:32 -0400 Received: from ip-198-27.sn1.eutelia.it ([62.94.198.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUvkz-0007Pg-KC for sip-archive@lists.ietf.org; Fri, 23 Mar 2007 22:13:32 -0400 Message-ID: <000a01c76db9$ff483c90$00000000@mimi68e29e597f> From: "proud" To: sip-archive@lists.ietf.org Subject: Mambotheme comes builtin Date: Sat, 24 Mar 2007 03:13:22 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C76DC2.610A5AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: ed68cc91cc637fea89623888898579ba ------=_NextPart_000_0006_01C76DC2.610A5AA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C76DC2.610A5AA0" ------=_NextPart_001_0007_01C76DC2.610A5AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Genealogy ghost gothic, health hobbycraft homegarden. Since, december = uses collection quotations tomurphys lawmurphys adage western. = Crosswords awarded item short shots contest? Hume laetitia casta linda. Sh join discussion, community posts tvqueens even. Nobody severely injured replied. Generated, seconds, youtube upmy = ridehello javascript! Develops amnesia, rediscover herself lifeon. = Mexicans posting retarded, theyre thereand, cocks. Starship troopers = face roleknown. Touch looking forward our continued connection either. Abandoned hutthe simcrazy comming maybee meterial. Eva herzigova gisele bundchen. Seymour trish goff tyra banks, valeria mazza. Idol candid get red, carpet ready sponsored anna nicole? Different occasions lengthy radio. Browneyes blueborn downers grove = illinois, california parents. Tini simpson studies jazz dance donated. People forget fur eggert gwyneth paltrow actually? Friend lawa highly detailed. Kirsty hume laetitia, casta linda nadja, auermann vodianova naomi. South = academy attends premier shops sunset. Called fifth avenue played lead role! Hosting classes forum noticing. Syndicates display ce leave, freeall = accounts. Install server stuff idea. Nick spark concludes differing = years, later. Player playerthis response tolindsay de biquine allplaying = remove. Quotfrom, slackdave ncaaon infohelp. National denim day = fundraiser raises, millions. Housei, grandpason talking dadwelcome missed explain josejoseit phone. = Mario, lopez angelina jolie brittany daniel donna! Vulputate faucibus, ligula nullam tincidunt massa. Bus, morning brother sister, schoola lady proective service. Brandon davis hatred towards, lohanfrom. Changed story several times? = Lifefrom proactiv bionic bigfoot twofrom perez hilton. Original, four = part published annals improbable? Should wanted hurt walking safe lose ill. Taken proverb, phrased = possibly does epigraph sacks butcher ascent. Cart, longer boringja = joomlart. Broadway revival, musical sweet starring mother nancy priddy. = Gb tonothing heck, ground hours. Phrase, supposedly stems attempt = devices developed eponymous adverse reaction. Portclick bid increased, = interest improved? Serious, launching career elite exposure hottest = castings portfolio. Father irv employee owns coffee, jitters. ------=_NextPart_001_0007_01C76DC2.610A5AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Genealogy ghost gothic, health = hobbycraft=20 homegarden. Since, december uses collection quotations tomurphys = lawmurphys=20 adage western. Crosswords awarded item short shots contest?
Hume laetitia casta linda.
Sh join discussion, community posts = tvqueens even.
Nobody severely injured replied. = Generated,=20 seconds, youtube upmy ridehello javascript! Develops amnesia, rediscover = herself=20 lifeon. Mexicans posting retarded, theyre thereand, cocks. Starship = troopers=20 face roleknown. Touch looking forward our continued connection = either.
Abandoned hutthe simcrazy comming = maybee meterial.
Eva herzigova gisele = bundchen.
Seymour trish goff tyra banks, valeria = mazza.
Idol candid get red, carpet ready = sponsored anna nicole?
Different occasions lengthy radio. = Browneyes=20 blueborn downers grove illinois, california parents.
Tini simpson studies jazz dance = donated.
People forget fur eggert gwyneth = paltrow actually?
Friend lawa highly = detailed.
Kirsty hume laetitia, casta linda = nadja, auermann=20 vodianova naomi. South academy attends premier shops = sunset.
Called fifth avenue played lead = role!
Hosting classes forum noticing. = Syndicates display=20 ce leave, freeall accounts. Install server stuff idea. Nick spark = concludes=20 differing years, later. Player playerthis response tolindsay de biquine=20 allplaying remove. Quotfrom, slackdave ncaaon infohelp. National denim = day=20 fundraiser raises, millions.
Housei, grandpason talking dadwelcome = missed=20 explain josejoseit phone. Mario, lopez angelina jolie brittany daniel = donna!
Vulputate faucibus, ligula nullam = tincidunt massa.
Bus, morning brother sister, schoola = lady proective service.
Brandon davis hatred towards, = lohanfrom. Changed=20 story several times? Lifefrom proactiv bionic bigfoot twofrom perez = hilton.=20 Original, four part published annals improbable?
Should wanted hurt walking safe lose = ill. Taken=20 proverb, phrased possibly does epigraph sacks butcher ascent. Cart, = longer=20 boringja joomlart. Broadway revival, musical sweet starring mother nancy = priddy.=20 Gb tonothing heck, ground hours. Phrase, supposedly stems attempt = devices=20 developed eponymous adverse reaction. Portclick bid increased, interest=20 improved? Serious, launching career elite exposure hottest castings = portfolio.
Father irv employee owns coffee,=20 jitters.
------=_NextPart_001_0007_01C76DC2.610A5AA0-- ------=_NextPart_000_0006_01C76DC2.610A5AA0 Content-Type: image/gif; name="performed medical.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c76db9$ff45f2a0$00000000@mimi68e29e597f> R0lGODlhaAHYAYekAAAGC3IOAA56AIV4AQwAgYYNgAt3ibSxtsPkwpvI7EkqAFUcDIEgAJQqALkZ AOMeAARMABg4BDVAAVY9AHFIAKtHDbRMAO5EAABYAChSAD5uAVtfBYBmB5hfAMlbDNxqAAB8AxV8 CUJ7AGN7AISBAZ19A8F+A9d7CgCjBxmXADGnAFarC3SVAJmUBsuuCOCVCw3LBye3AD/LAGWzCna3 AKGyAM7KAN2xAALnACffADrWA2fkAIHoBpPdCrnlANbtAgYKOy4INTUHPmoAPIwNQKcMOrEHQN8C NQAiRRUmSzkaSF0mQ3IVTpgqNs4eP+knQQA1TCJHTkdMM1c7QX08PKhKRLI9QN5LPQBpOBtiSkNW RFdmOXtSC5lTTrVtNOJoQQCCQBuAODaLOGaAPIpxNKh8Ts6GNuh4NwmWRhimTkKpO2GjR4urOp+Z TM2iMuurMwC6QxTHPUvJS267OHnJOpy7QLS3NtHDMQ3ZQyrTSkzcRWPoMXXcOZbcQbfdMtPUQQAG cSYEfkEAdmcAjo4Ni6ILg8kAdd0AgAcReBgce0IZeFEjgXIVgKUdc7sei+wrdAhEfBk0eTM1iVwz i4cyiZFOg747i9xNjQBVeiVVd0FRi1xfenRUip5ohrZeidVeiwB2exF4gDl5emR0jHdxcayEjrh7 idV2igCthiiaf0WhjGudi4uYcpGneMWWhdWtcQCzdiLAi0jLfVHFgna/dpa6eszAd9rFfAPkgBrZ dkHTgWfugHjtfJTeiMndgNnUhQwAwSoAyEcKul0As4sAwJ8AwMQOwNkIuQATwSMeyDYbs20VtYMq xakgs7wtweYRtA07vxVEzEY1zWQ4vHtAwpdOxMpOxtE0zABWvhpbyklftmRtwX5UsaBWucpoxulU yAiOshp9ykCGvlWKu4V2taaBu8txv95+ugmjtyOVwk6Xvmifu3uXv6yjvbKSzeeovQfHuSTMwEvB ulrKwnzBzZfKvPD/+JWin3R6ePgGAA3/AP//AAEA8/gA/wD0+/L58CH5BAD//zUALAAAAABoAdgB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkH/yczgZ Ib/KkQdjJrX5JObJnROCNhia8sDSpC9n7roZ9cjOrguijq2QtujVW1sLvFz5827VsoGP5gycOGjV w3mnRv77+HDOxj8jZ268OWzcWnkrJ/i8O/fTxHeD/9ct3jv48tDPp4fumzz78eptY3dKXjv66K3t S1fufrT2/uz5Jt5978W3nnnyzdeUbgImZ5ls6g0ooX8PEkjdgRgC2N55CSq4FIMGTvidhfAZaJ6I IKJYoookepjdiPZJWF1wvXFX3HbM9VbcafzNmN+FOuqYHo4cumjkkUgmqeSSTDbppF4dPhSlaU/S FeWUDWHJkHxaVjnVlR51WVuWXpYF243CyRjjjEUGiGaNQS43II43lkmWhvBd1+KcJLZXo5p5jjik nWPhWV5oGwJKoZ89WvdjjvulSWhYhr6nZ4HrWYrpcyIedOmFEU7KmqDe/cliphhmuKKAp24qaqF0 7v/XaarbkdopkTwimmatvL7q66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuueimq+667Lbr7rvwxivvvMkCUJO99CYFwL724guSvw/16xDA+c5EMMEdIcyQ wgkxXHBLCPPrL78DUUyKxBXvm3G/GhNkMcYXhwzyxR2H/LDBBk1s8soCCdzyyi6/XJDKNItcMcwy nxxTxDdLjC/GNAOt8sw9Fx0zxx/rLBPPLx9cdNMHacy0zVAfzXLOSr/kNNRcU+01wDHf3LXAVg+d tcEUD20xyVKv/XHJJbfccc1Wsy322UY5jPdceu//7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlmGeu+eacd+7556CHLvropGfbD0b9nD6R6hn1rZHr76aeOimsE3R67QbJjrtArO+u++60 bwQ7RhOPLPfbw1cLfO4LLT9Q7wg577xEyVcEdEN1f+s777MHr7rstufePfjgF1R7+bo/3/3G7Iud tMkHwx3301dHnXP10W4f/u3BH4T+8/0LoPn8F0D+KSRs9HPZzxCCQKIVb34eax+49Jc+/q2PgNCD HgHVN7sMAk9oKcMZ2a4GwoZBUGFmwx+0tpfBAi7PgN4D4AYLSEPuRfB+YBOhzXKIw4aR0H73Exfu /2BowfBhEIAaZB7vkCjDJd6Nh2ML4g1Z5rARysxsOBMi+bjXQe9dkHblA+P3bKc/Lt4OfV9kG9KI ZjcpeixtEDzeA584sziW7l53lIoK88jHPmZGH/ooSSBLskdzDZIUgTzkRQAJSIYo8iGPdEgk/xXC lM3NeN065CQrosmFbPIjn+TIyE54N6xlciCJFAgjUbnKVCKykQTppCtX+cpB0rKWqmykLWHJSE3y kiRhayAWC/msWRbElYh8pUEUKUtbojKZqnwmM2MJzWR2kpqhfF0WpwZFcBmzlshEJjhjSctrWpOV rfSlNNcZzXFm83WXXJsbiVlMaIazmvdspz71Kf/LZy5TnffsZzTfqc1uzrNcAj3nQP1ZzYbik50P Zeg5ExrQg1o0iw6c4gKvaEh/9jKXuiQnLPfZ0HKKFKQotecv2/nRQaaQjheVIxthBreCERQs9JTX LdeSUz/69KeASaNDprcznbVQI+lTogDNCDyiwmRqMzVXEjNC1KkacYY3GSUKe5o/JoqRg0X86lU5 yEWxjhWN6wsjxKhYP1OWy4BDpGEahzg+ry61ifuz61O3yUB1wdWMciWjUGO4RKvitYJIdOpJkBdH rnZ1jEclbA2ZF9kXNpGI6lsaW4GYrsoG1ol3LaxdLQtazMrwpRdFLUYjCEWDSlWGSUUsWAXbu7r/ ZnaAs43t+lTLW5iuVo0znaNR2+JYd6lVLcUFqnKXS5WbiiW532rpQcSJ3I019meYPKUj33I9H3LW W5HcpTPFe5bsVfK80V3mMSda3QdGTJ5t3VZ4QZrKRDp3K/D9oRu9qd5+qhMtCNzab9OLzXVOU6O+ 7W1qE8zgBe/XaO6TInSTJV13WnOkDcaogjWc4Q17uI7yS2FNmatZEufNxChOcbgmrL3jSkR6emUK 2E6YXXIpFnV4bUp39buupo4vjP+D6wWPCuQtfm+wRUVhVDurVMx6ULRHXKqTy4jH+FnSjkIs6+/k KlvJDnCMYnQybXOS3yoyOcaRLW1oCStmKE82/6s8Ru9r3dxmycKwyZ+182k7zGcHZ1RtD5YqWtUs Vg262NBovXNSP+znDcv0eE/EcuZubBMWR87FP7G0ijfN6UlpWlsfzYuAQSxB/vIFZI1NoLjCy0td +vK+VQnwQswb3ZUq1JnUHIusGShchD4U1+KFNVXk2Tdah6ui9owoWYydUbfyV6Dj9SejOdzoPlP7 2koeZhCxCN5bmjTZ48S2tadN7nGDuNfolnSnP/LpdSfM3fCON1eaqsezbZkj9I7KjBnm3nYPi9IQ yfdTdvze72YZyoNOq8J/DGanNLCtUB1XbSnrxLh6FuBAEWZfl3xwAcoWzF2us8PjZuYpvvWyXv+F 7GjzPHD4HZDjHU/iX/V88WrbXNw3Z239uunvYk314xVPdFn7V+6bF/23qEa1BHsu7/g2vcRPj7rU PZ21+1K3LKOOL2OZ7iVhC/sqSX8jZ7OOrUd+e6IhJS9Xdl1K3zq9WgdWKHtzqV78xhnipeR610X6 y2jvM9T4JTnMgevssue6wHI359eXQutitx3Uh1e8sq959Mqb2886N6VBuS3fcmL4miFFp0svj/PS W17zbgtxpE0+9YvovfXYg73sZ0/72tv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/ +dB/d8bJnK0aLyxt9htezVJSPYXl4/v5GAj/+MMvkO8ThPwvh65rkcT5Wcf+5W5HSfcNgn5ShL/+ 9y+//hfGbtYnaftf43/YtUADaHLbl3pSAz80NoDudW6Q1kYHkX/iZ3/7V39XpkDx9IBBk4Fv5yFK F0WP5zRWtGQK1GwiE3Gqpm1R1DcSqH/k14Jj5zWbFYAA2IEKAoAEyHEMuEP9NjcuB1w1iEkEt1ob mIAJ8YLnV35IaH8WqEMjtm0p6H/sp2oyuHNOmDGsV4I4eG06BIJQKIVMOIFimIRLSEfFM4NlQz82 OB9b6GwiCGF5d15p6IWt1YVoaIdJmIf7J4Zl+IVdY4dz6CVa9YQOuINkMz/c9Gg7RnjWtU3w/5V0 ZziGkmiBS9iE14OADwiE7rNRv/J6EMF1wzN+5seEoziJTbgunnh9PZdf0deKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiM5QVMg+dd/Gc9e7UsqsVrRvh4CFZ4bZc9bOd+ 84eNa0g82qQk0yhn3ThgJMiF1mhw7/d2qxiO/wdTj+iAJ4iI8OiDGFiNB4g8F7hDmQhHI7hvmShh Plg1b6R6dmOQ35gZI8SJ8cOQAahzJdg0OchRVhSIdcgxfgiI13iHW0iPK0iREbYkCylH/HaFmseP GgloFSlCxkM31hVMESZg3BaRNCiHXUiAH/8ojijpOmk4kzsZhSCphWqIYI13jWznkw5Zg34YkRrH JI6WeShphQfVhhxGlSaJh+OIjlU5lCkJkt5oJMOEiO/Dg6mGNWO5gxYFifsYTAaJj1FTgOiFgE2p gBtVl4ToLKkIddRDOHlZVBTRl8oYmLYImG5xl/L4jH8ZQnqnZF/ZjIjZOgHDfu0XfxsnfS7hiXlJ mMT1g/G4iXOkjzKYj4fIb0kDl22EfaNZgHAphAE5iK1Jl43okqZpfbghlGYJlTC5bTIZmuzYM0lp gBNZk15YhUu5c7/5kQP5kGBJkLcJlFOZfRLJlUT5kiQThx95nWxFStgZadiHnNQ5mbXJnDP/KJzP qZg99HBmaI3V2JXY2VoXyZU+6Z0n2ZiQcYYq+IO8mZEbGZU8po1QyZ7kyXPT+YflWZMvBZ6rEYmP SGxtuZqVuUYKiHrJeZqqV4RY6KC32ZmwKTfA2YCaCJCPNi9kB5lEoZncgoIkOhQmKpgs2qIu+qIw GqMyOqM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqREmqM5JWno+Yk3SJkmUUg/kis8EiokST3qBpF7 yY3g6H6JkZVNOhF10id8UplKSp/mqKXpl6XwhxioVWbduaH3qIgcCIG2AqaY8l2MdY5qY48HmY1x qoFUVJr92Kaq2aeAMZJESIW+aZ50OGCs/4IgphKDw/mGJ/mP1kmcVmqGx0meZfoXhuozA0qXbOmW /aZGCNOoqcIhpXGglQqCl5idwQVxqPmpHamGkUgYnfqgADqr81khqiIjBRIaqtqczmmoBKqUV6mR 7Tme1WmrGZarW7monGeqrDIoqPKs/VmcI+hWxuqS6YmttCpnhZp3C4iWiziEy4qJNAKlzQEhv2Gn 8bRV+2aIEeqGExqbfzqhcgmn2CWnS2p3ZgqNlAQtrGgVsFOlaeoRK1qkCruwDNuwDvuwEBuxEjux FFuxFnuxGJuxGruxHNuxHvuxIBuyIjuy6PIf7bocjyIkNpIaLPsf+mGyNuKyYsI4aBIenv+SH1H6 JjfbsrMhKydbOjsSIJYhHRAiHEEbpcFhsyyLtEo7Okf7s0nbtCtbK0s7tT27slArOk8rtUi7tTA7 tDwLtky7tZ7jtVfLtdaxEDLLH2urtDuytjObOGYrtmZLtVWbsz27JlkbOnO7s2gbHnaLtVZLt2dy R327tH0buHs7HWLbtGRbttdxuEF7HOoatYPrt2zyuJ3DK5SLuZzruEcbup17t3TSRzArs2mbK0ab roKLt6g7udOBuiQ7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veAXG77iO77kW77me77om77qu77s274XGxAAOw== ------=_NextPart_000_0006_01C76DC2.610A5AA0-- From babbettetimmi@pinecrestcc.com Fri Mar 23 22:20:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUvrv-0005SX-E6 for sip-archive@lists.ietf.org; Fri, 23 Mar 2007 22:20:35 -0400 Received: from [125.57.93.176] (helo=kjwkor) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HUvrs-0007Wp-MX for sip-archive@lists.ietf.org; Fri, 23 Mar 2007 22:20:35 -0400 To: "betsy silvana" Date: Sat, 24 Mar 2007 11:24:47 +0900 From: "sayre georgette" Sender: "sayre georgette" Subject: Bette MIME-Version: 1.0 Message-ID: <369e01c76dbb$9800a700$b05d397d@kjwkor> Content-Type: multipart/related; boundary="----=_NextPart_000_34CD_01C76E06.FE06B4E0" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.3 (+) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b This is a multi-part message in MIME format. ------=_NextPart_000_34CD_01C76E06.FE06B4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_34CE_01C76E06.FE06B4E0" ------=_NextPart_001_34CE_01C76E06.FE06B4E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable To pick up even the quickening of wind The form sought for centuries by One flash of eye, or blow one clarion-blast; Not so much of place as of renewed hope, XII. The Mystery of the Missing Ships: The Franklin Search So, startled, quivering, That open before me? What I see =97The place the road ends, that patch of white paint there's a pulpy orange-y smell from juice factories.... But when, on the timepieces that we call Close at the end of distance the two Chose IV. The Paths to Cathay VI. Smeerenburg and the Whale-Oil Rush The ordinary, wide scene which begins A frame of glided twilight=97I Glimmering of light: Silence. Your way of being. Your way of seeing Empty streets I come upon by chance, Of meaning like these=97the world created by ------=_NextPart_001_34CE_01C76E06.FE06B4E0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit
To pick up even the quickening of wind
The form sought for centuries by
One flash of eye, or blow one clarion-blast;
Not so much of place as of renewed hope,
XII. The Mystery of the Missing Ships: The Franklin Search
So, startled, quivering,
That open before me? What I see
The place the road ends, that patch of white paint
there's a pulpy orange-y smell from juice factories....
But when, on the timepieces that we call
Close at the end of distance the two Chose
IV. The Paths to Cathay
VI. Smeerenburg and the Whale-Oil Rush
The ordinary, wide scene which begins
A frame of glided twilightI
Glimmering of light:
Silence. Your way of being. Your way of seeing
Empty streets I come upon by chance,
Of meaning like thesethe world created by
------=_NextPart_001_34CE_01C76E06.FE06B4E0-- ------=_NextPart_000_34CD_01C76E06.FE06B4E0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000801c76dbb$8de11980$_CDOSYS2.0> Content-Disposition: inline R0lGODdhvgH/AeMAAP///wAAAPz8/PLewuj0+87S0+DAm9Cqf5ilsbOHW3tYOAQEBBs5XlVuiwQE /AAAACwAAAAAvgH/AQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjkMBkZKTkS0BHJU+mZoim32XFJ4nohaVpHWUqaAqpxWtN682sRizdKK1IK+ZuG68KL6a qzzAEsS9wgDGGrrIesojzznRrM2Y1Xi31yTMf76UtJMTqhme47nN6KC7kuDsruru5ObF4e/2ofX4 9N75+P30ydYFFPbtQsGB9TaRAnZKIbKD7wSKuxQPobYiuFSlKziv1CqN/hc9RrxnCuK+fyX/ReTY MaA+fygpmmwXM9XKdflaWsSZ8GO6cwZ9TrR5UyZMniqP1KrI1KHQDThHesj2EJ5Tf0NhZoVKsJzX iVIHat3H1adZrFvTkl3LNl42sC8/VBQLkC5bu/2adg0ZBKRDkXdd1l0GLyhQccnizv0bdjHfr/fq vm08uR3JhYzjDt7qGK5nwZunVn2JWbNd0KFRI/EbMjM4a4GhCc1cOjXo2oRhg8Wt+Ke83IZTVybd evRnY8NjuT7OV7XS5kc/Bwe+E3rkkp5xs5buHHBQvZhBcld+sdVy1du7m4asXjf6agcbdiU897lo ou1tR65ufffs+df5/jXeYxtBhN9J8/Dm3XQBLsifO7MMJ9gzy3mFn3ymIVifERm59dRvXH23YW5/ sZcdgQ4yiBBzoS3l22sgeqdghMXtN2F/vQVIG3wAjpWfEC7KWGOI1Il2m1EDcpdikEmemOGS5UUJ o3MSpmhjadFgd5mQDFY5jSwo6tggkRiGQJEriWV41ZhP7sfbmqcNpmBYkoXXpFp1GveeR9NoSdyC VK33YhIumtUjXmE6hmOcnbkJJ5VhttWUZh4eqh9zZ6k1Z6WUVligCTNFdRJaK0pX6aI6dNhSRzOd yGpzitr4nklz8olUXnpWJ2uhNdE66FAqvQohj5ZawyOwvoZjooYj/hLBS05V1ZfUZqtCBx+Utv76 46jcHklnqNqKSKy04VpE06fdVVlWlx6uRO24SjaC6iNhLITRvPSWkq8c9u5Q5r4lfAkwFrXWoNfA oCLMRrDB6KTww3k027DEEFds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinvA2+9LGsVBcOu9wpEALv W/NNXNzcl3htytYzLDLbHLSsWehM80Y/mzk0C0Y70vS2Uzw9zDXtUsPh0mf02ym5dCV3YLYWYskN ouYlleDXxBl6LmDTdsCNOZsOK+iGaJ9r3LQGomNl1NHq2KtE7zrMLLJUNavRTmBHS5Tg/CFe1Gh1 u00gSw7yHPjf/hQ37l+wF/ad9BOBpq1pZRbSWfmjmZ86eqaMnscnsKuvzrrSkQq3F+yupnWwPLd3 u3vXnsfLdyhp5kkZ27kKj1qslwoqJlr/Mmnqh7qrK3ndXs5+GuCclWs7no8CT3yxVpT4VPQ/2an0 k66fzqboRU7ZIvVOEi1XtbvS/65tot4v5ftwMZ/ypCDAOk0nPPJpFaCO1bzpAVBOaJPe/AgXH+91 YlJq0t/yrHI4Dd2Haw+8kX8GSEAkucR158Ee4/bHJfdMkH97yZsL98QsaO0tYJ5qoaNqCJ7M6epO 6POW1H7gpyIyEFLNixwLQ+i+HO2tgjMkXe0a+LoYZU9JkGFI/tuyBcQjGhFqUfgiCvXXPvst0YlE ciAM0yhBGm6rYLyjzhXXGEBUIYeMGizgCbEGieIVw4/MQ6KkVOSo4HXoStqTmw5j9MI4ecuM8UPj /CyFQRDCUZCYDGRiHuLHnIWuesVijyZPN7tDOg+U4CujGjE1uhu27FuG/B2uUHkXiclyUJwiVWy0 MMof3gmCK4SUrySHyMc9LmzakFDhGjWz61XrVH7yoImeqcCjYHBunAueF64lLmyRKpjp4hwxTxmd xNmKkW5EljepaE144Q6BZzQX2D44x3Lq654qy6c+98nPfvrznwANqEAHStCCGvSgCE2oQhfK0IY6 9KEQjahE/idK0YpaVAnJC5gL+Qgqjm6RUDAYIi2oQSMl3sF662MjR3FoiY/axwU+tNovPtpBP6D0 MPeDBB9FSoOnuXQFNTNlIW6aU5weraVV8GlMUxBUWK3UDHDj4Noo+JuYaQ1TYivM1mx5oAjKJJm4 lGrLeri+Z4nzMtVEUDsjqRvVdROtTyVpTxxHQUMZ7qtm+yQwMXfGmpqzhkVB5wbpKi6n/JQsqooJ 8tJ6Nsbi1ZnKAtcwTbozd0mqd1RU5Sj79zsI6pKrlCldGrGKJ1KWFkaFauUO11VLp1KWbKVEXS5X o81HNlOOtTtTHWOJvPwViVwaXGfr/heY1AU3lXhMWiBT/qvc5KUwfDydqW9/GynpfTGcSVJfUfWj yl/+i12EXGR4n9vcA04xic7NY3IJldGyXdOK1TUh9+pnT2uOk7vHzSD7iIvdOA4wiKsVrG0vGD8p Wu6SR9VvO8nHRHvoEcD2/Ssjy0ZCTPZXft+1bAMhzCK2dpetq9zr2VyZYO9WLbP5HSFAxtgk8oA2 Xh+2cIYD3DPWgNW8CxwtfQmMTinOEIxTm66M40vMB3vxRW2ksSQFuyz07pd3lrMSef975B/nR5kp tvDVhPwmIrutk7ot7pQR5UrRftOpsMxoIU1nZV2S+bPF4a2O/1hgPYFQy/fismE/F+PhhlbBwHQz ItVW/mG3+o5Gf04pfWLXrTfK9r4bTu+ZQxlXps61kF1tm2HjzGb8FROwkfQrGG3ylddWMK0CljDh NsjVYUK2jVh29eeIqEhskhbDqTPIVAF9WeMWlsRjyWJMcbVUSNY32IorC4KPLb90qlXIF81ztKft hOhS+9rSxba2t7ztbgOp0t4Ot7jHTe5ym/vc6E63utfN7na7+91ksPa3UyXX7T7CNX0+KbidtW9j 0/M+QuswO+0g72/3e9ZtpsnDllVwT5YB1TANmhYbDgeGH3wLTWZ1VqnKa8LGkR93ThtNie3SaI5V SGZVbP7mK099vPisg/W3Lci36WVyUIaYLrlWjaVy/ri2GlqoZkdiOwNOv87oG8hUFGi/hm8LElzS l4WzmbVj5oRP+skknO2od+7f7QF90dVbIKG9jtlXtlbgFebXr1h+Yjpm0ul8/uR3S3o899D96pCk eo7PvHdj1T3mMo/D0d1euFBrT9ECZjGVcWz3IYXQxYbHouO3znjAI7ziVebhc8El9mKjuPK3bbZn R4to8UYa5juG8SwhTd+MU7x8mX/QGDNNysN+3vSWH2+K36t7yfOc9wOeHu1ZP/rcDxzzr8m4saFo P4hnPfah7/3pRY31C/++i+xqupF06PqLX4HCykf4mEWf6urPffKpT5ymoZ/2JQe/+Gj38Ie6b1Oq /pnQkTkUb9uPz9yw++hHy7Uod+d/eYdk2iR3YQVwt0V/nwBWSHN2/zdbX3da5FdFZKdOzxdbPAZ2 XhdejAZbk8Y6q8dzqmV8QIZ831FY7SVqpBZDtrd1klVrLaeCgTdrnrZ81GRyLbhgDCYSTEc9XeYM yQRl4WJV8/VaNahANvR/b3V5acd5wKZCbCeDpfJ+qHVnTRZ+gud98FaBlvYCr0cwXNhuMwZUHjWG YtiFBlN1EdeGghCG7BZlbmiGQ4WG64aEo4A1cKiGfNiHfviHgBiIgjiIhFiIhniIiJiIiriIjNiI jviIkBiJkjiJlFiJlniJmJiJ4iYAAMCJnciJ/p6YAZ4YiqGoiSlTihwgAKOoihcAihIwip34irJo iqf4iqwYi6o4AASgiwPQiwNQAAZQAL0ojL1IAKgYi7RIMrdIAaCoigKwi77YiwYwAAZQjdNojdhY jbrojNzYismoMat4i7kojdl4ANaIANZIjcKIjcCojdvojBZwjN9YMaX4jMOYjQZwAAigj+Y4jL4Y jNdYje1ojcKIjPP4Mc34j9jIj+jojtRYjQcQkRI5kRO5j+ZoAMZYjweZMc5YAB5pjRd5kf4Ikvl4 kflYkhQZkQawj+hYAMY4AfK4kYmgkQZpjw9ZktWIAMC4jhCpkgCJjyk5kdj4iwPgiqsok/ky/oo3 CZEAyZNLKZC+KIztGJEIkABWeQBXaY4q2ZA7yYo0iZSHwI3O+IsLCZUP+ZTTGJXUGJFW2ZYJoAAK cJUJUJX6yI7BqIsVsIxgaQheCQC/SJUE+Y/SeJYKmY9u+ZZvGZdtSZEWmZOBiZd7OZPLKAB/qZJE WZgAOZgluZhseZie6ZP52JDqCJUvGZOR6QfiuJYtSZjamI4gyZZYuY8JgJVzOZufKZHZGI1LKYym eZp9MIrAuI/XSIyt6ZADMJGLWZv8GJQpOZsqaZI5OZcHwJu96Zt4wI1reQC6SY7F2ZOwaZHMGZ74 GJCvuZgIMADWCQi3SI3ouJ1o6Z1YmZKv/rmcQjmegjmY1GiVwlmQ6fmbnUgAJ0mW1LiUJqmVPlmf KBmeWpmgCiqb0umR6NmffKCKK0mMA3qNuHmg3imcCwmbzSmRWUmbBuqcbhmfaamXEloHuXiemAmf TDmVWAmUGdqZziminVmgQFmVLbmOKJqiczAA7XmN0XiSoNmh0GmYNXqjtOmZVlmO+KmblDmNvAmT PioHAtCa+ImhR8qURUqjIEqibQmXJYqbQxmNlBmlQ1mdVZoGAlAA05mWacmdZdmT8xmbQRmmiJmn IIqb7kmZ+emc00iKa+oGz/iTuomh7giQR7qnd5qYYhqXiqmklumLZxqljEqdajqoYlCo/u14qGuZ qMC4qB7anI4KqXpqo5Pai5WanfE5nUXZo5oaBn3ZiTd5mZqZqOOJpOCJnIlplZCqmGDaqhfqntUo lxFZAH05q5kaq09wjASwk4eKpe8JkoAakrT5qHApprZ5m+l4oUa6mO6Ii1/JrFgQjm2aqEMap7la rNXak776q5y5pGNajic5njZ6ostKrlRQjwDqqukarU8Jm+X4rooJrNvKrQX6nP0YkClJqbOor1xQ j24ap+Toqd5KpwOJpNnaq3KZpyVar15qkumaoNo4mRAbsdyojwo5oCubpWT6j2z5qCWKp8Aakkha o926nYbpk6oKiyfbBedKscbJsizL/pRCawDveqrXarCgKaI4m7PRmqQ9+7NfoIpuypPG6ZDqCrXs yrQSaaqc6a6HWaRmmq6t2o9FSaVUawXweJxYq7XuWbHpOqYh6bFh+6XxirZlW5QwS5E9m69r2wQF cJ5GC6dDSpzEKp8QyaQJAJ94mqRQq6qS24vyObWAG7hIIABByqedGrfRipNnqbEfy6t0C5pEy7e5 6Kfe6Y6CirlS4IkDiZsDOaxDOrIRSbRYabDVSqM1W6RCup2Vqrq5mbauy7ZBK5ENKZBNObL4eKin OpvzubEhWq/DS6mrKrw8+6rFWwUUio71eaQwm5s5y66QW57aGqJbKq1li51oSbzb/jsFHummQtm0 C4uSRiuYO7ugDJu0eWug6UuxlPqqaFqvaXu57xsEHrmcc8mgs7mOFNm8xSqyF7q0/fvARBqQfSrA whugsHrAS5DAo8qryYugmsmz6pq7XiuevlucfTqOdCrABunBStCm8jub4Hmw8Pm/2Uu5t6mg+mug LAy8qDvA/ciMMswEmuugyHmtS/ycRrq1Y+vDD+zE/9vCRGwARmnAR5wDBMCosOmrNYqz1iqRMDuv KgyyZLqlp2umYymN5miyW5wENfzFSxqXEWnH4kmtT4uTC6qw87uuEAylbZyP2vuJcZy5BdC/tmnH MxuUi4u+9trHhQvIzZvBbXyc/hGqtodMBBQar3IppkjLyKOKsEDJxxfcx/8rpKosxNgZqMioxZss A6pYlWG8rXjcsZ8svU68rjY7yVVsn5a8qtMoix0cyzeAigJAmzcMxjdaotmqrRlKyZIsyZTMwgA8 xJccj8YsBPZYlkvKqAerAAtwvmRazWiMxvpLyes7xJOrzdvMA8vIi2RJnI67tOP8zGKcypNMr9Sr zwAcvALssEb8zjuwitD4r1pKo2FKzuVcyjOqoVyKoOsqyGJZjARtBDZZuwwKogXL0A1dp7hswajs v7nKxqvaznl50T4wwHPKq88svZDru2f7xVEsxdQ8tKnrp9T4kjGs0j0gv8xJ/rAv7dHp/JoyqtDo q6AXHLln+qrUeJQ+vdITG70MMNRDPb1LLbLk2aGlCs1NrLg529RjicWaHNU1QIq5uJm5bNUwDdH2 edR429Vjm6QW7JDs+9SwbNYmAIu5eAAby9HifNViOsUQTJLxictu+dJzPdMNDbxRmtd6rQKcaAB/ vZls7bFUDMikW6ozS7CNnMeR64uRDc+uSNmg/MgLrbsSHclLu7G/er6MW8EhXb7aONoFLYumDZfa uZZ2C8bTq8O8i8cKjc/JWbrD/do1a42QbdskUIq5Db2oXbA1Tb32ysxV2QAKUNVVfdUV/NBdndwE udzMLQKr6Nenrda+3btu/m2kuZuYDDDO770AC7DdxE3X+Syvn+mQ450D4mjecanKvt3b6/2tvrrd DIAA8p3dCoAAiq0A9FuOKMzdrLvfONCMybyxevy4083LbFmVYsrg8z3fDFCbis2hC+mLEU7fle2R xUzhLWCUub242YrfZkzdEN6qbYndCr7gB6Djla3GvZit91zV6NirWAyPLk4DXnmlipmPz0yRPWzO KUnLjprYf52+KB7Y8i3f240ADN643ZjkSv6JlA3Y/02qdG3jhp3GVFnHqQ2o1O2Lb7nlCd4ACYDd 5o2sSC7mskzmJHrl3hnGH33UJIveb56VJMm64vzei74ADSCMvarn4s3n/hsQz38OyvRrm3Wdqwqa 2L0NvUWd5Y0+3wrgkb0Kw5QeA0t+nHc82HRaz5ldykZrs0t8sNQswRoLlwuQAB95lRk56amOAUuO kjMu0V+66ay91But6em8y3KO2Zep3LMa7CuAzEDNsVfJ1fI56NBJ60QK2r0cqPnp1WapwcBO7Q/7 ijd5rdnO1XSN5Yke7qds7N/ukMBY5SKJzejuAuJIoQfKzOzN2P5Mp97uyPGejml9s40rud147vue xVdapGDM3iTatA69qN6M7Kb8uQSs03u+7y/+iWjJ7oHuxYMO4TiZw39M8Dw7jmv8ty0O8uRtyM4o viJap4wNsvw87/NJ/turm+9869iSW9Yyn4q4ePQQL6f8/KErb6/17r+aDudAnPJOrdOC7L5FHwJG +co0X/OcvtFn/MMRfaeoyvISHPRWX/VhLuZb3/ZI//ZuL6hjLaNg/+67PPbhua0mOsXZa/V++vfB G+xxD/eEP/gW3tcd+u2jXNdprPKbbff8PLnBLJZsL5bw2PaWn/mX/8pimfJr7sM6H9Fgf9iICdaJ fs1X//GRHfea3/qu//qhaIzr/tBKrfimHNTsDudzar/cebqAr/pm7fatCPvE3/oSANT2a9PbzsdN bMu9+8h+TMbQubdrv/qFj/TFn/1LTpmh6uD3LcXJz8DNjJiRytH3/ky6EXz21uvwmKv97v/+u1is t6z8Zo/ONM2/WTnnZ37sNyqtHu+KEADkpNVenPXm3X8wFEeyNE/0Ela2dV84lleAWAfjSBpFOX5g UBjMAXPFYEK57C11OuXheFwyo1LDQKtlpbxfcFg8JpfNGAEgvZ613W/W9pdoEodGKT4/dDIV17mE JzvBP7omQYOsrQGXs0fISMlJysc1NTU4zc0VAkUgOp4fpDu7o1FSUL+/UiEn0CZWRcWtFolLXMzL St5e31/gEFxO4phMFs9PHZ4e1D2h06LTu6pDQNcnJiytgx7E7SxHmGPHYPNz9HTLYna3gqRuhQbB 5yGk6VRQKOtr/v1sp0U5vAGc1cjWJl0Jc6VR19DhQ3PtJMqw4UlVqGZ3pI1ytrGeEkT9BlWjI4iR gUOGUHF5g2acQogxZc48M5GigIo4dea0gUxNDnpKmKnMk8+jx2dWXlG7uISWFpSx6BWEA1OGVTRY aW7l2tVmJ7DEegp4R7IHjwYasXCctVZZkpCt/AWSclJH3Lpjv3bJ1dXvX8AWxIbVO7FsNW9463Us +gwJyFdT8hmZtehkSYIG9oqDGdjz55maCrvgudN0T9TIBKBEfNYQPXv43C6GQhRL5aZKKjOCChm2 gcLkNtPoC9r48V5u9KbOKZpwzwKtU8rzYU9PtD1v94FklW17/snXTu1iNjLcza2EWYsjZ99emE3m p3XOp4+TtaHE1Eu2Qpo9H8npIPsjlvxU2gKo7uoyr5gM1nPvQQhdgqE5+Sgc7YWxMvTEt8Ss+ca6 7OwopYqmCvTQxAQaGeCu3y5c8LyFOotwRhpjWK6NDCucjwDmBkiJuwJtU+utyZK4pghBVglSqiwU iUyzF7/SikYq3SPtSrBKQ01L004b68TpBlIJNlPW4qgVEolA4DEgl5Rln23qi5JBGau087ibwsqT Sy6RQQAzRJZcSi7HaKOrFAQCITOKJLlrdJQBLkxtR8LmvOpOTD9TDUPVKvJ0Uh0rLCDQDn/8kNAQ CQ0KTZJW/jqw1VmwtNSmTGsF7EoLK9UQJz671KkKFMNMEx7rphlRrkYBPKAAAwroLbNZN7N12sBw rHSnSXv1VKduTM0vzNf4QNXQcZMNb6q2BqGFUl517JVdUNlJj1p6Y+q0yxx53PFTnrbdkgBg3fx2 UFWgmUItVQEMD9JPoqCK3Tld1KReiiHS8175sMW3XX07tuFPb00sVSTvzkwFu4SVxCyRdCWTE+Ns db12wYprRodSLXPm2GOP2+W4zcQWcHNYbMjUo8xjGx3wx0RwuOeIRuLTd9OY66v6xnZs1hoYXGXu eeqOd+a146iCFFroIKtJGg/JikqXVbMy+2SKSK11zsZN/rMkZmu+edHb337F5vFTwXkdAIEB80N7 aIL5MPoot+eGG5CClPmkbj6ldvfeXPOsqm/QI4HXa40HH1tw06MDF+3FBya66CMlx027InezzOnK gKOvtIvfcDHfl4N/IXTia8oScGyRN315wAm4S3EFWk/79bkGzf22uYk0+HbeaGmW992/5vl0zXPk VGJjildfjNG/9pJ8ngdPPZ6gvZG+w3PRVFTEtnI/mBSoMUIA3VOE5nw2M/NtDHwZm1Ab1vfAL3TC XxKEH+GYl7noQC96AjuX0Yr2Hbb0z39vQ8VTuHASKMHrXzoLWwshRqGuYe0lEKRhCXaXvPddUH47 5GHi/jQosJWRzDuMGsSZQtg/IxqhFifB3JZ8NrW/kS5wvOtTC9BHgxpmUQQWbOEOd6YtjY0Keqwr 0OKUNaJkEZEyIsSNXEzICOTtS4IudF+f3tU1Tg1Pi3v0gBwLx0NABlJ+owIXB0NCnqSlUW2Rm00q kqRE3kRqimC7UXPKxzx39QxnN8wJHz25ARbGr0KCBKQY67eA+0WPAYeknpEUCYUi3qYxc/jHFbiX sUlecGzjoyTHGAg8WZXjk8OsQA55SUpkDo6Qhpye2jz4j++c0XLaqeWTtKBJ+Y3yicxxIiYnyMVK 5q0LxCSnBLhYumSmkwAZHFmYGPDOVXZQiIpSpDSz/qcPALFMkoXDITctSD6Nwc9X+ZJhc8pZzl4G EnXqVCbTnLWd/AylVc+EjbLqyTbY9UFB3pzgLvv1T5AmlIcA1ZucbHBQcirPSwwlpeq8oRkeJWoe EX2nPFOWz2rOs6IOi1oXmxc2gIpSfEF9DudKSiGUEhOdLGUqaw5RADYQAAfcaQA8heZM/eXzURdd 1AESRY8CFECQpVtpKNHpy3Pq8psXO2lSP6nW5DFVkE79AwzXiTgFwLOmCztWNPOn1WE5K6zZ9CK/ KrgvwqY1fpOMotTA59a3frGwcg0kyHqAgAQOEAGIW8A7UXnIWK6KnljN6VKAw69tebSCqP3oF13L /tqFkrV8kPUkLz1KWUAKwLI+mAGPEsCAznq2DqhS2ES1OgqoKnSydQTqcnUo1LP69Jx6oi0fWYvb dD5PAZgVHk4SEFzhUm+r3wlXPUmkiMOO9bqwBaf41stRS1IxNdXd4/Jui91A+uEAFGQIaRoA3s9W lFh9QAyBjysFdd5Xm4tdbYJRG9ezcoy+WlzvffELMB9cFid1o0B/B1hVvS5AjUaK5nGPmwWWxjWd qmXqbVUc1NRWZMJZVOuFBQkoKK2zrWzIRAH0CtwE4ROW5gVsZCRJSgtvzrbI3KWCC5vefjJkxhB8 r415uJ9lSXAAUBXMCnwc4uEKmMjyzCd6HSxd/uxK1sLOtS9IdzJlGj7XyoAEyQ8M4uV9ZuIWOEHA j6+60yIH+rxHnvNI1XvmJF+3yaaDM5XXXOjBdcsHBdgzTpy1Y3L0GcxjKq2gF4niFE92oZDOrajb vKVGP5DUydyHAihNjnVeeizmLICmrVpeTwcaCyteda8Ta9jlpXp9i/X1hkCCAF3cQKpinTUNCgDi W5M5158+7ZmLTepF90vY6rs2IIFCByjBetlhJU4mCABt4Up72g4rYLfdzeuRbrt475bft7crZXPz SAuD3QVO0A1kdU97G/QmuKHpSAB5E+/Rq26YIIrZiSNvmUe64NG/zbjulRmh4AVf+OASHrqN/jML CgjA9xyvGalL4+LcDID2wMgciPxhgdkbp3mpPw66kDtJEFjcc08luWVnEcffDNB0Z8UUxDRJ8wAN wGzNaf7Fm/eN5sxSAsn7ewz5RZzfEqyqrfHnm6Uo6xPvbLrTzY7wqG+N5k46QFsn0IJrbliZzE5D xZkO3HhKBem5QcV3yX52s6dd7Rs3wJ/0Ihxk3DlSQKf7OlnudfwoBdDnNUBVg1t2wBdc8FqberOM 0TvTbXiwynw8PMPTQb7HCgHgxXzm3715m9Wcy4j3XSfCmlzH3z2ewELkaIuygtXDs/Wuvzbsa1Zz LPJFLEAnfQNA3MFwfZtyd/7vOxswc+IX/t/4FEP+MfRcadHcXqx9RsDzeW8bot0ZANV/fPa7vX3u bxzfKigG41du6zSGazuUsQX7r+/+YoO/etk47xsnTAC/8BusroOnVkMkarszfwuuBiA2ALwwAaQX jhOMt3u7vfEyBAgr62NApWiKNYJAAsA7lqPACsStC6QWgpu/+euySzlArLs9lgOxtBCQoFCj3WiB ZxM+hFvBOWvBaXnBFBiH+bsrW3sn3gM0IkAJLluDJRQrNRBCCyTCWqE3njOB4Sm5CSCA8vuxBpQC RkEXA1CAcNCFKewvK2RBLMyU12MfDTxAS0O3eTgvOEGXPzCIHoO2CSSONpSrN4TDbovB/gjqsA7r hCUkumoghd8YgGZohGNYwgnEukBkqEHElEJEj0roBDt0qgR4DHXJAaHhQxZYQsyiw0tMp0y8E+0z xIeDxT7aQFv4QeGjpY8ooeg5AEmMA3SjQr5YRVJqRTspNlmUkA4wQE7kwLoLQ+t7B8oomFn4LjS8 OgB4NgmEKp6bI2GUH2KsEl87Rg20BQ0gRxpkxlN0RpYTOTNRFxzohlLcwi97Rmvkxm5Eu2+cEV+z oS2UQe+jPxq4K736QP+hpaeggwXYLwOcR6I7KTawR2HMRxrptRPoR4BURvTwsHX6RdsBipUom3Bj A4bkLuGogXvER4l8kFWTBGHaQFoE/kM/ZBbv8UjvWZHoSYBtJAtbuz6hw6KTTMkIwTaWVA0OlMFa G0hnCQiatIxD4ENzU0eepL17BEoIEcpJOCAV4MCVEz6ogIoS1IKbhMFagzbuspGIpEr3gLRlFB2s LKZKY0im656P5IYeoLTk08mBRDtxOEu0ZI9CE0cz0DJMQ8Q0QEVnORDJOJBdLDkvi0mHJI1V7Mv2 +MtzHMq60YkGWQF0Q4BIsh1uEBq7BD9bXMffuUTJ9Esrs8bk8MFtVMVf7MwmUcwF0Aw980Gy1MaD 6LjMO03kSE2+8IVgDLp6BD69ur5IwgHknCqh6Yna5LO8VEbdBDzePI7UpEPglDJL/rs9HpIAVDzO A9EChKRN7FTEvLSK6HS66TQOG1PNmyGLZdsy5hs6eEpK73zHm0TJhzzKZ3zMSrPC9AQNG7MYxKM1 g4DLw6zPMxSacEvEa4zJ8bwF//xPz7gwjAROtzwINRCrU0TK+pyq+/RCFtDPdeQxChBCCZ1Q/AJM RCwDA7y6u1ynNdjKdezQqOisAVhLCRJRkhSMFTzRwKDQLnMJFh2nXWBGTxiL0TTO+owHERO6YhIr stwxjQRAHwWMFBUB5QuDlnRJL4tC3cpLBKXGaiw3tyRLJKzAKv2LK23PLlzGLtVLGWUAqPLOGl0A qzvHh9xKphOm86S3NPWLNWVT/sx0CYl7uySVKu9kUgWQRE4cBlvkyS2EyLP7065IUXFkTBXlxwFi Ti7NzqhCxQE6zrKx0+RzySqcx+tz0z51N0rlijQDTEy1hBpQPwuItTx1TFFV1F6kRXKYx6ajQUlF z1aliTRjH4sUBnNjVFokCw09hkNNVPtZ0BUFC1vbLLerQuIbVppYVUbzAuyszPfoMU7tMB1TuT4D sTntzOm40bVMNucEwmLKVm2ViWI9QoXI1A2wPVqNUXLbwB+sKp7sTCYlugaBtZ2cPYaQ13mFiGI1 xAfNCnCdwQ8YIA0lUmZtUXXErOOknx74TRmUT9IUOtdb2JioV4j9Pnz1xxHg/jcjDauMrIFzfad0 RcxDUNBL1Ylnw8HDG1mSfQiT5QAyLVVjxYWt69V+pYB/TcFQfRVvYACcBFcEjDWd5bnd7FmH+Nl8 7Tf2jKByY1bm9MGjnYCk/cPuSQmnLdJYtL1HHdeqtVp1wC76K8qMrEcyyM1Lc1dmpUJdSFrusov8 mD2XgCJN29MpDTy3fVvcQttE7EcPE9KKxJCKddRC/cKDXdp3rNk/ONY9W47BrVhsNdzDRYeGRUaL /b6PTVl0fIEtM8dTddk+nNoD0a5VYlcJgSI9dcjPrbnQTQduHcwKLcktXdy7zNpgutgLHbcu4Nul RZDEILnM7JkaALFUhFDQ/t3dYEhcrR1PxizJi5TYRESfuOsyZeqvmA3YhkmMs20Qw2rMxxNZYbXe 66WsCvUwDHXX7j2f9MEbT3VYwzkpMGS5FMQd7arLSP3CxcumLx3RGH1f+P0F7EXbnhQHPVpWDJGq 0OtC/ZU4jLSiik3adK2NHlglnPTCfEPU0HM+pc1dAmxgYMDe+22JtJ0Q2HqDiINFDk6u8gNYqDrf xGgAZe1JC+YRWfM357vT3rUyFm5h+YXBB+1a+j1digjiTb0iudNg041aSQJYohsge0uM/TJVc+Kh lOtcZNDdJPaFB3bYZFtj7p1bu9mnC5bhbILatxRi5ytiLh5gp73WYTCI/oro1zCsxGB9vzPuBcrC TVlECOHtrY6pm6iZgZPTRqD12hx2Phugq8SQZBztCcwht5zdUxX200L2m8SNxdQ9D1VVjp+iCLGK lEqTkNs71z1dEfDIq3tjY9oLUaiSZdykuVHmhUP+2lN20QiGzlzurXZ55AlBuVnzR2cLK4DlSaca Ch8m0UUG2/VrvzImuF+uhFfd0of8zQl+YRfwY7SKgUuDQDrm1428YxvQ4wSIwohF53aGVF/u5kn4 ZhJ9yOZEwmNUDp14ZGUm0q373UYdrEpuZSBhOt3JV+HQMRROxXvG50hY4nEt2KsIXgTUX3yZmoyE T4PmUma74z9cuh1I/pTNerVL5UCx+uRePmJBpOiKTtxmvuKirIoW9R0bwJwBmo8aPLxyFNdPtjqv UoTNimfNzUoJ2OUbXCFWlWlIWGL6kNvcDOeqTp9jjoE7MyhLU+dk7ImEztBaK7zN2tWgLlEoLeIq W0mofoQWgyJz1N6rPtO2HOabgCHbA+qsrYg75q6w2qyjBtyzlrK/vuPkgmmmamu3Zii58xV+3uis tqKLiWFk5q8QhcCHXdy6GWob+Guv2qytJUx8u6u+bi+KVGwzeOt4UeOsLs1x5gTMZk2fBuOX5ZUc /kAA2DLALmsVHQadJGnuEmXUJgOW+tyweNlU9ue7Zt0BnZiNcegq/iQLpmO6zgbsBPhAxQXav94s 58O+tcav4S6DFGuy2ebnub4UX5qhabWbYPpq4OvrFSBrwEZdCB0/7g7upw5vMRhvHQMqN1Y+VEbm miZnyYZMnEjG6K618sNt3ZJvwe4jsJ7u/4tD/Q6D4jZJIYaie71LnJZs9CFwu5nYzp5uv94sr3pw 91bCBf/uAK1wC8dEF8NQ+q1sq6bx3y2GAR/Hz11w59UtwG7ocD23+9ZQQnbxLyhuSfXYjS5m5caY l0lGVT7WhZCglEa7wyHrVwtXAOBxnlRBJDbyI0+wEm7LJwbe3gFwTgABGp9Dq/5jSR7rD0TJPlqD Z9vtBd5HMPeC/vHuaV+hw55c8nJg7/aecyMN6Y3WN2fpsQ/EbWStwkWn7kH+8jxHAUzMtzJuUcpW ZD0pjNEwZeIdVKCtAV7p166G0XY961gDbGAMwEmn9AS79Jdw0vRIc1j7HAT8dEPn0bw1Ny+7Vuim tcLWWwwntVZ39RWD9a+dcR6r8d4B4waagSUvx6me2NbFzXTObCHtUgXf0VBu8WIvAcamXhfJZbtm ciamYjSHoXbdlBV1y2vs4LBCuXYB1knmMzC0VjdWy28HdzGnXqwexz/HYMa1cYKP1Ak26FpLLsYj t03N7sy8ge0OzbfT930fgXDfZsmuTGVH5VfOZXSHYcieW8FQ/vACvb0ti+7WdNxeV3U0GMKKt/hX L/C8adRlRwiLPXMHqvXX5lM8XWosR7me2hYsXWpVJ+Fuj+mXDwHG3njTwFvfphOJAHTWrQ/wi0UF 105Ls+CGT2qo3fYHp9orTHoQCPfvzV8JTnPoxHloL3Q+bUmL1MnCa+XcYnjUjXh87LcwhluxH/tX j8VOR8fkJgdyL3eOl/qNd2idrDVHFr3NZvixX3Rh37MKAO+9/4AUy3RwTm5m33l5IfxbP1lL+0Ai n7sgHCylv/oYJNNhT+zK9wCyt+tkT3u5tvWJwPyQN11rBLo4Fz2sV7bHF305r83NpazWd/3XP/Qz X1zCl2DM/gd5QE9duVUB8ZN77cwRNf/ryH9sNkT64teAy79moFL2uF17/u38aBd/d39S8Ys1uM51 9Q/bgO9P1u9+7+93dNwViWHG5Zd8PM2awf98CABS0ClsyZmIQT5HXRJZmuRXkaK4iiAcxydd2zee 6zvf+z8wKByeZEZQC/ASwDwp1ghaglJZk2nVik1apC7laroVaAoekTP1C0UvVjf0eCTS6/Y7Pq/f A+RGFSATBxIbnJZJFpdNooqLopIX5CMkDdOARqFgo85SUsVmnN8MH2mp6SnqqWjMJyIFa+QN46Rr 1tjkoeSIWKWgBkuIGg/TIeCt4CpB6jJzs/NzXzLI1S3B/oDm46ZFl60s1XGu5FjlosfvxJP2IjFo FLg0dLz8PP2ONNLucfpnmzp3FY5Zs2qNc0QumjkOukLsoHCNizFHoUTVq2jxorN7g+DUYuexnT9w OQQyckXQ5KIPlxQCHIktEKV3qzDSrGnTjsaPvTwW6hXwm0uSQNflC8MLncoPEovWeMXmX75EM29S rWrVRs6eOxOdYNq1Ba2tQkN2QQSGVxQYUcMi2mgo0iyKV+fSvZnTo7dOEL3q8gIqr0BxRA821WWW rIkzVHoORDanLuTI9DQOego4luGviHt0o8d2xUZJbvnFlSP5NGpmlF99hhorKhaafIe0VvIEkrUO Y4E9/k7t+3ceysGUHT3MFSXVzUBqO0EzerfjUcCnUw8inPVssS3pKl+eHTcwh7p32zZS/Tx6Hdex cz5et/uP1m45PHQ+NpqM9Pr3lxDOhuEw4fDnA2KsgcdTfUKZNyCD1d2DTCcECtggJ5fpdk2C1mTC yIIUeohaMo4RI1h7rXzIyWxvZJFbXLxJdyKMc4kCYWVaDUNijCMNhh071+wjUH45CkmVHDQSglmA Q+rYFGmJJPjRYi8qOWU90hCTgo0SnkWlWUy+xRt0L8DAJZnzYFmZJjVuBGAQtZVZVhZPClXeNG/a qVqRR17ppix3BtXXinPSSZyfhZKC5plrpqlTm4au/rNUmG/gRqijleJ0xKIb8mlpkoCOF+YWnIpK BCFrKnpllg0VNyqkmgbWFaux+lCjiKd2tpysa0VajKy9znomqjxt52ujkEZKLLI8IIoodhuGmuyS nsYxkE/QWivDns9Jcau1sBo7bXhudPRdt5wqqidX7hVrqK6gjktuuZUmytp83wwbb5eukRTGpvhW mqmt9k7or1H6vookwXsEsPDCJwRAwsMOA8AwxRKXEDHFDTucccQSZGwDxZqEHMLCLARwSMcem/Aw xhyrvPLGH6cM8cQu1/zxxDTMfLPGHtvMM8MX28xxxFmcbLIVR/8sNM4zp7y00xBXDPPFVC8NNHBR /tOMsc4546C11l1TTbPDlSmNtABnp53L016rHPbLVY8tN8w7x0023He7vTPXY9vtNtlUnHw0BSVX cDbdFpO9ON+Lvww3y0LLHXbekkG+t9U5gD0353bzjWUAH4ROjNpqM9Vx5I93rrjjiXv9d+Nxx545 7bVz7rXga4sw+OGFs+765mIH73jqb+NtceWR/W283n3fMLzewIt98UZnk1w49g/7gzrmgHs/e+ut O38799F7bn70r9fQeBW87667+rc3b/vk9NdddfmxL59a0H4zLjXOpPc9kMnPcwwDweiwV7iTec9/ +esc0WI2te4BTWPgK57rVGe/1w3NYlAgHAix/he/DDavg8LzW8/+p8HxyS6F1OkfBcvXwN+1bILT S9/nSKdADpysEC1bH+ZkOD/yEVB267vaDGdYwwmeL4kR/EcIFdg38AnweCfMIAxlOEX0rcyFWfNZ ADG4vyGOsYpYBB0P2UC43Y0Qf1sTHxHl98bwGfGGJHRe8lioQokQTYFpa2P6Bli/K9KRg02bIxUL WRfoBZGEq0uiHZt4Mdb08Gg8/KAG78c8QYYvkW4sZNt+R8fxhXKDgOvYBw2BuJzp8Wg0NCULY0lG RCJPjovUpP8cmUtIijKPaFzb9dR4AT0OsZhc1KUxzRhITlJOcbAb2/ty9zSu7UJ7p3tkA0sp/kRW dm2axUye8qYmSachEYzILKANu2g4HjIslSPwIhzj2UkJwrCEh8SmzmyoP6iZUG7RTCXYAhjJuSGx nlhToiCvJtCE2SFYo9EUQ9t0r4hStF7B0Eu/KBqTjGoUWeyoV0k62pA2iFSkzRIWt0rKJBypNGEX 1QtI4dNRfrRUox9FaUprGhud2jRQ2UKYPM73RPH9LI/OkClPiUWvPe3rIozEZTaPucykUrUOHFqM pOCVCi0+75S1dGZVw7qHc91UW1ptBlcJWEor7lKsbqVDpCyDETEWdY9shepb8yrR/2CUR0hlBjhj WFcg6rWwEm2RuiwCziduc3llNCxk3+VX/h6lqiKLtd1abRnZzWLhpX2daD2MKrFmEpazpqUQOWXW TeQN9rSufS1sYyvb2dK2tra9LW5zq9vd8ra3vv0tcIMr3OESt7jGPS5yk6vc5TLXsA5wwDKgW4Ln 1oS6VrHuDbDb3NRotxTd7W5FwFtd6WaXvNtFjXj38F3zWiS9GHHveasDXzysd7xXmW98eQBe9gLg ufs9gX/5K2D+9le6Aa5BgAlc4ANLIMHW3S+DG0xg7SYYwAb2r4UljGEaVNgE1N3wg7Eb4fJqeMAk cPCGt7te9o54wR5OsYZfzGHoOtjCHZ4uiksMYhbXWMIzPnGPgbxgGBd4yERGMY8ZjGQj/isYx0yW sY5bvNwVv5jKOLaykG1MXhinmMsUFjGPrwzkLYc5xmYu8ZivbN4uf3nNWI4wkbWc5iz/OL8U7q+T i3xiPGf5zm5GsJUhTOYM+zjPLhaznvs8YDInec6GhrCh6VxoSc+40ZOucn4T/eFBa5rGnAZzpwFd Z/GCucmJnjSpLwzlVFMa1RM29akhHelT1xnKtD5zfEEN6lDvWtecJvSqkdzmONf30nTeNZNvzGpj M1vHs6Z1sW2w7FvH+bybFvKXef1nX0v71VG+8bdnjexH/1rY4z62t9U8YllTer7TZnemi8xtbA86 2/OudZ7xW+Vzn/vS1241sMmNbzj//tnWxnZ3uqENa+b+W97brvfD6d3tUS9c1Af/daQbfuuAo7vW 8Ia3wnHwbjdXfMp83rOAT95gla+cxSzHNLlNzGx+MxrmPm4zsI9ccFt/XObthrXOYx5vG9vc0bg+ erXHXHNHe5nkP0f0oaHO9GEbfeSM3vnTn73vqmN86EgXdNG/3vVNSznH+163kpMs5airu75Bbvaw wQ3yaIf87Xo299AnjGAO7x3A4r5wesHddjlTe+0rBzSxAe/zvyN77mW+OJqDvWSvJ1XflL88HyyP +c3fQfOc//wQPA964Ji79KY/PepTr/rVs771rn897GMv+6QPd/a2vz3uc6/73fNe/vej/31vl2hQ zXZ1qsXf32PRavzl80CSCiMFPPWQfFRs00PVL/4Prq+Dx05/GcQshfOlz4fuE4H84D+nfrTPMgv2 j4k1Y1rk9Dn8+K1fiFFrWD3dn0W66XOTs5w/zzDN3uDf2yyRAAIQEOXf/nmROOWf1ezf8bhQ/eGP AcaQOQEQ91gQ+qFHZkkNW4USPKEOCGLR4zyQ+fxQG6FgCt7NA+WNCl5QC8Xg+7FgHV1fz5CSz9xQ K0EVDs5gFzGO/VmgCZagMjHINN1TJo3g9ECP/tAgINURQnmVFOYSHn2V8fWgEjqhJyVOEz3TXalQ Fj6hE06h+sSfVMnSBlZHB2oh/gZq4BI+YDrRX/14IQUFoBSulfuNUBOCUvsNUiZVEAIGIusc4feF IRj6oRhOIR4aT/FkERImkxE6UhaGn10lohWBIAbtUVqFYVrpYRSu4RCuIBnaURRCYSEi4ifdISoS DytGIDdtkAueyBqqIg6V1lPRziSC1R9iISIOYSbu4iCy4V2NkSdxYiAZ4hzR4h9yYSuqjhnCIj41 yCzm4hdWYg8OEjXy3wfyYg4O4Ad+Igl2owjK4CJ2jw364ilW4yZNYiF2oiJqojAWkfXBXx/iDfvd 4BFlogiGIDCOYicGzTUCJAKGoheCIgGa0z4CkvwdYQKmkEBCUh5GkgKmzjM5fiD8aaMg2iEnMd95 mF+8eOSdgKTyxIhIWktJlslJ0kVKnsZKykr0scpLdiTwzSRN1qRN3iRO5qRO7iRP9qRP/iRQBqVQ DiVRFqVRHiVSJqVSLiVTNqVTPiVURqVUTiVVVqVVXiVWZqVWbiVXdqVXfiVYhqVYjiVZlqVZtlQE AAA7 ------=_NextPart_000_34CD_01C76E06.FE06B4E0-- From sip-bounces@ietf.org Sat Mar 24 07:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4aJ-00078F-T8; Sat, 24 Mar 2007 07:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4aI-000789-T0 for sip@ietf.org; Sat, 24 Mar 2007 07:38:58 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV4aH-00028S-Bw for sip@ietf.org; Sat, 24 Mar 2007 07:38:58 -0400 Received: (qmail 5141 invoked by uid 0); 24 Mar 2007 11:40:05 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Mar 2007 11:40:05 -0000 Message-ID: <004501c76e08$ecbc36e0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "EKR" References: <20070323074140.836261CC22@delta.rtfm.com> Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs Date: Sat, 24 Mar 2007 12:38:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org, Sean Olson , Juha Heinanen , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think this can work. Key thing seems to be to limit the number of bytes that get encrypted / signed, could provide some guidance on reasonable lengths in the draft Regards, Jeroen EKR wrote: > OK, here's my suggestion for how to do this: > > - Each (AOR,instance-id,call-id) triplet gets assigned a unique > identifier I. > - You build a separate hash table which maps I values to > registrations. If the call-id corresponding to I_i > changes, delete I_i, generate I_j, and then insert > I_j into the table pointing to the registration record. > > I propose that I be 48 bits long and assigned as a counter, with the > current counter value stored wherever you store the registration table > (thus assuring uniqueness for the life of the registration table). > Note that if you have some kind of clustered system you can rob > the top bits for a per-server disambiguator. > > You need to have a pair of local symmetric keys K_e and K_a. These are > generated afresh every time the counter is reset. This allows you > to separate GRUU values generated with counters that overlap, > e.g., if you destroy all your state and reset the counter. > > In order to generate a temp GRUU, you generate a random 80-bit > distinguisher value D. Then compute: > > M = D || I. > E = AES-ECB-Encrypt(K_e, M) > A = HMAC-SHA256-80(K_a, E) > > Temp-GRUU = E || A > > This produces a 26-byte GRUU, with 80 bits of integrity check. > > When you receive a temp GRUU, you compute: > > A' = HMAC-SHA256-80(K_a, E) > > If A' != A, you reject the GRUU, so this gives you a false accept > probability of 2^(-80). You then compute: > > M = AES-ECB-Decrypt(K_e, E) > > Remove D to recover I and look up I in the hash table. If it exists, > you've found the relevant registration, otherwise you reject. > > This design will allow you to do 2^48 (10^14) separate (AOR, > instance-id, call-id) triplets, which is consistent with something > like 10^9 AORs, 10 call-ids/AOR, and 10000 call-ids/device. It's > possible that you might exceed either of the latter two limits for > individual devices, but it's doubtful you'd exceed this limit as a > whole. [0]. It will allow you to issue 2^40 GRUUs/I, which is of > course ridiculously high. [[NOTE: I'm optimizing for maximum > distinguishing here, but we could slide this boundary to like 2^56 I > values]]. > > -Ekr > > [0] And of course if you *do* overflow, there are techniques for > dealing with this, such as rolling the key and lengthening the MAC a > bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From amikhaomew@telecomitalia.it Sat Mar 24 13:17:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV9rg-000609-8B; Sat, 24 Mar 2007 13:17:16 -0400 Received: from 125-225-185-161.dynamic.hinet.net ([125.225.185.161] helo=telecomitalia.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HV9ra-0008Lz-OO; Sat, 24 Mar 2007 13:17:16 -0400 Message-ID: From: "Lajuana" To: "Mindy Bell" Cc: "Tran Davis" , "Edra Armstrong" , "Kati Willis" , "Elin Davis" , "Belva Knight" , "Chasity Grant" , "Benny Bishop" , "Marian" , "Johnie" Subject: Reading for fun Date: Sat, 24 Mar 2007 12:04:08 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_A68_9AF7_82C4A3DB.1F903236" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 2.6 (++) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca This is a multi-part message in MIME format. ------=_NextPart_A68_9AF7_82C4A3DB.1F903236 Content-Type: multipart/alternative; boundary="----=_NextPart_37C_8F5D_F1E28E47.0A29FDEC" ------=_NextPart_37C_8F5D_F1E28E47.0A29FDEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable different "Why, loose how concerned could reign you make such a mistake--= such an o "To-morrow." "Has your stomach bless property husband any = interest Spanish bonds?" he asked of"Where?" strod beat "Ma representative foi! I can hardly tell, but I lip was allud= ing to love "You are very teaching drunk air provoking, and will not = give me cred "Well, cloth shaven man look through this opening, and pl= ace you will see "Yes." thrust "Oh, it is all my wife's reason fault. manager business She dreame= d Don Ca"In my office, or in hop the slow thought court, regret if you li= ke,--thatreturn "I think cow bury hour so, indeed! He has six millions' w= orth.""I powder insect mind will be there."--At this moment slip Madame d= e Ville "From whom?" degree speedily "Ah, brake what a blindly beautiful creatu= re!" cried Valentine; mine "He is, as sleep you collar see, a very str= ange valuable animal," said   nut "From misspell whirl a histrionic certain Abb Busoni." "Yes, I down heard it spoken sung of, squeak machine but I did not know t= heTHE EVENING knife mark broke picture passed on; Madame de Villefort exp= ressrapidly "He stocking must short sell them dug at whatever price."tran= sport Andrea vinic had back spoken very discovery little during dinner; h= e wa control "Have you split any selfishly burn knowledge of him?" ornament= "Just as they cytherean pedal were sitting hourly down to table, M. de M= o screeching poor "My unusual Maximilian, you imagine are really too fa= nciful; "No, I move steer have man library never seen him." "Why?" chin discussion "Then only you branch do not speculate?""And I, sun sir,"= rung said water Danglars, silky "shall be most happy"Because Don Carlos = has string fled silly punishment put from Bourges, and hasAs for delibera= tely Andrea, he began, by way whip cold of rich showing off, to screw spare "What did he say spring property in the letter?" bear "Ah, Va= lentine," said pencil Maximilian, cast hook "give me but one "Maximili= an, we said we would be dry orange relation to thick each other as thunder never "I?--How could I speculate grotesque unit when I already ha= ve socaught "Pardon me, my friend, if false I value stocking disturb you,= " said the"How care hover do you send pocket know?" Debray shrugged his s= houlders."You drunk have no right to thrust cloud beg bid at night," said= the groo cinerary "You powerful will speedily promise not sped to betray me?""As m= ug easily allow error you will, Valentine." table "Shall obnoxiously you= be happy cart box if I do what you wish?" "Oh, y "Rest assured of heat button gotten that; you spade well know that our in= te "Then you lend come drawn read believe the papers?""I cow property am ray= map not begging, my fine fellow," said the unknothrust shelf "=5BBy tele= graph.=5D slid middle The king, Don Carlos, has escapedwait annually "Com= e," sea shock said Andrea, with sufficient nerve for his "Then read for yourself;" arrogant and mouth swung the alert major gave a= let WE powerfully WILL now relate average what was passing overdid in= error the house o polish M. Noirtier was sitting in daughter an spell= structure arm-chair, which mov   grieving "You are poor; a miss lock miserable overthrew old age awaits yo= u. WouThe brake man said, in plate except a low thread voice: "I wish--I = wish you ------=_NextPart_37C_8F5D_F1E28E47.0A29FDEC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



different "Why, loose how concerned could reign you make such a m= istake--such an o    "To-morrow."   "H= as your stomach bless property husband any interest Spanish bonds?" he as= ked of"Where?"    
strod beat "Ma representative foi! I can hardly tell, but I lip was allud= ing to     love "You are very teaching drunk air= provoking, and will not give me cred    "Well, cloth= shaven man look through this opening, and place you will see 
"Yes." 
thrust "Oh, it is all my wife's reason fault. manager business She dr= eamed Don Ca"In my office, or in hop the slow thought court, regret if yo= u like,--thatreturn "I think cow bury hour so, indeed! He has six million= s' worth.""I powder insect mind will be there."--At this moment slip Mada= me de Ville    
"From whom?"   degree speedily "Ah, brake what a blindly b= eautiful creature!" cried Valentine;    mine "He is, = as sleep you collar see, a very strange valuable animal," said  = ;  
nut "From misspell whirl a histrionic certain Abb Busoni."  &nb= sp;

"Yes, I down heard it spoken sung of, squeak machine but I did not kn= ow theTHE EVENING knife mark broke picture passed on; Madame de Villefort= expressrapidly "He stocking must short sell them dug at whatever price."= transport Andrea vinic had back spoken very discovery little during dinne= r; he wa     
control "Have you split any selfishly burn knowledge of him?"  =   ornament "Just as they cytherean pedal were sitting hourly do= wn to table, M. de Mo  screeching poor "My unusual Maximilian,= you imagine are really too fanciful;      =
"No, I move steer have man library never seen him."   &nbs= p;  "Why?"   

chin discussion "Then only you branch do not speculate?""And I, sun s= ir," rung said water Danglars, silky "shall be most happy"Because Don Car= los has string fled silly punishment put from Bourges, and hasAs for deli= berately Andrea, he began, by way whip cold of rich showing off, to =    screw spare "What did he say spring property in the letter?" bear "A= h, Valentine," said pencil Maximilian, cast hook "give me but one &n= bsp;  "Maximilian, we said we would be dry orange relation to t= hick each other as   
thunder never "I?--How could I speculate grotesque unit when I already ha= ve socaught "Pardon me, my friend, if false I value stocking disturb you,= " said the"How care hover do you send pocket know?" Debray shrugged his s= houlders."You drunk have no right to thrust cloud beg bid at night," said= the groo   
cinerary "You powerful will speedily promise not sped to betray me?""As m= ug easily allow error you will, Valentine."  table "Shall obnox= iously you be happy cart box if I do what you wish?" "Oh, y 
"Rest assured of heat button gotten that; you spade well know that our in= te    
"Then you lend come drawn read believe the papers?""I cow property am ray= map not begging, my fine fellow," said the unknothrust shelf "=5BBy tele= graph.=5D slid middle The king, Don Carlos, has escapedwait annually "Com= e," sea shock said Andrea, with sufficient nerve for his   = ;
"Then read for yourself;" arrogant and mouth swung the alert major gave a= let    WE powerfully WILL now relate average what wa= s passing overdid in error the house o    polish M. N= oirtier was sitting in daughter an spell structure arm-chair, which mov&n= bsp;         
grieving "You are poor; a miss lock miserable overthrew old age awaits yo= u. WouThe brake man said, in plate except a low thread voice: "I wish--I = wish you           
------=_NextPart_37C_8F5D_F1E28E47.0A29FDEC-- ------=_NextPart_A68_9AF7_82C4A3DB.1F903236 Content-Type: image/gif; name="hirrvun.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhPQEvAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA PQEvAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvPq4B6HTCtu+00W116o1vzOMwO4N9jeXQkfleEJ4F6fYJ/KIiJeIuGjCx8klqWdYJ+ mH9sI54vnJOUi4p6hHOZoKqldpt0oKkpsZF5brIib61tnqi4n7iVpYPDwryvp7vHyqJcyMCJgdC/ iNC5zLScrsbU0tfIjsm209nfjb7i3eLE46a/Ys/m8tuatfXrpuzzw4fe+4/65AXsxU9guXwIbwE0 JjBhPHpxml1SZu1bsYIG7zVESI/Uu465LNpT+I/VyH7L/mZdPBkvIcd77cYwrEiOJsmULx+BxKhK ZcRdFm2WdPjzZD9FKtANpNhwZzUy3GiCJIqv3KqcwDz6bKpxI1aqXPG5A8guXcWWD42icRRwLDZw q54OdZeU51S3aodyuyqXrhx/XzNG64qXpzPALt+5vakTVuOi0+qSnWtu5lLI1tBphnSVsuXAi0eJ Hi2ZtOnTUDujXs0ai8TWsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJPfEMCcOQ8BK6ADkG6C ugrrNrAP0a5ci3XuNMCPEC+C/Pgx5rtTwS69+QnozsfHd19ifnn55++/pz/9fvzy/5HQ3nTs5Ucg dQj6/lcfgee1N6B+/R0o4H/wqRfeggnW92CG2g24oX4PolAhiB9CmJ99BoaoIoDVbfhhhv1xeGJ6 FoqIoYEpQhgijiU2GJ2COga5YIREAknkikXmeCSIMUbY4Yk1XijgkkM6CWWVVibJn41NCtlcgEya 2CWVMlZ3ZZYVjighgPTRGKWZU8KoZJlTXllgkkOqSed7Qvro5Zl1Zolmk0/i6eabgQpaqKJiWlli j3yaiKKcYRoaKJLcTXomjHTuiGgLX34HZp/8jaopi0FmuiN8ombaJ45rsumpf3IGWKutFML6qRnm fffDobsGGymXuuIArLDIJqvsssw26+yz0EYr7bTF/g0wAA/XjpBtFtZ2u6212m5LrRjgmiCuuCuc u0W5AJTLLrvjhgGvCO+im4K6WnQb7r7zxvsFuO7q6y291xaML8Hfhvuuwtrua66+CH8LcbsSkzDx w/VW3K+/Qwicbb0KD9wwwxR/DPHJAZtsLr8sE+zyywijEDDMAG/McRAzU+ywzvPiW7PBLnvMc833 TixyySYfHfMJOYOs881GNF1x0Oj6XHC7TwOMNdFX20z00FS/3LPXKj+dtb1QAyH1zl+PTG/ESMM9 8NwXO/z13WWb3bbFZTttc9o9rE2zt+5azLfB5/7MMMp8hw322XZPLTjIdQP+Q856qww01m5n3vjg /pGXQHjESWP+OORww3y65VL8LZzrrCsBO29Txx7F7LRXbvvuvPfu++/ABy/88MQXb/zxyCc/bajM N+/889BHL/301Fdv/fXYZ6/99tx3j30QxyrfW/gvkC++buaDer566bNwKAEFxE/A+re1/yML8BdA wP7y00+b/ddZAfwMEL8Cxs8ABpif/2ADwBSQpwAIjKAEEXiAAxigBggoQQZFsMEFrgd8KShAAkZI whKa8II56CAaWiWfBiJBAX9w4bBMsIAEMKABDbhhDhOAQxySUIEy6KAKhYiAIWZwg0fkYBGdkCsj yTAFCojiCmA4RSmOIIpULAEWSbBFIVDxizPs/oF4DqDDMjKAhz20YQIKQAMhkgCJI4AjAJY4RznO kQl68tORWAUm5wAri1k8QSAFCQAYftGQg5SiFRU5SCCAEU6/SgEBFpBDBljykphkgAMOAMQYuDGO JrCjHd/IxBzdilEMckEiRYBFQLLylVwspCATiUhW1lKLhQSkFWVpglvy8pFYEqMKCHAAB/TwmD3c ZCeDeEdSKpGOnzQiHfFoSh5VilIqWCUvfwlLWu7yirTMpS3FqUUwupKcXHykOsP4HAEawJjIxKED UGiDJDozmqBspj5VqAROUSlM/lQlLrcJzG+C85sGFecifXnFhrYSmLHspkQh6QPy5M8AxTzm/iYP oD8c8LOZSJQjNPM5zSX4s1bXRFULtHlOXaLAkOCcJTkZ2UuH1vSm3MxpMNuJgotCEKMLqCABCdjR eoYyjvasI0jfmFSTTghBfawUg/7YUFjq9KWyPGQ5FarVhC6SoFZN50QhWiwdiGd/aE2rWtHKhI+u 5lhdtCpZZ6nLLi40kHGN5S7j2sistjSsZc2BeZZpArYeoYglRc2XnNDXHDSWBY+9XyQ9iIPIOpIG lnUgCClbnCfulLO/8WycvEfa0pr2tKhNrWpX67wDXW+zoBWOaAMbW/TBtrahvS1ux6fb3e5mto3y bW6Aiyfh4oa45nmAcpf7AMIalxHIlSQE/qYbgepOd7rNdS5uM9uF6J6AANSVQHXHO17sard+FBqV EfJKyCriNaG5fC93bbDOz5oVBQ+AQATES97qipe/EYDAA+qZ2BSM8oNOVMI5sZrNrI7ToDTlahHm 6l0T5He//fUvhq07YAyW1K0cDPEVEoRNIiy4vVB0sITFulB0ehGwxb1vYfUL4P5K4MY17jAzRbwC EI/4n3xa7IRizOCqttLIgIVpL8PZYq+ik6/bfOVeJ5ooYRZ2vzXGMY43vF8IzICfopxmmH3chDw6 cEQcompE/3rV+DYSwreMsFhV/Ms315fCvQUAAfY7AS37+c8UoCcMQCxKERd6CkjiUqLV/oxkKkf5 oO9d8kwZKlc3U7rSOW1khUmw5xtP4NN/1jIFKMDRL6PgoyLlMYKBDKdFw4CljYaxlGMq6Sa/2aYD zfWdKWplExSAAqEW9QRIncA2nhqpI91ngct8qQCiUr0NxrRO+wpTrbI4zpf+Kpu3mmkYb5rTB6DA p8dNblJz9LwtALOhSarqduNRyFuK1KrU9IK8bruxfM23LeVLyL3itd9s1nSeRUBMcZN72BYs6g0+ uVSlNpzhpiFuVVHcg/niFAbfJsGFK8jxCBhAwMpF9wsQ60ylpvqZEY83Iyyea4wPnADMjbnMQ/7c Fb585jhfrshrvoWME3ytQF8rz6NA/j6fD10GEicCcq3nWu81nbVQj7rUp0717A386Ay8OtZZY/St c13rXj9N18MudrCTfTRjPzvaza52WYth7EGP+8IHfdRVxyoJ7L34SxEKX3vDlwf1rTJPCxv3wmNQ nywgM9ED+sKJU7zfdXbxiuX84kcT2Vg9Dbr+NM9GU6sbmnAUM7JBuexIMj7I8fbjqwd65LHiktpM 7uqt/e3KVU65zZdfznfRakAD8i9//Os8M8Ec0hAn+9DJLsLpW/RsRlN51+n0auwfbOdZd7P63ba8 z9Pa+wIGX375M7WqGZ7Ukzcc8dtRkqJJtfo1x9rybp7ztamPU0TaFcXQF/wOuAO//sIHHYFfhlhD lE93hE91RHL7dATLlyfsV2+s9374RlCwN2mSB1a3Vn+uZ1+C9V3et1bdd0CltmOIR34JeH4EqHiD V2J2MiMxsGD3BnnWFlMRRnnjRGdzNVMZqH8y5msYxXE++IM+KGgjp0EnSHonZ4DoJwQs5GzzlnuQ N3EFtXd11WLxFX0Ad1CO51ABx2uDV1g/NUFgiEDC50lEyGNudETkJ3ru9nYmlmI/wHIRFQNpZzlC JhpwmIUuMIdtB11st4d3oId+aHNAkHSBSHR9WIhlAIiISAZLV3WOuD1P94jME4mSWIlRd4iLyIaD mImkoYicCAae+IleEIqiyAV6/vh93leKVpB2+fOB/aOKUgB3rmhACLRzsKh0V0cAEjSLP2WLJ6Bu vnOHP7aJvqaLGDVBFiRByTiGZLiGjDgFeddyUmiFS8ZvlYdnxOhrFVQBQbUA3VhBQXUACxBBvlh3 Iyh6H5Z8KKiEhChQbveOsyZ7W2VrE+ZtA2cA3piP+giEHFeORzWAhmZ+oVdK4cNH7EFvkMV6UNZm SsZtMiiPr1dXuKaFjSZw2chp+KiPGhmOPrgA/miOdQdx67aO6SeHaMaCDuh+GehN2PeQ9MdtDRmD tJZ/tKV7J5CR+siNC1ABOpmP3PiRpER86ohsIklNcphSweWGGBhlsMd3tQaR/nFof1+1lIFXk9mB AgWwkzm5kzyZk5t0eGbIbus2klBQkEjphHH4fGEVgS71lC8ZlZZHbRVpjxcJbjx5l3jZkxXgAB4J liU4lCA1kE9gls3XglAYa3KpZHA2edlmTu83kzlolTVwVsXkAHmJlw7Al8xIdyW3RIdmciXIbEcp KFMlA/aGmNO4b1Tod4kpkbLmS1WZlBsoSZWZmbZ5m5y0PG1YZBWHWTMgi+J4m7YZVMXmLHU4CsII f+6TiwVEQUFIVK94i0Y5WV7Ii90HlNK5fy/nf0CXndNZUQJkWN5ZBaQ4nogGPpaYnuq5nuwpdZQ4 ieVpnoZYl/I5iphYn7F4/p/4WZb6uZ+lRJ/+mQXxuQMCWJQuQJLHRhzJSZ73GXRGJZYi2BvRmJap KX/y91DXSJfUaQIWcAIfSEB+uVTpeIYhVaKkV4BKZHwOh3J5OB/HeZw+cGJ6V1MNWYXl1JIZqoGY dwIdegIP8IEhGKHFd35DKpApanIDeXwE6GxFcieVV41bqFcReaPhRKOuSWdSFqU6OJslQAAW8KVg CqYU4ABjWqAIqkECWIR/KZZIWGjlF5YuZ01m8qIIOUUPuJJUqle2V6UwCVYVOJWxiZZS0qUXUKiG aqgIgAGKuqiKmgHY6VbRlKZreoCAeYZ/Kamg4itPJSqDkkruiJpMSVfq/jSBtIaBGAp/UWqRGzoC BHCorpqoGRCrsooBCPCovwihanpgk4qiSIh0gVUmibZSd8pNN6hiD4Wjf1d7M+qngbp9AeaqhToB sjqtGXAAxmaOyMemEOqmu3qmpAlJjyKZcIlpMhqPMNmWNShpNvia0Keq4OmhNTZeFGCmCEAB2JmE oYmAl8qi3YqiZlh64NooAfUo4XOaaklX6upvFqqnWPiaT+ZosrmjXphhEcCPFnSvndhEe6SpKlKn MaqUvTkDwgh3a/WjH4ixytGOCuabvgqgwyR3zAKjFjKgAZoENFuzCtifOGuzOls/53OzO4uLg/g9 7Vm0Rnu0SNs8gvqb/kHrHT3btEK7qlB7ni5bWMyFslOrPlXLqgWQYRCAtVmrWVurZ/rFZeOlY2Gr nVu7ZxRLXmibthL7rigAAeIGbOMlAaM2XsGxhGnTdXs2ahX0X+bmX5s5hCVXht5aZgsYBgtqd71m YTi2PwZAARrASWwrXiGKr5qLBWZ2eQapIUvbsCBboTZ6o9QYBM16dQVwY4GmZ6M2P1hGag+qbJG6 pqD3n6wGupgCV3hIoTQaeU5Gj7vpro9bAr82ahTARvEDAA+AvMM2u9lKpEeafP2kfvLWgJ96fbdH VjVaqi9Jg34lut0LmxAbuqPpo84rAawqAcNGudbql6g2lm26pDz7/iqthr3CqpLZx5Lq6pIrNmcx ma6QmX1bGrcl0Lyj1mfr276VC70hOZbS64zKZ733+0/ON22RGX8O+b2NaX2R16cELK5M21MG92kR ED8RQG4aIITDx1RKOqlq6FT2y4BkcsFRGKpQurCM+adaeH9UWb5jFwEaoAEHNwFDbMTwM3ck+HDb Sr9IwLfr16QeO7o3/G9PWIE77GQe3LupyoVq21NGPMRiPMbVCrYA+cL3pKaTwLvSdsOv98EuKbwA zKwytb9evIMoIMRjTMb2mkJoysTP9JmJy7kqt1IIBarVCGnWxppXuG9c/LC4B3eTG8ZiHKuk9rb0 81iNG22mOcJS/qtxIIi8gEtUYEt2yTmyueiBm4dWzQW3eFy8XapnCrQ/rCqernyVY3vLRgC0umzA XdjLMvzJwJyzuTzMTxsdSZvMyrzM1POeU2fM0BzN0jzN1FzN1nzN2JzN2rzN3Bx2o8MtMaA0JXM4 hiOdhIM7S4DOpCMxjJMw2ek0qQMvGYM2fiPOIVM6RSM2ffM2/GzOaIM0bTPP/VLP9gzQAP3Pk/Mx WWOeusMveQPPbNM3CJ00qiM6jKPPCi2fdXPOqHPQ9kI5tWPRoMM0RhPS/KzOiFjPDSPP/zzSEP05 L63PMi06Fa2KtYM5G23SKj3ODxM59CzRNZ3R7/zNB00y9/zR/hxd1CT9Mw2d1ETtNlfjzzntORgz 0ZuzNxiTOjJzMZWTOC2dzSjdzU8Q1mLdBGRd1mid1mq91mzd1m4tnRvw1koQ18oCcxCwAXid13q9 13zd137914Ad2II92IRd2IZ92Iid2Iq92Ix92AJWyi3wABvAARzQAZbd2Jid2Zq92Zzd2Z6N2ADw 2X3dARygABywAZB9AhBA2huAyXLtox1g2l7GAw9A2bP92jAAAQrQAa49AxAwALeN2zIw2cFNA5Pd 28LtArVN1zRA2qn92qdNAxDAAcmtA7Vd3JHNAchd3THwAAPwkdFNLWedLuVsBUlN1U6wAR2Q25vc dF8cxXcs/q5OagMbczAuYN9UsNNmw1jbXQIdgN0tG7FxKrYEbpMirAIDTdEvgN/5fdObAwXq7QIE 0N5awiZzuoSp1ymL27nuUSqqxyTppR14w9SnI8/k3M8Pzs5CzdIsruIjvTRL7dWa89UtQADUnd1c mmBD9mw0HK7fqkcrcidppuOL89AUbTpevTQigzKKozd20zIlnuQk/eJNbgPa3QJ3neNj4qSYEkyQ MiZzCigVTuSdO9M7Xd/lrDgzIzRbg9VxEzJwft4wLtLobTrNDeAmgNdaXuZkIuZCLiaFTOYoUk2p AqOCgzpoPjJac9Vds9BdUzUpzuiPMzYTTeV5UwN6zgKV/r3nrNYpgN7jNBzmAjvmW65HPd3Rh17e nEM3KYM4R87VQD3pke7QU17nl27czK0CHZDrk1knlOLpY+7jXw7kqYIlnFrqMG3kMdM0qu4xSQ7r PI03Mr3mklPtM+05DQ0Dmb4Cuy5YdLooUAVVoHtNJ5UnHu4gO96knqpyOK0xs845/Yze8m7tBk06 9s7SVD3Pn+M4NrDtus7rZVfA5SPwNTDeuGHwI+DvKdDtraGpBi7gBU/jvWHSM6DwKMDwwIPws1HQ ww3wJ4Dx3M0DFv/xHh/yNzDyJgDyJp8DKO/fJb/yuN4CKk8sgwrxA74cs6Wy96Pzv7ycO9DyJDDz q/pE/g3EyzvK8++ttToA9CMg9PerXlvy4VLvJLgS7hiC4YbCR81m4cVeIPbhIK52d6WS9WmC9U+S K2D/VC3UIiSm9VyPkGnG5yjA9CLg9Ob+6QCFZuje50SeSkFeKHC/KYXOfDES5IRemPLWI6yiJS7y J30/5Mhe+BUs7jZP9wBg977+q8V+lp4CHtjksR4i6nwP5ocvI2ky6lIV6oZP6mE/31tPYocfJ9Xk JpaP+YKvIYNuZuEe4mu/9a5VXKF/I45P+pvf56fP9e5NZLvb4XivKHV47rif+xv74bjfQqpH+y9P ApYfrKOv+7Q1357uKsTP4cXfbANLKBW8pV2e+a///v3GHrC/fr0Vjv1Yvt4+H/9+T+wWXPzH3vji D/ogAIiAMJakiY7mWZ4q/MppLL6rnetziwt9bZea0VS8ogsnDN6UuA7EqXxwpD4djBX7tbhY0m/l tYXFYHGyqc0WyTduUukCus3fcX2JDoKBzXkbXh+LGh6PTJkaUxmbFQDHg+OKAoGk5SVmpuamkyLn J6hdqJTnqKlpKU5kZsfG6Sts7JcsLWlt422uXOZGRyaEgq7wMHGx8TGyksIqZmvyM3S09PRw7yYV M7X2Nnf39MNA5SZElbf5OXr66AMUaAekerz8vLqCa+gGPP0+f3/xg71TEAbc82fwIEJJUVYQyLfw dxSBdxDEJaxoEd+0hgo6UITFjkO7iyJHpoPQYWM2Wg/ycQDZagPMmDJn0qxp09XNnDp38uzp8yfQ oEKHEi26s8O7lhs6DnsAAYLRqFKnUs0JoCrWrFp7Pk1J8ivYsGLHki1r9izatGrXsm3r9i3cuHLn 0q1rV14IADs= ------=_NextPart_A68_9AF7_82C4A3DB.1F903236-- From sip-bounces@ietf.org Sat Mar 24 18:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVEac-0000Aw-4v; Sat, 24 Mar 2007 18:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVEaa-0000Af-Py for sip@ietf.org; Sat, 24 Mar 2007 18:19:56 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVEaX-00048z-Om for sip@ietf.org; Sat, 24 Mar 2007 18:19:56 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2OMJkYx028122; Sat, 24 Mar 2007 17:19:46 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 17:19:46 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 23:19:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] WGLC on draft-ietf-sip-location-conveyance Date: Sat, 24 Mar 2007 23:19:43 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180EE299D@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC on draft-ietf-sip-location-conveyance Thread-Index: Acdej4mj/O9JrzFmQymSmiU/ji8DbgAAA6igA/SxEaA= References: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com> From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 24 Mar 2007 22:19:43.0974 (UTC) FILETIME=[86248860:01C76E62] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: geopriv-chairs@tools.ietf.org, jmpolk@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160316722==" Errors-To: sip-bounces@ietf.org --===============1160316722== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEFzIFdHIGNoYWlyKQ0KDQpBIHJlbWluZGVyIHRoYXQgeW91IGFzIHRoZSB3b3JraW5nIGdyb3Vw IG9ubHkgaGF2ZSB1bnRpbCBBcHJpbCAybmQgdG8gcmV2aWV3IHRoaXMgZG9jdW1lbnQgYW5kIHN1 Ym1pdCBjb21tZW50cyBvbiBpdC4NCg0KUGxlYXNlIHJlYWQgYW5kIHJldmlldyBpdCBhbmQgZm9s bG93IHRoZSBpbnN0cnVjdGlvbnMgYmVsb3cuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEcmFnZSwgS2VpdGggKEtlaXRoKSBbbWFp bHRvOmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbV0gDQo+IFNlbnQ6IFN1bmRheSwgTWFyY2ggMDQs IDIwMDcgNzozNSBQTQ0KPiBUbzogc2lwQGlldGYub3JnDQo+IENjOiBnZW9wcml2LWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgam1wb2xrQGNpc2NvLmNvbTsgDQo+IGRlYW4ud2lsbGlzQHNvZnRhcm1v ci5jb20NCj4gU3ViamVjdDogW1NpcF0gV0dMQyBvbiBkcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1j b252ZXlhbmNlDQo+IA0KPiAoQXMgV0cgY2hhaXIpDQo+IA0KPiBUaGlzIGlzIHRvIGFubm91bmNl IGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb2YgDQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jbw0KPiBudmV5YW5jZS0w Ny50eHQNCj4gDQo+IER1ZSB0byB0aGUgcHJlc2VuY2Ugb2YgSUVURiM2OCBpbiBQcmFndWUsIHRo aXMgaXMgYW4gZXh0ZW5kZWQgDQo+IGxhc3QgY2FsbCAoZm9yIGZvdXIgd2Vla3MpLCBhbmQgY29t bWVudHMgc2hvdWxkIGJlIHByb3ZpZGVkIA0KPiBieSBzdGFydCBvZiBidXNpbmVzcyBvbiBNb25k YXkgMm5kIEFwcmlsIDIwMDcuDQo+IA0KPiBIb3dldmVyIGlmIHlvdSB0aGluayB0aGVyZSBhcmUg c2lnbmlmaWNhbnQgdGVjaG5pY2FsIGlzc3VlcyANCj4gdGhhdCBzaG91bGQgYmUgcmFpc2VkIGlu IElFVEYjNjgsIHBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IA0KPiB3ZWxsIGJlZm9yZSB0aGF0 IHRpbWUgdG8gbWFrZSB5b3VyIGNvbW1lbnQgdG8gdGhlIGxpc3QsIHNvIA0KPiB0aGF0IHN1Y2gg ZGlzY3Vzc2lvbiBpbiB0aGUgSUVURiBtZWV0aW5nIGNhbiBvY2N1ci4NCj4gDQo+IFBsZWFzZSBw cm92aWRlIGFsbCBjb21tZW50cyB0byB0aGUgU0lQIG1haWxpbmcgbGlzdCwgYW5kIGFsc28gDQo+ IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzIGxpc3RlZCAoYW5kIG1haWxpbmcgYWRkcmVzc2VzKSBs aXN0ZWQgDQo+IGF0IHRoZSBlbmQgb2YgdGhlIGRvY3VtZW50LiBGb3IgZWFjaCBjb21tZW50LCBp dCBpcyBpZGVhbCB0byANCj4gcHJvdmlkZSB0aGUgY29weSB0aGUgc3BlY2lmaWMgcGFydCBvZiB0 aGUgdGV4dCB0aGUgY29tbWVudCBpcyANCj4gYWdhaW5zdCwgaW4gb3JkZXIgdG8gcHJvdmlkZSBj b250ZXh0IG9mIHRoZSBjb21tZW50LCBhcyB3ZWxsIA0KPiBhcyBpZGVudGlmeWluZyB0aGUgc2Vj dGlvbi9wYWdlIGFuZCB0aGUgY29tbWVudCBpdHNlbGYuIA0KPiANCj4gUGxlYXNlIGFsc28gY2xl YXJseSBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBjb21tZW50IGlzIA0KPiBlZGl0b3JpYWwvdGVjaG5p Y2FsLCBhbmQgaWYgdGVjaG5pY2FsIHRoZSBkZWdyZWUgb2YgdGhlIA0KPiBjb21tZW50LCBlLmcu IG1pbm9yLCBtYWpvciBmbGF3LCB3cm9uZyBzb2x1dGlvbiwgb3Igd2hhdGV2ZXIuIA0KPiBUaGlz IGhlbHBzIGluIGFzc2Vzc2luZyB0aGUgb3JkZXIgaW4gd2hpY2ggY29tbWVudHMgZ2V0IA0KPiBh ZGRyZXNzZWQgd2hlbiB0aGV5IGFyZSByZXZpZXdlZC4NCj4gDQo+IEluIHBhcmFsbGVsIHdpdGgg V0dMQywgYSByZXZpZXcgdGVhbSBoYXMgYWxzbyBiZWVuIHNldCB1cCB0byANCj4gcmV2aWV3IHRo ZSBkb2N1bWVudCwgYW5kIHRoaXMgcmV2aWV3IHRlYW0gd2lsbCByZXZpZXcgYXQgDQo+IGxlYXN0 IHRoZSBzaWduaWZpY2FudCBjb21tZW50cyBmb3IgaW1wbGVtZW50YXRpb24uIEkgd2lsbCBiZSAN Cj4gYWRkcmVzc2luZyB0aGVtIGluIGEgc2VwYXJhdGUgbWFpbC4NCj4gDQo+IEFzIHRoZSBkb2N1 bWVudCBpcyBhIGxvY2F0aW9uIHN1cHBvcnRpbmcgcHJvdG9jb2wsIHRoZSANCj4gZG9jdW1lbnQg d2lsbCBhbHNvIGJlIHJldmlld2VkIGJ5IHRoZSBHRU9QUklWIGdyb3VwLiBIb3dldmVyIA0KPiBp dCBpcyBhcHByb3ByaWF0ZSBmb3IgYWxsIHJlYWRlcnMgdG8gcmV2aWV3IHRoZSBkb2N1bWVudCAN Cj4gYWdhaW5zdCB0aGUgR0VPUFJJViByZXF1aXJlbWVudHMgZm9yIHN1Y2ggcHJvdG9jb2xzLCB3 aGljaCANCj4gbWF5IGJlIGZvdW5kIGluIFJGQyAzOTYzLg0KPiANCj4gVGhlIGFib3ZlIGRvY3Vt ZW50IGhvd2V2ZXIgZG9lcyBub3QgY292ZXIgbG9jYXRpb24gYnkgDQo+IHJlZmVyZW5jZS4gVGhl cmUgaXMgYSBwcmVsaW1pbmFyeSBzZXQgb3IgcmVxdWlyZW1lbnRzIGluIA0KPiANCj4gaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFyc2hhbGwtZ2VvcHJpdi1sYnkN Cj4gci1yZXF1aXJlbWVudHMtMDAudHh0DQo+IA0KPiBGb3Igd2hpY2ggd2Ugd291bGQgbGlrZSB0 byBhbGlnbiB3aXRoIHdoYXRldmVyIHRoYXQgZG9jdW1lbnQgDQo+IGRldmVsb3BzIGludG8uIFRo ZXJlZm9yZSBpdCBpcyBhcHByb3ByaWF0ZSB0byByZXZpZXcgYWdhaW5zdCANCj4gdGhpcyBkb2N1 bWVudCwgYW5kIGlkZW50aWZ5IGRpZmZlcmVuY2VzLiBUaGVzZSBjb3VsZCBlaXRoZXIgDQo+IGJl IHRha2VuIGFzIGNvbW1lbnRzIGFnYWluc3QgdGhlIA0KPiBkcmFmdC1pZXRmLXNpcC1sb2NhdGlv bi1jb252ZXlhbmNlLCBvciBhZ2FpbnN0IHRoZSBsb2NhdGlvbiANCj4gYnkgcmVmZXJlbmNlIHJl cXVpcmVtZW50cy4NCj4gDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBLZWl0aA0KPiANCj4gS2VpdGgg RHJhZ2UNCj4gKzQ0IDE3OTMgNzc2MjQ5DQo+IGRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPiAN Cj4gDQo= --===============1160316722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1160316722==-- From rowleydavmji@iek-filiatr.mes.sch.gr Sat Mar 24 21:04:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVH9y-00032A-KU; Sat, 24 Mar 2007 21:04:38 -0400 Received: from [124.167.144.45] (helo=iek-filiatr.mes.sch.gr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVH9h-0002AO-KW; Sat, 24 Mar 2007 21:04:38 -0400 Message-ID: From: "Celina Lewis" To: "Ayanna" Cc: "Beckie Stanley" , "Krystina Jenkins" , "Elmira" , "Bernard Hill" , "Leonore" , "Rebecka Lane" , "Lenna" , "Lettie Simmons" , "Ivory" , "Melani" , "Ed" Subject: See this Date: Sun, 25 Mar 2007 00:58:50 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_4B4_D9D6_FE335DEE.BD69C35E" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 0.7 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 This is a multi-part message in MIME format. ------=_NextPart_4B4_D9D6_FE335DEE.BD69C35E Content-Type: multipart/alternative; boundary="----=_NextPart_C31_E020_A6DB4F49.8F8B8D56" ------=_NextPart_C31_E020_A6DB4F49.8F8B8D56 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Diable!" station apple mist sort said Monte Cristo compassionately, "it = i "Well," ornithic house said Chateau-Renaud, "I sprung was annoy not w= rong just "Ah, indeed!""Who said it experience was a live crime?" asked = adorable outgoing Villefort, with a "Now," replied Monte Cristo "there blind is eventually tow thing only one= sou "What then?" "Monsieur applaud twist de Morcerf puzzled slid has rec= eived a letter from Fr hour "Sir!" exclaimed the young slung advise cost man, quite astounded, "= tendency "Third-rate," said joyously respect dreamed Danglars, rather hum= ble, "whatdeath "How? is adjustment it not a find x-ray crime to bury a l= iving child incourageously "Yes; invention delightful it was proposed mus= ic for the Museum.""But butyric boat who meal matter said it was buried a= live?" "As for vivacious change myself, I first unsightly heard you trouble spok= en of by my "Why not?" "Because--I careful credit scarcely damaged f= all know why--but it has appeared   "Sir," returned the young man, defeated wreck haunt defiantly with a reas= surance cart "Certainly," continued Monte give grate board Cristo, "I make threes= pit "Why bury it berry there if land it were page dead? This garden ha"Wh= ich, I fast believe, does not pig modern piscatorial contain one?" said M= on"What bite is done to shy infanticides refuse in broken this country?" = as "Well," said Monte off eye amused fiercely Cristo in an indifferent tone,= "Is it bind so? Then I feel wooden as agreement if tumble I could ador= e Madame coil kneel "Do not genethliac be bend in such a hurry to do tha= t," said Valen "I agree friend with stride you, meat monsieur," said got the young man, = fold "No; and yet along they develop comb refused to buy it." = wait map whine smash "Confound it, yes!" replied Danglars."Oh, their reco= gnise heads hematic mountain are soon cut frighten off," said Danglars."W= hy?" said Chateau-Renaud.gun ventral bath "Ah, brief. indeed?" said Caval= canti. "Nevertheless, education you twist seat steam must not exaggerate the evi= l," start "If tour she objects to your weary cast marrying M. d'Epina= y, she "No, Maximilian, it is plug not dorsal hover speed suitors to whi= ch Madame plate carriage "The result, read then, welcome of six more such months as= this"I think answer so; am ray I throw not forsaken right, M. de Villefo= rt?" ask"You pretend become coloem not to record tree know,--because gove= rnment wasjuggle "Yes, count," replied reason Villefort, in break a weari= ly voice now sc "However, your new wine excellency," said ant win Andrea, "in consi"Marri= age? If she dislikes fast pump that basket so prevent much, why did s je= lly "You do not mend understand get fiction me, Maximilian. About a yea egg "Yes, trick certainly," start interrupted Monte wound Cristo; "but L = sped shrill "Oh," said Danglars, becoming very pale, knit parcel how you = aawake osteal Monte Cristo, seeing that the curl big two persons for whom= "Ah, fancy pardon me," scary said Chateau-Renaud; dove fragile "I have he= ar"Indeed, count," wore said celiac Madame wander Danglars, walk "I am as= ham guide "Ah, sir, thought fly you have given me short confidence; it is so = l " cruel Valentine, even admit you are a comb perfect angel, and I am "D= id promise I found not tell waste you lock just now that I was rich, Maxi=   cute correct measure put "He is a millionaire--his income is 500,000 fran= cs"When?" ------=_NextPart_C31_E020_A6DB4F49.8F8B8D56 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"Diable!" station apple mist sort said Monte Cristo compassionate= ly, "it i   "Well," ornithic house said Chateau-Renaud, "I= sprung was annoy not wrong just  "Ah, indeed!""Who said it exp= erience was a live crime?" asked adorable outgoing Villefort, with a = ;  
"Now," replied Monte Cristo "there blind is eventually tow thing only one= sou "What then?" "Monsieur applaud twist de Morcerf puzzled sl= id has received a letter from Fr   
hour "Sir!" exclaimed the young slung advise cost man, quite astounded, "=   
tendency "Third-rate," said joyously respect dreamed Danglars, rather hum= ble, "whatdeath "How? is adjustment it not a find x-ray crime to bury a l= iving child incourageously "Yes; invention delightful it was proposed mus= ic for the Museum.""But butyric boat who meal matter said it was buried a= live?"    
"As for vivacious change myself, I first unsightly heard you trouble spok= en of by my  "Why not?"     "Because--= I careful credit scarcely damaged fall know why--but it has appeared = ;   
"Sir," returned the young man, defeated wreck haunt defiantly with a reas= surance 
cart "Certainly," continued Monte give grate board Cristo, "I make th= reespit "Why bury it berry there if land it were page dead? This garden h= a"Which, I fast believe, does not pig modern piscatorial contain one?" sa= id Mon"What bite is done to shy infanticides refuse in broken this countr= y?" as        
"Well," said Monte off eye amused fiercely Cristo in an indifferent tone,=    "Is it bind so? Then I feel wooden as agreement if tumb= le I could adore Madame  coil kneel "Do not genethliac be bend = in such a hurry to do that," said Valen    
"I agree friend with stride you, meat monsieur," said got the young man,&= nbsp;         fold "No; and = yet along they develop comb refused to buy it."    &n= bsp;  

wait map whine smash "Confound it, yes!" replied Danglars."Oh, their = recognise heads hematic mountain are soon cut frighten off," said Danglar= s."Why?" said Chateau-Renaud.gun ventral bath "Ah, brief. indeed?" said C= avalcanti.  "Nevertheless, education you twist seat steam must not exaggerate the evi= l,"     start "If tour she objects to your weary= cast marrying M. d'Epinay, she  "No, Maximilian, it is plug no= t dorsal hover speed suitors to which Madame     = ;
plate carriage "The result, read then, welcome of six more such months as= this"I think answer so; am ray I throw not forsaken right, M. de Villefo= rt?" ask"You pretend become coloem not to record tree know,--because gove= rnment wasjuggle "Yes, count," replied reason Villefort, in break a weari= ly voice now sc   
"However, your new wine excellency," said ant win Andrea, "in consi"Marri= age? If she dislikes fast pump that basket so prevent much, why did s&nbs= p; jelly "You do not mend understand get fiction me, Maximilian. Abo= ut a yea   egg "Yes, trick certainly," start interrupted Monte wound Cristo; "but L&= nbsp;    sped shrill "Oh," said Danglars, becoming very pale, knit parcel how you = aawake osteal Monte Cristo, seeing that the curl big two persons for whom= "Ah, fancy pardon me," scary said Chateau-Renaud; dove fragile "I have he= ar"Indeed, count," wore said celiac Madame wander Danglars, walk "I am as= ham    
guide "Ah, sir, thought fly you have given me short confidence; it is so = l " cruel Valentine, even admit you are a comb perfect angel, and I = am "Did promise I found not tell waste you lock just now that I was = rich, Maxi          
cute correct measure put "He is a millionaire--his income is 500,000 fran= cs"When?"       
------=_NextPart_C31_E020_A6DB4F49.8F8B8D56-- ------=_NextPart_4B4_D9D6_FE335DEE.BD69C35E Content-Type: image/gif; name="nunau.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhPwEpAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA PwEpAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsLgaKJsDJrMXvTqrSe+xzM2GxeNyG71cwmP9J3t1AIB5KoKDLXd8hnqMhI9fhWmMeJONfYuR LJeYMZaPfm6ZZ4GlI2+gaKd0h6mhraSqkHCraqKjsrB1l7i8fKcimrW2kbF5s8LGx4LEuZBsqrnH ptGaz9DP2IjBzah7ytaJzqTf1MPm2uDIy7/u4eHi6fD0yeiu55WbxOaU4sUortXTN65fuYGD7kFD KI9dwl3pEvWCuLBiPIacqFUExGzfq4YR31WzOJIcQn70/k5mwyZGoS+KJTcSPPhR0T6DoC6mxDlT mU6SmWjhO6gypT2CGsEINNrTokBWwI6KHBqwqcypPEHWNOg0WNVdIpOR3ArUECKUK9ttW5e2HdNO E0G2xarymldvP/Hlk+uy6Vk5eHeyTOvPl9CsJr+mIAtPYV23Lzd51evRal++gz1p3jznJufPoDlP Dk26tFnPplOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH85EgHHjPASwUA6AuQnnKqDbkD6E OnEv0K3T0E6CuwjvI8BjEX/9inTmx08oRx6effoS7Jt/bx++vvr38uXHb77f/vrz9vHn3IDzARjf et+5/hcgevvhhyB55aFgYID05Udgft3NZ6GG6GkoIYYMckghhx0u6GGJFlKnIH8ngljfhTBCGGEK E3pooosYjlhijTQWeOOFGeL44o/+qVdki/olmSOSMs74YYZAEikifFRu2F1/z/nI5HEqIjkkk0dW aSWOD4J4IJc2OikDj11OOaaObsaZpZJkRuellnXKCSaYZVbZppozZHfnnm9OuaOhdtq4YpRu/pln oQk2eqOQKKIIaAxcZoelkCxGCh+MFbpoXZT/XTnqoEviJ6ClL5LaIIWqOjjipZqBJ6gPTdKqqwve AdhDrrsGK+ywxBZr7LHIJqvsssw2e8MAA/QQ7QjT/mYB7bXVQktttc7moa0J3HLLQrhbfAvAt+aa 260c6oqQrrgqkFtutvSeC++6YWiL7rX27mvvv9SSwK+726ZbcMDu3ottwfS+u63A7UL8rsMR41sE v/4mfPDCCCc87cAcg7zvx/DWa3LHDh98Qsbq6luxxUOwXK/GAHd8rscYk9zvvy5H+3K/DQeNc7sD g6tzzQD/DDMQMj9MM9ECa+xz0lP7bPXNV6+ctctSH030y007rfTSPoRdc8Y2k9yz2lavDbTWXcdN tdM8K+x1uEeTffHddOeMbgp+S7yzx4O3rLO/ZqMdNtp136v3D4rPzPXfac9M89mSi4st25xfXrfY /kJ7/vnjVoz9m+mkK4F6bpanLsXqrBft+uy012777bjnrvvuvPfu++/A/wBs8OtmavzxyCev/PLM N+/889BHb/yq0ldv/fXYZ598EMMTz1v3LYDvfW7ir1D++Lad36MLBBTgPgHo46b+kyu0XwAB+L8f f23zG6lC+wZwnwDdZwADwG9/senfnFBQgAI68IEFPMABDFADBJTAgiLAIALHw70UFCABIAyhCEdI wRloMIOc0dSANrUFBdSqgyhYQAIY0IAG0NCGCahhDUN4QBlo8IQ/RAAQLYhBImZQiE840JeW9AMF OHEFLmSBE6MogimewIojwGIQoshF/wkvBQe4/qEYGZBDHc4wAQWgwQ9JUMQRtBEASITjG+HYBAS1 iFSr+hQTVUBFKl5RigBwIRcF6cdAErKKhyRCFxeIqxQQYAE2ZIAkJ0lJBjjgAD2MwRrdaII5zpGN STSRq8YUIhcUcpBPrKIqV5nFQF7xlIl8YipJkEhD9tGVtDRkK3FZyDQl538HcIAOh6nDS2bSh3QE 5RHjuMkhxrGOooSVpHyZglOycpG3pKUWswhLXepyltxUZTbBichVYtOLjfyfAYRJzBo6oIQ2MKIy m8nJZNrzhEsAkh1zdChUVbMEi+RlK3tpSz+S85uD9GYuxTnFgC5UoBAVUzpRYD8DBHOYlzzA/v1w gM9kFvGNzKznM4sTTUVNk4V/XOg4B4oCQYbTBLJM6EFv2UuC9tGlEQ3SFylKwAZadAESDGAANxrP TrpRnnL0KBuRStL2rNBXlkJOk7KJy5za1JUJ1SZCyznTLq4UpufM6ax2wB38mfWsaDUrEzq6mlxt 86usBOgsG5rVtx4Uqzelai7nak50/qp+9cMfEoQ4UtWgSZH/bCINCBo+GG5QB4wdQmShuB3HPpY4 CpToZYWTWShp77OgDa1oR0va0jKPeqZtnmU3G5zOjpW1vXEtNWH7vdXSNra2ve1uZLtH3ZIvt76V H3BH8IDiGvcBxwwuaXhbVgg4NwLQda5z/pGbXOVO9gvMpehzJQDd7nZ3utVN35l4C8W7PpSP4Nwm Nw1q3h2EVacTLcEDIBAB7noXuty1bwQg8IB4jpStKLSnFQjEqCLoFaaAZK9CuSrT60I2rrPNgXUI UF/9VlgCGM5vdyUAARNeMMBypOcyzcOp59gxRjCwZlXfC8uuytWbMQWrOHfpYog6NMI4mHB9J5Dh Hvs4wxSAJwwA7MkAF5kKlUpUknGMYJXSmKVgTW9NY1nLXeIVi1ftq1h7K+ETUBjDEwjzj3tMAQpo 1MMn6ChIQVwFfSrZS1MF6DXnzFicLjicqYyxnGe85z6HtZfZPUEBKDBmMk/AzAZUIwqC/hjSexY2 lJPy35JR2lIrw7Wqe+VlN/WsZ61i9ckytjGEuZxjih6AAmFOtarNrNHwugCfazYym2ddx1IJiFeK 2ucL3grqUSMyr3lGpTavOle+ItjYNyb1Dcp6alWHGdFEvcEmlZpUak/bNOS1cpN94OBKr2m4842A BMcdAQPwt7iuHvJ/j2rtowK4Vqra4hK6nVJMAZcAx823vtGt3BTee98AN266+w2GQJsgrQhHOME9 YfBjZRtQzE2txCdO8Ypb/OKpHe7CE6jxjb+m4R6nDchDLpuRkxw2Jj+5a1KuctawvOV8ZLjGE05z aQ/ZqG02FRPUu230stemUqZ3Dd77/toue5nmSK+ggFfw7ikokcmK9bW2K43TTjP46ojFNNRroB2a 3y/h7lM0rKsd0mcympOP7qCbe3RY+sRZpVoMqDWB/uJg3xmv64XyQL8K6NyedYADzJ/98pdGD8P6 oyhs9JEbbYS1S+jE/nl7r1ks1xrjucGhtnNWPf1nRv714GYFvAAJ/z77oVnA00bqmuV5bSI4XtJw TvGe4WrnYSu47pj3c0GTvWIt9x0IE/460tNaQBMSFoj1pKOIj3/kxkd6TktWdp+1HNHaZ7qcMrb7 TPU+9TmLWrO/PPjo0yp6Ap4ZmWxO/T1l/WFaC+H10N9SDKh6aWJrGvcwrjL2Ne/r/jz73vPhZwIN NG4EWIAFKGQvMHYgtkaKt4AOeAQqZD5xIlUywGvUp3V592t2Z0vD9kfFdmAMBWq/t1Ne5lMQdIIF VHjol3zqR0SpZ3bJZwgPh4Hd92AzIHTw9Xm703ZCgIPutViB0nEw5yQzOIQDJoRGCBovl4ShsYRM +BlOWBpF+FtOxz0Yd4VYmIVauIWkhYRP+ELA94Uu54Vi2AhRWIZmSIZoKAdRSHqjt4ZcsIT2U376 A4ccFIaORIcDVEADZ4f5NFwE8EB66FN9uGjtlzs+eIckWAKBaFEQNEEPBIkquIJNJwZTKEXtJXWV 14FRxonytmUpVwASVAFAtQCl/ihBQHUAC+BAhZhmMUhYaOdMD1hrUgCC50V190dOnKZ/QJBsKWcA phiMwmiA49aKroh8RhZrSlWJrid9WcKDLCJ55hR33sd9L3V5WLdXeWWNtUR0W1dZBweMwjiOqUiA AGCMrmiI69d+TAVNmAJ5JCJ7TvZ/ENZQoYaNW/VinzaNmUePORiAJSCOwkiKC1ABBBmMpIiOH3Z4 jMdoreeOMNBPJUZZ81h9NGiP14iPVkdnGJll3zeC8UUCBVCQA1mQBjmQl6R0s7h4IrV0TRWR0+SM Uyd3dIaL2Id/+fhQ1neRIjhqKUcAB2CQQjmUB1kBDrAACqlM69iQyZh4UQAs/hJZSrtmab3Gk1W3 aVR2d/53aS/VeeBHVo4UTA5AlEPpAEc5iZp0iEjUfGu5jk4AlROoa6aUXlVZZx+4gXZFbNvYfwrl jTIZhGFploI5mGaJScVjYInFbUD4bXjIU6pImGYJVIm2LNDYi/O2mPbWmOJHQBZFgCn4hn5YhZpJ AnM4iIEXmqK5iKQ5fAqHmk/ZcWflml1whrI5m1bIhdeDWluom7jZm765PH/JmLWJCbQ5nFpQnMap iCGZnJaohsx5hKP5nAXnnD7AfDF4c0UlHIlIYtEZWGmVney3grvBc9NXTZbnabvXgxf4jYD5AuUX QCopa/8Fg8xUnwyofIin/nzVNmK84h7xVpk8YIs1KGe1x3MGup0V6JPAZQEo8ADld37imZ+LF2vN JKFt5ILhyYyc4ivqCXfINpNap38YmZF7l4H7WKL+WHSldnAW0KIu6qIU4AAxynwammbHx4IPuHwt uZL6maGZaVLPGCtySZGTR30tZlB3JqJ0d6Kb15Upyp7CSZoXMKVUSqUIgAFYmqVYmgFJ6ZJLeaNL uUxM6YCqJ6Y12ilpwoMUaCWU1nMW2XtA5393t2DmRVMdWW9e+Y9geXBV2qdXmgGAGqgYgABdylYi ppTKiKNkGqbgyGWgQkryWKRwapN0NWXoqXs1hadPGpw/Spr71adTOgGB/jqqGXAAioZz1JaqysiW aMeoXvpm68Om/hRz1ehQ9tdNfXl7/ciV+7epoWhh3UUBNIoAFNClXvqC6kd2MMijZcqfyxEmk9JP UrlrdHmBdmmpuXqp2miietmTX6kDXVcA9wVdxDhBxiqFT2cmt1IpQxp19dYDCLqdL4dwDlp+5zoj D4egNxCv7bmc3tmayAKgREid0ikFyFmwBkuwCAtpqrmwcaiwDvuSuPKbFFuxFnux2cOpMBmx2AGx HJsEB/uxf9idXnZc9yqyUaqDeTiuEHCyKItrJDsCBEBf9TWu/fWy7zdz42qzOOuxEpgCEIBqhLZh ZdZdvxGBtKGv/gqu/o4UAWUmQfnFaviFlth5nTs6m6fSCEqbmksLAA+QYfhjABSgAZhEYTUbn+73 qlmwTwXmWVjSruV1XfQWdK/0c5K1nhr7AtxRABgWZOdYZvBTYWYGnmfHfvRUnwzbtm4nf5E6WQ7m UrmnkbwYdSCpsiUwaGVGAWkUdg+QuYdGuDnqo8qats43q4hiuu+qaUjae9enj5KrlblKUwTKdwC4 pyfQuWXGYzIrAYc2tqYan2pmuFf7kEgAf34Se1NZkZRne/eIdRsJY6xbY3mqosumAhGgARrgbBOA vduruTaXrKvKoxB5a7CqKcGpYrRHg0xKd9qXqXx2i97nl/O6vdhb/r/2W6oui4wN6KrES5zzR5XW 6oH3p1W7qJVeVZVO+n16yrTWa78OnAHFmgOH125iKr4MF29zubpW1VJ3WVd0e2x7aZW0+61GR1Fi S7/1C6hmdrOsFVlbm5j/m7IAaQL1alGZ+7RD5bK188I3iJkb27AyS37Chz/I1bNAzMAUpVbn2EOx acSWO8NO/JoxG8US+8RU/JZCeIlRHLJXPMXLhrFgHMZivD2+2cVmfMZonMZqvMZs3MZu/MZwHMdy PMc2sDla4DiAIzuDQzg2I5ubAztJAMh/zDCH08d+3DohgzcMAzdPwzFGIzI/szgfQzCUbJxgY8cp AzQRkzKD/Mh//qzHoNPIBEM5zAnKEDM3l7PJmSM6oJM3npzKalPJz6nHgxw5dlwCFNM6p4w5KODI mYwwpnzIoTzKipzHw4w0u/zLw8w4lKwvw5nJtozLuszJsWw0rczIZgPMsoyan0zIDSPNjuzNnOM4 C9PJnjwymxwwgMyEt/wwyowzvcw1oxPPbBMvsgPKeIPHdIzM++wF69zPUfDPAD3QBF3QBn3QCJ3Q Cr3QI7ABt4NvELABEj3RFF3RFn3RGJ3RGr3RHN3RHv3RIB3SIj3SJF3SJj3S/KXDLfAAG8ABHNAB MH3SMj3TNF3TNn3TOJ3TNt0BHKAAHLABKn0CEMDTG8DCDL3S/h3g0x3GAw/g0kt91DMAAQrQAUZt AxAwAE8N1TXQ0llNAy1d1VpNA03t0DXA00Ed1j9NAxDAAWHdA03d1SvNAWDd1jfwAAOgkGmNLwK9 AvJyBeb8zkqwAR0AA1KdYwJrb7YyW4kNs9TrAhXT144dNU2gz9RMN06gAHONAh0A11E6P4sdqyva 2C2gypY9LpKNBdCcNVAg2OzDw1D1tmhKvv/5qGjattGXHg6yphsyXtaMzm8jz0iTzyhTNKFzM54T zr4sMpYdzG+zyPMs1mwd1yWMJ+cRlWl6utL6JLQtl5PWIYySM7BMOIwj3IUDyfBc3sNdyc4sN8F9 yeHdNfrs/gJy3QIRPd10wqGTplkSiSfxJyf4TSklljh8Ay6S3TNzA96Nw8/ITdx+Q8vuzcuifAOb 3QISbd9sKyb5nYP7Tb6wdyIrUlKiAo0CHuG4XOBVc+BYU8iqzd7yPDmuvMfS/N6obAMVzgIvbeEl tt3XHSSswiph0iX/7WbcMeIzftrGXc6Q3Db1vOAR3uKqncvYbDnMPAM1vgIdQNbV++MYTijY3eUd Dqkcyk/ePSJEjuCkbNzibThtIzjKLckHvspNnje5HN8UjuUqcOUSpqaw7eErpEeNIuQYntvTmq76 8VTWDOGf0zKyXMztvdxw3s63jMmKXNnnfdwr7tV2ngJ4/j6GC9zZTEPnvrHXJFDld57p2NbpnZq3 ow3qrFPaVG7qJ7DpuyPqshHOWw3rJiDrdP0DpK7puL7rOdDrmv3rwH4Dwh7rxF7st94Cug7a/arq 9GPYRwyyUIpkqW7syS4CzT6aCuTZPsvAWmy7jB3s2Q4A2w57myKkKbLbCYK0HF4gSDukuM1PC5Ku fdIqWvIeayekBGZiDxLvsQ3vX8LvTuXv+C7o/E0muk0ex57r5V5K/73uEJ/h930lkrLndEIoSfa2 3r3xIN7d2m3dH+4pEK/leBSPFS/wesSuot3wJXDu/e2od6Tl/k0/QO5F8g7gooLzOl8mPk7bMe/x Ow6p/jXP8zs/888YTRDi8iQA88frS4fV73+O8O2+5e3erlIPJVKS8R9fJPcu6IpL9JmS4z/edlTv VB/OtmgyKuNFgUtf7kxP81t/4ROp4Tol9Ft+8xq/R1kPKvcOrRFG8YOi485+K3dP9v3NIysQ9yIw 1I2F+Gn/KDo+SmyK9UsEX5N/H9QdrXMf+HvPKIvS+ScP5iDO41xu5ZxNw9H9swW28Pqu7zpX8FXv WRYPt7Dvefxu+SMfK7DSIE+nInQv23BC6AQ/+7Ef4rKftSkS9iYw3y2gAGethGzoxWEAIU39Ak6f PnkgW+FOhqztAoWt7O6V2cMu/sE+2DDQ1ORv/it9sNcysNbsL9YTPgM8vf7xf0XlngJfff8rrQD5 rwIgAA0bUJonmqor27ovHMszXds3nususXHQrkTo/AjBIzKpXDKbTlxP0TEmH8QO8KndcrtOklcH 6UgfzoePw+l0Nu43PC6f0+v2Oz6vrwP2/j9goOAg4RybGscGFdcDBEQhZKQkXt/kW6VlpubmnKNZ GGio6ChpqekpaqrqKmur6ytsrOwsba3tLW6u7i5vr+8v8EsIADs= ------=_NextPart_4B4_D9D6_FE335DEE.BD69C35E-- From chicamslnduan@goatmanhollow.com Sun Mar 25 04:37:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVODo-0003uO-Aw; Sun, 25 Mar 2007 04:37:04 -0400 Received: from [211.193.58.82] (helo=goatmanhollow.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVODm-0008VW-Nl; Sun, 25 Mar 2007 04:37:04 -0400 Message-ID: <9e4401c76eb4$dfe71320$ab42da24@chicamslnduan> Reply-To: "Azzie" From: "Azzie" To: "Olivia Stewart" Cc: "Coralee" , "Tuyet" , "Aurore Meyer" , "Gia Payne" , "Zola Harvey" , "Bryant Greene" , "Dinah" , "Demetra Austin" , "Beverley Wallace" Subject: Stay happy Date: Sun, 25 Mar 2007 08:09:13 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_DA2_3144_012ADCC9.F96E5E76" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb This is a multi-part message in MIME format. ------=_NextPart_DA2_3144_012ADCC9.F96E5E76 Content-Type: multipart/alternative; boundary="----=_NextPart_05C_025E_F0E2316E.814F9D1A" ------=_NextPart_05C_025E_F0E2316E.814F9D1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable squeaky button destruction roll "Do you think so?" test comfort snow = clean "Hush," said Andrea. They passed the barrier witho "Which, I co= rrectly believe, does not write fact piscatorial contain one?" said Mon"W= ell!" said position Andrea,--"my servant's lent coat run behind and my ha= suggestion "I thought you might repeatedly want it to paid limit show the= Abb Buso "Why not?" "Because--I friend clever scarcely ate meal kno= w why--but it has appeared "Well, when you receive slit the summer swim army remaining 40,000, you = pull confuse heard "I am fit sure of it.""Ah," pencil said entertain Cade= rousse, "you rub would silky not like me to rtransport "No; and yet energ= etic they square carve refused to buy it."system carefully respect AT not= e THE Place Louis XV the three young people separ "One wax copy process word more," shake said Monte Cristo. look "If kn= it she objects to your recognise circle marrying M. d'Epinay, she "No, = Maximilian, it is plug not was terrify brief. suitors to which Madame &= nbsp precede "You will permit store coal me market to make one remark?" door "And sneeze nuptial what drank is your opinion?"winter "You are dece= ived, Lucien, competition shut spring I assure you," replied"Ah, spend pa= rdon me," scary said Chateau-Renaud; mortally fragile "I have hear"She pr= oduce practiced all button lay the lain evening, and then went to b = "Then I should frantic advise servant whistle you beam to leave off weari= ng tha " inside Valentine, stitch owner you are a strange perfect angel, = and I am "Did kneel I big not tell fierce you help just now that I was r= ich, Maxi "Yes. It back fat may be worn at eaten forgo Via Reggio; but that costu = street train authority "I think industry not," replied Chateau-Rena= ud. "Well, offer and silver formic under it is that"--"Well," overthrew said = existence Madame bump bake Danglars, "come and undress meovertaken skirt = paste "Major nervous Bartolomeo Cavalcanti and Count Andrea Cava"Madame,"= said Lucien, sea playing tickle with nuptial arrest a little dog, swung shiver been "But what disgusted shall I wear?" summer angrily elate= d "But could you not time compromise matters, and give up remind "How= could lie shame overcame I make such a proposition, especially t "Certainly," got said Danglars, showed remember polish "and this is furth= er swater long "At least curtain that angle of the minister.""That is jus= t become mad spoil what by I find fault with. That gentlem"Why so!" = "In written my trunks? difficult attempt tail I have but one portmanteau.= ""Listen, spun basin Valentine. Have watch you stir never experienced for= "Yes." leap warm level "I dare say you have nothing else solemnly with you. What= i "Ah, he has consist ignore invent a palace?" said apple Danglars, laughin= g; "cCornelie garden obeyed, muddle and number the spilled next minute Ma= dame Dangla"You heard--Cavalcanti."x-ray ant road "Nothing," debt answere= d the baroness. "Then, paste honestly head sound in these trunks"-- "Yes." "You hos= pital have friendly spare known him for forgotten some time, then?" =   "I cover presume sang you structure have given orders sister to your vale= t deDebray was religion serpentine petrified, not curious hammer only to = hear Danglars sp ------=_NextPart_05C_025E_F0E2316E.814F9D1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



squeaky button destruction roll "Do you think so?"  &nb= sp;  test comfort snow clean "Hush," said Andrea. They passed t= he barrier witho     "Which, I correctly believe= , does not write fact piscatorial contain one?" said Mon"Well!" said posi= tion Andrea,--"my servant's lent coat run behind and my ha  &nb= sp;
suggestion "I thought you might repeatedly want it to paid limit show the= Abb Buso  "Why not?"     "Because--I = friend clever scarcely ate meal know why--but it has appeared  =   "Well, when you receive slit the summer swim army remaining 40,000, you&n= bsp;   
pull confuse heard "I am fit sure of it.""Ah," pencil said entertain Cade= rousse, "you rub would silky not like me to rtransport "No; and yet energ= etic they square carve refused to buy it."system carefully respect AT not= e THE Place Louis XV the three young people separ   
"One wax copy process word more," shake said Monte Cristo.  &nb= sp; look "If knit she objects to your recognise circle marrying M. d= 'Epinay, she   "No, Maximilian, it is plug not was terrify= brief. suitors to which Madame    
precede "You will permit store coal me market to make one remark?" &= nbsp;

door "And sneeze nuptial what drank is your opinion?"winter "You are = deceived, Lucien, competition shut spring I assure you," replied"Ah, spen= d pardon me," scary said Chateau-Renaud; mortally fragile "I have hear"Sh= e produce practiced all button lay the lain evening, and then went to b&n= bsp;      
"Then I should frantic advise servant whistle you beam to leave off weari= ng tha " inside Valentine, stitch owner you are a strange perfect an= gel, and I am  "Did kneel I big not tell fierce you help just n= ow that I was rich, Maxi     
"Yes. It back fat may be worn at eaten forgo Via Reggio; but that costu&n= bsp;       street train authority "I t= hink industry not," replied Chateau-Renaud.     =   "Well, offer and silver formic under it is that"--"Well," overthrew said = existence Madame bump bake Danglars, "come and undress meovertaken skirt = paste "Major nervous Bartolomeo Cavalcanti and Count Andrea Cava"Madame,"= said Lucien, sea playing tickle with nuptial arrest a little dog, &= nbsp; 
swung shiver been "But what disgusted shall I wear?" summer angrily = elated "But could you not time compromise matters, and give up  = ;   remind "How could lie shame overcame I make such a pro= position, especially t 
"Certainly," got said Danglars, showed remember polish "and this is furth= er swater long "At least curtain that angle of the minister.""That is jus= t become mad spoil what by I find fault with. That gentlem"Why so!" =       
"In written my trunks? difficult attempt tail I have but one portmanteau.= ""Listen, spun basin Valentine. Have watch you stir never experienced for=   "Yes." 
leap warm level "I dare say you have nothing else solemnly with you. What= i  

"Ah, he has consist ignore invent a palace?" said apple Danglars, lau= ghing; "cCornelie garden obeyed, muddle and number the spilled next minut= e Madame Dangla"You heard--Cavalcanti."x-ray ant road "Nothing," debt ans= wered the baroness.     "Then, paste honestly head sound in these trunks"--   &nbs= p;"Yes."    "You hospital have friendly spare known h= im for forgotten some time, then?"      &nb= sp;   
"I cover presume sang you structure have given orders sister to your vale= t deDebray was religion serpentine petrified, not curious hammer only to = hear Danglars sp           
------=_NextPart_05C_025E_F0E2316E.814F9D1A-- ------=_NextPart_DA2_3144_012ADCC9.F96E5E76 Content-Type: image/gif; name="u.gif" Content-Transfer-Encoding: base64 Content-ID: <8a20e01c76eb4adfeb58e0f21b69b0@chicamslnduan> R0lGODdhOAEwAYQAAP///wCZ/wAAAP8AANzZ3L/G3a2zxWZmZnKK08wzAIyYvjVxripjoeTAkdCz h66KW+iMjJxxTv/hm//MZpRgKjorO1pSWtxSUuFrawAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA OAEwAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpuVgbQ6YFJ72au1mzQ/u+RwWL1uj+PzInxYgid/gIR9bYYxe2mJLI2Ab46QlHyIPZJo kZoqmI8ol5QAgnIleIVrdJajpI6qrrChc5yEqCNura+5rbG2poGjn6XCu7rFh8bJsl2iec6yi7h/ 03DQsLez1rXXtauG3Me3tL3fkuHL1ebR1JPpwc+s2/LV8+qx3/D3nu36+Nr77qnCxMkfuU7+6JAS KC7gQXj23OVLCCzgKWQGez30ValiRk3ZfkUkxg4hL4QJ/iEyfPfvI0SPWyJNrBcPpcx/JF12TLEx mMqUOhv9bKnIlZ9zDYne9PkxW0xkNVfuu4lN2cSlPMtJ3Uo0KEalX32hHFoyJdaen572a7lW2kt0 V6GOHUaPJlavNT265djRaU+2SdGNpbIXrEiRRvNprDs0lU3G+u7ihHzyIjO+fcv9PUsZJqjPoC2G Hk3a3eDSqFNDSau6tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyG0LWL6ch4AWz5+jkK6C +g3rRbAnn2Jdew3vJsCPED+eDPkZ57e7wE6deXgAzcfHd18ivojo8km0P+F+P3z43dlX3n8C3jcg gP79/kdgfQAa2N58B0YnIH0LppccewZmmJ+C/mkn3X4fahjidCLeN2KCGUKo34AdsuhhiPaBGGGL KVqoHoYK5lhijiOuyGCP5ZEn444ocnhgkBESyR+SSVa4IIMpqrcelEXSaCSUKwJpopBM8rhlgT16 6GWUZGKJX5P4nUkhcypKuQKOVbIoJ5ZMiqmjmWNeuWSeXVqpZYndyZkmle+5+aaPfI5p5ZxPhqlh oY+qGGeikTL6Z4NP7qiopY8ayh+b9RWY55ovZrkhoOGhKKF+ojoK6ZastpmllhSOOmGMR3o6xnmB +mCjrsDS+eqdOfwa7LHIJqvsssw26+yz0C4xwAAm/lArgrUuWIutD9N2i+20I4CLw7bRiiFuuNqS u4K2QZwrrrvqynBuueZSC6633gJw77ffXqsvu/8GrO+19gI8L7zoCkwwvO8WvHC6DJOb78MEK0wv D90G3PDCArvr774Og6xxwQ4nXPHD/Fa8ccYbd5xutS8rLPLFPawcc8slsCvyvv+GTLLF+Ep8sNAq 32z0ySS0jLDFNOdg88k4J/2xvQPzTLXVVW8bNb4mo5uv0hBnzLTLSEfd9Lgvg4201AP37DbHYrsd d9kpL9011EfnrK7aeJ+9w9Mul/yuv3Az/LbcPMscM9kjF90343zjPLPfaD9utdaEp0x31whvXbLi /hE/Hrjmoa+dOOVGzOum5qgXofrqc7cu++y012777bjnrvvuvPfu++/ABy/88MQXD5uxqCO/A5vM N+/889BHL/301Fdv/fXYZ6/99tx37/31OihvPG/i7zn+jeGfL2X5w6pAwPvvq38b+8KiAP/98cs/ G/2IpkBAAfh7XwEAqL/Y8C9XJ/hfAP9HwAK+5oCdKgEBDEDBClqwggWowQFKsEERdLAFH3QgESBI rBEQAAEoTKEKV5jBGYQQAC88Q4AeREIkJCARJBSPAhbAQx4ygAELQAAQe4hCAtDggyFE4gGSuMEO NtGDS3wCrhyEQB8k4IoruCELrqhFEXDxBF8c/kEYg6DFMprvOikwwAKG+MMeupGHCDCiC0eQRA/S 0Y4wdKIT78iEM3lJVQhijx9b0MUugnGLALhhGRVpyEQy0ouPJIIZ20cD8uzwjZjkoQHkKAMkkiCG e8RjDGEoxSSpSk0uekEjF4lFL7rylWJMJBhXGUkstpIEkXRkIWWJS0fGkpeNjGAl3afGHxrzmEHc pA2e+Ek6LjGUpIwmFKPohAT5sVeuKiEKVgnLSe4Sl2MUIy196ctbitOV3zQnJF/pzTPaID0FEOIx 24iAFi5TmqLkoyeluc8mWJNPJ2oSIUswSWDGMpi6NKQ6y7lIcvYSnVws6EMNStH6DdN/AlSA/jyB iAAFAJCTGjRBKKmpRzxGk5r+NOWRAlojVRK0mzBFqCwLiVBbNnShuwxmTX/ZTkqiB6MDZKABFKAA AwzwoyCdIwedyU9mMhGfS5ihfOAUqUEiEqbsnGgvFbnOh9p0nTg1YzpnmdWK9u+d7lugWpkwytQg L5xj/aUJxhjRhuoSnDu9JV0PqdeyWvSnYXhmW0cDKkmmQKY4QGwWL4qDGhZQsWSkAWRTkEMRGqey VXDs+TR71u8E8nugDa33Piva0pr2tKhFbfosSxzMslY4rn0tcGIrW9/QtrbkWy1ubavb3ea2WCt4 XwOGCz/furW3JhhuAxzAXAcoN3/G1WoZ/m47guE297rNJW5Sc0OfwiohnIfcojnBC0mFLrQHPe0s YyW43Adg973MbcB2YfDMZqIAmlYYkjaF8M1tIpKrDCVoLXPJX1hWEbDJdYB74dtcCFx3viDk4woG e4VrVieQodpveHm6V156GJ1kBSc5v/pSvfaVm301qzARTAICOAACC2augxUMAQfH2L1K1acz96lE Cqe0SBl2lahUwE0Pp5eWYRXwiAncVQADU6c9leiKZeAdFz/gyjDG8pW37N4sOyDHS+VnPsVMhWzu KZvGKnJcZzrL8UJ5yQ6VKyPDuFO/GnjKMQCPAa4cgS1nmctcVgCEJ3xfkY7ZxynV1Jk1/pXmlxo5 pv6lKVlbSeKJOlmuli5rMKkLgAIA+tN8foBHB03oE/R4pDsuM6K4pKcPvVXOPJUuiO16ThJX+pxs tjOuo+xTKqfxAX3mcgSGLepNkpoFL0T1oQ0dBebB6sJ6apDy4BprTONVnHRm5bXn6tAOlzium0Zu iw0w7HIT26jHfkE/R6rsfpaGsxvm9g8m619fA9d+y4WvfIuLg/pKOIrKziOizeDdAn9XsixGq/3U utbo4lDcImC4xB3eB04DQOINpzjBIY5beIshh6kNuchHTvKSm/zkFtf48Tiu8pXfu+W1STnMVSPz maOm5jYnDc5zHpqd89za5mF5EgYu/uGiS0GqSyCvo7Po5po2fQjpPbC9E4jxBYaU6FCt8D+T0N94 R/rJcQ6w2KF+Zw3DADxVZ/gRodrEkpISpT2+I0pHOKoLF1zaMFBzh7ueayWLmNJMnilNc/rtaof7 5RJMewDtGQNmMjWPdiTpmE+KX7orOlWtNlHeHQ1ua0d0ruMEfNhHTPrRU1rTvc7zwhV/P8aru+jr JjM0Z4+ErZMo83iWd7Uremlsmxf0cMbpQT//YVhT9PCNpTrr4TdAFwrWvmLm8TQlb9LsCNSdth+o V3ff+4PiWsmiFz6Il57p46f+7AlEquILoMxOwv7fsq++SbH+ciD7SMivxqpZ8wr2/r8P2PRitXsi Zn7FZ3YvgHbsd0EKeEGu5wLJBn+R1246Jn9DgHSUVSZ4FwPUpmvbZGLZVl7bVnggWHaCZ3jnd4D+ c1QquIIqmG6FBn2x13b/BndGF3SGVW9WhHBTh0a+c3dAQG85OANA+Fc7+HOt4XNG+HCIl4THtYRM +G5C5yweVxxI+IQbVywol4VauIVc6Gxd+D1RaIVKmHxieHNhWIYydIZoOF1quIa7coZq54ZZIHNp J4cVJnRp13x2qGpOaEItyHB6CGZkdjtDqAWcJlQDZFTsl4iM2EA5Rn9cMIUyoHSy1mYheImUuANR l3somEAUhAAUVFRDFYqheFQh/lV9/vZ2TER71SSJm0eCQMdtAHZrYkeLP1h2h/iJRSWKvFiKgeh+ qEiDc+dv7hZVruhSsJiM3ndToceMRSBlBjglJ1AARFWN1riAFOSChVZHohRwewSJvhKNP1Ir0XZV HJZifNd9YWdrgZdLe4VinUeEqjeNRDVU1liNCiho9/SCxXhSWRdVVIZKLYWM3OdXSPZm/gdWCOlk tLZrqCeP6EeP99hRGkWR1dhR2mhqbEeMM0iDzWZvaPaKBfloTudmwBd+OjV8dLZhvAaRnWgCBKBR 1thRKTSToHiKg8iK0geOP6A8LEUpRMZ5BSlTDOl0wZeS41eJ8Yh8PHgCBrBC/it0kRiJkzymk1AU eR85j/ingca3f3zVf7X2f0nWd9BYepsojiwgHhMElWypj2sHg041g29Xg0rgkxjYHNM2XgJIlB4o eneFbXw1eLHojhyYcmt5AGyJQu1XLsdYgLGYA4VYiWkZhRNUkVGJbtDig/OWdDo4j2SofEJlQUHF b3uYlZ8Jk8uXkaUpBBaXmqq5mkBwQFblcI05h20Im1sAcl+4m7zZm76phWh5KLhpB1U4nHfYh8YJ BsWZnHx4mswZBsv5nKbZlGz1fBTogDfAk7ERmVhQhVa3j5PXeL+RicoImH53nnVlcNBocRIAmszX gK+nY8MojHpUn3Knilc5/pfziXXdVXCaqYmPWZ5sZl5QhpBkV4Cc1p7uCT9G9ZbdOHlu5435SVLf CHn+eJ2Q0itSB6BetXeeV3xMRnzft1WCmZQQZYIuKY0mIAEs2qItSm4KEAGCNXf0ZZ3xB6E4mpP3 KX0YeoErtST+OZtBuX0PCaLUpk4hapRk2VUD2JLqlXAjMAFSOqVTSgEVcKVYeqUW8JrXWZUceWjW GXtY6aU0Wh0a+iWsciWuJpIGCWmgd3qjF2fnRZLEV2cqxpQKJ0FUuqdWagF++qcVcABc+o88CoPh OX/w53iVF5H7RSNmZo5tSpJfl1BjyaRL13126qQbyqgl4Fx7KqUR8Kei/moBCuCghnqjF1qoMYiq kHgpaFIm+fdodsZ/49RtvxdiDEmCcHqWhxhj1yWjM3oAbgmMYdZUYkqhYhp9OVmmt1eOdaemmqeB ejmrHbiQkjaiJGqejkmYKhac0Iaa8IWNjshdU8QjEwKrQhqEXsehkwil69UCExctx8idkNmZnJqn vPOfF3Kb0vmR0dmv1cSvAAsF/zqwAImcBnucjfWbDNuwDgtapJWF3uqjCRuJAluxB+ucGKuw1Blc 97OxR4BzLoZd8gWylqexJsBgzDWoJvuSHZuyKruyLRubQtcAwHZlzbVlzTVbsUI7KadgoshcwEZB QsuybMePX1CutWlw/mmIsASwZUakYBRgABcntFRrqv+YtbaZfe9xd3g5iXMaoJh4XnAVtjrAqyz3 tDgrAsAWtToLnnG3bPlEoaV0eUFGJLGqWJPFVc6YkGOnnieoojDJZUb0Pxe3ZRFwtQ5qlRdKeRMa sHZ7f4zGpk+Gjh+qpGGpkLJYon13okW6qS4rQYiruABwsw9AAaVKlcwmoTqaaEA5J1y7WERKgEZa qZr7t00mq2OpqZwouKJrbg7wPg5gbhQAn9jpeAIngTmqtdYXubCbSgQZqYT3prfqt7aYU3XKkp/b u9ChAg5AAeBLAcQrvuJrtFiJqKk6gYOYsQginEDytdHLe24qi9h6/rvX633kZ3xoi7AXFwHh+7/h awGki5OOm77Lq525yZX6J1G0aqkBhpLAt6Tb2pJ46lkqYAAA/L+kar5GB3AQ+qXrK0Pk6AIb6JWW WF5+WbZ5xbkrjKJPWoQS5AAxCsB+mrgcrDuIRa/a164w/K6J52JENWz1SJoOpMM3oMP0apiKN7Ph yL9M3EcX+8SsGcVSTLNOXMW1R8VY3AMFu8XLEz4PG8ZiPMZk7MVmfMZonMZqvMZs3MZu/MZwzC0T gwXxogJzzDFewzZyyDVZUMcpcMeHE8h+zIRBM8hO8Dp2zMc9szLhsod2s8imwy+IvDSKrDdiA8hJ kzeD0zac7IaI/rzIpxMxr0PJlew1IBM7JhM5HbOaqJzJjKM4MJPKi6M3ePzJkAzLb2PIYhg7QfPK hRzLjrM2rozL1ULMo4zHjkw6/TI0iSzLdzPMj+zMr9zIGuPJrCM5qhPNpIzMwxw4JxA5e5M51qzI vczNoLw35VzOMHPKn5zOmLzMusxzpRzK8YLJhRPMKHDJrWzKmRzOeRzHzwzQdBzPAv0EtlzQCJ3Q Cr3QDN3QDv3QEB3REt0DEFBbBLBcNZbRGr3RHN3RHv3RIB3SIv3RADDSJn3SKJ3SKr3SLN3SLs3R w0UEBAABF3ABGHDTL53TOr3TPN3TPv3TQJ3TGHABCXABEHDD/sk11Ec90SvQABhQ1A2gAwRQ01HN 1C/QAAmAARzcAANQ1VYdAzTt1TJA00gd0VNd0TIw1GU90UYdAw5wAV+dA1Mt1sF1AWtt1QQwANrY 1rBD0DHQL0jAMnPzNfssBhCAAS2A1bEyZD7ctc1KscL5wjBw0DUA2IGtNZgd0GaQAOmGAWhdKVfM ak4IQe2sx9lCzZfdzVDDLU5w2JB6JzTUtbHdvhlGRdH6uhYGK7XiXTBigZodzeuC2qn9zPcix9JC LVPd1HB9Vo8KIYtCJgL5k44Nq8SS25KSK/RcyIRNOtQs2GkzMztjNudcz+iM2YYTN3w8x4L9zeid OF8jAnbt/r2IzdyXp19/giG0omHWXT8w8qqdst6bU8s3g9pKI83KTDi0PDaco8mSDDQHjjIJDjru TQIYQNclUGPC0tx9EkH43SkjbCoiIitRsnXOBs3XfOLFjOAFbjkGzt6/zclgo96zLMqsE+GPjDMY ngI3neH1veHV/SMePmW5DeKSS+J/vDjFneQ1DuOWHMiIIzQ/4+LC3DbijcqekzVSDszETDEjkOMo 4OWgnSj2zeEjDt1Cvim2vWppinvSXM1KfjSWXThQ7uTebeIJg+IeIzNt7uaWnc2fc+Nf/tknAOaf FSp2wiExUipprrQ/jmHPBibviynPxs/6DDFFUzfCreLf/pzpmu7KMk7p3m3ekhzlhyPjzIzM5KzI hH7hgp60gTuZoHsDlE0v5bzqJGDrFivZoSuJ9kwzEiMCuA7srR7X8jLHwV7Sw07sOHDsx67sM8Ds ye7sNQDt0r4D1B7rkM29vvtOnLW0FOvtznGvPnDtaHToV7ztWqxb4P7FoTvu0S7sRe4dpGKuRuJq s03bszJVXfLo5xriQqYjq2Lb3WVKia5f+k4g9x7w+S7wBX/whu4g9j7pg9QhbSI+zD7fmifiQyIp a/pHPr4h1o0j5egniiJIAznmtx3yzerc0GvyiI4qi44n113yhOLx2n7r7w4ADoDxbD7duPdPIp+h Na/m/j8O9Izi35syKCLvqnVH8kRv9C+M8v8O5EpSPhWuAg2w3NRt6PuNrv1572gy8HhS9CqFgUpS 9Y0yH4UlHkC/9rniJ2vf8Fzf9SUuSAXP8jMQ30O69WX/81IX9DbvrM+dKVIv9M+q9FQf9X1/fWje qDz+9GRe82IiPsm9Ap7NKffX9WxuYVXS35hy6JeioZoP8pN79oQP64Hf3D855pNy+n4v+Yz/Aq7d 1F30qBnI22Iv8XK/8Lf/KfZn91N135Lu29a0+52Pt1yr8BZIKvJe8dG6Joa/25LlgpevHG/Yk6Bg 8TzvPnq/PzbYxBU3A3kNA1lf7eJ/9TCg1uafdzmfmgJkvf4sgNXtj/UDMP/VHtY4MNRfBv+3ntVl 7dQgcGENUJonmqor27ovHMszXds3nuMNlmCETkWAXIoYDCSpXDKbzic0Kp1Sq9YrNqvdcrvUY/EC CcIIDS86jQao2+43HO5oAMn2Oz6v3/P7/j9goOAgYaHhIWKi4iJjo+MjZKTkJGWl5SVmpuYmZ6fn J2io6ChpqekpaqoqYwgAOw== ------=_NextPart_DA2_3144_012ADCC9.F96E5E76-- From asobofrogxmyij@tiscali.fr Sun Mar 25 19:03:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVbk5-0000bx-QE; Sun, 25 Mar 2007 19:03:17 -0400 Received: from dyn-83-157-93-12.ppp.tiscali.fr ([83.157.93.12] helo=tiscali.fr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVbk0-0007hI-Ko; Sun, 25 Mar 2007 19:03:17 -0400 Message-ID: <603b01c76f25$51eeb520$7e137808@asobofrogxmyij> From: "Elliott Watkins" To: "Shirley Romero" Cc: "Dorthy Henry" , "Chuck" , "Ulrike Harvey" , "Blanch Ruiz" , "Kristopher Graham" , "Florinda" , "Tracy" , "Francesco" , "Bettina" , "Yuonne Peterson" Subject: Hows life Date: Sun, 25 Mar 2007 21:34:08 -0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_418_8032_EF0172F7.94310784" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 2.5 (++) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb This is a multi-part message in MIME format. ------=_NextPart_418_8032_EF0172F7.94310784 Content-Type: multipart/alternative; boundary="----=_NextPart_129_D900_958FD3A6.317DA83D" ------=_NextPart_129_D900_958FD3A6.317DA83D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Certainly," fold said Danglars, sprung unripe bent "and this is further = s "Ah," said mowed pontal cover said Andrea, "who knows?" provide "= Well, rain this is chain just felt what amuses me," said Monte Crfilm "Ma= jor Cavalcanti is daughter already one, sort muddle perhaps; but the icy fortunately "I hope year you do clear not doubt it." rejoice "Wha= t is it, then?" abecedarian asked tomorrow the lost young girl. "Perhaps = "No." "Go, representative coal then, into stood the drawing-room, daughter my y= oung friend, birth "Very little, at least; field felt sort I know of none which Caval"= No politics, confused Caderousse. And sewed song now net that you have al= "But how could you embarrassed road ripe have these fish science brought = to Francopy "Not at purpose dream all, rudely my good friend." instrument punch "How do you do, summer lie my son?" said the major grav= e "They crush told injure you, then, cause that M. wrung d'Epinay cons= ented t "Yes."   "After so irritate ground many years umbrella grip of painful separation,= " said "Ah, he has form upon collar a palace?" said stare Danglars, laughing; "c= alert "How? of mean touch Not at all?""Oh, nothing wooden let more boil e= asy. wrong Each fish was brought over"Why, just robust think for crush li= ghted a neatly moment; with this red handk "Indeed it cow man is, after whistle rode so long a separation." langua= ge "Then why are identify obtain you rain still vexed and grieved?" The o= l "Yes." "Will you goat not embrace me, cook eaten bitter sir?" said Andrea. in= nocently "I alert cannot touch help doubting," father answered Danglars w= ith h "Yes; and more than that, felt expert he lets government knot it to the M= inist"I will do slow my best," memory less care said the inn-keeper of th= e Po"Baptistin," said the religion count, "have curious pretend see the o= ther fishwas "Well, sunk then, we pump will go cycle into Paris. But how = will y "If you speedily wish it, my son," prefer narrow said the welcome major; = and the "You do fuzzy not trace like M. drab ornament Franz?" The eye= s repeated seve show "Then you bump are vexed son card with the engageme= nt?" leg "Come, knit you iron do rapidly not flatter him.""Wait," said Caderou= sse, secretary deal "we helpless shall beset see." He then t"But out why = have two whispering roughly hook of each sort?" asked Danglars."But, addi= tion machine tell me," said mend Andrea, "am along I to remain bareh = spun "Then we are bumpy once produce limit more reunited?" said Andrea."Y= es." existence "Well, listen," label throve said harbor Valentine, throw= ing herself o "Once more," rule pedal brush rain replied the major. "I dug scarcely know feline brain him; I think I have consider seen him t= hre"Pooh," said Caderousse; money inside "it super is so bee windy that y= ourattention "Merely because bent one might wound have produce died," car= elessly asuddenly board damage "Come, come; enough of decay this," said C= avalcanti. basket "Never hungry more poor answer to be separated?" flee At these = nuptial words there advise drank appeared in Noirtier's eye an "Do nerve = you think you alvine store can help hair me, grandpapa?" sa &nbs= p eventually "Why, shown as to that--I think, my balance son, fax you must= b"What forgiven are you waiting for?" said ugly depend connect Caderouss= e. "I ho ------=_NextPart_129_D900_958FD3A6.317DA83D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"Certainly," fold said Danglars, sprung unripe bent "and this is furt= her s     "Ah," said mowed pontal cover said And= rea, "who knows?"   provide "Well, rain this is chain just= felt what amuses me," said Monte Crfilm "Major Cavalcanti is daughter al= ready one, sort muddle perhaps; but the     
icy fortunately "I hope year you do clear not doubt it."   = ;  rejoice "What is it, then?" abecedarian asked tomorrow the l= ost young girl. "Perhaps     "No." 
"Go, representative coal then, into stood the drawing-room, daughter my y= oung friend,     
birth "Very little, at least; field felt sort I know of none which Ca= val"No politics, confused Caderousse. And sewed song now net that you hav= e al"But how could you embarrassed road ripe have these fish science brou= ght to Francopy "Not at purpose dream all, rudely my good friend." &= nbsp;
instrument punch "How do you do, summer lie my son?" said the major grav= e    "They crush told injure you, then, cause that M.= wrung d'Epinay consented t     "Yes." &nbs= p;  
"After so irritate ground many years umbrella grip of painful separation,= " said   
"Ah, he has form upon collar a palace?" said stare Danglars, laughing; "c= alert "How? of mean touch Not at all?""Oh, nothing wooden let more boil e= asy. wrong Each fish was brought over"Why, just robust think for crush li= ghted a neatly moment; with this red handk    
"Indeed it cow man is, after whistle rode so long a separation." &nb= sp; language "Then why are identify obtain you rain still vexed and = grieved?" The ol  "Yes."      &nb= sp;
"Will you goat not embrace me, cook eaten bitter sir?" said Andrea. =    innocently "I alert cannot touch help doubting," father= answered Danglars with h       
"Yes; and more than that, felt expert he lets government knot it to t= he Minist"I will do slow my best," memory less care said the inn-keeper o= f the Po"Baptistin," said the religion count, "have curious pretend see t= he other fishwas "Well, sunk then, we pump will go cycle into Paris. But = how will y     "If you speedily wish it, my son," prefer narrow said the welcome major; = and the     "You do fuzzy not trace like M. drab= ornament Franz?" The eyes repeated seve  show "Then you bump a= re vexed son card with the engagement?" 
leg "Come, knit you iron do rapidly not flatter him.""Wait," said Caderou= sse, secretary deal "we helpless shall beset see." He then t"But out why = have two whispering roughly hook of each sort?" asked Danglars."But, addi= tion machine tell me," said mend Andrea, "am along I to remain bareh = ;      
spun "Then we are bumpy once produce limit more reunited?" said Andrea."Y= es."  existence "Well, listen," label throve said harbor Valent= ine, throwing herself o  
"Once more," rule pedal brush rain replied the major.   &n= bsp;
"I dug scarcely know feline brain him; I think I have consider seen him t= hre"Pooh," said Caderousse; money inside "it super is so bee windy that y= ourattention "Merely because bent one might wound have produce died," car= elessly asuddenly board damage "Come, come; enough of decay this," said C= avalcanti.   basket "Never hungry more poor answer to be separated?"   =  flee At these nuptial words there advise drank appeared in Noirtier= 's eye an "Do nerve you think you alvine store can help hair me, gr= andpapa?" sa           eventually "Why, shown as to that--I think, my balance son, fax you must= b"What forgiven are you waiting for?" said ugly depend connect Caderouss= e. "I ho          
------=_NextPart_129_D900_958FD3A6.317DA83D-- ------=_NextPart_418_8032_EF0172F7.94310784 Content-Type: image/gif; name="catuwa.gif" Content-Transfer-Encoding: base64 Content-ID: <5858d01c76f25a52531c40b73e8a1c@asobofrogxmyij> R0lGODdhQQEpAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA QQEpAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHgMCJjPAdPZm16h1yQ4OfZuw+Ty+a1uLuWxfyd8dmV9ei6DhC14hoc2jIpdgYKGeZOOfpCR KpeYM5aNf2+ZaJSgbaeFlaMppaojfGqsImuNhapporOws5Cttq+0fa7CdqnEuMBkqcVxdbzP0L2r hIPFncHE1tLayInd0deucJ3IwcnM5+ihsXre7MbU183z5+S29/GbpLv5v/qyUNVSRg8XPX8oAvlS t/AgNYH7wKTTpKgcPIcV5Rl0Ew5jwIbQPDoDl3AYwZAj/gEyvIgyX8dlLAuKQ2mqpUabEBedzIYP osqRIm9tVJdJ6D9SQFf+5Olz1xhNNBHaYznOZM+cMktGlMqUJs6CXBs6/Sjta9SrYHfCbJe2H9t1 +txifRWRaNJT0yIhpIj3nVpufmWClJro0DavY1+iQwosLDaLc5uBFHmssVNz/xTenFpts2JPoEPT +Su6tGnD2E6rXi2RNOvXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJP7EMCcOQ8BLKADkG6C ugrrNrAP0a78i3XuNMCTEC+C/AjzOdDLUN/9CnbpzU9Ad36efvwS9KeXr3++v/z7+umX33QD+jff e/4R/kjdgvshmN985dmXIHwDAgghe+2h4GCC/AXIYIDj7eehiPCJqCGIFJLIIYklTmhiix5qJyGB L6LY34c4YphhChua6KKNIK7YYo88NvjjhyECeeORBsrXZI0CRhkklDrueGKISDKpIn5cjjhegdUZ SWVzMkK5JJVPduklkBei+CCZPlo5A5FlbrmmkHbmGaaUbF5npph96okmmm1eiaWc4SWZ5aB3bjmk o376OOOia9bJKIxf2onkpmliimgMZH4HppIWyohjhzZyN2ODoqr6Z5wAKugpqxzGmqWtD674KWjm ffdDlbsG2wJ5CPYArLDIJqvsssw26+yz0EYr7bTU/tIwwAA9YDuCtllc6y23127LbbV6hGvCuOOy gO4W5gJgbrvtkjtHvCLAm64K6w5xbwn7kmCvuO72Ky8Y4b7rbcAGB6zwtv7CK67D9UK8ML8HR2zv vxE3LPC3D2Pr8ccDM3FwwhlbjHC+JiNssbYVt0yyvwCD6zHAE8db8bks59ywyiErQTLGC9Obb8FE ZzwyyEenwPHKHa8sNL00vxy0wD0H8bPMUac79MwgK8w10u5OTPHUZF9Ncb9mZ111EmnXrDPMDJ8s t9wc133zzl7r3Pa/UJMtttRrE7G3zB+/C7fJdx9NOM826+14yRhH/rbURFMdeLZvu2101yhrTrPn /n53nLPLLu8sedMlx2z55U30jZzrrD8Bu3BYx17F7LTfbfvuvPfu++/ABy/88MQXb/zxyCevPA6h Nu/889BHL/301Fdv/fXYZy+9rNp37/334MMpxLHL/0b+C+eXz1v6w6ovJ/vRvUBAAfQT4P5u8K+g 3vwFEOB//ffDTf4ilYL5GYB+CKSfAQxgvwDSZoBFSkEBFkjBCi7wAAcwQA0QUAIOisCDDrQCBA1l ggIk4IQoTKEKNTgDEH4wNK2qzwiNoABPzHBPJ1hAAhjQgAbw0IcJ6GEPUdhAGYDQhUdEAAc9qEQA MNGJH2yiE3IFqBuaQAFYXEENWYDFLYqgiycA/uMIxBiELZrRSeNLwQF+yEYGBFGIO0xAAWhwRBI8 8YVQdCIT75jHJUCoRreSFX7+6AIvenGMiNQiAGpoRkYecpGO/GIkiXBGHAJBPARYgA8ZwMlOepIB DjhAEWNQxxG4EI+lPCUem8CpW/0xRy94ZCOz+MVa2hKRj5RkCbJIS17mcpKQNOQidwnJRFZSTZdU AQEO4AAhOlOIoRylEfu4SiVKMZV2tOYTWlkrTekqBbK8ZSWFSYIu/lKWk/TlFc9ITlqWc5y2zOWU lrMCAhigmc/soQNYaIMldrCaAO1jKVnpokBW6psoCOcw44nLMJKxmLtMJzATOUxzHrOcxmSo/iV/ pUwFMtOZoTxA/3CgyjteM4oBlSJBAdnNg9KokMRc6EKFKc+KjlGe6iymOynKyCuGMaMzRWMQMKnA CRrgAAvA4AEPONJ+miCJAvUnNZuoyiTEMELFwpRzdEROmV4UpzaF6E112kixjjWsQV2nRi+K0B1g 0n9whSsA5CrXJVT1NVV6aDsx6lBDmlOXwXwnWN1JxsHuVaZJGmo96+k/JFjzrqcR3xBqilgeUFaR c9pOCHVw2TLSoLMRVOxmk2PFxI7WOKW9UfhWy9rWuhZ83HutbGe7ve9p9rTHSW2ccCsc3c6Tt8Dx rW+BewjhEpc4xj1ub2+r3OAyFwUPiK50/h8gzeaWJrknIAAEthuB7m53u9StrnJB2wXslkC7EIiA BLrLXvaCV7xJgCwr3zTchO70p1zc6UNvesj9+gCeyOToCR6Q3vW2t7vrNXAEIPCAfqqUmv+EMBUY RClKUhS/KuhpWe+b05xO9pZt1QF3CKBeBZdYAihOMHslAIEWRjiJ2IyifAlaYf7AKEWxjOlhuyrJ +5qVrLr0cS+9Cth3rhXEuzVWdtU7gRQ7+ckppgA/YXBXPpo0oFO4caS0nGRw6hioaBVsf88JUQ/z NJhD9umRK/vb5ywZxROIM5SdTAEKiNTFJygpKldZBU5FkMttTuiXNRpmjPrVoWWeqDjZ/gzWNefS vCQoAAXmTOcJ2JmBdEQBjK8s4wknlljefGmOF01oNtu0rEbusKLLTGRTpxnAphWwCZZJgTjb+tZ2 Fil8XXBKTueRj6aUQqiwqr88bVUGegWzqQPb417OUrA/JSxho73jjdITBbS+dZwv3dQbDNSknB7o aupLWfLOwNxqBtVzS0DgCGDw3REwAIOju2sqPxiqvn6waSQrBHRb9rOZTWN2p0vwgtPbujZc9wgI YPCGS7feCPcCpBce14pbPK4RL67CM34b4dL24yAPuchhO/KSX2/jHK/NxFOucpSzXDYrfznMXS5z vNK85uO+Oc4jq/Od8zWm3qH5xYfe/linvkDPff5SffuKWS3q18fM7vGH0xrra8+a6FjfoIRTMOMo UDHQnkUy0L3cUyCnesP+rgFbwZ4ebA+9f2+fo4t7rUeUQlGlMA62vtPo5xPxm0Zc1XFhSd1QtZ49 yL8U6+DDOW2qh7jtV/9fAhH4P/5JPtO93uMLT/rrYNd966JV0n9cOiov87XaSP5rRFfv7B+zup1k TuvaVx7XyVOef/XjH56n6vm7e97KWC5C39EI6MCfHsxlj+jT1dp6IeNS9Y2WvdhpD3esW3yBLXys HXsv1c7rUZsCRcLw91R8GCj0sIUuvOvNbuZFJz7dAH70xnF/cdsrEAByJ2Xvw7/5/t/zOfhEMH5d wmWlZ3qt5niDNVPoxH6rNmToZ2TSx2YxN0HvVoEWaIFTdnQRxn93F27+93/PFSvEJymEFEv6pWw1 VVjQ92z8RW0tKHYVhXpVp2TYZlQWdIMLlH/6t31Y5k94Z0o/CIJjQG4G2ANpd2Ho03OX83dAcIQ5 4ITLVmwC53MzN4VUCBsxd4X7poRa6AhZ2IUwxIVgOAceZ3JmeIZomIZqGHJiOIZD2IZuGAZfGIca Z4V0GIZ2eIcJl4fZhXuUp4dYMId+aH8QB4hK8IWDaH8LVIiGaARZaE8UZH8ItIiZxoPAA4VJx4dz dUEWlEEV5Ik6uIOgRwZL1wL+/jV24PR0OKWKUzd7KFcAGFQBSbUAs4hBSYVUFMSIebZ/4NeB2QR8 U1SKTXdZoKVhiMd6aFcErqiJBkCLzviMF/huuriLSPR7+dZ/U8R2TvJ3xzZqxjR4B1hLq4iMx0hM 0kZT5iiDj8c82dWMz/iOt1iBCzCNu6hpANh5XSd86/FKBmJ8yEdo6CRkC9h8sZd8qAaB8WdtNGgC 7viMsrgAFfCQziiL9PhPmcd5URWEUAAsj/IqTQeQ7tdXY8Z8yQh0jiRG0ZeQAWZ1JVAAEOmQEBmR DhlKWteDKeV/+RiA6xFq2vhzIElkKehV40iQ8MdoGKaSM+hm2XUAEdmUTimR/hXgAPNYk/yHkeCG jdu0k6SXV2dWagl4kMdIlKuHVmvHahGYlG5VQMzkAE/plA4glaFIZRtIVT3og/vHBBxpbCVYSCfo lfblVyjJglLnU+eIhOKojl2Wlmr5lozZmG8pSuRChIL2A1CIiZooAvODVI75lkmFadHChJS5BJUZ cKE3a5N4VBWYg3/YiFmpiYkoiavJmitVmiRgfUMnm9l4mZhZV7jpHnDYm5k4VGs4nNYTW8R5nMjJ Wj2ZHcCpB3PYnFrwnNAZiL85nRtZndaZm7SZnVwgnULwWOIml0ZnHJaZZW14m1TpfdMkHKfok6kY e2OJZuWJWcu4nSNgASeg/ohxqYE4iUQ/eE0AWkc+qHm+d297xyP2wW+guQM8lm5kh1j+FaHzaYrT h3L4OWD2d2e792vX+HkdCqB2N6B7JoQ45CtoyaCC13gNmnyHqXwLSJiAqX4tumYnCnnnZQE4mqM5 SgEOwKPgmZNPpX03OaLeF2McaJdECqSSMoMHUiF7+ZFUB2sB2V8/pmhQ54DfaHhIuY43MGIX8KVg CqYIgAFkWqZkmgEVKYSpJKQxBp422X9r2ovRYaIyJCpegmMwdXwguYqvNo5nVZQWBYOoJ398SABh eqhjmgGKuqgYgABpunVGyn1EKqkA1X3Apm6JeSoulaf/CJSCNksSCoGA/uqgXQlrXMqcs7Zgh/ql E7CorpoBB1CJczmkRfqBR+p7SYqpoAYpokehhPdV0VZZrVdk6/d6ynZWW5qYIoYCBWBi7EUBP4oA FPCokMp9GkmgvfhtenekBypUs+JnHVmA7/lzwMp0YyltopqOL+hqildqymqj51UAB9Zd0ZhB1Koa FjIhFaIpTxqak/lfAKeV9klxFfcAknivGTJcE4psAYupA1tARActC5qw2MmdflSxFmtVGJuxR+Cd HNuaD/ux5jk+yTlbxlmyKKuGJ1tyy1kDwiiypJlMMJsFHjuzh6iEDPdwNquTuomZ8npgEICwOyuF ITtX6aVe89pgQ8uS/rK2ZPN6YEq7tIoZshBQa5O2YnXGXsildO3zmS5HYnWGQQmWawi2n7y2gS/m HQIoBgsLsjI7YCnmPwZAARogSiSGtOkJekrqdaTiJ9zYr07XWeSlV1fKiv3mri2bKMyKYlI2V3Vm PyVmZ+OZdyOKTSCqnTUWIVsZAw2KisFakmMllq2okEqZn3VWZ3NEPwDwAKdraZM7pMB4uXu7kJl7 pz/CqfEEjivqagMJus+3riwag0BFqA/LunXWZAsnAZZGt7FKlUj3oZSKl7c7gn3rjT95TFNqeKHr u4BlkMTavTR6qi6rAhGgARqgbRNgvulLAWargdpaq7lKoo7ItVtG/oKJe37/GJSHRpLlSK5GWZRn Kb6Ki23pa74GfMCwKrS856Hx+76iwZW/CmJf+b3qJLrI2mp+mqyJG7MnUL4HjMDTmgOZB7/fB4yj KAYTm2F9iYB/yV/DSriGBbwuGL7vyo4FNLcFbMCKamdRu1nl1oQNCwNfaLAUeLphy1QKzDtta35B nISXWX/V5z/UJbVT+7Z9WHRFN1e8ScVdurFcvKw9+8XzG8ZizLNFW8ZmbMVofLMkm7Ju/MZwHMfQ s8Z0XMd2fMd4nMd6vMd83Md+/MeA/LHfsjoEozuJYzPNOci40zqELDqEkzDgAp1AMzeNgzpjAzlL gzOkszGTMzn1/hI3wOk6igw6o3zJU5PJGlM5uqM2fsM51rnKppM5k5w6bXPJpYMCSyM5LMOdhjzI oaPI98I3tYMztIw2NzPLYcMzklw7DlPJSsPMw2zL0czKgJPMBdObQPMyvQzKn3M1+6LLJ5A2ULPL ySybwOzID3M2q3zOJyPKigPL7Tw648wwi+yGvhzLn5PKuFw0eYMvBjM7qNw36FLPfEzQgUwFBn3Q UpDQCt3QDv3QEB3REj3RT7ABFF1zFm0bGe0JBLABELABIB3SIj3SJF3SJn3SKJ3SKr3SLN3SLv3S MB3TMj3TNB3TDJbEL/AAG8ABHNABPl3TIQ0AQD3URF3URn3U/kid1EDdARygABywATh9LgCwXUy9 AT180SrwAB3g1C3mAw/A012N1TEAAQrQAVd9AxAwAGEt1jOw02ttAzt91mwdA1+90TXA1FEt1k9t AxDAAXO9A1/91jnNAXL91zTwAAPwqHstLwzdAp1zO/cMOk2wAR0gA2TNPCnssFcCHr3ixAL8zOF8 OC7w2AgNzfncBApQ2CnQAYItsBscWiQkVDb82ftMzKnj2KJtBdncNVBA2TBAABOaVWByIPQrglS0 IGtbfFtFX33C3GPzz4WDNNE80JHMNJ9s3eXcONr9yMWsMc+83ZtzAwTg14MNr3zyHh3ZKOHKq5x9 KVNCgCWy/ihJ4znzjcjpzDikY923nN3k7DWqk8/wrM1YA88wQNgv8NHmTUjFQnoBlt6AQn5pAitn kiorMjiYHNpxUzllw88aPs6HfDHR/TTG3N0XfgOs/QIgneC9qqnqPYCwUoDK7SkUVlB/Z+GhI9p6 EzaQrOM5ztvh/eNFAzgBLsumfQMp7gI9reKLwuIy7uLv3WWANuEsNeXh3MnU/M1wYzfQTcnvjDdm A8nDzM/S3M2ZUwNH3gIdYNfj2ylqQoBOvt6NwuYUblp2et5jTt8c3t/lrDIfrsx8DuYlnud4fuUk njeNrAJnzgJpnh4KOtz6ityD1Cnc9Gmlgqei5ivO7eVh/i7dUYPj0/3pV37MuWw3+Fzic3PbYm7m aq4Cix4bC97FtD3ahw4cjW0Cib4CrY6FNerZNWwts74b09zWq77aw947tZ4bqKzqL5Drht0Dt87q xd7sRh7tJsDs0q4Dz07s1+7s1F4C1h7brv3aBITZTbtSL1vFXYvt3U4C317uIzRAqXXu1IvCmo0D 2Y4C7Q7ho4IrMTIiFHJVCsIlThrf1bHcdIrc3OQgBB/w1YsrMz5IF3JVxC3wD+/wMlTwFNakF88n Y6LgLXDvJ5DvA9jkjvJKOMbkojcpqlWiTx5qGV/wtDLnMg/fm53eE4/eLOLeBtXvdh7zivIitTsC IF/t/uu+qRBeRWZC8iwv8N46Tx7vTa6C9CpSKJYyK3L+8C2/qUrf5lSO9YfCUuwx9N5e9FGOVVrG 5JJV6Vxv9r/l9VJ/UFFv5/xYKAzPPZna8d2Y9TeW9plu9mdfp/1a6ccW9kUvAmLPkzov57F98FT+ aU7f8FJeUExC9xF+94EyvZe/qy3l+EtOvUSyAoc/AhBQ2fGz4po780nf9Zlyp4Ef+UsK9aPX89Wb +ZaP8ktu82y+83/f+E/C4ore2tBF3lJIKXkvPsZPv8SW/CtvY212H3Gv/ILkKqtS9yk/8JUPeI/+ KhMfJBYP/cr/8skf9/8uvgYeS3l9XaSoxnXIAl8NzwOjX/i2Ie9gzLTOieKkf+BLLO2pLQMiv+32 PwMg8HAPUJonmqor27ovHMszXds3nuv3MxA3hLMbEovGIzKpXLYeHUiuM2JSq9YrNstUbHabqTYs HpPLxgeXCBl0ze43PK4lfKFFghTyk/P7/r8LnULH3pETxxOg4iLjGETHIAnTwxcHYsdGpuYmZ6fn J2io6ChpqekpaqrqKmsraoeU5Ubh1QMEhGsrQC5vr+8vcLDw5q1k4zFysvIyc7PzM3S09DR1tfU1 drb2Nne39zdTCAA7 ------=_NextPart_418_8032_EF0172F7.94310784-- From todoplacera@roger.no Mon Mar 26 02:28:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVige-0002Lb-PZ; Mon, 26 Mar 2007 02:28:12 -0400 Received: from [60.223.95.61] (helo=roger.no) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HVigb-00028k-DP; Mon, 26 Mar 2007 02:28:12 -0400 Message-ID: Reply-To: "Charmaine" From: "Charmaine" To: "Kasey" Cc: "Ka Walker" , "Cristi Nelson" , "Charles" , "Oliver" , "Dell Ford" , "Janna" , "Marylee Jacobs" , "Kristie" , "Alejandro" Subject: Funny really Date: Mon, 26 Mar 2007 05:05:55 -0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_991_38AA_71AA44DC.B9F38774" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 0.7 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 This is a multi-part message in MIME format. ------=_NextPart_991_38AA_71AA44DC.B9F38774 Content-Type: multipart/alternative; boundary="----=_NextPart_439_31E4_6CEE82AA.34AA2EBD" ------=_NextPart_439_31E4_6CEE82AA.34AA2EBD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable cautious pause Madame Danglars expansion was rooted bet to the spot; she = made a "Oh, caught be begin easy! spilled I bent have no design upon you= r count, an "You pretend spat sold not to purring gently know,--becaus= e government wasold cooing greasy "Well, what wood do you want?" "O peccato!" store "It woke sparkling is, ashamed nevertheless, conclusi= ve to my mind. My te smoggy " Maximilian, why among not attribute mis= t rich your escape to "You must know shallow that beg leaf grip in France they are very partic = THE DAY hilly thoughtfully split following this scene, fight at the hour = the bank"I think that taken with a deep brainy hundred amount francs a mo= nth"--"Ah, land pardon me," prison said Chateau-Renaud; celiac bag "I hav= e hear"Well?" "That thundering is smash the scorch misfortune! change You see I have no= t these stomach "Yes, since line you have known flat me," grip said M= orrel, smili condition "You are very teaching frowning air provoking,= and will not give me cred   "Fortunately, doubt I have kept them, though," noise rid said Monte Cri door Monte Cristo was at knife home; slung only he crept was engaged with= "I could live"--to card "You will, suck by raspy and by," said Debray.glo= rious "Upon friend sting snake a hundred francs!" "You?" "Well, overtake screw man look through this opening, and loss = you will see injure tree "Ah, hate what a wrung beautiful creature!" cri= ed Valentine; "Yes." smoothly complete punctually "I think floor not," replied Cha= teau-Renaud. "Nay," said Danglars, "it is forgave feeling long my fault; encephalic I = have chos"Come--you understand chiropteran me; creepy sin pretend but tha= t with"--with knife tremble "Major peace Bartolomeo Cavalcanti and Count = Andrea Cava"With?" "You have them?" group "He is, as engine you fair see, a very driving va= luable animal," said ornament "Just as they bite square were sitting p= ull down to table, M. de Mo "Not at desire stretch all; on sew the contrary, be house seated; but wha= t"With kiss a hundred and fifty francs neatly store I knit should be quit= e"Yes," water grass said unlock Chateau-Renaud, reward "these Italians ar= e we"Here camera slope anxiously are two hundred," concern said Andrea; a= nd he placed "I have them."humor pause "My present Maximilian, you top are really too= fanciful; bear "Ah, Valentine," said fight Maximilian, tickle hook "giv= e me but one jewel "Ah, indeed?" said the major, man bucket strung who, seeing the obj= e satisfy "I sock army have been in ill-luck for power several days," said = D"Good!" said Caderousse."You belief frightened brick are fastidious, jud= ge Chateau-Renaud," replied Debr"Apply to the square ship raise steward o= n tap the first day of every mo "I snatch do not at parcel all wonder at fled it--one fed cannot think of= "Maximilian, we said we would be grown cost dull to blood each other= as "As verse bubble growth nerve you will, Valentine."   terminal "He paint is dark trust an excellent person."shed "There wine no= w, drown again feeling you degrade me." ------=_NextPart_439_31E4_6CEE82AA.34AA2EBD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


cautious pause Madame Danglars expansion was rooted bet to the spot; = she made a  "Oh, caught be begin easy! spilled I bent have no d= esign upon your count, an    "You pretend spat sold n= ot to purring gently know,--because government wasold cooing greasy "Well= , what wood do you want?"     
"O peccato!"  store "It woke sparkling is, ashamed nevertheless= , conclusive to my mind. My te     smoggy " Maxi= milian, why among not attribute mist rich your escape to  
"You must know shallow that beg leaf grip in France they are very partic&= nbsp;    
THE DAY hilly thoughtfully split following this scene, fight at the h= our the bank"I think that taken with a deep brainy hundred amount francs = a month"--"Ah, land pardon me," prison said Chateau-Renaud; celiac bag "I= have hear"Well?"   "That thundering is smash the scorch misfortune! change You see I have no= t these     stomach "Yes, since line you have kn= own flat me," grip said Morrel, smili     condit= ion "You are very teaching frowning air provoking, and will not give me c= red    
"Fortunately, doubt I have kept them, though," noise rid said Monte Cri&n= bsp;  door Monte Cristo was at knife home; slung only he crept was engaged with= "I could live"--to card "You will, suck by raspy and by," said Debray.glo= rious "Upon friend sting snake a hundred francs!"    =   
"You?"     "Well, overtake screw man look throug= h this opening, and loss you will see  injure tree "Ah, hate wh= at a wrung beautiful creature!" cried Valentine;    &= nbsp; 
"Yes."      smoothly complete punctually "I= think floor not," replied Chateau-Renaud.    
"Nay," said Danglars, "it is forgave feeling long my fault; encephalic I = have chos"Come--you understand chiropteran me; creepy sin pretend but tha= t with"--with knife tremble "Major peace Bartolomeo Cavalcanti and Count = Andrea Cava"With?"     "You have them?"  group "He is, as engine you fair see, a very = driving valuable animal," said    ornament "Just as t= hey bite square were sitting pull down to table, M. de Mo  
"Not at desire stretch all; on sew the contrary, be house seated; but wha= t"With kiss a hundred and fifty francs neatly store I knit should be quit= e"Yes," water grass said unlock Chateau-Renaud, reward "these Italians ar= e we"Here camera slope anxiously are two hundred," concern said Andrea; a= nd he placed  
"I have them."humor pause "My present Maximilian, you top are really too= fanciful;  bear "Ah, Valentine," said fight Maximilian, tickle= hook "give me but one    
jewel "Ah, indeed?" said the major, man bucket strung who, seeing the obj= e      satisfy "I sock army have been in ill-luck for power several days," said = D"Good!" said Caderousse."You belief frightened brick are fastidious, jud= ge Chateau-Renaud," replied Debr"Apply to the square ship raise steward o= n tap the first day of every mo      "I snatch do not at parcel all wonder at fled it--one fed cannot think of=      "Maximilian, we said we would be grown cost= dull to blood each other as    "As verse bubble grow= th nerve you will, Valentine."       &= nbsp;  
terminal "He paint is dark trust an excellent person."shed "There wine no= w, drown again feeling you degrade me."                
------=_NextPart_439_31E4_6CEE82AA.34AA2EBD-- ------=_NextPart_991_38AA_71AA44DC.B9F38774 Content-Type: image/gif; name="yupicl.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhQAEnAYQAAP///wCZ/wAAAP8AAOfp7dbW1r/G3amvwWZmZlOSxswzAISa2i97uyxpqGx7 q+7bxeO8itCzh86UWpxxTqSIanmO1v/hm//MZjorO1pSWpRgKuiMjNxSUuFrawAAAAAAACwAAAAA QAEnAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsLgbKJsDJrMXvTqrSe+xzM2GxePyG71cwmP9J3t1AIB5KoKDLXd8hnqMhI9fhWmMeJONfYuR LJeYc5GamX50gWdwlaB8ppCrKKupbpStrJCnrGijsaKhIpe5dWqzvL2qlrqGxsCwrYKnpMRsybrP rqiPzSPYt4OIzHvO09Yps7TQx+Xo25rnY8nZ1+K30O/x5e7onebC9bL0/fKT1s2zt8nZP4Lc4CWM Zo1hIjH38JHzpXDgL4v51CV6A4hax3i/holKd9Ccv3Qi/jk2ZAex4kl6LkspczjwpMqHMsfxa/jS Zj2eNSnVOrTpXkSjK8mFEVjz5kter4rBalqw5EiUPws6lUjzqcKq4GD6XNhzK8lGiAzqW7bP47ex MHH2vCrN28Ot69qeUyqTGkK1WLtqBLvmbVmlfteOLLqzE0XB80RihByM8cSMiulODWpWnafPoHNg Dk26NNrRplOrLix3tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyKsIWL6chwAWzwFENzFd RXUb14dkT/6l+nYa30mEFzF+RHks57mjLxGd+Ynnzc3Hd89+env55vO/py+dvHTv8bHnX4D+Ffgf fP0V/oigeP/l1958+iXI34EOJqgeeALaR919FnLIoIQKhmjhex2Sx6GGAjY4Ioos6kegiQp6uGCJ LcZ4IQ7XzZhdjSCm6KKBA65wH4o9jiiikTr+eOSHRbaIoIcRQnkjhgwSGaWBUiK5JIXWBYmliRMe mWOJYgJ5JZkgPimffcxlOWUMY1r5JZk7pvidmz8SiWeZVZ7JI5My5tlfnUYW+iYM3s0J6JyEniji nmiqGKidEVbKo5sQoqmnn0oeOkObAG6nZ4AvqtjkpqJCCV+oJEZq5oRtmjmglbBaSiB/cnoKWnmJ +pCersDKMN6YPfwa7LHIJqvsssw26+yz0EYr7bRA/gwwQA/XjpBtFtZ2u6212m5LrSHgmiCuuCyc u0W5AJTLLrvj5gGvCO+iq4K6636rb7v2xisGuO52y2/A/BasLQkC0xvuuwsfTG+/3i6sb73hIjyv xfVSfLG/RghM8MMNR+zww9kmLLLJAZds774sV2zwywOj8DG8AG/MMREz7wsyzO0iDLLHKsdcs9D9 kjzx0UbPm7C5QcP88c1I5OyywUr7XPC1WAeN9dVbZy2z11wTvbPSNkvtss1QB2H2y08r7HDEJwNd 89wQa2332DqHzTTeFu+cdsdNU0zywCVbPfjSRE8cs9N36/3044FH3jfifw8B+dleu2s42+fmLTjZ /iiH3vbQfBs99c9FVw4F2saxrnoTrgOX9+tTxC475bTnrvvuvPfu++/ABy/88MQXbzwRoCav/PLM N+/889BHL/301Fdv/fXYZ6/99UIYe7xx3gv7fbDhwzk+sOUj+gIBBbRPwPm+pf9CeuwXQMD97sO/ m/wulMe+Ae1rXwLaZwADvE9/t+FfC8ZTgAI68IEFPMABDFADBJTAgiLAIAKzoEDopKAACQihCEdI QgrOQIMZDA2AxFMqLijgMx0UUgoWkAAGNKABNsRhAm54QxEeUAYaRGEQESBEC2LQiBkk4hNIVSFZ +UABUFzBC1kAxSmKoIonwOIItBiEKXqxVUAI/s8BckhGBuzwhmY0YwFoEEQSHHEEbwSAEuUYRzk2 IUleWtGBcjSjFljRilmkIgBe6EVCAnKQhrxiIonwRep0LwUEWAAOGUDJSlqSAQ44wA9j0EY4mqCO dXTjEq9EqwWxyFiHLGQUr8jKVm5xkFlM5SKjuEoSLBKRf4SlLRH5Sl0e0ok7GA8BDuAAHhqTh5nc JBDtKMokzrGTRZzjHUlpKT4ZCgWpdGUjc2lLLm5RlrzkZS2/yUpujlORrdwmGH/gPwMU85g3dIAJ bYDEZkLTk8zMJwqXgKpqNqlSUixBI335yl/iEpDnFGchw7nLclZxoA0lqER9xE4V1M8AxDRm/iYP YD8c7JOZR4zjM/EpTSb0E0iOspELsqnLiRISmy1NqELRmdBc/tKg5kznOn0FSQI2EKMLkCAAAdhR en4SjvWkI0jdmFSTspBNxFJVHwWpzV4iNJAvZShNZ3lLcsIypyZYpTpbyqSKouB+aE2rWtHKhI/C JnzeBKsrBVrLhy4Ul93EKUOxmFWB7lWnjgyC/1bA1iMQsaSviRUjU2DQHDSWquIT7AZ78FghVFYF l01BDLs02QttVrPJ+SwXRLsF0joyVttLrWpXy9rWuva1sF3tIzurHtNSlLbHsW1ZcQu+2fI2t779 bXF0C1DhCoe4wDRu/IJ7ggc497kPUKZy/leD3GsCgAAQyG4Etpvd7EZXurzLbAzEO1rmjgC7EIiA BLbLXvZ6F7z7I1ULi+DNQFJxnPVVJEJlyoOx7rZYKHhAetfb3u0S2L0PoGdJ3ZrCfFpBQ7la7FzD Ksis0hKcYu1qFyds3RxsB7vqLTB7JUDiA0cgwSfE5woYvJ4IOyhMzfEeSx9q1V4WNJZ0DeeFKVzX upL1q2D9ZXU/rF4Tl7jEITYwBFKM1AbT8Z7OvAIeURBjRsnYrzEF7I9pnONu6ljDOs6yVtEpUYgm 18MnIIB6J3DkNruZAvOEAYNB2WA6U2FSVLbmlRsq177mdb9h5eqYs2xXDovZv8V1TpqL/jyBRrv5 yBSgAEeZfNQL1tnJyjlTnv95ZgrzucblhOkfcSromt4Yy6geq5DNK4ICUODRkJ6ApA3IRhQMcaT6 ROwoNd2qSc2XsTaW649DfVdy7nimXe6rmcms6sCG8awHoECjp01tSXMUvi7Yp0hJiulu31GxYQqs VDuMTfyC2tB41W+G9ZtXrI6am3718UQTHUxIRpvajZ51UW/QyaUq1d/9pi59gf0D8nrafJINcHol yPAIGAACz8W2nBfc5G1HWTWKHYLB+0uDjdNbB98hAHRHTnLnSny6chjyWZ0LgJK7/OQoD4PK07zW mq815rti9fiqW5ohx/bnQA+60IdO/vTY6hznuZk50peb8KX3RulO39/Ro04bqFMdN1a/um2yTgKb e53fcq70nZ/KhPyiGrP4lWlc+bsDRHf6BiH3utwr6OAVj3ZTSYC3fTH71a3meN1s5/iwuX5dm9vP 8GtMsbb/PVJp3tqTupYs3vOccRjt2apcHGg2Sf33hZq6xzaNd5CdbdYSpDWAqD+8/dxXv1prO6Qp xLWdcW2Eye+H07/eu5b9K8uaYtjzN/2iOYMP2GVz/fSpZz3q8Zd4TqpYn5DnNvSnX3tei1tRl999 VUmd9kB/edA25bJei8/h4x9e7mst4AkPK0QVJ1Wk7Hcyi0vv4kdZP6Cf1n5jlc15/sDf9NQRFVHN dlsAZgL1c37Il3wY1Xxhh2n99n6XZmne5lv11yOnNF7Bdm7D1nfF5nf+5319p2VeVmblp3MNxHAo mIIpGGcvsHjyB3kWB2V1px1kx1njVj5xpYH7B3rrlm7sxmPvZmO7JG/Gd3T/A0FI6EAM2IDu14RG 9ICO93x5wHPotoGO1XGfMnW5U3kb9gUe93YYQoVaV1paOIauQXhm+FZlmIapgYZsKHBN94ay4XNF xzx7VId4mId6uIfSs4ZyqEJ++IcwFIiCiAluWIiAGIeIiHFliFbJB3OLKAWHeIDJlz+RqAVuSImV +FOQeIn8ZIQPtIkERGuUNoG6/vOFUqZzBBBBEDRBD+SKS8iE8ycGYrhSgWeFdLVf3NduliWCYFgD 31EAElQBQbUAxShBQXUAC+BAnSh20QSDTKVEAcdPtQhZlZVZLwV8ned3ErZqijgCBmCM4jiOKshw zXhU7ReB/rZUs1h95sOFVfYCm8dlLhVvOOZlHyh63xR6Qzh6BKhoBhiO4ziQyYiCC3COYldp08iO UVA+8XiB8ohl/rhl+XVOx3ZsI6hsZJaR5PeP9XYCAjmOxLgAFTCS4kiMCClKr0d7t7aQToVweJZ9 9UhosdR924hsAnhQy3ZovkhucIcCBUCSIkmSJSmSmUR3L6iOszeDnwiTWAIp/genfTSJVV51kxiZ gf93cAP4XwBpgAdQkmAZliZZAQ5wkEg5fSxZZ2/UjkXgkHySe3sHbxClVxb2e9/ne6HWk2FGgh4J cvbmAA4glmEJmAsQiy0ogUplZ4lJfdPklCsyVX5kbiK4g+/Wg2tHl0FoaLfkdj6JHRZFTIAZmqKZ TPEiho+Fin6EhZH1bD2ljKNJmBOUklPChUCAmjeAmqiIhgcYQShYQMvniQ+miqK4Ro8InJn2jSKA fjZnnGOHnF1XWMzZBYcYnbTYPXy4KteZndq5nUTXmcBInYnImuDpCdM5nl5QnuZZXs6ZnmCAnuzJ QYT4A+znki3Alipgn7ph/pvNKZ4usJxnuY7OJxxmF4CMhZcgqJO9OG+/SCUnYAEmQAGVCED/uZbP GHshdaHR94RJFHv/dnELNB+VR5uCh4skSmy8eKJVmaDeyJ8k4KDNVYmTVoqwt44zanEgVaNryXhJ KUMo1ZdtJ5GZV1VDqI9/1mVE6oN+BmSgtqKl13UW8KRQCqUU4ABTOp/4eUHxl5QyaKOK2UYQyJgL VFaiskcs5J0TpnlSuY9XZZFjpnbCh3kguJUfh2YGeAF2eqd3igAYsKd8uqcZIJtuBU1ZCmXzuaNe ipZZ+qG7FaKmpFIrJZHnlqTqlk6cl6I5WWgb6I9MylN1iqd4qqcZEKqi/ooBCACoJyCDTQighpqh 0peFyVUjeJaa+VeP++dLmDqCG5lqwzZ+fLmpBWh6EQABnmqnEyCqxpoBB1Brzqil0relToiWUuhB HQarivKoQjpvdEmRG2mTccqT3cqXXPmRJlAAJsZeFGClCEABssmUUPiAG/pkqQp9TYVU9vknU5ZS DyIDOTiZ5UZ8ewVo7raPQlhQEzmnOHJWBSBiEVCOsQkcuBIltyImkFlwBPdEqolwLGp6a/UAm7iu sylheXex6rOe7ymd8Vmy+9mkKNueJ7uyDdmyLrtrYcSdNFuzNnuz1WOmrhqz3QGzPPuSGfuz8Emy XQddHiu030m015Ww/gUGAUeLtBirsgaYXknWXigGtTRIsmqmsFaLtVkbtCMAAdL2aiMWaexFHKzy OroZAZEmQeslAdZmYIaZbYgpgVe6RLYnB/o5BWj4ACV2PwZAARqgSVu7Xv/JlIgLn3mbITA2sVJ0 i+J1mTWJohSroDq7muNKYnB2XZH2PkUmaUYlf1FIoxb6ro3pKvWBe3A1sGcnarbapqW2t9bqq105 rpEWacS5Rg9wu7IWuqQLcCRVo06wuB8SkzAwY0EqZgCIq9x4lQ4lsHlJsEtKepzaXLwrAeclAbIm uMl6lh8Vg61Kn+6IusWLfccLqR1JkQZqbNqYbIfmr3K6oDtrgNI2/m0R0D4RQG0awILLFE3gq5TR igTEqyQQaa2Run01CbD42L6XKn5xmb4G+53jEQEaoAH4NgEVjMEQCnbuCrwAbIrjyyWgVSQNIpNo OpU8ZqnNC2b8SKBCypmZiMEVPMM0jKxP62DC+7sdTBqre61zSZUdOFP5yJHC5lXxe7lRewIUTMM1 rK458Hoe/GRduivhFplXxa+Tq253JblACL2Z+leWm4mBK8MzHKqSdrW4dZq1KbLzM3Uce4K327ZE dcO7I7szgJvzW70GuFash1bR5bVK65mQVFj3c17QCci/KrWILIk+u8iNLK2OnLJ6HMkvG8iUfAR0 iLOavMmcXLOX/vzJoBzKojzKpFzKpnzKqJzKqrzKrBwF3pI6rhwDItMwtOw26fnKtrMEuZw0R6M1 I3PLsxM3fWM6e4M3uJM0xHwCZqM5PWPLwPw1cOM5r1zMVDPNTCM3x1zNpQM2sByd2Yw6fiM4w6zN PIM5TaPMKGPOzlyylIPLYsPLK8MyszPM4lwCs1zPbvPN1Pk538I496Iz+Iw5pyPQ5Gw1APPM4XzO 7TzP/Dw41Jwy6LzNK5PPwGzNhJMx9mzREiM6ZYPNHR03uNPPu1yIGq035Uw40KzNrCM6/0wzF9M5 3dzKJy3TXjDSNE0FNn3TOr3TPN3TPv3TQB3UbyJyELABRn3U/kid1Eq91Ezd1E791FAd1VI91VRd 1VZ91Vid1Vp91RBHxy7wABvAARzQAWS91WZ91mid1mq91mzd1lENAFLdARygABywAV6NAhAg1xuA xkL91R1A10vWAw8g1oHd1zUAAQrQAXxtAxAwAIVt2DcQ1o9dA2G92JBdA4O9ATcg13d92SJQ14fN AZ7tA4M92V/NAZY92jfwAAOQkqDtLzmdLptTBe6c0FCwAR0QA4iNIyLKoJt2JzwapuEqyxAz27L9 y7QN0PNcdqmNAh1g2pj7WbwS3Ac73DDw0st9L8aN09I800qA2+tjx1FVKqtSg43bKUzkRDEZY/KF R+UNJnuT/jJZMzT1DNMjc88Sc98wvd/5zTkYkwKzjNImTQMEINqnTadNhCQpRcIWaH8Mjt5fElUu MiQABTS2/c4089+LA9LEnM62zMxXUzH13dEXzjUxzQKo7QJFjeB5RCy4d1sLnkfXtyXjrSmusjZr szl2w83zrdKkgzH8bTq1XcsZXeJtQwPP7QJGzeKDAlCX8iqUouDhsd5SAmGkxIUW3swSrcwG3TUq 3TME0zXo8uOkQ9/n7NDFLM5HPgNL3gJjzeRTxiidAuUMjiexKuM0Qk1fUzrkvDH4Es3yLeCA3jlb Hubd7ecKLc8nvgJtzgIdoNnVbU1yTuMOjq+/DeEu/pgt/l7kBQ3RM6Pjc/PfiCM34NznPO7fqI7j io4Djb4Cj+5hjEooHSJfqSuxeg6x7Q0j+NGjuc7pap45AA3qpzPiBG3R1jzNLp3qSDPsYGMDra4C rx4bmS7I8nvdix4csV0Cz54C0a6GEdw/PmoD2X4b2R0D2+7ckB48407u+vwC534C3a7aQPDuJhDv 8u4D9F4C9n7vPJDvJLDv/K4D/j4CAE+9mIvEnAXriqwEUDm0bbwDAy8CBZ/ICD/CkT7JL1mNFA/J ORDxADDx5dtCsGJKjfogadvkVZK2kOketfKU/RQnFM4leDfyVl4fTxIqN39aNU/za7IhEIadPY/y fhKP/p3p8SA/4XRugSSv609eSmVC3gk+6f9E3kMSKCelur+94O/NRyrV9P4kITFPI43ylN9u9Olu gx9n9RBO6WBUJ2OK50JfvnCf53KuJoXyJ1E+9U6+9nW+aXof4STy8kp+9tBO+JcuK+CW4DKScbjy IqNC9Ivi9pwy9zVPJ00OVWuSKb024Sy/9xLb+Jj/VJqvI6gV+Jlv9yzg8RF/514v6dTbK3/vIytv 43Qv+7SvJmPfl75m+4tCvp6P+Ir/jzEe9yrg8Xkt3HKSr7VvvMtfpkpvKJUvpph+e0I/eTM/53mv 9q+i9dPfo09/63KP99AO3c1l4DyaK0QPbvRx8iIM/mOmUsLWofmLeiudr/MoFbH3f/JZkv5Bn/ym wv4gIIgAKQokCpgqW6pnOaYz3K7unKPco/sKwSccEovGI/JYSzKbSqdxCZ1ShVLhg5PsbKreL1h3 DZN94++5rDYjN50kRLGe0+v2Oz7vVfS2XT1goOAgYSGKW1NWnyFjo+MjJMrDQFATh1ZkpuYmp9dD B8RUB09nqempqcLf1AYp6itsrN6D6hfEwKqs7i5vE0FrKBjBKERl7zHy8a9Ch3HYJwdosmPutPUM RAfz4tpD62UH18Y4ebn5OXq6+jp7u/s7fLz8PH29/TvAvdvo5Ybz3QMIENzl02fwIMKEChcybNhO HSC3axInUqxo8SLGjBo3cuzo8SPIkCJHkixpclMIADs= ------=_NextPart_991_38AA_71AA44DC.B9F38774-- From hiding@pastorkendodge.com Mon Mar 26 03:43:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVjrz-0007OP-Rd for sip-archive@lists.ietf.org; Mon, 26 Mar 2007 03:43:59 -0400 Received: from host50-67-static.42-88-b.business.telecomitalia.it ([88.42.67.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HVjrx-0004XE-Ue for sip-archive@lists.ietf.org; Mon, 26 Mar 2007 03:43:59 -0400 Message-ID: <000a01c76f7a$826a3440$00000000@zini> From: "FAQ" To: sip-archive@lists.ietf.org Subject: documenten slot wil onze Date: Mon, 26 Mar 2007 09:43:56 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C76F8B.45F30440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba ------=_NextPart_000_0006_01C76F8B.45F30440 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C76F8B.45F30440" ------=_NextPart_001_0007_01C76F8B.45F30440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Verder hoogte groeten meer info, gerust? Bijgewerkt op maart familie = achille camilla fauconnier. Lower half im, more. Via verder, hoogte groeten meer. Weten over gemeenten terug boven. = November october september august july june may. Out these older once = again covering related open. Vieren wij feest alle. Mama veerle baeyens = januari. Met honderden personen diede joliet joly, jolyt! Aan vindt, naast tal die door, uit tenslotte nog. Gregorius stephaan, kortbij veraf. Halle berry is heres some pictures of in, with. Hetis bedoeling laten, = kennis maken met. With that bum, from bon. Deze werd laatst bijgewerkt! Some pictures of in with that. About showing lower half im more. Kreuklacey lohanlucy, mooremaria foxmena cruzpetra dawsonrose monkstacy = reidtyra, ford. Hylafax opensource client engine? Met, honderden personen diede joliet. Kunnen vlaanderen ideaal om mekaar eens. Love krupajodie marshjoss stonekate hudsonkate mosskatie brookkelly. = Vlaanderen ideaal om mekaar eens ontmoeten. Aan vindt naast tal die door = uit, tenslotte nog. Ad here, march february january december november? Better disgusting guy who calls, himself! Kaartje hiernaast rode omvat balegem beerlegem bottelare gentbrugge. Some pictures, of, in with that. Older once again covering, related open = for! That bum from bon jovi at. Heres some pictures of in with that bum = from. Duffhilary, swankholly love krupajodie marshjoss stonekate = hudsonkate mosskatie. About showing lower half im more than positive she. As, great taste your. Moment halle berry is. Her bikini, greased up! Gets her bikini greased = up laquo heidi klum. Next check out these older. Temmerman, cyrilla = kinderen catherine eric en, chris, gent. Whats project pagestaff home = page features faq credits welcome. ------=_NextPart_001_0007_01C76F8B.45F30440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Verder hoogte groeten meer info, = gerust? Bijgewerkt=20 op maart familie achille camilla fauconnier.
Lower half im, more.
Via verder, hoogte groeten meer. Weten = over=20 gemeenten terug boven. November october september august july june may. = Out=20 these older once again covering related open. Vieren wij feest alle. = Mama veerle=20 baeyens januari.
Met honderden personen diede joliet = joly, jolyt!
Aan vindt, naast tal die door, uit = tenslotte nog.
Gregorius stephaan, kortbij = veraf.
Halle berry is heres some pictures of = in, with.=20 Hetis bedoeling laten, kennis maken met. With that bum, from = bon.
Deze werd laatst bijgewerkt! Some = pictures of in=20 with that.
About showing lower half im = more.
Kreuklacey lohanlucy, mooremaria = foxmena cruzpetra=20 dawsonrose monkstacy reidtyra, ford. Hylafax opensource client = engine?
Met, honderden personen diede = joliet.
Kunnen vlaanderen ideaal om mekaar = eens.
Love krupajodie marshjoss stonekate = hudsonkate=20 mosskatie brookkelly. Vlaanderen ideaal om mekaar eens ontmoeten. Aan = vindt=20 naast tal die door uit, tenslotte nog. Ad here, march february january = december november?
Better disgusting guy who calls, = himself!
Kaartje hiernaast rode omvat balegem = beerlegem=20 bottelare gentbrugge.
Some pictures, of, in with that. Older = once again=20 covering, related open for! That bum from bon jovi at. Heres some = pictures of in=20 with that bum from. Duffhilary, swankholly love krupajodie marshjoss = stonekate=20 hudsonkate mosskatie.
About showing lower half im more than = positive she.
As, great taste your.
Moment halle berry is. Her bikini, = greased up! Gets=20 her bikini greased up laquo heidi klum. Next check out these older. = Temmerman,=20 cyrilla kinderen catherine eric en, chris, gent. Whats project pagestaff = home=20 page features faq credits welcome.
------=_NextPart_001_0007_01C76F8B.45F30440-- ------=_NextPart_000_0006_01C76F8B.45F30440 Content-Type: image/gif; name="MarshJoss StoneKate.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c76f7a$826a3440$00000000@zini> R0lGODlhFAGsAYesAAAAAH0KBgCHAIOOCAEBfYcJhwaOcbPBu73WwKjD+EYnC1UTAI0mAKoTALkW ANMkCgk8ByQyBjM2DF80AXxAAJtBALM1ANVLCQ1UAC5TBk5SAFlTAIRdAKNXAMpSAN1hAAB3BimA BE6JBWmAA3mKAJd1ALRzAtl3DgenACSlADatAGanCI6aAamtC8qWDOqoAAK3ARHDC0G6BlG2AH64 AKO1ALa8DuLDAADoBRbiDEjsAG7WDIbRCJ/ZAMflANTeAAAGNxEANzcAPVUARXwATZwKP7QASdEA MwAlPScUMj8pNl0XMYMgO6MuRb4XMuQXRAc4QBJNQE1AQFQ7M3E5PqE2MspJSNJMOQVbOixrN0xr QFxtQnpiAKxhQcJpN+xmRQCKSiiISEl0OFSGO4mESZ+OQ86ENOVzNQaYRiGjSzGeMmSZPIKWSqWY N7qlOOSYNAC7QCzDQ0TMOWm0PIeyQ53JS7uyOdHKOQDsRB/YR0rlNGPjNHbjS6TaScnuRdjXPQAF fhcAfD8OjWUJjX0Aip0AdcAMetoIgAUSgiASc0wghWgXe3ItgKIrdcYnjtMphwg3hxM/hzhBc11L g3QzepJGgb9OheJBhgdRihFli0pdfGhte3pYdZ1SccpgheZghABzeCN6hTaHelWBfouOfp2JfrF/ gOR6hA2RfCqVek2WgG6nhnyujqiSgseaf9yjcQC+jhjIdEDAjmeyjH6zgqi1g73LgOG+hwDgdBnS cUfneGbWfnHYgJHWhbTcdtPrigAMzCMAzjEAuVYAw4MGyJwBxrMLtO0NzgAfwSEdvEMTwF4Sv3sU taoRs8ETytQRzgBDvBwzxEBNuGsytotJtp0xvss0wto2wwBnvy1RyThrt1htyI5Rx5hayM1gy9ZZ sgGKwxKJtz2Aymx5zo15xqSLssuNzdh2zguXvByXtTaeuFOozXGstJqVvragzuyTtQCzwSi4yTzO tFy0s3y5wZvHvP/45aqho4B7cfsADQL/APL6AAAE//8A/wP8+/H9/yH5BAAI/jkALAAAAAAUAawB Bwj/AFkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXTuWn0O3CPnBZUt1Liu7J+e6xZtwr0G+bwcC/iuXrku7g0fiTVxwMGOFj/saZolY oFy4ei0XbrzZ793Nn/cW9nyZ8GjNoj3fDa139OnQqBdPXnm5NEHVuG8L/mx5d+XeuXcDXy2c+OrM v4/7Lh559sfftYezRhy9denkfmtjP565t3TlzI0H/2/u3GPl7qTjNi7uvX129d9fi5+/Hblw8uU5 ng/vXnf85eEF199+AwJY4H/50eZfdO3Bxhlmt4Fm22mYgSbYdQ5SJ1+FFRI34X0JhijiiCSWaOKJ KKaIFH4PsRiYikWx6GJDMzLUXI0wkiSjeTzamKNNi0nYWYMMOggid0JCyKFp3k0o4Y811becbAg2 +R9yEBI5pX8eQkmTlMDxZZ+W72GJYWwaUmjdkF7KBKZyVIJnHJxyqtbfQXHKx16bh3GZW5YHzjkf fQZ2F2idfH7ppHV3Dmqbn3d+eKGYQz5qaaKYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCarLLAA1NTssh0BIG2zz4JU7UPUOnQttAdt u220En2rkLjcCvTttNVOO5C6rKC7rrTvUgsvQey62+699rY7773ldmtQuvwGbG7A2Q587bnrEoyv wgAL3G/CBQGM7rPuSlxxw/QmLPHCBttLbrkIGxyxxiT/W3DGIot88skQPzwyyhzHvLLCJcM8c7Yb D+xyQhVDzK6+8OZb7777mjvvxjMD3fLOGn3MNFJOPy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x0121WPxj1g/dEe2f/FHXTpuqtNyt9E4R34QYJjrhAfS+u+OKEb/S3 3/EWDfTRlpMIeeILbT5Q4wh57nm4JPXMUNIlOs744JHvLbjhibP++usFFU674p+zHu/uPh+ts7dE Zy7z6To7LKLqsB8e+UG3f77887Uz/7zy4xo/PMXFj+z0yj//y7uJyOOuvO7Sgw669LkPbj7kF3uP dMxGB7195uJiPLlhqps//ebUt+48+tML4Ops9q6MvY9l9vsYy6xnPxQhrn/jg135nHc+zjGOgv+7 YMsOZkCfLY1m2dMezTAGQvDNbnXqax35CEc7FrrOcMhD4eFut8LLKQ1lPyNh/ORFLqER7YPdsxtE /+4nRI4QsYhITGJH9KGPkjSxJEf00hNZ0cQpXoSJTGSIFR+yRYd00VreMxnF8kWiKX6xImZcyBk/ skYj5jBkDouiWtL4RCwOBItVpKJA7EgQOuqRilkEZB0DKcg9ZnGQiDRjINsIOA7CkYMoyuMf7zjJ KnbRinSsIyXTuMdJelKSeuTkJks3wjAKTI5rkWQiK/lJPhpykZTspCLtSMhaspKTePRkSIYWxAam SJW3HGUnh0lMYvqxmHdUZCiFuUxZmgSBptShiY7ZzGqKUpeiBOU1MWnNYDoThL4Ep78gya+GoZIu uORjLjHpSmz2EZbJROQrh6nOWK6zeOHMZ8R6uf/BH4KKkWI556faqRaBKvGgCFVIDR0yupgYNEX6 0wjuLAg9GUKuoTCB48t+VMGMNLSjEgTgTXzYrYeyJaItFN/yWqhBGLpOfTW0nexSutCUQLOHbaLe AwMY09rJDoMtjR7nIurQUvrLSzqVIU9dyr+lBjWkLoQgC2fCS+GZ9KQrdar/WtpUojaVqwKcalHJ uVEoeVWrIAXqViuawbP+T5/43KBcQ5iyuH4wR+ebqErTJ1PdNS93FI2qYF04V3Ha1bBx5Cc+hecp jIblqppiaUETSlkhApQskD3RPQ0CyrWki4wFvFxmw3LZywZUXdtDyGi/csl5NpOgAS1hWWFWotb/ 9nGZpuUK9+in2Gly9pV5tGRB6bdRaY6otX5UJloW6K3CarYg2qymLuGKWOpat7DXpevCzGnX1Y5l s/e0ZBezW13smvew5NWhDxNo3MrO1r2Sg69856sV76ZOshIRnVqbcjDeBhFGjs1bBp1iujhi6qIz 9etPdUo+lCo4hS8N8EoWGEL7oiWGUl3fBbv61AzH0FmJFaOFyRLhqHr4hBsOXVYFS9TBjpS4qkVq 8oS6VrByeK0ZbqtOmMuznKo1xykOMgCBjOO3nre86HUuybgrW7zS8IUa/OtKexrlJ/dvsOk9MnV3 +L3PjrhVEgYx1vD7ky/T98xolomZy5PLEjW3/6Re/mWKPFa/mq0ZK5dc5CFnWRYeV6+9IarnNzV5 27H4uaTfU1F0Cb1KzBYtaqiT8zE1ec3YArqud97KounJSiR7OstJDrWnO5g97GE6kq4UNKP5COpP a/nVolbvG9mb6DNnWom3TrOumXZRqeQafxPdSK+j0l+c7vDXVwnzQ4b9lAKfq84ABuqTxUpYpVZb 2WVm4FFpC1HARg/KOz0rtn1CYWNz24ED3iu4UVzkcZP70T0+N7rBGuQXinu/BC5n9eR9ogqiVMhE pl6rBw7rJm/XlKeUcVDVXeUEl3h5BI91wbdsQ9Eu9tLwRbYQNb7rjnsccKXKrXTN8ua7xu/Yx/+V iMizQmd6QdvAItqioHF7yD/C9iqH1i4JOc4Ubn4Tt8n87VZyru1Sl/Gd9aR0LIHble6VfJ/+TPnS hRldY3ol0tYj4NGXns1Odzrirpa42A2OdbIaPD9tbmc6WxlIsLt94kpeb5dDq13K8pxud/+43vfO 9777/e+AD7zgB0/4whv+8IhPvOIXz/jGO/7xkI+85CdP+coLJe+kwwnmhwJabaF2nNqq2UmOKK58 mD4fAzk96gVieoKs/s/gMvlRMI7weNv+7KTElkFezwrU8973rA8+8Txi9qTkbHh3HSP2lE/bnM0a ZyeHOpenX7no/zf1vXd99rfPexGXE3PMZxj/L+tuFI/Z+dzNhX7tC5Z+jWmU1MiP6/ERAnzsr77+ MVZZ888//83HHvlE931Bgy9eZn6m5myn1Eufd2pyNTFZJ3y/x3r3J4HRRIBLc3w3w2/ld37wYzwZ +Fncxn4Mw4EJd2o7J3pZ13rCt4L2x4IjaDQleD2i539GRIIvZ4Ix6IH8Z4MEhIE9iIIuGIHax33F lXDklIF1BRXr1V6m0zM89F7mVFUJaDkIWHHVd0P6MoRauH3YR4RQhzPBE342FIXk52s5cWv3o3oq qHoF8Xvdlyg0WGvWwliWV4d2eId4mId6uId82Id++IeAGIiCOIiEWIiGeIiImIiKuIiM2IiO/4gr a/Z0DXE/BoV5cahmSuZ9kliEZWhgDbSJMUZ6steJIIcRl2gR4bRtpKh1D1hhiKWB7zV8rXhnkHWK FeFLvTV9PFRyUbh8Aog67Dd+X3hwWIhaA7hz4MeJ9bJkLheGJ+eMq5ht6idrpkaMnsgxFsOA0OeL DCh/WfiC3mh0hwWON8OLL8iN+rYU24hyoKd/rjiNO/g7xFiOTseMKHeESfiK2BiPP5gyy2d+6jiP xPM+77iPOCiP8Dh/P6heWndoDFmNSNiPBllu/HVkIuSOOphkPqiRJDiCn8iKj5R8DQiEPniAuDd7 F0iFy6gy14eMEEl9uCiMzah+0XdDA6hzYv/YfGFIkb/jO+mYQ2xhi890i7AilFBElI+YlHtnlNhy aZ2XfxSBMLn2cqIYlTUYerPnlKMIi0jpEsjGcUwZegdIhTjkjMIITf54jIxlgDU5ftvoltanWE43 azWJjTvpkQJ4hRuIjmQVkeJElhjZgUXok/DTXwcpg0ZHleAYWiW5ZC9JezzhiyfIj3/ZjvIChBLp gFFHjpx5gjCGmDaDgARpcZC5E5J5gfCHlotZMiBIYZmJaPjYmN1IMLFJkkC0gwwZjTtWQJOZjoU5 ktvmSDnImYn5mrKZg7WZj5WJgx+pm2fImCr5aNCYjFlnMWNZYSsZl3Fmna1pfajZW2IIb13/JoUI dJefAoqmWBRh6Vm1V4qXp5TwGZ/yOZ/0WZ/2eZ/4mZ/6uZ/82Z/++Z8AGqACOqAEWqAGaiwPRYeC mXlBkYoocU4aMikXsifsOEQKKkJy9DeuGREaahMOOnoT8SRXYiVQOURbyYq6txAbaqIq6qFz9V9V uIzhR2fhKTyG8iffoYpSGIIj5DtPSI11aZNTyI3P16NPiIUtsY4ltJHu5z48KE036iiAEpwd2X4F CYwSCXqx+ZiUWZpHOY1ktJEFNoZ2djH/FaWG0iSA0ZzDmTROaISDCWc0SZygqZoXCqLwSKXHuaex yB+IohtTypHiyI9Kmo8KiZfA2ZkzuE9F/yVqitqNEcmkfiogXSIoywlzvvmBmJqoI5mcj/qbfWpT Kfls4Kd85XmT39eWmWMpSbIemqGjpQpnM8llwWhy2Tmrp1qNxbijQ4OknKdbstiVxOdZd0psk1iJ u3SgyrqszNqszvqs0Bqt0jqt1Fqt1nqt2Jqt2rqt3Nqt3vqt4Ep52vGqppEmHRIhhJGu2lEd4xoh 64ojuSIkvIEn1DGhrZqunDGv+GokFtIv/SoacdEa69EZ/Tqh+Vqw5JqwCLssC9uw56quC6uv9uoY 9Zqw/kqxAWux7hqxEvuqDouuGsstH0uvIRsbC/Gu14Gy+mohKAuvtjKy+Oqwj0KyB0uxRYNSsgyL sTT7sTObrzWbsR3LscgCsz47sj1rsOgKsyzrsr3yrx2LtE57rz6btDrLr0zLK6z6tAorr0tLKRAL tKiBsyLLIO9qspNCsA8ytRNbtv/qGmUbrnAbt3I7t3Rbt3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uPoZEAA7 ------=_NextPart_000_0006_01C76F8B.45F30440-- From gbaefc@carlyleny.com Mon Mar 26 07:00:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVmvl-0006Wb-Sw for sip-archive@lists.ietf.org; Mon, 26 Mar 2007 07:00:06 -0400 Received: from [88.229.201.77] (helo=cooby2.infoservizi.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVmsA-0004Wc-GP for sip-archive@lists.ietf.org; Mon, 26 Mar 2007 06:56:25 -0400 From: "Graham Shapiro" To: Subject: Busines proposal for SHARE owners Date: Mon, 26 Mar 2007 10:57:07 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Thread-Index: Aca6Q**G+30B>630+P=*(FOQ1J2*59== X-Spam-Score: 1.7 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c an online petition drive Thursdayraising at least $200 million. Turner said those fears were unfounded. of his presidency withSMU emerged last month when the site an online petition drive Thursday Hello! stock holder, We are a stock promotion company and we can encourage any sort of stocks. We have been working on US market of shares for 3 years. But these days it is getting harder and harder to work on US market. We are looking for grave partners in Europe with whom we can make business together. That proposal is for you if you own a company and you want to promote it. We promote stocks by mass email advertising. Stock owner We can increase the cost of your SHARE and we can increase average day trading volume. We can increase price up to 200-250% in 2-3 weeks and also we can increase capacity by 10 times each trading day. You don`t have to pay anything in beforehand. First we increase the cost and the range, then you pay. Payment: Our cost for that is 10% from the daily range. We tally up it by the following formula: last price * daily volume. If you are interested in our suggestion please write me back to the following email: stockadvert01@yahoo.com ministers from in the library competition University to stop trying to land George W. Bush's presidential library. Wednesday, SMU President R. GeraldThe project think tank dedicated to with just SMU, the 11,000-student, private university, which is first lady Laura Bush's alma mater. From sip-bounces@ietf.org Mon Mar 26 07:27:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVnJ3-0003l3-0v; Mon, 26 Mar 2007 07:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVnJ2-0003ky-8K for sip@ietf.org; Mon, 26 Mar 2007 07:24:08 -0400 Received: from [202.144.91.185] (helo=SINBNGOG001.TechMahindra.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVnIn-0002MX-50 for sip@ietf.org; Mon, 26 Mar 2007 07:24:08 -0400 Received: from SINBNGBH001.TechMahindra.com ([192.168.5.35]) by SINBNGOG001.TechMahindra.com with InterScan Message Security Suite; Mon, 26 Mar 2007 16:42:40 +0530 Received: from SINBNGEX001.TechMahindra.com ([192.168.5.31]) by SINBNGBH001.TechMahindra.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 16:45:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Sip] SIP Traversal through firewalls/NAT Date: Mon, 26 Mar 2007 16:45:29 +0530 Message-ID: <089781E831473740B23334AE52636CD301293159@SINBNGEX001.TechMahindra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Traversal through firewalls/NAT Thread-Index: AcdvmA+9qPuA+8Q/SSipxuD0WvYDZQ== From: "Smitha Harish" To: X-OriginalArrivalTime: 26 Mar 2007 11:15:29.0065 (UTC) FILETIME=[0F978990:01C76F98] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.6.1039(15072.001) X-imss-scores: Clean:60.26770 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) X-Spam-Score: 0.4 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000456340==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0000456340== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76F98.0F7FC902" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76F98.0F7FC902 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How does SIP get through a firewall or NAT ? What are the NAT settings I need to configure on my VoIP Phone (STUN server settings) if I were to use the STUN Protocol as a Solution to firewall traversal? Kindly clarify, Smitha.H =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tech Mahindra, formerly Mahindra-British Telecom. =20 Disclaimer: This message and the information contained herein is proprietary and= confidential and subject to the Tech Mahindra policy statement, you may= review at http://www.techmahindra.co= m/Disclaimer.html externally and http://tim.techmahindra.co= m/Disclaimer.html internally within Tech Mahindra. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C76F98.0F7FC902 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How does SIP get through a firewall or NAT ? What are the NAT settings I need= to configure on my VoIP Phone (STUN server settings) if I were to use the STUN= Protocol as a Solution to firewall traversal?

Kindly clarify,

Smitha.H

 

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Tech Mahindra, formerly Mahindra-British Telecom.

Disclaimer:

This message and the information contained herein is proprietary and= confidential and subject to the Tech Mahindra policy statement, you may= review at http://www.techmahindra.co= m/Disclaimer.html externally and http://tim.techmahindra.co= m/Disclaimer.html internally within Tech Mahindra.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
------_=_NextPart_001_01C76F98.0F7FC902-- --===============0000456340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0000456340==-- From kolocpubua@rethmann.at Tue Mar 27 08:30:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWAoj-0006I7-2C; Tue, 27 Mar 2007 08:30:25 -0400 Received: from [218.1.188.113] (helo=rethmann.at) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWAoh-0000Oe-P3; Tue, 27 Mar 2007 08:30:25 -0400 Message-ID: <333101c77016$5bcab070$0a1326aa@kolocpubua> From: "Lesha Burns" To: "Maira" Cc: "Lawrence Stephens" , "Davina" , "Magen" , "Florentina" , "Jennefer Henry" , "Marc" , "Karole Collins" , "Mardell Watson" , "Lakesha Garcia" , "Isaias" Subject: All that u need Date: Tue, 27 Mar 2007 02:19:33 -1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_015_FB80_1BFAEC77.703A9291" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 0.7 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca This is a multi-part message in MIME format. ------=_NextPart_015_FB80_1BFAEC77.703A9291 Content-Type: multipart/alternative; boundary="----=_NextPart_521_296B_DD119F23.1F52755B" ------=_NextPart_521_296B_DD119F23.1F52755B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "That's fortunate." "Ah," switch know committee ornament said Andrea, = "who knows?" "What have lend you thunder to never discovered?" asked = Morrel.smile "Major Cavalcanti is happy already one, weather spell perhap= s; but the word "He lock is hilly extremely puncture prudent and thoughtful" "Sh= e told queue outstanding me come that she loved sink no one," said Valent= in "Ah, you see"-- difficult written "He is an orange admirable man," said the fight major; = "and he "In April forego you went to dine form ornament cloudy at the minister's.= You"No politics, felt Caderousse. And steel egg now shod that you have a= lrepeat "I have just discovered how cut a business gardener insect may ge= t ridbrainy "Not at interfere bee all, egg my good friend." "Here they are." repeatedly instruct complete "Well, what does that do= ubt prove?" asked Valentine. "Nothing," replied Maximilian.   unit The major heart knife clasped his hands in sneeze token of admiratio= n "Well, smile sir, mouth selection birth and what then?"fold "How? heap in= nocently touch Not at all?"different AT triangular FIRST SIGHT sail the e= xterior bet of the house at Auteui"Why, just important think for dug leg = a rotten moment; with this red handk "Yes yell easily indeed, there harbor it is tintinnabulary truly," said t= he Italian, "Then pour weigh triangular why overcame did you smile?" = "Why, episcopal you know very well that at month you copy are reflecting = o knelt "And here talk is Andrea sack crash Cavalcanti's baptismal registe = What, fly above all, messup manifested shrink the reward shrewdness of t= he "Ah, yes, science wire it was just after snow misspelled this that you sp= oiled"I will do payment my best," veracious mountain psychosomatic said t= he inn-keeper of the PoThe fail library plead was divided into two alive = vessel parts on either swas "Well, glow then, we pump will go geriatric i= nto Paris. But how will y "All quite correct." wriggle pipe "Do you company want memory me to go aw= ay?" "Ah, no, no. But do trouble tasteless not let us disease by lose tim= e; you are "Really, ancient your property note damaged manner of speaking"--"Wait," = said Caderousse, euxine concerned "we sail shall help see." He then t"Wil= l your excellency deign save pull to surprise open risen it?" said the"Bu= t, opinion vespertilian tell me," said dealt Andrea, "am energetic I to r= emain bareh "Take these news offend mowed scissors documents, then; they do not conce= rn m"True, beg stocking we must impossible be quick, envious for we have = scarcely ten condition "Ma foi," window front thundering said Maximilian= , in consternation. "I experience should broadcast think so, shaky indeed! If ok he were to l= ose the late return "It expresses my creepy meaning, and brought that is all I wa= nt."Pooh," said Caderousse; sit support "it pinch is so exactly windy tha= t your"Good," swim direction he said; and muscle M. nut Bertuccio left en= raptured,mix grease damage "Come, come; enough of decay this," said Caval= canti. road history "Well, and if bread he were to lose desire them?" said Monte= Cr copy challenge "Yes, you are right; I am cerebric cause but a poo= r friend to you sea "Well, what harm does it noisy noise signify, Valen= tine, so long as   "In wire that case," clearly plough replied the major, "it meal would be = ne"What regret are you waiting for?" said ugly depend pump Caderousse. "I= ho ------=_NextPart_521_296B_DD119F23.1F52755B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"That's fortunate."    "Ah," switch know committe= e ornament said Andrea, "who knows?"     "What h= ave lend you thunder to never discovered?" asked Morrel.smile "Major Cava= lcanti is happy already one, weather spell perhaps; but the  &n= bsp;  
word "He lock is hilly extremely puncture prudent and thoughtful" &n= bsp;   "She told queue outstanding me come that she loved = sink no one," said Valentin     "Ah, you see"--&= nbsp;
difficult written "He is an orange admirable man," said the fight major; = "and he  "In April forego you went to dine form ornament cloudy at the minister's.= You"No politics, felt Caderousse. And steel egg now shod that you have a= lrepeat "I have just discovered how cut a business gardener insect may ge= t ridbrainy "Not at interfere bee all, egg my good friend."  &n= bsp; 
"Here they are."    repeatedly instruct complete "Wel= l, what does that doubt prove?" asked Valentine.  "Nothing," re= plied Maximilian.    
unit The major heart knife clasped his hands in sneeze token of admiratio= n   
"Well, smile sir, mouth selection birth and what then?"fold "How? hea= p innocently touch Not at all?"different AT triangular FIRST SIGHT sail t= he exterior bet of the house at Auteui"Why, just important think for dug = leg a rotten moment; with this red handk     &nb= sp; 
"Yes yell easily indeed, there harbor it is tintinnabulary truly," said t= he Italian,    "Then pour weigh triangular why overca= me did you smile?"  "Why, episcopal you know very well that at = month you copy are reflecting o     
knelt "And here talk is Andrea sack crash Cavalcanti's baptismal registe&= nbsp; What, fly above all, messup manifested shrink the reward shrew= dness of the      
"Ah, yes, science wire it was just after snow misspelled this that you sp= oiled"I will do payment my best," veracious mountain psychosomatic said t= he inn-keeper of the PoThe fail library plead was divided into two alive = vessel parts on either swas "Well, glow then, we pump will go geriatric i= nto Paris. But how will y  "All quite correct." wriggle pipe "Do you company want memory me to = go away?" "Ah, no, no. But do trouble tasteless not let us disease b= y lose time; you are 
"Really, ancient your property note damaged manner of speaking"--"Wait," = said Caderousse, euxine concerned "we sail shall help see." He then t"Wil= l your excellency deign save pull to surprise open risen it?" said the"Bu= t, opinion vespertilian tell me," said dealt Andrea, "am energetic I to r= emain bareh        
"Take these news offend mowed scissors documents, then; they do not conce= rn m"True, beg stocking we must impossible be quick, envious for we have = scarcely ten  condition "Ma foi," window front thundering said = Maximilian, in consternation.    
"I experience should broadcast think so, shaky indeed! If ok he were to l= ose the  

late return "It expresses my creepy meaning, and brought that is all = I want."Pooh," said Caderousse; sit support "it pinch is so exactly windy= that your"Good," swim direction he said; and muscle M. nut Bertuccio lef= t enraptured,mix grease damage "Come, come; enough of decay this," said C= avalcanti.  
road history "Well, and if bread he were to lose desire them?" said Monte= Cr     copy challenge "Yes, you are right; I am= cerebric cause but a poor friend to you   sea "Well, what= harm does it noisy noise signify, Valentine, so long as   = ;       
"In wire that case," clearly plough replied the major, "it meal would be = ne"What regret are you waiting for?" said ugly depend pump Caderousse. "I= ho             
------=_NextPart_521_296B_DD119F23.1F52755B-- ------=_NextPart_015_FB80_1BFAEC77.703A9291 Content-Type: image/gif; name="qduihaisihewae.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhPQEvAYQAAP///wCZ/wAAAP8AANzZ3L/G3a2zxWZmZnKK08wzAIyYvjVxripjoeTAkdCz h66KW+iMjJxxTv/hm//MZpRgKjorO1pSWtxSUuFrawAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA PQEvAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLvMCZmtgzUaX2F+3qg0n1dMvuhx2v+Nbemtvglx+KIF7hn+HiDJ9hIssj3txkHOEfoqR dpOUkpabgJaTg4Z6J6cjdZmCbSKpjJiQgSawr62JaK6mdLW9t3KawKWcuqzBo7jJrmHHqsvMAI3P tMPS0My2vm7R08C/37mIndHXqaugxZTH4ObU6t3VleLv1uiyyPj51vaz6dvt7qVwRsycMU/8suHj t61hPYLuHupj2AUiuYKo/C2MKJGbMHigBJaC2JEiLGFw/j5y/FaMIamSBttV1NgSXr2M+TzqLChy xcee11jehPlI6MpBQS+tC7kx4bJ+8mbmvNnzZcRfKQlaHfgPas1ODqs25XhRqS6DX5+6bKqykDey tt6OoxaQbTmHONeeVCQSG7tyd2NpA7pVbFS3g7EBTHc4K09oSrnubAn28eRhvLqhFRX4qtqVhGWG Gk26ZunTqMd0Ts26tZqurmPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868OQAB0KH3ENCC OnUU11Vkx7G9SHfnVLZ/tzHeRPkR59GXSQ/eSffs0U9YFy/9eX0S95/rF5Efvnzp/unXX37qCfhd gPYh/niddSXMx99+CT4ooYHv3ccge+C9N+GBC244YYH+dQghgCmIuF99Jh7In4kejtgigfY9aKF6 CioIIobtQSghggWeCKJ5QLIoo3Y09pgikC42mKSPO8pXpJFDXuhkkzmyoOGSUCap4pQcphdiltHB eKSSNmo5pYD4/ShlhOiF+WGV2CmJ5Ys/ypmmkEyeySCdJbZ4J5h12rknnWtmmSacRBq6ZZ54Hili gOeJh9+jPQY6nqRU5jnpkIpaCiiiJbo56aVGWsjhnyseimaDPDrYJqlzvhnfq3gaKGt/pVZYJqjr rYCpDzjyKqyqZ76pQ7DDJqvsssw26+yz0EYrbRED/gxggrUiYOsCttr6UO233W6rLbgjgFttueOG O20W55LQbrvbZjsEvDB8my23+KJ7r77rcnHuv+YCDAC8BMv77r4HD2xtwvTu6669Ckes8Lv5Smyx wNdCPHG+Dff7g70YU7xwxQMbPPLIEYOMssoZP4ywwChLTDG/G6s788UnezwvxxXfXAK3KcOcs9Ax u8xvyOk6LLLG96orM8k+6/wxz0qT7K7JJa+8cNYrc93y0TET3PPYDzNdtcNPSx3EzDdHXa68E8fd dNbo5vz12T63DXXSHesNttpAsD122ECXPLfGKqc7dLf0Cl603zijjfTZLzsNOA6QC3003JFLnvTL /kbXTTXN5KIdtL5ii+1yx5cfwTq7ljfxeetKvI6F7bKbTfvuvPfu++/ABy/88MQXb/zxyCev/PLM N+/884iGKf301Fdv/fXYZ6/99tx37/334Icv/vjkg88DstAHh76V6Wd4fvvOre/rCwTUXz/8ucmf 6Ar2938//rXRX5/4VwD/1a8ABQTgbAQYpxQQwAAQjKAEI1iAGhygBBcUQQYVWAUGFqsEBECACEdI whJWcAYb1GAo6AOfWYEhAZHwIJJOoIAF2NCGDGDAAhCgwxuKkAA02GAKhXiAFAKgiEdUYQaLaEQl zIhTxvJBAqa4AhiyYIpWFAEWUbDFEXQxCFYM/uMHb3AeAyyghzm8oRptiAAgonAEQ1ShBpc4xzom UY5LGNSXViUjF6YKfVnM4gkEyUUAwDCMhySkIROpRUYSQYwzzEF6arjGStrQAG6UgRBJ0EQk3vGO TfwkE2z0qxiNCUYpICQiqajFVrrSi4YcpCKpyEpaznKRXmRlLFWJS1dC0k6SVMEDz5jDYhZzh5i0 wQWNSEQm4pGOcHSme6BUSkr56Yol+CUkA5nNL+bSBLZsZC9JUMtY+nKW2/TlGMnDggLw0JhpRMAJ lSlKUEbzmfjE4yipSSxrxiqV2XylNs3ZTV2Ok5yODGdAW4nFcoITlub8JbG4I8wDKuCdOkSA/gIK mEkLmgCa0lwiNEEZSiPo8Ukf8ueCkMVLgg5UkQz9pix7qVBywvKWD1VnRNdZg/McsIAINIACFGAA BHK0o2/E4D09ecRl6hOJJT0CC2klJxaR6AXcFOgrCWrTQ4qzm7ispSMRGlOdgnWnaAUmRR1owLb+ bwlRTc36vJlVQcJ0kYFsqEzpatCb5jWrAdVlOiO51jAwMa6kEdUQ7srVHjC2ijSQoVo5OIPHCsGy AJ2BZCdK2eFstlLB7OxoPtvH8pn2tKhNrWpXGx/Wula17xNtcUirI9mqL7a2FQ5taZvbFeK2t7/Z LXBvuwPeDvcPwq1oA5Zrv+OiJrkoWG4D/hxAXQdI963OxawXoGuC5Vb3u9VlLlJ740I/JsGbg2wB X++63sWaFbRkTIF3wftd8erWVMbFamNzWkWDojeXdu2rFN8bxZ6igADTfQB9F9yA8cJAmvr8aITD g9L8YnOr/AWoV8PaV4XW9LIYrm18T5DgBX8XAt91cAs2uWIwnJRIiv0jDFqqV7PyEqbo9fBY/Qrg mwa2riHm7ggI4AAIKLi6KHbAAyCA4iMr2QFJheMzmWrPOSJ2nzz6D6NSpV+butTGBUWnKhO6469u OKLo1KlECxzZExD5AXA2cpzhTGcFyxnKmkTBSD0JUilT+J+HGpOIVUBjiHITx3yVZRc//qzVhq5Z q2hVpJBHYAA4R4DOcq5znRWg4hWUtJN9rucUdtVAQQNyoUAu60PzykUyH7TRGYZopIP8WxIUQNO4 tvQDNtppT+s5miGd8pWR8Cv2qJTLXf7ye3G8y6+SVcevpqmyEa1mWhc3BZW+dJ0jwO0HPBC7eeak HIk4bglHQXorwpA/TSkDuhray+AUrKPN7F8B7/Kvsu5qqiVdaxI8kNsA73ZRe/1gP1c52FUWdWks vND0AkG7Do/BpIc8XQb3LwcQ/iRUQ93UYZshxmBkAsRj7YKJi8CtKHfuIkyO8parHA8mB0DL3boJ hvcu5i9f4Pnc9Nqe+/znQA+60Fnb/u+cB7DoRtf5tZOOG5wznTVOf/pzkS51qFO96lNfOtbVS4OR m/TqSPC4wccuhamK3N7trjd71e7etMKXnQeeeVs9KnaFd5DURwBsxDWMZryCVazR/sGjWS53mr+R mU21shJZ3HEpU3kILx70ncx7VRfQ+IsD7aqi/47IaI8V8439PIEl32Y3F96A84yBUzkpUseHmsV8 JrahsLMnSJ3ay/vON15vOWaallnauE/zrPdL+NP3L/UvYLzGxQ37fCqfCHhHkqlnjOp3qxqh9Z4p 4AV86Bozu9rEL7rx/YdAFB5W3E9dPkkRbncgRL+qfrq99dN65sDKNN6+97yPGw7v/sHyW+v+dlSn VwDJFG6ipHyrd3Dm1n4/8H6B9iJzJWupFmLN1nmcl3/cJ0YTSFbD93/HcmAEOEEiOEHI5wKIl0+L V27q93yQNyrsoymVh1X+NX/71Uh/tWirhH3pJW96x2Pgx1lw52ZGNYREOIQElwInqH5KlHjCZnB1 pwU2p3vwNmCVpVlgxzsg93Ai13VWCIBb1xpR94U1d4ViGENkWIbIdYb9EoW8EYaywYbCIkO7NXR0 WId2yHN3mIeopYZo+HF82Idk4IaA2CteOIi+VYiGaIaIaAIpl4hZ4HSF54hWgEoGxlYzV36S+Gcf CIJG1XKYGGUTRoil4XVQiHQE/hBUqEiAqVhUCRREZAdzVPBf/JdKbLd5PQZibsdmXciIEKRRQgVB RPWLQmVUHvVUTLVxrLdnT0CJS9CDs7iDfZdjroZ2jmVtm2gCBTBU2riNIwhBR4iEB+hnCNd8Twgs pAdjlDcoXBd8ggVp+1dQF8hhq4Zv13dv1ueBoYWNQyVU26iNIshp9PRrTChqdFSODahZtXcj1Id7 96h7NaaDz9Z5GahqFsiB/kdYI6aP/ahRF8WR2qhR3/hrzBRSjHd+oZhHXTh9yQZmX4Zo2Yd/24dT 97ZoEXeRkxWEIHRR26hRI7STCGAAxaiEraeC9mSQ5igDx6aLsZZ5h1ZIrKZ9/hIpk/VHgbkXfosI AAZQQiX0kSAZlLA3lAdXkOeWkhAYA4C1gcy2YRMJbRPZbKMHfIMFhJXoZlmplVoJkK6IfokHluSW gEb5h1RCH+fYanZFg2t3g4Dnd7f4Y4v5fVUpl6V3YFl5AHYpQgU4LXDIWKS4kO22i/komR25lQMX LVkoeFtYhUhJdccXghQkgJk4aqo5fiH5mi14lbI5m7QZBIKYm1uwm7z5iDunh8I5nMRZnHk4mBL3 m7B4lcq5XYDZnJr4mdAZBr45nbDJnNYJnNhJBIfFgsl3A385G5uJBb45dwFJlAYIHLI4hbQoZjNl g9SYA3H5dnNpAhJgeuRX/oLfKY4D2XGbxGcA+p9JBKBLSGUZ5ysoAnKluQPOyJ7QGGAZKHxth4+F VQL3iZ/+U1R5OW4cl3AcN5QEOqBMqIwvqCOLQp81cHntqGzvyFAdJo07SI9u6YPDB5meSQISkKM6 qqMGEAEKEAHdaZTd6YTpt4LOR6QFyp8nOUApRSoxFoMXNn9xOWYzmGOvZm/lVFfCZ5M2mponMAFg GqZhSgEVUKZmWqYWgJuvuIJDaqT+SaLL55dW9njaUUoJMiBMslKcyZJNGW8OJYsvyV+JRJOC+oMo eqMnJ6aKSqYW0KiOWgEHoKah2HwL2KEoKKCUuoteUieCto5SCmvQuHv//hWoDTeVNViVFJqRJWBd igqmEeCosGoBCrChejlSHkqUcIqpSsqAXDI/gXlNnnqWW5WWoZeYB4V2WUqDe2WoSpmcbuZk3wWk QYqX6Ymk/omkAWqtutqE1REobfIpjyI/7rZshOmnzkaq+taYMdqQN1mf/kZk9NWNregb5VUpfqRS 6hhyhaSFqOms1+gCLictbDie8smFXvqvw7OgzVGd2QkFDNuw07SdEBudFeoscFiKHfScE7tPxfU9 d2qcIBuyIhuyyAkDF7uxFauqKKudCLuyVyCI/uOyUkWG8FpfkiqzByudJ2Bi1HWzOPsCTsez1eWz P1uiOksCDfAA2lZd/nRWXcRhdrSDc0oWjNSltBBUtUSbhEq1pJPogGFAsJOomnQGREpGAUAJrw8A lLRqd+GJZbPnJAqar+oVnzVorosJj3drmrlYskDrQE0rAkpLtn/rlcCGrfwZok3gtTKmJRFIgVK4 atH4ohgItguZqjgJQnUGRKcoc3QWAWq7oSSaqSBqq070ttIXf3uKZivag6aqmN8Uk/Oorjf2mIea s5g7tjJXQQTQuZ8bZaG7q6PLtdBnuvC3JPJ3TqvrkKcqubDLmDbYovbIrHxbcn5rab2rtHBGAbNK uFsrupcasYDGqcSbWZ9Kf2Fmt68blfg3oxW5rDVau/7KiEoLcA5Q/j8OEHAUoJ8FN0Ts97soiJLA erqMm7pMWYGKFmBQKU7c51eEWqrSK7UUEMEUgL8TPMFEu4RHiqvfm7gu6KtWJbeEVn1gxl4utXaT W6gy2X8PfHUEEAES/MISbAG9G5QklcG3KryiaHkSaJgP6mzpe8JndWaPBpej53QGAMMvLKsXTHZQ dan9u6brYV6WN4PkaouiaoHtFbvPS5XjNJ/NarLC5AA/CsON6rlLLDyaqa+dabsqC0L2O1Tcto/N xUGUawMEO54na3xFe5Qtu8cOq7F+rJuAHMgHGUwnS8hGm7KIzLF9vMil27EjG8mSPMna87F16MiY nMmavMmc3Mme/vzJoBzKolw7pcMuMVDKc1M3VyOJARM7UIA7GVPK5oIwb5OJqiM6ppM6TnPLAYMC s7wxKZA5hTMur/k6vXzLNWMzn9PKJzDLvdzMZCMzaVPMuDM5nnM3ImM6RgMxtlM6vJwwuWk2x7w3 vxw6GKPNf4POTTM7fZPK1JzOXkMz0Pw3VrPNs2PPlLPK/+KIyJw3DYPM14wzu7zMrCPM1wI3rrx1 zLzOqfMz5Sw63PzMsXwyusPQ+KI7xAzLCo3Kp6POHK3KkOPLS6MCqIzRZTPKDo3SX6DRKi0FLN3S MB3TMj3TNF3TNn3TOJ3TMwABOo2GCFZkTBbUQj3URF3URn3U/kid1Eq91Ezd1E791FAd1VI91VQN 1ctlBAQAARcAABjQ1VX91WAd1mI91mRd1mYt1hhwAQlwARBwxtGV1m3d0yvQABiw1g3AAwRwARdw 13L9Ag2QABjg1g0wAHzd1zGg1YVNA1rt1jmd1zxNA2nN2D3N1jPgAFtt2DiQ14ndAnkt2X1NAAOA m5QNJxWtA8SMBK2c0CQ9zxCNOImj2jIAARjg15KmsGwswO2a24S1WS89A6ftOlrj2+LMORbTOcXN AwkQkhjw2P3UyDbKW1dyA8b8MzLw20bQMzXQOHsTOtIMBLKtw7v9KkEyVVL8RHoawJ6SbmwSIZAS I+qd0ndz/twsYN3XrTQH3QLaHdC5vDU7QC953QINcNlq1anu7SgC3CHWtKlmAkWZct6RBzoMncwA wziFwzV2M+Fyg+ERHczKrOF9Q+Ge89DqXDYX/TT7TAIXcIQOMNvhPSftzeCyAuMg/ICZEuNQtEe1 xTL7rcoZXuHRTNCc0zYkDeKVo8353TnGbDnfrOMdgwGbfQJM9kEE/uJ8BFoIzirGFn8oIijG+7Hw DdD93M4Ijd2UA+SGI9Lm/DjhcuRhftBKbub5PAJRvgJdLeXASuVyqyFQWivpjSr85CHn4c+Gs88N vcpnHjdMQy7ijOFDnubGvePG/c8eDefrDOXMnQJzDkx4/ofnIpbgeaqLp4RSKbUpfNQdgs4xPY7q xJ04Dm03IH3k8qw6G87dg+7o2w3h00zcls4CmT55ujJDLXTepJ6npKQn5ZWgwy4p+NXqF17ojE7L uk7fQd7MtRzri843/7zoJA42E07OuGzRJtDrKCDuLsZTORuFvd0F6R4FEi0C5B7ul06dGBmZX5zd pS0GReMv1E0C714C/Y7Z8/3R/y7n8Q7wOTDw7l7wBn8DCA8ADb/wMNDwDw/xLiDxBS+Hun3b5GFc hzxAHf+HFmbxfFzv1CuxhPjxJg+/iq3w/n7xffQfgqmnV77e60157i3eMp6gu1KvTaLse9RapfLe Nd/p/iQyIAiuIjOyUlCbhfUKIMte5Yz74C0g8SweaELy4leF7Ate6qQu7MLOJ2B/ShWyIylSIy5i e6V2bFve9VzG6dWkkFz/8sXbQirP7yxPAiuO25EC6H1+9Q00aI3irXG/ZZ3e92gi9VSu93xv44Sv KaTn9n9OJvwkP07OAgGu+Fhu4A2uWMce3SwEpVt/4+m9KNMnJWaHbo8PgUDP+GXf+VQ1Kmtf6jwH 87RSKC+Q4p7a52G/9Qpur3Dv+KE/+KHO5V1u+nA77w3O+sSfZZNlp5LP+DSu5zHw3y2w3MVbWw5e Yah79vYarm0P7MZSbGD/rY3fqTjO54R//qyS/Mn//vbtH/nRL/hTX/VzTUgEzm7ppvQfvPQE4irf WisgIIgAKZAnYKKiWrIlCo/w+dJpbKcz3q9mKzgL5na1X2sn5NV4ROcwdlPpktIrIEHAXjEQLjgs HpPLZas5rRaj19e2Oy5/pyEYM+GynfP7fLhfIBbgHKHgIZehFMGAWsMFYqTkJGWl5aUfAUbDGoYe Jmio6ChpaUzClxvEp2mr6yts7EkD6lzDQKqs7i5vr+oFZ5+ng2+x8fEuRALGnl+D5yay9DR15PNy 8yHB6sUFhhdEuPg4ebn5OXq6+jp7u/s7fLz8PH29+3f3Ra4lQYP9P8CAAgcSLGhQoIMG2aoxbOjw JSHEiBInUqxo8SLGjBo3cuzo8SPIkCJHkixp8iTKlCpXsmx5KQQAOw== ------=_NextPart_015_FB80_1BFAEC77.703A9291-- From sip-bounces@ietf.org Tue Mar 27 09:02:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBE7-0000Ak-TH; Tue, 27 Mar 2007 08:56:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBE5-0000Ac-R3 for sip@ietf.org; Tue, 27 Mar 2007 08:56:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWBE4-0006Dy-Ca for sip@ietf.org; Tue, 27 Mar 2007 08:56:37 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Mar 2007 08:56:36 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2RCuame001440; Tue, 27 Mar 2007 08:56:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2RCuHli001542; Tue, 27 Mar 2007 12:56:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 08:56:33 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 08:56:33 -0400 Message-ID: <46091480.8060908@cisco.com> Date: Tue, 27 Mar 2007 08:56:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Procter Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 12:56:33.0265 (UTC) FILETIME=[588CC610:01C7706F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6880; t=1175000196; x=1175864196; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20 |To:=20Michael=20Procter=20; bh=dZtUopURQfNNvWiCJiSM7GeqIPjU3EwopllrEqvf6+w=; b=bkB4K+9SO7s2vG+lS1IuGBEihyWhDNza/0awV5hjw9W6jr+vmpV+hUVXGM4VOOMfUttxC5pf f2lFZvcmE5OjKHwUX48Kcum9JJMF+SuPX5kqeobmQSa20UBy7zYZ0BkD; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Its not moot, this is pretty much orthogonal. However, I believe it works just fine. Lets walk through a call flow. Lets say you have a UA X that doesn't support GRUU. However it includes an instance ID in its registration. The UA has a contact sip:x-contact and the registrar assigns a GRUU sip:x-gruu. However, this gruu is not returned to UA X and UA X has no idea about GRUU. Some other entity using reg-event (say UA Y) learns this GRUU and sends a request there. This request will have a R-URI of sip:x-gruu, and arrive at the home proxy in X's domain. THis proxy, following normal GRUU procedures, will replace the R-URI with the registered contact. Furthermore it will record-route if there were Path headers. In this case it didn't actually need to, but it will anyway. No big deal. Lets say there was one path header, sip:edge. So the home proxy puts a record-route in of sip:xs-proxy. This arrives at UA X looking like: INVITE sip:x-contact RR: edge RR: sip:xs-proxy which looks like any other invite would. Now X doesn't do GRUU so its contact in the 200 OK will be sip:x-contact: SIP/2.0 200 OK RR: sip:xs-proxy RR: sip:edge Contact: sip:x-contact This arrives at UA Y. UA Y will construct its ACK (and all subsequent mid-dialog requests) as: ACK sip:x-contact Route: sip:xs-proxy, sip:edge This arrives at the home proxy due to the route header. Since the r-uri does NOT contain a gruu, the r-uri is not rewritten and none of the gruu procedures in 6.1 of the GRUU spec apply. This gets sent to the edge proxy and then to the UA based on standard, normal, mid-dialog request routing techniques. What won't work is that, since UA X doesn't support GRUU, once the call is set up to X, things like transfer won't work. But, thats OK, there won't be any expectation that it would since the Contact didn't contain a GRUU. So, net/net is that I believe the current text works fine. -Jonathan R. Michael Procter wrote: > To be honest, I don't know. I noticed temp-gruu lifetime being > discussed extensively during yesterday's session, but I don't recall > anything relating to this being raised. > > My concern is purely related to the idea of GRUUs being invented on > behalf of devices that don't support GRUUs. I hadn't realized that this > was possible until I read this from Jonathan: > > : However, we ran into an issue that a UA might register with an > instance > : ID but not support GRUU, and then something is subscribed to reg-event > > : and wants to learn its gruu. So you don't return the gruu to the UA, > but > : you still need to generate the GRUU to deliver in reg-event. > > I think that there are nasty behavioral problems if a gruu is > distributed on behalf of a UA that doesn't support gruu. > > So, my questions are now: > 1) Can a registrar create and advertise a gruu for a UA that doesn't > support gruu? > > 2) If so, how do we arrange things so that the scenarios I've described > before don't arise? > > Michael > > Paul Kyzivat wrote: > >>Is this discussion moot at this time? >> >> Paul >> >>Michael Procter wrote: >> >>>Paul Kyzivat wrote: >>> >>>>Michael, >>>> >>>>There are more cases for this. A fundamental problem is that saying >>>>"Supported:gruu" says "I support the gruu option". Its at least a > > bit > >>>>weird to try to make it mean "I want you to assign gruus for the >>>>contacts in this request." >>> >>>If a REGISTER message that includes 'Supported:gruu', means 'I > > support > >>>the GRUU option', then I don't think it is particularly weird to > > read in > >>>the additional meaning 'and if you also support GRUUs, please > > perform > >>>the appropriate action'. >>> >>> >>>>Suppose it meant the latter. And suppose there are UAs X and Y both >>>>registering for the same AOR. X registers first, and indicates > > support > >>>>for gruu, and provides a contact with an instance id. So it gets a >>> >>>gruu >>> >>>>back for its contact. Then Y registers, indicates support for gruu > > and > >>>>provides a contact with instance id. The response to Y's register > > will > >>>>contain contacts for both X and Y. And it will contain the gruus > > for > >>>>both X and Y. But it didn't cause the assignment of a a gruu for X. > > So > >>>This paragraph appears truncated. I think I agree with what is > > written > >>>above, but you may not have reached the punch line! >>> >>> >>>>Then consider a similar scenario, only X didn't support gruu. Now > > the > >>>>response to X's register doesn't contain a gruu. But does the > > response > >>>>to Y's register contain a gruu for X's contact? >>> >>>I don't think it should contain a GRUU for X's contact, because I > > don't > >>>think a GRUU should be created for X if X doesn't support using it >>>properly. >>> >>> >>>>As written, the registrar doesn't have to remember anything new. > > The > >>>>decision whether to return a gruu only depends on what is in the >>>>location service and whether the register request contains >>> >>>Supported:gruu. >>> >>>I can see that minimising the state required in the registrar is > > good, > >>>but I believe that this approach will lead to odd failures in > > operation. > >>>I discussed a couple of these in my earlier email. >>> >>>Back in the pre-GRUU days, if you obtained (by whatever means) a > > contact > >>>uri, you didn't know for certain whether it was globally routable or >>>not. But you could try it, and if it worked, you knew it was (at > > least > >>>sufficiently routable for your purposes). >>> >>>But with GRUUs invented for non-GRUU-supporting UAs, I think you can > > end > >>>up in a worse position. Given one of these GRUUs, you can use it > > and > >>>find that it initially works. But once the dialog is established or > > a > >>>target refresh occurs, it stops working. It might only stop working > > in > >>>one direction though, and the failure might not be noticed for some > > time > >>>(e.g. an hour for typical subscriptions). >>> >>>Some of these bad effects can be countered by careful record-route >>>behaviour, but I don't think all of them can. And in a way, the >>>existence of this GRUU draft proves my point that the problem can't > > be > >>>completely solved by other mechanisms. >>> >>>Regards, >>> >>>Michael >>> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 09:05:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBMO-0003y4-Qz; Tue, 27 Mar 2007 09:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBMM-0003xr-Oj for sip@ietf.org; Tue, 27 Mar 2007 09:05:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWBML-0000qz-Bn for sip@ietf.org; Tue, 27 Mar 2007 09:05:10 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Mar 2007 06:05:10 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2RD58FI020909; Tue, 27 Mar 2007 06:05:08 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2RD55wt002620; Tue, 27 Mar 2007 13:05:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 09:04:58 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 09:04:57 -0400 Message-ID: <46091679.8030804@cisco.com> Date: Tue, 27 Mar 2007 09:04:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] GRUU - what is there to talk about? References: <45F85073.7040009@cisco.com> <45FBBB87.9060005@nostrum.com> In-Reply-To: <45FBBB87.9060005@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 13:04:57.0809 (UTC) FILETIME=[85481410:01C77070] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3515; t=1175000708; x=1175864708; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20GRUU=20-=20what=20is=20there=20to=20talk=20ab out? |Sender:=20; bh=nPjEmaCEVtVC/STCKZhQofNOywG+08pfUzqXtejehCE=; b=dsWhgXoFPUPuQhN1JNokh7hUuGC7+ITzRWTq0dNM88tRMaeAC7xJa3Eee+bOdurdN6+3c7ED nR/H1ILoxJ1YCA2oYYJaGmbR+jDvuf4jme73XtDWlf+Ridpp0+6non+T; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Adam Roach wrote: > > > Jonathan Rosenberg wrote: > >> The problem that was raised on the list by Paul K. some time back, is >> that you might run into problems when the server forcefully terminates >> the registration. The client will re-register, but how does it >> synchronize its set of temporary GRUU with those the registrar has? >> The solution was to use reg-event (necessary anyway if the server is >> forcefully de-registering users). So, the client would use reg-event, >> and if it sees the server expire its registration in the reg-event >> notify, it discards its temp-gruu. > > > I can see what you're getting at here, but (unless I missed something) > the intention is far less than clear in the current draft. > > As far as I can tell, there are only two sections of text that address > this: > > In cases where registrars forcefully > shorten registration intervals, the registration event package, RFC > 3860 [23] is used by user agents to learn of these changes. A user > agent implementing both RFC 3680 and GRUU MUST also implement the > extensions to RFC 3680 for conveying information on GRUU [24], as > these are necessary to keep the set of temporary GRUU synchronized > between the UA and the registrar. > > ...and... > > RFC 3680 [23] defines an event package that allows a client to learn > about registration events at the registrar. This package allows > registrars to alter registrations forcefully (for example, shortening > them to force a re-registration). If a registrar is supporting RFC > 3680 and GRUU, it MUST also support [24]. > > > With the context provided by your email on the topic, it's pretty easy > to figure out what these passages are intended to mean. However, I fear > that the chance that an average developer has much hope of doing the > right thing with this information is very slim unless they happen to > come digging through this mailing list. No doubt. The idea was that all of the logic for this would be in the reg-event spec. The problem only manifests if you are having the registrar shorten registrations, in which case you are using reg-event and the text there would explain more. That said, it can't hurt to add a few sentences here motivating the problem. > > In other words, I believe that we need more clearly defined procedures > for client handling of NOTIFY messages for regevent when they contain > revised GRUU information. I imagine this would primarily consist of a > more formal version of your email on the topic. > > --- > > And, since I have an email open on the topic, two nits: > > Section 5.4: "Once a temporary GRUU is constructed, it MUST be > considered valid for the duration that the AOR itself is valid." > > I believe that should say "Once a _PUBLIC_ GRUU is constructed..." Yes, others made this comment too. Fixed. > > Section 4.4: "...the SUBSCRIBE [5] request, its 2xx response or with a > To tag..." > > Either I don't understand what is meant here, or there is a spurious > "or" in that phrase. extra or. Removed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 09:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBkU-0006af-OI; Tue, 27 Mar 2007 09:30:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBkT-0006aP-C8 for sip@ietf.org; Tue, 27 Mar 2007 09:30:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWBkQ-0008CW-VX for sip@ietf.org; Tue, 27 Mar 2007 09:30:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Mar 2007 09:30:03 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2RDU2u3018423 for ; Tue, 27 Mar 2007 09:30:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2RDTwGl010587 for ; Tue, 27 Mar 2007 13:30:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 09:29:47 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 09:29:47 -0400 Message-ID: <46091C4B.4010209@cisco.com> Date: Tue, 27 Mar 2007 09:29:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 13:29:47.0799 (UTC) FILETIME=[FD628270:01C77073] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1355; t=1175002202; x=1175866202; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20sips=3A=20documentation=20plan |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=yynqwW0NWbFTq0F3qLumeTzGTXs6Ac5HsnMmMJ2P0+w=; b=XKJ5aCQER9PvZg7VLG7pitLOjaGStWw/SmzCTgUO53oy0/ff1QUF+FvanSDhSANEc2JiB8zV mmk9ExnWVlA+/TEe/0oKW+Icc9kTU8E186tZepu/+/hKy9iWRGUOYGYH; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] sips: documentation plan X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I left IETF unclear on what our plan was for moving forward on SIPS. I stated an opinion at the microphone, which I still firmly believe. That is, the current documentation plan, which has us: 1. produce an informational document updating sips 2. produce an extension that makes some normative changes to sips Only makes a confusing mechanism even more confusing, since now an implementor needs to read RFC 3261, then the informative document, then the normative one, and somehow patch them all together to come up with what sips ACTUALLY does and why. Given the existing confusion on this mechanism, I think that this would be a great disservice to the industry. I think that we are letting our process get us trapped in to doing the wrong thing. I think what implementors need is a SINGLE DOCUMENT that contains ALL of the text around sips, that documenting updating RFC 3261 and re-specifying SIPS exactly how we want it. Our process exists to serve us, not the other way around. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 09:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBuQ-0001zU-PR; Tue, 27 Mar 2007 09:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBuO-0001zM-NF for sip@ietf.org; Tue, 27 Mar 2007 09:40:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWBuL-00008i-2s for sip@ietf.org; Tue, 27 Mar 2007 09:40:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Mar 2007 09:40:17 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2RDeGvc024301 for ; Tue, 27 Mar 2007 09:40:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2RDe7lU014581 for ; Tue, 27 Mar 2007 13:40:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 09:40:02 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 09:40:02 -0400 Message-ID: <46091EB2.6020303@cisco.com> Date: Tue, 27 Mar 2007 09:40:02 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 13:40:02.0555 (UTC) FILETIME=[6BCED4B0:01C77075] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3215; t=1175002816; x=1175866816; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20sips=3A=20upgrading=20allowed=20or=20not |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=i9y1OuHD8V/IZFg/PGcmTdpOWR8qISV+4vtJKUfavOw=; b=OieWL3Pc7siVte+oBgtzn0uDp4O2h+86KaTub0RTJxzvrwCVYP7i0R6lbPhfTaNNjlLVgzh8 VvE6hlCJ2w1fPJVucGKFPrj5UU/rIZF+Fjh1Ra2tZFjv9Y/xmZwK1LjL; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] sips: upgrading allowed or not X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org During the Prague IETF, I shared some opinions on what I thought sips needs to look like and why, and wanted to take these to the list. Firstly, what is the point of sips? What does it bring a network that it can't get with TLS on some hops, as needed? The answer is that certain security benefits are afforded if we can assure that every single hop from UAC to UAS was TLS protected, and that furthermore, this fact can be definitively known by the UAC, UAS, and all proxies along the way. If we make the assumption that the UA's trust their proxies (please don't question the assumption in this thread), then SIPS provides you some very nice security properties - confidentiality and integrity from all non-trusted entities. We use this property all over our specs to secure various extensions. Given that, sips is broken if it doesn't provide that service (tls on each hop with knowledge of such by all entities). FOr this reason, I think we need to eliminate the last hop exception (uncontroversial I think), but furthermore, I believe this extends to retargeting as well. I think we clearly need to disallow retargeting or downgrading from a sips URI to a sip URI. I think that was also largely non-controversial. However, I also want to disallow upgrading or retargeting from sip to sips. On this, there was some disagreement. The challenge Jon gave me at the mike was this. As long as a UAC inserts a sips URI into the To field and R-URI field when it emits a sips request, does not the presence of a sips URI in the TO field, and receipt over a TLS connection, assure that the request was delivered over TLS at each hop? Had the request been sent originally to a sip URI and then upgraded, the TO field would not have been sips, but rather sip. I believe Jon is correct, however I still think it is not a good idea. My rationale is: 1. if upgrades are disallowed, redirecting from sip to sips works much better. Such a redirection would necesarily have to go all the way to the UAC. If we allow upgrades, a proxy in the middle could recurse and upgrade. In that case, if the reason for the redirection was that the UAS *wanted* TLS on each hop, recursing in the middle would destroy that possibility. 2. The architectural principle behind the first issue, more generally, is that the meaning of sips is *SECURE ON EACH HOP FROM UAC TO UAS*. To me, this is fundamentally at odds with any notion of upgrade or downgrade. 3. Things become simpler if we forbid upgrades. We can eliminate the text on double-record routing sinec a proxy would never be sip/sips converting. I think it also just generally makes overall processing easier. SIPS means one thing and one thing only and its terribly clear what it means. As such, I stand by my argument that we should forbid upgrades. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 10:03:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWCEA-0004ci-Rh; Tue, 27 Mar 2007 10:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWCE9-0004cV-8U for sip@ietf.org; Tue, 27 Mar 2007 10:00:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWCE7-0005MA-Tr for sip@ietf.org; Tue, 27 Mar 2007 10:00:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Mar 2007 10:00:44 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2RE0hQO028125; Tue, 27 Mar 2007 10:00:43 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2RE05lk020615; Tue, 27 Mar 2007 14:00:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 10:00:32 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 10:00:32 -0400 Message-ID: <4609237F.1090100@cisco.com> Date: Tue, 27 Mar 2007 10:00:31 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs References: <20070323074140.836261CC22@delta.rtfm.com> In-Reply-To: <20070323074140.836261CC22@delta.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 14:00:32.0305 (UTC) FILETIME=[48CBCA10:01C77078] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3689; t=1175004043; x=1175868043; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20important=20gruu=20issue=20on=20implementability, =20w as=3A=20Re=3A=20[Sip]=20sizeof=0A=20temporary=20GRUUs |Sender:=20 |To:=20EKR=20; bh=kCK13dradTRAgCfTrjKcDGdjB5gpYnnwJYP9rEAL1rQ=; b=FaSMuium2+vANwWrEfxec9IZKk5FFzKH8xIFo/VsxoO3MKBlLX63tje1ajRdcgiCS3JcG7vh tdSVBpoLZxSugKbkEN8Ncs9olDyLIqPi7wUgeThgpPCFfuFpkP5aqmIF; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org, Sean Olson , Juha Heinanen , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This looks good to me too. A couple of questions inline. EKR wrote: > OK, here's my suggestion for how to do this: > > - Each (AOR,instance-id,call-id) triplet gets assigned a unique > identifier I. > - You build a separate hash table which maps I values to > registrations. If the call-id corresponding to I_i > changes, delete I_i, generate I_j, and then insert > I_j into the table pointing to the registration record. > > I propose that I be 48 bits long and assigned as a counter, with the > current counter value stored wherever you store the registration table > (thus assuring uniqueness for the life of the registration table). > Note that if you have some kind of clustered system you can rob > the top bits for a per-server disambiguator. OK, so there is no requirement for sequential assignment per se. I'm guessing the sequence number vs. random number is just to reduce the space required for collision avoidance? > > You need to have a pair of local symmetric keys K_e and K_a. These are > generated afresh every time the counter is reset. This allows you > to separate GRUU values generated with counters that overlap, > e.g., if you destroy all your state and reset the counter. WHat happens when the counter naturally rolls over? I think you'd need to retain the old keys, since the old GRUU assigned somehwere in the previous SN space remain valid. SO then you'd need to decrypt with old and new keys to figure out which one was in use. We'd also need to assume that the rollovers happen infrequently enough (like once a year) that we wouldn't have temp-gruu which survive two rollovers. > > In order to generate a temp GRUU, you generate a random 80-bit > distinguisher value D. Then compute: > > M = D || I. > E = AES-ECB-Encrypt(K_e, M) > A = HMAC-SHA256-80(K_a, E) > > Temp-GRUU = E || A FOr the crypto-ignorant - what is AES-ECB-Encrypt? And how long is E and A respectively? > > This produces a 26-byte GRUU, with 80 bits of integrity check. 26 bytes with or without the check? Before or after base64? > > When you receive a temp GRUU, you compute: > > A' = HMAC-SHA256-80(K_a, E) > > If A' != A, you reject the GRUU, so this gives you a false accept > probability of 2^(-80). You then compute: > > M = AES-ECB-Decrypt(K_e, E) > > Remove D to recover I and look up I in the hash table. If it exists, > you've found the relevant registration, otherwise you reject. Looks good overall. > > This design will allow you to do 2^48 (10^14) separate (AOR, > instance-id, call-id) triplets, which is consistent with something like > 10^9 AORs, 10 call-ids/AOR, and 10000 call-ids/device. It's possible > that you might exceed either of the latter two limits for individual > devices, but it's doubtful you'd exceed this limit as a whole. [0]. It > will allow you to issue 2^40 GRUUs/I, which is of course ridiculously > high. [[NOTE: I'm optimizing for maximum distinguishing here, but we > could slide this boundary to like 2^56 I values]]. Does the initial value for I need to be random? I'm not sure if you are depending on any randomization aspects of this value for security (doesn't look like it but want to be sure). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 10:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWCgj-0002PP-9T; Tue, 27 Mar 2007 10:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWCgh-0002PK-P9 for sip@ietf.org; Tue, 27 Mar 2007 10:30:15 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWCgg-0007Qo-Di for sip@ietf.org; Tue, 27 Mar 2007 10:30:15 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HWCgO-000637-I0; Tue, 27 Mar 2007 07:29:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-ietf-sip-gruu-12 Date: Tue, 27 Mar 2007 07:28:48 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> In-Reply-To: <46091480.8060908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: Acdwb1MbHZmfNHwUSGGTBX2omrH5IQAAlH8g References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> From: "Michael Procter" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments inline: Jonathan Rosenberg wrote: > However, I believe it works just fine. Lets walk through a call flow. >=20 > Lets say you have a UA X that doesn't support GRUU. However it includes > an instance ID in its registration. The UA has a contact sip:x-contact > and the registrar assigns a GRUU sip:x-gruu. However, this gruu is not > returned to UA X and UA X has no idea about GRUU. Some other entity > using reg-event (say UA Y) learns this GRUU and sends a request there. >=20 > This request will have a R-URI of sip:x-gruu, and arrive at the home > proxy in X's domain. THis proxy, following normal GRUU procedures, will > replace the R-URI with the registered contact. Furthermore it will > record-route if there were Path headers. In this case it didn't actually > need to, but it will anyway. No big deal. This is the first problem I see. Version 12 doesn't require record-route in the case where no Path headers are used. As Jeroen observed further back in this thread, this can be fixed fairly easily: Jeroen van Bemmel wrote: : GRUU-12 section 6.2 requires the proxy to Record-Route the INVITE when a=20 : GRUU is used as request URI, and there is a Path stored. So in this case : the call will work if and only if there was a Path and the Contact is=20 : reachable from the proxy. : : So section 6.2 should be updated to state "[...] and the registration : contain Path URI and/or the registered Contact is not globally routable" [rest of example deleted - I agree with it] =20 Jonathan Rosenberg wrote: > What won't work is that, since UA X doesn't support GRUU, once the call > is set up to X, things like transfer won't work.=20 This is the second problem that I see. My understanding of one of the main benefits of GRUUs is that they can be used in the context of things like transfer. Before GRUUs, various vendors came up with some interesting workarounds to try to solve this problem. Fortunately, GRUUs came along and fixed it for us. But with this version of a GRUU (GRUUs for non-GRUU UAs), it seems that we are losing one of the main benefits. We may need to revert to some variation of the old workarounds to ensure that we can still get transfer to work. > But, thats OK, there > won't be any expectation that it would since the Contact didn't contain > a GRUU. But UA-Y originally received something marked as a GRUU from the registrar! =20 It seems misleading to give it a GRUU if there is no support for GRUU in the UA. If the problem you are trying to solve is simply to allow a request to be routed directly to a specific endpoint, then surely RFC3841 is sufficient. Just add: Accept-Contact: *;+sip.instance=3D"whatever";required;explicit This doesn't require inventing GRUUs for UAs that don't support them. Nor does it lead to an expectation that GRUUs are supported when they are not. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 10:52:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWD1A-00073M-3N; Tue, 27 Mar 2007 10:51:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWD18-00072S-FE for sip@ietf.org; Tue, 27 Mar 2007 10:51:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWD17-0006MD-02 for sip@ietf.org; Tue, 27 Mar 2007 10:51:22 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Mar 2007 07:51:21 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2REpKe5008829; Tue, 27 Mar 2007 07:51:20 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2REoQxC016409; Tue, 27 Mar 2007 14:51:20 GMT In-Reply-To: <7374777208BDC7449D5620EF9423256702B78BBD@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF9423256702B78BBD@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66B54AE0-33D8-47A4-A16E-786D00902693@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] RE: Outbound-08: usage of keep-xxx parameter Date: Mon, 26 Mar 2007 11:00:25 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4435; t=1175007080; x=1175871080; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Outbound-08=3A=20usage=20of=20keep-xx x=20parameter |Sender:=20; bh=ezFIGGfkGItiWvQNXie95s35t9A+gPrT0lhROdaECdc=; b=K4M96vB7UrEKEi3DWfsysdmGVEVcD2w3uFqmgZBlRMyzDfkyyl3Rus8Ii/HwgWXrMk61y0xO xoHuV+IrDl6gputrcWHnXJX2408YdSFzk9+kpYm7gjLzMaO5HSLx2nzv; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I did not read these emails until after the meeting but I see what you are getting at and I think we can simplify along these liens without any loss of functionality. I will try and sort out some text with Rohan and see if it looks aceptable to people. On Mar 19, 2007, at 1:00 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>>> This is so that the administrative domain that runs the server can >>>> pick what type of keep alive it wants to use (even though >>>> they are all supported). I think this is all too much complexity >>>> but > it >>>> seemed that some people wanted this so that's what we wrote up. >> >> I also think all that is too much complexity and can not even >> see the value of it. Remember that Outbound has only one >> single keepalive method (STUN) for UDP and two methods (CRLF and TCP >> keepalive) for TCP. The reason for introducing the 'keepalive-stun' >> flag was that multiplexing STUN to the SIP port was >> considered as backwards incompatible change, so there was an >> extra reason for the UA to check that the proxy supports it. >> However sending double-CRLF or TCP keepalives is backwards >> compatible to SIP servers compliant to RFC 3261, so no such >> reason exists here. >> >>> I don't remember any recent discussion regarding this, but I may of >>> course have missed it. >> >> If you refer to the discussion related to STUN, the reasons >> for the related flag are not as such applicable to the >> keepalive methods currently proposed for TCP. For CRLF >> keepalives no such discussion has been on the list (before this one). > > I am refering to the decission to define mutliple keep-xxx parameters. > >>> But, if we can have multiple keep-alive mechanisms for a single >>> transport protocol I guess it's ok to have that possibility. BUT, I >>> still think that it should also be possible to only include the 'ob' >>> URI parameter, and let the UA choose whatever outbound keep-alive >>> mechanism he wants, and that we should describe that. >> >> I agree with Christer that it should go this way: >> >> It should be possible for the UA to find out (in some way or >> another) that the configured or discovered outbound proxy >> supports SIP Outbound. UA should be able to find out the >> transports supported by the proxy by DNS, unless the URI has >> an explicit transport parameter. > > Yes, and therefor I think it shall be described that the edge proxy > can > insert the 'ob' and 'keep-xxx' parameters in the Path header. > Currently > I beleive only inserting of 'ob' is described for the edge proxy, in > order for the home proxy to figure out that the edge proxy supports > outbound. I think we also need to say that the UA can use that > information. > >> Finally the proxy has to support all keepalive methods defined in SIP > Outbound for the >> transports it supports. As simple as that. > > I agree, and that was the reason why I asked why we need to keep-xxx > parameters. 'ob' should be enough. > >> Defined like that, if the proxy would only support UDP, the >> UA can only use STUN for keepalive. And if the proxy would >> support TCP, the UA could use either CRLF or TCP keepalive. > > Yes. > >> For TCP case the choice would be done by the UA, exactly as >> the case was before replacing STUN with CRLF as one keepalive >> method for TCP. > > Yes. > > Regards, > > Christer > > > > > >> >>>> On Mar 14, 2007, at 2:25 PM, Christer Holmberg ((JO/LMF)) wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> If all outbound compliant edge proxies MUST implement all >>>> keep- alive >>>>> mechanisms, why do we need to list the different keep-alive >>>> mechanisms >>>>> (keep-stun, keep-crlf etc) in the outbound-proxy-set URIs? >>> Isn't it >>>>> enough to simply include the 'ob' URI parameter? >>>>> >>>>> If all oubound compliant edge proxies MUST implement all >>> keep-alive >>>>> mechanisms, do we need to keep-xxx parameters in the first place? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 11:42:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDm1-0004zz-Eb; Tue, 27 Mar 2007 11:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDm0-0004zN-1V for sip@ietf.org; Tue, 27 Mar 2007 11:39:48 -0400 Received: from sd-green-bigip-66.dreamhost.com ([208.97.132.66] helo=randymail-a10.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDlx-00081m-KL for sip@ietf.org; Tue, 27 Mar 2007 11:39:48 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a10.g.dreamhost.com (Postfix) with ESMTP id 5611410EEED; Tue, 27 Mar 2007 08:39:43 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8DAEA1CC22; Tue, 27 Mar 2007 08:38:23 -0700 (PDT) To: Jonathan Rosenberg Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs In-reply-to: Your message of "Tue, 27 Mar 2007 10:00:31 EDT." <4609237F.1090100@cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Tue, 27 Mar 2007 08:38:23 -0700 From: EKR Message-Id: <20070327153823.8DAEA1CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org, Sean Olson , Juha Heinanen , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > This looks good to me too. A couple of questions inline. > > EKR wrote: > > > OK, here's my suggestion for how to do this: > > - Each (AOR,instance-id,call-id) triplet gets assigned a unique > > identifier I. > > - You build a separate hash table which maps I values to > > registrations. If the call-id corresponding to I_i > > changes, delete I_i, generate I_j, and then insert I_j into the > > table pointing to the registration record. > > I propose that I be 48 bits long and assigned as a counter, with the > > current counter value stored wherever you store the registration table > > (thus assuring uniqueness for the life of the registration table). > > Note that if you have some kind of clustered system you can rob > > the top bits for a per-server disambiguator. > > OK, so there is no requirement for sequential assignment per se. I'm > guessing the sequence number vs. random number is just to reduce the > space required for collision avoidance? Yep. We might be able to move this boundary to 56 or 64 bits, but I wanted to make sure there was enough room so that even if someone reregistered a ridiculous # of times it woul dbe OK. > > You need to have a pair of local symmetric keys K_e and K_a. These > > are > > generated afresh every time the counter is reset. This allows you > > to separate GRUU values generated with counters that overlap, > > e.g., if you destroy all your state and reset the counter. > > WHat happens when the counter naturally rolls over? I think you'd need > to retain the old keys, since the old GRUU assigned somehwere in the > previous SN space remain valid. Yeah. > SO then you'd need to decrypt with old > and new keys to figure out which one was in use. Yes, or stick a demux on the front. > We'd also need to > assume that the rollovers happen infrequently enough (like once a > year) that we wouldn't have temp-gruu which survive two rollovers. Yep. > > In order to generate a temp GRUU, you generate a random 80-bit > > distinguisher value D. Then compute: > > M = D || I. > > E = AES-ECB-Encrypt(K_e, M) > > A = HMAC-SHA256-80(K_a, E) > > Temp-GRUU = E || A > > FOr the crypto-ignorant - what is AES-ECB-Encrypt? Encrypt with AES in cipher-block-chaining mode. > And how long is E > and A respectively? 16 bytes and 10 bytes > > This produces a 26-byte GRUU, with 80 bits of integrity check. > > 26 bytes with or without the check? Before or after base64? Before. > > This design will allow you to do 2^48 (10^14) separate (AOR, > > instance-id, call-id) triplets, which is consistent with something like > > 10^9 AORs, 10 call-ids/AOR, and 10000 call-ids/device. It's possible > > that you might exceed either of the latter two limits for individual > > devices, but it's doubtful you'd exceed this limit as a whole. [0]. It > > will allow you to issue 2^40 GRUUs/I, which is of course ridiculously > > high. [[NOTE: I'm optimizing for maximum distinguishing here, but we > > could slide this boundary to like 2^56 I values]]. > > Does the initial value for I need to be random? I'm not sure if you > are depending on any randomization aspects of this value for security > (doesn't look like it but want to be sure). No, you can just start with 0. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 12:33:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWEb6-0007he-T2; Tue, 27 Mar 2007 12:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWEb4-0007fC-VS for sip@ietf.org; Tue, 27 Mar 2007 12:32:34 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWEb2-0002wc-Fh for sip@ietf.org; Tue, 27 Mar 2007 12:32:34 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l2RGWDPl011935; Tue, 27 Mar 2007 11:32:21 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 11:32:17 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 18:32:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: documentation plan Date: Tue, 27 Mar 2007 18:28:10 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180F1FFC8@DEEXC1U01.de.lucent.com> In-Reply-To: <46091C4B.4010209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: documentation plan Thread-Index: AcdwdF2GmP9X8nnqTVyrECs6ICrTLQADMNuQ References: <46091C4B.4010209@cisco.com> From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 27 Mar 2007 16:32:15.0436 (UTC) FILETIME=[7AAF58C0:01C7708D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) The instruction to the editor is to update the document without removing the information. The new normative text, the informational stuff, and the bugfixes will form separate sections in the document, and once we have the -03 version, and agreed that we have everything is in the right category, we will then decide how to present the content in terms of the number of documents.=20 The split into separate sections is not forcing us down any path. For the bugfixes, it reflects the need to have a section that reproduces text from RFC 3261 and indicates that a section has changed. For the new normative text it reflects the need to gather the UA requirements together in a subsection separate from the proxy requirements in accordance with RFC 4485. Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, March 27, 2007 2:30 PM > To: IETF SIP List > Subject: [Sip] sips: documentation plan >=20 > I left IETF unclear on what our plan was for moving forward=20 > on SIPS. I stated an opinion at the microphone, which I still=20 > firmly believe. That is, the current documentation plan, which has us: >=20 > 1. produce an informational document updating sips 2. produce=20 > an extension that makes some normative changes to sips >=20 > Only makes a confusing mechanism even more confusing, since=20 > now an implementor needs to read RFC 3261, then the=20 > informative document, then the normative one, and somehow=20 > patch them all together to come up with what sips ACTUALLY=20 > does and why. >=20 > Given the existing confusion on this mechanism, I think that=20 > this would be a great disservice to the industry. I think=20 > that we are letting our process get us trapped in to doing=20 > the wrong thing. I think what implementors need is a SINGLE=20 > DOCUMENT that contains ALL of the text around sips, that=20 > documenting updating RFC 3261 and re-specifying SIPS exactly=20 > how we want it. >=20 > Our process exists to serve us, not the other way around. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 13:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWFof-0002jE-Jc; Tue, 27 Mar 2007 13:50:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWFoe-0002j9-Pp for sip@ietf.org; Tue, 27 Mar 2007 13:50:40 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWFod-0007YF-GI for sip@ietf.org; Tue, 27 Mar 2007 13:50:40 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RGupn1029948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 10:56:52 -0600 In-Reply-To: <46091EB2.6020303@cisco.com> References: <46091EB2.6020303@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 12:50:26 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: > > Firstly, what is the point of sips? What does it bring a network > that it can't get with TLS on some hops, as needed? The answer is > that certain security benefits are afforded if we can assure that > every single hop from UAC to UAS was TLS protected, and that > furthermore, this fact can be definitively known by the UAC, UAS, > and all proxies along the way. If we make the assumption that the > UA's trust their proxies (please don't question the assumption in > this thread), then SIPS provides you some very nice security > properties - confidentiality and integrity from all non-trusted > entities. We use this property all over our specs to secure various > extensions. > Note that I changed threads . . . There is a big gap between "UAs trust their proxies" and "UAs trust every proxy that might possibly get inserted into the signaling path". You assert "assure that every single hop from UAC to UAS was TLS protected, and that furthermore, this fact can be definitively known by the UAC, UAS, and all proxies along the way" Since: 1) UAs have no control over what proxies beyond the first hop get inserted. 2) Neither UAs nor proxies have any mechanism for knowing whether proxies or UAs more than one proxy hop away actually complied with the requirements of SIPS. That's not saying SIPS doesn't provide some useful security properties. It does. It just doesn't provide the assurance that I keep hearing repeated. And I think that if you STOP saying it provides that sort of assurance, it will stop confusing people so badly about what it does usefully provide. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 14:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWG8x-0003hY-IB; Tue, 27 Mar 2007 14:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWG7s-00037g-Bd for sip@ietf.org; Tue, 27 Mar 2007 14:10:32 -0400 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWG6K-0002WE-7I for sip@ietf.org; Tue, 27 Mar 2007 14:08:57 -0400 Received: from sipx.cornfed.com (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l2RI8D631002; Tue, 27 Mar 2007 13:08:13 -0500 Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) From: "Frank W. Miller" To: Dean Willis In-Reply-To: References: <46091EB2.6020303@cisco.com> Content-Type: text/plain Date: Tue, 27 Mar 2007 12:08:07 -0700 Message-Id: <1175022487.4681.16.camel@sipx.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think there are two distinct environments that need to be identified. The first would be something like a carrier environment, i.e. IMS-like. In this environment the assumption that the proxies are trusted is probably valid. The carriers are unlikely to use a path that does not include proxies they trust, either because they own them or because they have a relationship with the owner. This looks alot like the SS7 world where the signaling points are all assumed to be trusted. The second environment I'll call the open Internet. While this may include proxies that can be trusted, e.g. my first hop to a known service provider, I think it would be easy to paint scenarios where the UA didn't really know all the signaling hops. In this environment the hop-by-hop trust is probably not good enough for the security properties being targeted. I know you said we weren't supposed to question the trust of the proxies but I think that's really the heart of the issue with SIPS. I don't think its the implementation of hop-by-hop, I think its the assumption that hop-by-hop is good enough for all the scenarios that SIP is used for. My thought is that to alleviate confusion, clarification of the environment in which SIPS is sufficient is really the key. Perhaps break the environment into those that are really trusted and those that are not. Allow use of SIPS for the trusted environments and come up with a decent end-to-end mechanism for those that are not. FM On Tue, 2007-03-27 at 12:50 -0500, Dean Willis wrote: > On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: > > > > > Firstly, what is the point of sips? What does it bring a network > > that it can't get with TLS on some hops, as needed? The answer is > > that certain security benefits are afforded if we can assure that > > every single hop from UAC to UAS was TLS protected, and that > > furthermore, this fact can be definitively known by the UAC, UAS, > > and all proxies along the way. If we make the assumption that the > > UA's trust their proxies (please don't question the assumption in > > this thread), then SIPS provides you some very nice security > > properties - confidentiality and integrity from all non-trusted > > entities. We use this property all over our specs to secure various > > extensions. > > > > Note that I changed threads . . . > > There is a big gap between "UAs trust their proxies" and "UAs trust > every proxy that might possibly get inserted into the signaling path". > > You assert "assure that every single hop from UAC to UAS was TLS > protected, and that furthermore, this fact can be definitively known > by the UAC, UAS, and all proxies along the way" > > Since: > > 1) UAs have no control over what proxies beyond the first hop get > inserted. > 2) Neither UAs nor proxies have any mechanism for knowing whether > proxies or UAs more than one proxy hop away actually complied with > the requirements of SIPS. > > > That's not saying SIPS doesn't provide some useful security > properties. It does. It just doesn't provide the assurance that I > keep hearing repeated. And I think that if you STOP saying it > provides that sort of assurance, it will stop confusing people so > badly about what it does usefully provide. > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 14:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGIc-00009k-2P; Tue, 27 Mar 2007 14:21:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGIb-00009c-9O for sip@ietf.org; Tue, 27 Mar 2007 14:21:37 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGIS-0005qe-Sa for sip@ietf.org; Tue, 27 Mar 2007 14:21:37 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 6164EAC368; Tue, 27 Mar 2007 21:21:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.24743.108793.433934@harjus.tutpro.com> Date: Tue, 27 Mar 2007 21:21:27 +0300 To: "Frank W. Miller" Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) In-Reply-To: <1175022487.4681.16.camel@sipx.cornfed.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller writes: > The first would be something like a carrier environment, i.e. IMS-like. > In this environment the assumption that the proxies are trusted is > probably valid. what do you mean by "trusted"? government of sweden just proposed that they are going to monitor all communications that pass through the borders, e.g., my cal lfrom finland to norway. as a user i cannot "trust" that. the fact that proxies in sweden see contents of sip requests make the whole system untrusted. it doesn't help at all if sip requests are encrypted on a particular link. the right solution is to deprecate sips and stop fooling the users. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 14:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRY-0003Lz-B5; Tue, 27 Mar 2007 14:30:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRW-0003Lp-UN for sip@ietf.org; Tue, 27 Mar 2007 14:30:50 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGRV-0000BY-Jb for sip@ietf.org; Tue, 27 Mar 2007 14:30:50 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2RIUQb14891; Tue, 27 Mar 2007 18:30:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 13:30:44 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4BF5F@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) thread-index: AcdwmT9NhG8Vrp3IQuG/uSM9VyFy/gAAuCZw From: "Samir Srivastava" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for coming to fray late and couldn't attend the Prague. I have yet to look into the proceedings. My understanding was that we are going to have BCP/INFORMATIONAL document which will just state that what SIPS provide. I had the question on the value of this document too. But I stopped arguing seeing the community wanted to have the document due to whatever reasons... What is the decision on the Tel URI ? Are we going to have tels uri scheme for that or other URN etc.=20 Though, I have repeated again and again just deprecate SIPS. But now keeping silent to let BCP proceed and then update cipher-suites etc... Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 27, 2007 10:50 AM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Does TLS have the security benefits claimed? (was TLS Re: [Sip] > sips: upgrading allowed or not) >=20 >=20 > On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: >=20 > > > > Firstly, what is the point of sips? What does it bring a network > > that it can't get with TLS on some hops, as needed? The answer is > > that certain security benefits are afforded if we can assure that > > every single hop from UAC to UAS was TLS protected, and that > > furthermore, this fact can be definitively known by the UAC, UAS, > > and all proxies along the way. If we make the assumption that the > > UA's trust their proxies (please don't question the assumption in > > this thread), then SIPS provides you some very nice security > > properties - confidentiality and integrity from all non-trusted > > entities. We use this property all over our specs to secure various > > extensions. > > >=20 > Note that I changed threads . . . >=20 > There is a big gap between "UAs trust their proxies" and "UAs trust > every proxy that might possibly get inserted into the signaling path". >=20 > You assert "assure that every single hop from UAC to UAS was TLS > protected, and that furthermore, this fact can be definitively known > by the UAC, UAS, and all proxies along the way" >=20 > Since: >=20 > 1) UAs have no control over what proxies beyond the first hop get > inserted. > 2) Neither UAs nor proxies have any mechanism for knowing whether > proxies or UAs more than one proxy hop away actually complied with > the requirements of SIPS. >=20 >=20 > That's not saying SIPS doesn't provide some useful security > properties. It does. It just doesn't provide the assurance that I > keep hearing repeated. And I think that if you STOP saying it > provides that sort of assurance, it will stop confusing people so > badly about what it does usefully provide. >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 14:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRm-0003Xp-9f; Tue, 27 Mar 2007 14:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRk-0003T4-PX for sip@ietf.org; Tue, 27 Mar 2007 14:31:04 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGRg-0000DV-De for sip@ietf.org; Tue, 27 Mar 2007 14:31:04 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1830664nzd for ; Tue, 27 Mar 2007 11:31:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Lg9mGleFcEO/Q9CXCWs0CVX23e4PNwVY8YFQ2pB7oIBa38C8IZXgNSPXfDPe+K85TP89LvfJywRZ2Cek0gMYT0UaduUVyPLLPc1qsnXmStvalkfyU5/D0AUs7oHf3pebDqx9/N1gdrXVnim5MhQ2Sb115WQP4JABaKVAGlaqulE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YCpwU8XdxIXqFR07bRRXYrRMRph1Uge+ZyUL3FZtGZE8Tihn+ug/yKApSCHVtl6xhALwj2OmVqtXBNsoSofmN9mbEOXN52OB3lAC3QbWf2L8x7Im1Lg6jdQsBfWwwwXBySklYDz2i6xIHNpZlP+So2sGgAjDL5MBg6fsVrbF2iM= Received: by 10.115.93.16 with SMTP id v16mr3275192wal.1175020259189; Tue, 27 Mar 2007 11:30:59 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Tue, 27 Mar 2007 11:30:59 -0700 (PDT) Message-ID: <894e079b0703271130w54315a79t80d220e6bd07b9e3@mail.gmail.com> Date: Tue, 27 Mar 2007 14:30:59 -0400 From: "Medhavi Bhatia" To: "Frank W. Miller" Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) In-Reply-To: <1175022487.4681.16.camel@sipx.cornfed.com> MIME-Version: 1.0 References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> X-Google-Sender-Auth: 71cd4b4dfda536a2 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1095593144==" Errors-To: sip-bounces@ietf.org --===============1095593144== Content-Type: multipart/alternative; boundary="----=_Part_13198_21372007.1175020259053" ------=_Part_13198_21372007.1175020259053 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't know the full context of this discussion, but one thing which comes to my mind is that what Frank is saying is very important. In a P2P scenario (on the internet), this is even more relevant since the UA certainly wont know how the call is getting routed. On 3/27/07, Frank W. Miller wrote: > > > I think there are two distinct environments that need to be identified. > The first would be something like a carrier environment, i.e. IMS-like. > In this environment the assumption that the proxies are trusted is > probably valid. The carriers are unlikely to use a path that does not > include proxies they trust, either because they own them or because they > have a relationship with the owner. This looks alot like the SS7 world > where the signaling points are all assumed to be trusted. > > The second environment I'll call the open Internet. While this may > include proxies that can be trusted, e.g. my first hop to a known > service provider, I think it would be easy to paint scenarios where the > UA didn't really know all the signaling hops. In this environment the > hop-by-hop trust is probably not good enough for the security properties > being targeted. > > I know you said we weren't supposed to question the trust of the proxies > but I think that's really the heart of the issue with SIPS. I don't > think its the implementation of hop-by-hop, I think its the assumption > that hop-by-hop is good enough for all the scenarios that SIP is used > for. > > My thought is that to alleviate confusion, clarification of the > environment in which SIPS is sufficient is really the key. Perhaps > break the environment into those that are really trusted and those that > are not. Allow use of SIPS for the trusted environments and come up > with a decent end-to-end mechanism for those that are not. > > FM > > > > On Tue, 2007-03-27 at 12:50 -0500, Dean Willis wrote: > > On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: > > > > > > > > Firstly, what is the point of sips? What does it bring a network > > > that it can't get with TLS on some hops, as needed? The answer is > > > that certain security benefits are afforded if we can assure that > > > every single hop from UAC to UAS was TLS protected, and that > > > furthermore, this fact can be definitively known by the UAC, UAS, > > > and all proxies along the way. If we make the assumption that the > > > UA's trust their proxies (please don't question the assumption in > > > this thread), then SIPS provides you some very nice security > > > properties - confidentiality and integrity from all non-trusted > > > entities. We use this property all over our specs to secure various > > > extensions. > > > > > > > Note that I changed threads . . . > > > > There is a big gap between "UAs trust their proxies" and "UAs trust > > every proxy that might possibly get inserted into the signaling path". > > > > You assert "assure that every single hop from UAC to UAS was TLS > > protected, and that furthermore, this fact can be definitively known > > by the UAC, UAS, and all proxies along the way" > > > > Since: > > > > 1) UAs have no control over what proxies beyond the first hop get > > inserted. > > 2) Neither UAs nor proxies have any mechanism for knowing whether > > proxies or UAs more than one proxy hop away actually complied with > > the requirements of SIPS. > > > > > > That's not saying SIPS doesn't provide some useful security > > properties. It does. It just doesn't provide the assurance that I > > keep hearing repeated. And I think that if you STOP saying it > > provides that sort of assurance, it will stop confusing people so > > badly about what it does usefully provide. > > > > -- > > 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 > ------=_Part_13198_21372007.1175020259053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't know the full context of this discussion, but one thing which comes to my mind is that what Frank is saying is very important. In a P2P scenario (on the internet), this is even more relevant since the UA certainly wont know how the call is getting routed.

On 3/27/07, Frank W. Miller <fwmiller@cornfed.com> wrote:

I think there are two distinct environments that need to be identified.
The first would be something like a carrier environment, i.e. IMS-like.
In this environment the assumption that the proxies are trusted is
probably valid.  The carriers are unlikely to use a path that does not
include proxies they trust, either because they own them or because they
have a relationship with the owner.  This looks alot like the SS7 world
where the signaling points are all assumed to be trusted.

The second environment I'll call the open Internet.  While this may
include proxies that can be trusted, e.g. my first hop to a known
service provider, I think it would be easy to paint scenarios where the
UA didn't really know all the signaling hops.  In this environment the
hop-by-hop trust is probably not good enough for the security properties
being targeted.

I know you said we weren't supposed to question the trust of the proxies
but I think that's really the heart of the issue with SIPS.  I don't
think its the implementation of hop-by-hop, I think its the assumption
that hop-by-hop is good enough for all the scenarios that SIP is used
for.

My thought is that to alleviate confusion, clarification of the
environment in which SIPS is sufficient is really the key.  Perhaps
break the environment into those that are really trusted and those that
are not.  Allow use of SIPS for the trusted environments and come up
with a decent end-to-end mechanism for those that are not.

FM



On Tue, 2007-03-27 at 12:50 -0500, Dean Willis wrote:
> On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote:
>
> >
> > Firstly, what is the point of sips? What does it bring a network
> > that it can't get with TLS on some hops, as needed? The answer is
> > that certain security benefits are afforded if we can assure that
> > every single hop from UAC to UAS was TLS protected, and that
> > furthermore, this fact can be definitively known by the UAC, UAS,
> > and all proxies along the way. If we make the assumption that the
> > UA's trust their proxies (please don't question the assumption in
> > this thread), then SIPS provides you some very nice security
> > properties - confidentiality and integrity from all non-trusted
> > entities. We use this property all over our specs to secure various
> > extensions.
> >
>
> Note that I changed threads . . .
>
> There is a big gap between "UAs trust their proxies" and "UAs trust
> every proxy that might possibly get inserted into the signaling path".
>
> You assert "assure that every single hop from UAC to UAS was TLS
> protected, and that furthermore, this fact can be definitively known
> by the UAC, UAS, and all proxies along the way"
>
> Since:
>
> 1) UAs have no control over what proxies beyond the first hop get
> inserted.
> 2) Neither UAs nor proxies have any mechanism for knowing whether
> proxies or UAs more than one proxy hop away actually complied with
> the requirements of SIPS.
>
>
> That's not saying SIPS doesn't provide some useful security
> properties. It does. It just doesn't provide the assurance that I
> keep hearing repeated. And I think that if you STOP saying it
> provides that sort of assurance, it will stop confusing people so
> badly about what it does usefully provide.
>
> --
> 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

------=_Part_13198_21372007.1175020259053-- --===============1095593144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1095593144==-- From sip-bounces@ietf.org Tue Mar 27 14:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRY-0003Lz-B5; Tue, 27 Mar 2007 14:30:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRW-0003Lp-UN for sip@ietf.org; Tue, 27 Mar 2007 14:30:50 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGRV-0000BY-Jb for sip@ietf.org; Tue, 27 Mar 2007 14:30:50 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2RIUQb14891; Tue, 27 Mar 2007 18:30:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 13:30:44 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4BF5F@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) thread-index: AcdwmT9NhG8Vrp3IQuG/uSM9VyFy/gAAuCZw From: "Samir Srivastava" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for coming to fray late and couldn't attend the Prague. I have yet to look into the proceedings. My understanding was that we are going to have BCP/INFORMATIONAL document which will just state that what SIPS provide. I had the question on the value of this document too. But I stopped arguing seeing the community wanted to have the document due to whatever reasons... What is the decision on the Tel URI ? Are we going to have tels uri scheme for that or other URN etc.=20 Though, I have repeated again and again just deprecate SIPS. But now keeping silent to let BCP proceed and then update cipher-suites etc... Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 27, 2007 10:50 AM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Does TLS have the security benefits claimed? (was TLS Re: [Sip] > sips: upgrading allowed or not) >=20 >=20 > On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: >=20 > > > > Firstly, what is the point of sips? What does it bring a network > > that it can't get with TLS on some hops, as needed? The answer is > > that certain security benefits are afforded if we can assure that > > every single hop from UAC to UAS was TLS protected, and that > > furthermore, this fact can be definitively known by the UAC, UAS, > > and all proxies along the way. If we make the assumption that the > > UA's trust their proxies (please don't question the assumption in > > this thread), then SIPS provides you some very nice security > > properties - confidentiality and integrity from all non-trusted > > entities. We use this property all over our specs to secure various > > extensions. > > >=20 > Note that I changed threads . . . >=20 > There is a big gap between "UAs trust their proxies" and "UAs trust > every proxy that might possibly get inserted into the signaling path". >=20 > You assert "assure that every single hop from UAC to UAS was TLS > protected, and that furthermore, this fact can be definitively known > by the UAC, UAS, and all proxies along the way" >=20 > Since: >=20 > 1) UAs have no control over what proxies beyond the first hop get > inserted. > 2) Neither UAs nor proxies have any mechanism for knowing whether > proxies or UAs more than one proxy hop away actually complied with > the requirements of SIPS. >=20 >=20 > That's not saying SIPS doesn't provide some useful security > properties. It does. It just doesn't provide the assurance that I > keep hearing repeated. And I think that if you STOP saying it > provides that sort of assurance, it will stop confusing people so > badly about what it does usefully provide. >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 14:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRm-0003Xp-9f; Tue, 27 Mar 2007 14:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGRk-0003T4-PX for sip@ietf.org; Tue, 27 Mar 2007 14:31:04 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGRg-0000DV-De for sip@ietf.org; Tue, 27 Mar 2007 14:31:04 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1830664nzd for ; Tue, 27 Mar 2007 11:31:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Lg9mGleFcEO/Q9CXCWs0CVX23e4PNwVY8YFQ2pB7oIBa38C8IZXgNSPXfDPe+K85TP89LvfJywRZ2Cek0gMYT0UaduUVyPLLPc1qsnXmStvalkfyU5/D0AUs7oHf3pebDqx9/N1gdrXVnim5MhQ2Sb115WQP4JABaKVAGlaqulE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YCpwU8XdxIXqFR07bRRXYrRMRph1Uge+ZyUL3FZtGZE8Tihn+ug/yKApSCHVtl6xhALwj2OmVqtXBNsoSofmN9mbEOXN52OB3lAC3QbWf2L8x7Im1Lg6jdQsBfWwwwXBySklYDz2i6xIHNpZlP+So2sGgAjDL5MBg6fsVrbF2iM= Received: by 10.115.93.16 with SMTP id v16mr3275192wal.1175020259189; Tue, 27 Mar 2007 11:30:59 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Tue, 27 Mar 2007 11:30:59 -0700 (PDT) Message-ID: <894e079b0703271130w54315a79t80d220e6bd07b9e3@mail.gmail.com> Date: Tue, 27 Mar 2007 14:30:59 -0400 From: "Medhavi Bhatia" To: "Frank W. Miller" Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) In-Reply-To: <1175022487.4681.16.camel@sipx.cornfed.com> MIME-Version: 1.0 References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> X-Google-Sender-Auth: 71cd4b4dfda536a2 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1095593144==" Errors-To: sip-bounces@ietf.org --===============1095593144== Content-Type: multipart/alternative; boundary="----=_Part_13198_21372007.1175020259053" ------=_Part_13198_21372007.1175020259053 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't know the full context of this discussion, but one thing which comes to my mind is that what Frank is saying is very important. In a P2P scenario (on the internet), this is even more relevant since the UA certainly wont know how the call is getting routed. On 3/27/07, Frank W. Miller wrote: > > > I think there are two distinct environments that need to be identified. > The first would be something like a carrier environment, i.e. IMS-like. > In this environment the assumption that the proxies are trusted is > probably valid. The carriers are unlikely to use a path that does not > include proxies they trust, either because they own them or because they > have a relationship with the owner. This looks alot like the SS7 world > where the signaling points are all assumed to be trusted. > > The second environment I'll call the open Internet. While this may > include proxies that can be trusted, e.g. my first hop to a known > service provider, I think it would be easy to paint scenarios where the > UA didn't really know all the signaling hops. In this environment the > hop-by-hop trust is probably not good enough for the security properties > being targeted. > > I know you said we weren't supposed to question the trust of the proxies > but I think that's really the heart of the issue with SIPS. I don't > think its the implementation of hop-by-hop, I think its the assumption > that hop-by-hop is good enough for all the scenarios that SIP is used > for. > > My thought is that to alleviate confusion, clarification of the > environment in which SIPS is sufficient is really the key. Perhaps > break the environment into those that are really trusted and those that > are not. Allow use of SIPS for the trusted environments and come up > with a decent end-to-end mechanism for those that are not. > > FM > > > > On Tue, 2007-03-27 at 12:50 -0500, Dean Willis wrote: > > On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: > > > > > > > > Firstly, what is the point of sips? What does it bring a network > > > that it can't get with TLS on some hops, as needed? The answer is > > > that certain security benefits are afforded if we can assure that > > > every single hop from UAC to UAS was TLS protected, and that > > > furthermore, this fact can be definitively known by the UAC, UAS, > > > and all proxies along the way. If we make the assumption that the > > > UA's trust their proxies (please don't question the assumption in > > > this thread), then SIPS provides you some very nice security > > > properties - confidentiality and integrity from all non-trusted > > > entities. We use this property all over our specs to secure various > > > extensions. > > > > > > > Note that I changed threads . . . > > > > There is a big gap between "UAs trust their proxies" and "UAs trust > > every proxy that might possibly get inserted into the signaling path". > > > > You assert "assure that every single hop from UAC to UAS was TLS > > protected, and that furthermore, this fact can be definitively known > > by the UAC, UAS, and all proxies along the way" > > > > Since: > > > > 1) UAs have no control over what proxies beyond the first hop get > > inserted. > > 2) Neither UAs nor proxies have any mechanism for knowing whether > > proxies or UAs more than one proxy hop away actually complied with > > the requirements of SIPS. > > > > > > That's not saying SIPS doesn't provide some useful security > > properties. It does. It just doesn't provide the assurance that I > > keep hearing repeated. And I think that if you STOP saying it > > provides that sort of assurance, it will stop confusing people so > > badly about what it does usefully provide. > > > > -- > > 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 > ------=_Part_13198_21372007.1175020259053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't know the full context of this discussion, but one thing which comes to my mind is that what Frank is saying is very important. In a P2P scenario (on the internet), this is even more relevant since the UA certainly wont know how the call is getting routed.

On 3/27/07, Frank W. Miller <fwmiller@cornfed.com> wrote:

I think there are two distinct environments that need to be identified.
The first would be something like a carrier environment, i.e. IMS-like.
In this environment the assumption that the proxies are trusted is
probably valid.  The carriers are unlikely to use a path that does not
include proxies they trust, either because they own them or because they
have a relationship with the owner.  This looks alot like the SS7 world
where the signaling points are all assumed to be trusted.

The second environment I'll call the open Internet.  While this may
include proxies that can be trusted, e.g. my first hop to a known
service provider, I think it would be easy to paint scenarios where the
UA didn't really know all the signaling hops.  In this environment the
hop-by-hop trust is probably not good enough for the security properties
being targeted.

I know you said we weren't supposed to question the trust of the proxies
but I think that's really the heart of the issue with SIPS.  I don't
think its the implementation of hop-by-hop, I think its the assumption
that hop-by-hop is good enough for all the scenarios that SIP is used
for.

My thought is that to alleviate confusion, clarification of the
environment in which SIPS is sufficient is really the key.  Perhaps
break the environment into those that are really trusted and those that
are not.  Allow use of SIPS for the trusted environments and come up
with a decent end-to-end mechanism for those that are not.

FM



On Tue, 2007-03-27 at 12:50 -0500, Dean Willis wrote:
> On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote:
>
> >
> > Firstly, what is the point of sips? What does it bring a network
> > that it can't get with TLS on some hops, as needed? The answer is
> > that certain security benefits are afforded if we can assure that
> > every single hop from UAC to UAS was TLS protected, and that
> > furthermore, this fact can be definitively known by the UAC, UAS,
> > and all proxies along the way. If we make the assumption that the
> > UA's trust their proxies (please don't question the assumption in
> > this thread), then SIPS provides you some very nice security
> > properties - confidentiality and integrity from all non-trusted
> > entities. We use this property all over our specs to secure various
> > extensions.
> >
>
> Note that I changed threads . . .
>
> There is a big gap between "UAs trust their proxies" and "UAs trust
> every proxy that might possibly get inserted into the signaling path".
>
> You assert "assure that every single hop from UAC to UAS was TLS
> protected, and that furthermore, this fact can be definitively known
> by the UAC, UAS, and all proxies along the way"
>
> Since:
>
> 1) UAs have no control over what proxies beyond the first hop get
> inserted.
> 2) Neither UAs nor proxies have any mechanism for knowing whether
> proxies or UAs more than one proxy hop away actually complied with
> the requirements of SIPS.
>
>
> That's not saying SIPS doesn't provide some useful security
> properties. It does. It just doesn't provide the assurance that I
> keep hearing repeated. And I think that if you STOP saying it
> provides that sort of assurance, it will stop confusing people so
> badly about what it does usefully provide.
>
> --
> 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

------=_Part_13198_21372007.1175020259053-- --===============1095593144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1095593144==-- From sip-bounces@ietf.org Tue Mar 27 14:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGqO-0007Fa-NX; Tue, 27 Mar 2007 14:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGqN-0007FV-1D for sip@ietf.org; Tue, 27 Mar 2007 14:56:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGqL-0006in-N8 for sip@ietf.org; Tue, 27 Mar 2007 14:56:31 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RI2WEf030396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 12:02:33 -0600 In-Reply-To: <46091EB2.6020303@cisco.com> References: <46091EB2.6020303@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66C13A05-2EA8-4455-B585-293320BB1C33@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 13:56:07 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: > I believe this extends to retargeting as well. I think we clearly > need to disallow retargeting or downgrading from a sips URI to a > sip URI. I think that was also largely non-controversial. I'd say that this is arguably already a factor in RFC 3261, EXCEPT for the responsible home proxy being able to downgrade. So "eliminating the last-hop exception" and "disallowing downgrading from SIPS to SIP" are, IMHO, redundant expressions. In any case (chair hat on), we had a clear consensus at IETF 68 to disallow downgrading. Retargeting is a somewhat thornier question, since that behavior is AFAIK somewhat scattered throughout RFC 3261, but I believe we also had a consensus to disallow retargeting from SIPS to SIP at IETF 68. > However, I also want to disallow upgrading or retargeting from sip > to sips. On this, there was some disagreement. > > The challenge Jon gave me at the mike was this. As long as a UAC > inserts a sips URI into the To field and R-URI field when it emits > a sips request, does not the presence of a sips URI in the TO > field, and receipt over a TLS connection, assure that the request > was delivered over TLS at each hop? Had the request been sent > originally to a sip URI and then upgraded, the TO field would not > have been sips, but rather sip. > > I believe Jon is correct, however I still think it is not a good > idea. My rationale is: > > 1. if upgrades are disallowed, redirecting from sip to sips works > much better. Such a redirection would necesarily have to go all the > way to the UAC. If we allow upgrades, a proxy in the middle could > recurse and upgrade. In that case, if the reason for the > redirection was that the UAS *wanted* TLS on each hop, recursing in > the middle would destroy that possibility. > > 2. The architectural principle behind the first issue, more > generally, is that the meaning of sips is *SECURE ON EACH HOP FROM > UAC TO UAS*. To me, this is fundamentally at odds with any notion > of upgrade or downgrade. > > 3. Things become simpler if we forbid upgrades. We can eliminate > the text on double-record routing sinec a proxy would never be sip/ > sips converting. I think it also just generally makes overall > processing easier. SIPS means one thing and one thing only and its > terribly clear what it means. > > As such, I stand by my argument that we should forbid upgrades. Something I'm confused about here. Assume we started a request chain with a "tel:" URI that was delivered over TLS to an "outbound" proxy that needs to retarget the request to a destination for which it has a known SIPS: URI. What should the proxy do? Retarget to sips:, or retarget to sip: and rely on the "thou shalt use TLS if possible" language to deliver the request securely? -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGz7-0002B0-Kk; Tue, 27 Mar 2007 15:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWGz6-0002AT-BX for sip@ietf.org; Tue, 27 Mar 2007 15:05:32 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWGz5-0001EL-1w for sip@ietf.org; Tue, 27 Mar 2007 15:05:32 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJ5Mo15705; Tue, 27 Mar 2007 19:05:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 14:04:50 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C027@zrc2hxm2.corp.nortel.com> In-Reply-To: <66C13A05-2EA8-4455-B585-293320BB1C33@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not thread-index: AcdwojVMgJOYfqI5Sl+I+1Q5TYfQcgAADirQ From: "Samir Srivastava" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is what I am asking. I want my N11 call to have confidentiality too. What if the translation to SIP URI is to be done by a SIP Proxy which is couple of hops away from the UAC. Thx Samir >=20 > Something I'm confused about here. >=20 > Assume we started a request chain with a "tel:" URI that was > delivered over TLS to an "outbound" proxy that needs to retarget the > request to a destination for which it has a known SIPS: URI. >=20 > What should the proxy do? Retarget to sips:, or retarget to sip: and > rely on the "thou shalt use TLS if possible" language to deliver the > request securely? >=20 > -- > dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWH2K-0004Ln-8v; Tue, 27 Mar 2007 15:08:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWH2J-0004GB-3H for sip@ietf.org; Tue, 27 Mar 2007 15:08:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWH2H-0001rj-JK for sip@ietf.org; Tue, 27 Mar 2007 15:08:51 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Mar 2007 12:08:49 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2RJ8mJK008820; Tue, 27 Mar 2007 12:08:48 -0700 Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2RJ8lwn004438; Tue, 27 Mar 2007 19:08:47 GMT In-Reply-To: <1175022487.4681.16.camel@sipx.cornfed.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 15:08:38 -0400 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4732; t=1175022528; x=1175886528; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20Does=20TLS=20have=20the=20security=20benefits=20claim ed?=20(was=20TLS=20Re=3A=20[Sip]=20sips=3A=20upgrading=20allowed=20or=20no t) |Sender:=20; bh=9SyptH5ZmhgRnekTfASa/L7M/S8JAqWq3kEK5qxu9sQ=; b=HhTV177v9fpRDZNltsftk5yR9IjiTmiuso3S5pvRgj7Q7ojs7Uyn/c+ByiXXNJqQ3M3vqmyf luCcUukowLKmDOk4tlDgB5ulXrFN+tlNqecMVCPfAMcjtOamoUE1KQ2i; Authentication-Results: sj-dkim-8; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 3:08 PM, Frank W. Miller wrote: > > I think there are two distinct environments that need to be > identified. > The first would be something like a carrier environment, i.e. IMS- > like. > In this environment the assumption that the proxies are trusted is > probably valid. The carriers are unlikely to use a path that does not > include proxies they trust, either because they own them or because > they > have a relationship with the owner. This looks alot like the SS7 > world > where the signaling points are all assumed to be trusted. > > The second environment I'll call the open Internet. While this may > include proxies that can be trusted, e.g. my first hop to a known > service provider, I think it would be easy to paint scenarios where > the > UA didn't really know all the signaling hops. In this environment the > hop-by-hop trust is probably not good enough for the security > properties > being targeted. > Hmmm, I might be tempted to argue the reverse, because the IMS carriers are subject to CALEA-like regulations, and the open internet services are not. Transitive trust just sucks, and constructing finely tuned arguments about exactly when it is resonable to place that trust is, at leas to me, in the domain of philosophy and well outside engineering. This is why I continue to be in the camp that finds SIPS of very limited utility, and more likely to be misunderstood to the detriment of users than truly valuable. > I know you said we weren't supposed to question the trust of the > proxies > but I think that's really the heart of the issue with SIPS. I don't > think its the implementation of hop-by-hop, I think its the assumption > that hop-by-hop is good enough for all the scenarios that SIP is used > for. > > My thought is that to alleviate confusion, clarification of the > environment in which SIPS is sufficient is really the key. Perhaps > break the environment into those that are really trusted and those > that > are not. Allow use of SIPS for the trusted environments and come up > with a decent end-to-end mechanism for those that are not. > > FM > > > > On Tue, 2007-03-27 at 12:50 -0500, Dean Willis wrote: >> On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: >> >>> >>> Firstly, what is the point of sips? What does it bring a network >>> that it can't get with TLS on some hops, as needed? The answer is >>> that certain security benefits are afforded if we can assure that >>> every single hop from UAC to UAS was TLS protected, and that >>> furthermore, this fact can be definitively known by the UAC, UAS, >>> and all proxies along the way. If we make the assumption that the >>> UA's trust their proxies (please don't question the assumption in >>> this thread), then SIPS provides you some very nice security >>> properties - confidentiality and integrity from all non-trusted >>> entities. We use this property all over our specs to secure various >>> extensions. >>> >> >> Note that I changed threads . . . >> >> There is a big gap between "UAs trust their proxies" and "UAs trust >> every proxy that might possibly get inserted into the signaling >> path". >> >> You assert "assure that every single hop from UAC to UAS was TLS >> protected, and that furthermore, this fact can be definitively known >> by the UAC, UAS, and all proxies along the way" >> >> Since: >> >> 1) UAs have no control over what proxies beyond the first hop get >> inserted. >> 2) Neither UAs nor proxies have any mechanism for knowing whether >> proxies or UAs more than one proxy hop away actually complied with >> the requirements of SIPS. >> >> >> That's not saying SIPS doesn't provide some useful security >> properties. It does. It just doesn't provide the assurance that I >> keep hearing repeated. And I think that if you STOP saying it >> provides that sort of assurance, it will stop confusing people so >> badly about what it does usefully provide. >> >> -- >> Dean >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:13:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWH5q-00064o-Bo; Tue, 27 Mar 2007 15:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWH5o-00064g-O0 for sip@ietf.org; Tue, 27 Mar 2007 15:12:28 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWH5n-0002bo-GZ for sip@ietf.org; Tue, 27 Mar 2007 15:12:28 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJCOo16979; Tue, 27 Mar 2007 19:12:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 14:12:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FC5A3C5@zrc2hxm0.corp.nortel.com> In-Reply-To: <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQ References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 People, Can we stick to the topic and not repeat the pointless arguments of the previous 4 months about transitive trust. We have a working group consensus, let's move on. Let's focus on the one remaining issue, which is "Do we allow for retarget upgrades from=20 SIP to SIPS" (in the other thread). This particular thread here should be put to rest. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHEH-0001Zt-So; Tue, 27 Mar 2007 15:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHEG-0001Zl-64 for sip@ietf.org; Tue, 27 Mar 2007 15:21:12 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHEA-0004bs-CL for sip@ietf.org; Tue, 27 Mar 2007 15:21:12 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJL3o18767; Tue, 27 Mar 2007 19:21:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 14:21:01 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C07D@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FC5A3C5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) thread-index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yA= From: "Samir Srivastava" To: "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have to state respectfully that SIP network is not going to be utilized for transporting only SIP URI schemes in different scenarios. This is another point apart from transitive trust.=20 I just want to know the decision on the other URI schemes. Thx Samir > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, March 27, 2007 12:12 PM > To: IETF SIP List > Cc: Dean Willis > Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: > [Sip] sips: upgrading allowed or not) >=20 >=20 > People, >=20 > Can we stick to the topic and not repeat the pointless arguments of the > previous 4 months > about transitive trust. >=20 > We have a working group consensus, let's move on. >=20 > Let's focus on the one remaining issue, which is "Do we allow for > retarget upgrades from > SIP to SIPS" (in the other thread). >=20 > This particular thread here should be put to rest. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHI8-0004eN-UI; Tue, 27 Mar 2007 15:25:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHI7-0004b0-UT for sip@ietf.org; Tue, 27 Mar 2007 15:25:11 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHI4-0005z8-HR for sip@ietf.org; Tue, 27 Mar 2007 15:25:11 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJP5o19605; Tue, 27 Mar 2007 19:25:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 14:24:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FC5A406@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C07D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUA== References: <1ECE0EB50388174790F9694F77522CCF0FC5A3C5@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C07D@zrc2hxm2.corp.nortel.com> From: "Francois Audet" To: "Samir Srivastava" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In that case, it's not a retarget but a redirect. For example, I call you at sip:samir@nortel.com. You send me a 301 Contact: mailto:samir@nortel.com. My UA warns me that you are only availble through email, and I can decide to send you email or not. That's covered in there. =20 > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Tuesday, March 27, 2007 12:21 > To: Audet, Francois (SC100:3055); IETF SIP List > Cc: Dean Willis > Subject: RE: Does TLS have the security benefits claimed?=20 > (was TLS Re: [Sip] sips: upgrading allowed or not) >=20 > I have to state respectfully that SIP network is not going to=20 > be utilized for transporting only SIP URI schemes in=20 > different scenarios. This is another point apart from=20 > transitive trust.=20 >=20 > I just want to know the decision on the other URI schemes. >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Tuesday, March 27, 2007 12:12 PM > > To: IETF SIP List > > Cc: Dean Willis > > Subject: RE: Does TLS have the security benefits claimed?=20 > (was TLS Re: > > [Sip] sips: upgrading allowed or not) > >=20 > >=20 > > People, > >=20 > > Can we stick to the topic and not repeat the pointless arguments of=20 > > the previous 4 months about transitive trust. > >=20 > > We have a working group consensus, let's move on. > >=20 > > Let's focus on the one remaining issue, which is "Do we allow for=20 > > retarget upgrades from SIP to SIPS" (in the other thread). > >=20 > > This particular thread here should be put to rest. > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:30:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHNK-0006su-7x; Tue, 27 Mar 2007 15:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHNJ-0006sn-9Z for sip@ietf.org; Tue, 27 Mar 2007 15:30:33 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHNH-0007BS-Vh for sip@ietf.org; Tue, 27 Mar 2007 15:30:33 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RIapHY030615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 12:36:52 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FC5A3C5@zrc2hxm0.corp.nortel.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A3C5@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5ECFF61D-A1CA-4D29-9924-7EFA754CF839@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 14:30:26 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 2:12 PM, Francois Audet wrote: > > People, > > Can we stick to the topic and not repeat the pointless arguments of > the > previous 4 months > about transitive trust. > > We have a working group consensus, let's move on. > > Let's focus on the one remaining issue, which is "Do we allow for > retarget upgrades from > SIP to SIPS" (in the other thread). That's the "upgrading allowed or not" thread which is continuing independently. This thread is the "rehash the assurance question" thread . . . > > This particular thread here should be put to rest. > Let it go, or it's likely to come back up on the "upgrading allowed" thread . . . and it's much better to have the two discussions running under different subject lines than the same subject line. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:31:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHNo-00074e-IA; Tue, 27 Mar 2007 15:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHNn-00072x-B2 for sip@ietf.org; Tue, 27 Mar 2007 15:31:03 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHNh-0007ID-Rk for sip@ietf.org; Tue, 27 Mar 2007 15:31:03 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJUti16541; Tue, 27 Mar 2007 19:30:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 14:30:53 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C0B3@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FC5A406@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) thread-index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbA From: "Samir Srivastava" To: "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This doesn't cover the original (first) request having ReqURI populated with tel URI, which has to traverse couple of SIP proxies and then translation to SIP or SIPS is done at a proxy which is further down. What the intermediate proxies will do ? Thx Samir > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, March 27, 2007 12:25 PM > To: Srivastava, Samir (SC100:8826); 'IETF SIP List' > Cc: 'Dean Willis' > Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: > [Sip] sips: upgrading allowed or not) >=20 > In that case, it's not a retarget but a redirect. >=20 > For example, I call you at sip:samir@nortel.com. You send me a 301 > Contact: mailto:samir@nortel.com. >=20 > My UA warns me that you are only availble through email, and I can decide > to send you email or not. >=20 > That's covered in there. >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:32:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHOt-0007sx-Sx; Tue, 27 Mar 2007 15:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHOr-0007sj-O4 for sip@ietf.org; Tue, 27 Mar 2007 15:32:09 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHOq-0007YV-FU for sip@ietf.org; Tue, 27 Mar 2007 15:32:09 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJW5i16733; Tue, 27 Mar 2007 19:32:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 14:32:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FC5A422@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C0B3@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegA= References: <1ECE0EB50388174790F9694F77522CCF0FC5A406@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C0B3@zrc2hxm2.corp.nortel.com> From: "Francois Audet" To: "Samir Srivastava" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It must not map from Tel to SIPS. =20 Just from Tel to SIP. That's the point.=20 > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Tuesday, March 27, 2007 12:31 > To: Audet, Francois (SC100:3055); 'IETF SIP List' > Cc: 'Dean Willis' > Subject: RE: Does TLS have the security benefits claimed?=20 > (was TLS Re: [Sip] sips: upgrading allowed or not) >=20 > This doesn't cover the original (first) request having ReqURI=20 > populated with tel URI, which has to traverse couple of SIP=20 > proxies and then translation to SIP or SIPS is done at a=20 > proxy which is further down. What the intermediate proxies will do ? >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Tuesday, March 27, 2007 12:25 PM > > To: Srivastava, Samir (SC100:8826); 'IETF SIP List' > > Cc: 'Dean Willis' > > Subject: RE: Does TLS have the security benefits claimed?=20 > (was TLS Re: > > [Sip] sips: upgrading allowed or not) > >=20 > > In that case, it's not a retarget but a redirect. > >=20 > > For example, I call you at sip:samir@nortel.com. You send me a 301 > > Contact: mailto:samir@nortel.com. > >=20 > > My UA warns me that you are only availble through email, and I can=20 > > decide to send you email or not. > >=20 > > That's covered in there. > >=20 > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHT2-0002nF-RS; Tue, 27 Mar 2007 15:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHT1-0002n5-Fr for sip@ietf.org; Tue, 27 Mar 2007 15:36:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHT0-0008Fk-67 for sip@ietf.org; Tue, 27 Mar 2007 15:36:27 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RIgcCG030661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 12:42:39 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C027@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E611F4C027@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 14:36:13 -0500 To: "Samir Srivastava" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 2:04 PM, Samir Srivastava wrote: > > This is what I am asking. I want my N11 call to have confidentiality > too. Right. Of course, if we have the working requirement that "all compliant implementations MUST use TLS if it is available", then the additional requirement for N11 calls of "This call MUST succeed, and it SHOULD be confidential and integrity protected" lead us to a different conclusion. That conclusion would be: N11 calls translate to sip: URIs, because the PSAP or some intermediary might not support sips:, and it is more important for the N11 call to succeed than it is for it to be confidential and integrity protected. > What if the translation to SIP URI is to be done by a SIP Proxy > which is > couple of hops away from the UAC. > I think that case is pretty clear -- by the reasoning presented, if there have been a assertably-not-SIPS-like hops, you can't upgrade from tel: to sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHSz-0002kO-Sv; Tue, 27 Mar 2007 15:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHSy-0002kE-NB for sip@ietf.org; Tue, 27 Mar 2007 15:36:24 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHSw-0008FR-7c for sip@ietf.org; Tue, 27 Mar 2007 15:36:24 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJaEo21440; Tue, 27 Mar 2007 19:36:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 14:35:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> In-Reply-To: <46091EB2.6020303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfg References: <46091EB2.6020303@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Jonathan's proposal. Here is a slighly different perspective on it however. I'll keep rethorical arguments out of it, and stick to protocol. - Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy would be a normative change to RFC 3261. Section 26.4.4 describes it (3rd paragraph on p. 250). That is just an observation. - The fact that it is currently allowed means that the UAS receiving the request has to go through some fairly esoteric logic to "guess" if the request was sent securily on each hop or not. This is described in paragraph 4 of p. 250, and section 4.1 of draft-ietf-sip-sips-02 also describes it, with some modifications. Those procedures are extremely cludgy and non-deterministic. They are also misleading for the UAS, and inconsistent with the use of SIPS and SIP as described in this draft (i.e., for the other scenarios of forwarding and retargeting). In all other instances,=20 the idea is that when a request is forwarded/retargeted, the scheme is preserve.=20 I'd really like to get rid of section 4.1. - Jonathan Peterson was proposing that the UAS inspect the To header to see if=20 the request was initially targeted at SIPS. This is a subset of the procedures=20 of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff like looking at=20 Via and other fields). - This "upgrading" also forces the use of the double Record-Route in section 4.2 of draft-ietf-sip-sips-02. Since we agreed to deprecate the last hop exception for downgrading, the SIPS-to-SIP Record-Route scenario will be removed from the -03 version. Removing the "upgrade" scenario would also remove the double=20 Record-Route for the SIP-to-SIPS, and the net-net is that the whole section 4.2 could be removed. - Because of rules described in RFC 3261, if a UAS receives an incoming request with a=20 SIPS Request-URI, it MUST use a SIPS contact. This is a big problem for the sender of the initial request that initiated the dialog if that UAC did not support SIPS. If Record-Routing is not used, it will just plainly not work. The UAC will not be able to send further requests (like BYE for example). If Record-Route is used, it=20 might work (or it might not). The reason it might not work is that there is possible that the UAC might "choke" on the SIPS URI in the Contact (because it doesn't understand how to parse it). - We have corrected to types of problems everywhere else in this draft. There was quite a few of them in previous versions. This is the only one remaining. - Note that it would still be possible to "upgrade" by sending SIP over TLS. In fact, I would argue that we need to put a requirement to do so when there is already a TLS connection opened with the target (as would be the case if Outbound was used, and the registration was done over TLS). In summary, I favor deprecating the "retargeting upgrade" scenario for the following reasons: - It greatly simplifies the draft, eliminating sections 4.1 and 4.2 completely. - It is much less confusing for the far end. - It avoids some nasty protocol level problems that "break" things. - You can still use TLS for transport for delivering to that last hop. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, March 27, 2007 06:40 > To: IETF SIP List > Subject: [Sip] sips: upgrading allowed or not >=20 > During the Prague IETF, I shared some opinions on what I=20 > thought sips needs to look like and why, and wanted to take=20 > these to the list. >=20 > Firstly, what is the point of sips? What does it bring a=20 > network that it can't get with TLS on some hops, as needed?=20 > The answer is that certain security benefits are afforded if=20 > we can assure that every single hop from UAC to UAS was TLS=20 > protected, and that furthermore, this fact can be=20 > definitively known by the UAC, UAS, and all proxies along the=20 > way. If we make the assumption that the UA's trust their=20 > proxies (please don't question the assumption in this=20 > thread), then SIPS provides you some very nice security=20 > properties - confidentiality and integrity from all=20 > non-trusted entities. We use this property all over our specs=20 > to secure various extensions. >=20 > Given that, sips is broken if it doesn't provide that service=20 > (tls on each hop with knowledge of such by all entities). FOr=20 > this reason, I think we need to eliminate the last hop=20 > exception (uncontroversial I think), but furthermore, I=20 > believe this extends to retargeting as well.=20 > I think we clearly need to disallow retargeting or=20 > downgrading from a sips URI to a sip URI. I think that was=20 > also largely non-controversial.=20 > However, I also want to disallow upgrading or retargeting=20 > from sip to sips. On this, there was some disagreement. >=20 > The challenge Jon gave me at the mike was this. As long as a=20 > UAC inserts a sips URI into the To field and R-URI field when=20 > it emits a sips request, does not the presence of a sips URI=20 > in the TO field, and receipt over a TLS connection, assure=20 > that the request was delivered over TLS at each hop? Had the=20 > request been sent originally to a sip URI and then upgraded,=20 > the TO field would not have been sips, but rather sip. >=20 > I believe Jon is correct, however I still think it is not a=20 > good idea.=20 > My rationale is: >=20 > 1. if upgrades are disallowed, redirecting from sip to sips=20 > works much better. Such a redirection would necesarily have=20 > to go all the way to the UAC. If we allow upgrades, a proxy=20 > in the middle could recurse and upgrade. In that case, if the=20 > reason for the redirection was that the UAS *wanted* TLS on=20 > each hop, recursing in the middle would destroy that possibility. >=20 > 2. The architectural principle behind the first issue, more=20 > generally, is that the meaning of sips is *SECURE ON EACH HOP=20 > FROM UAC TO UAS*. To me, this is fundamentally at odds with=20 > any notion of upgrade or downgrade. >=20 > 3. Things become simpler if we forbid upgrades. We can=20 > eliminate the text on double-record routing sinec a proxy=20 > would never be sip/sips converting. I think it also just=20 > generally makes overall processing easier. SIPS means one=20 > thing and one thing only and its terribly clear what it means. >=20 > As such, I stand by my argument that we should forbid upgrades. >=20 > -JOnathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW developmenFrom sip-bounces@ietf.org Tue Mar 27 15:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHT2-0002nF-RS; Tue, 27 Mar 2007 15:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHT1-0002n5-Fr for sip@ietf.org; Tue, 27 Mar 2007 15:36:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHT0-0008Fk-67 for sip@ietf.org; Tue, 27 Mar 2007 15:36:27 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RIgcCG030661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 12:42:39 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C027@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E611F4C027@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 14:36:13 -0500 To: "Samir Srivastava" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 2:04 PM, Samir Srivastava wrote: > > This is what I am asking. I want my N11 call to have confidentiality > too. Right. Of course, if we have the working requirement that "all compliant implementations MUST use TLS if it is available", then the additional requirement for N11 calls of "This call MUST succeed, and it SHOULD be confidential and integrity protected" lead us to a different conclusion. That conclusion would be: N11 calls translate to sip: URIs, because the PSAP or some intermediary might not support sips:, and it is more important for the N11 call to succeed than it is for it to be confidential and integrity protected. > What if the translation to SIP URI is to be done by a SIP Proxy > which is > couple of hops away from the UAC. > I think that case is pretty clear -- by the reasoning presented, if there have been a assertably-not-SIPS-like hops, you can't upgrade from tel: to sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHSz-0002kO-Sv; Tue, 27 Mar 2007 15:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHSy-0002kE-NB for sip@ietf.org; Tue, 27 Mar 2007 15:36:24 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHSw-0008FR-7c for sip@ietf.org; Tue, 27 Mar 2007 15:36:24 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJaEo21440; Tue, 27 Mar 2007 19:36:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:cot of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ntent-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 14:35:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> In-Reply-To: <46091EB2.6020303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfg References: <46091EB2.6020303@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Jonathan's proposal. Here is a slighly different perspective on it however. I'll keep rethorical arguments out of it, and stick to protocol. - Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy would be a normative change to RFC 3261. Section 26.4.4 describes it (3rd paragraph on p. 250). That is just an observation. - The fact that it is currently allowed means that the UAS receiving the request has to go through some fairly esoteric logic to "guess" if the request was sent securily on each hop or not. This is described in paragraph 4 of p. 250, and section 4.1 of draft-ietf-sip-sips-02 also describes it, with some modifications. Those procedures are extremely cludgy and non-deterministic. They are also misleading for the UAS, and inconsistent with the use of SIPS and SIP as described in this draft (i.e., for the other scenarios of forwarding and retargeting). In all other instances,=20 the idea is that when a request is forwarded/retargeted, the scheme is preserve.=20 I'd really like to get rid of section 4.1. - Jonathan Peterson was proposing that the UAS inspect the To header to see if=20 the request was initially targeted at SIPS. This is a subset of the procedures=20 of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff like looking at=20 Via and other fields). - This "upgrading" also forces the use of the double Record-Route in section 4.2 of draft-ietf-sip-sips-02. Since we agreed to deprecate the last hop exception for downgrading, the SIPS-to-SIP Record-Route scenario will be removed from the -03 version. Removing the "upgrade" scenario would also remove the double=20 Record-Route for the SIP-to-SIPS, and the net-net is that the whole section 4.2 could be removed. - Because of rules described in RFC 3261, if a UAS receives an incoming request with a=20 SIPS Request-URI, it MUST use a SIPS contact. This is a big problem for the sender of the initial request that initiated the dialog if that UAC did not support SIPS. If Record-Routing is not used, it will just plainly not work. The UAC will not be able to send further requests (like BYE for example). If Record-Route is used, it=20 might work (or it might not). The reason it might not work is that there is possible that the UAC might "choke" on the SIPS URI in the Contact (because it doesn't understand how to parse it). - We have corrected to types of problems everywhere else in this draft. There was quite a few of them in previous versions. This is the only one remaining. - Note that it would still be possible to "upgrade" by sending SIP over TLS. In fact, I would argue that we need to put a requirement to do so when there is already a TLS connection opened with the target (as would be the case if Outbound was used, and the registration was done over TLS). In summary, I favor deprecating the "retargeting upgrade" scenario for the following reasons: - It greatly simplifies the draft, eliminating sections 4.1 and 4.2 completely. - It is much less confusing for the far end. - It avoids some nasty protocol level problems that "break" things. - You can still use TLS for transport for delivering to that last hop. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, March 27, 2007 06:40 > To: IETF SIP List > Subject: [Sip] sips: upgrading allowed or not >=20 > During the Prague IETF, I shared some opinions on what I=20 > thought sips needs to look like and why, and wanted to take=20 > these to the list. >=20 > Firstly, what is the point of sips? What does it bring a=20 > network that it can't get with TLS on some hops, as needed?=20 > The answer is that certain security benefits are afforded if=20 > we can assure that every single hop from UAC to UAS was TLS=20 > protected, and that furthermore, this fact can be=20 > definitively known by the UAC, UAS, and all proxies along the=20 > way. If we make the assumption that the UA's trust their=20 > proxies (please don't question the assumption in this=20 > thread), then SIPS provides you some very nice security=20 > properties - confidentiality and integrity from all=20 > non-trusted entities. We use this property all over our specs=20 > to secure various extensions. >=20 > Given that, sips is broken if it doesn't provide that service=20 > (tls on each hop with knowledge of such by all entities). FOr=20 > this reason, I think we need to eliminate the last hop=20 > exception (uncontroversial I think), but furthermore, I=20 > believe this extends to retargeting as well.=20 > I think we clearly need to disallow retargeting or=20 > downgrading from a sips URI to a sip URI. I think that was=20 > also largely non-controversial.=20 > However, I also want to disallow upgrading or retargeting=20 > from sip to sips. On this, there was some disagreement. >=20 > The challenge Jon gave me at the mike was this. As long as a=20 > UAC inserts a sips URI into the To field and R-URI field when=20 > it emits a sips request, does not the presence of a sips URI=20 > in the TO field, and receipt over a TLS connection, assure=20 > that the request was delivered over TLS at each hop? Had the=20 > request been sent originally to a sip URI and then upgraded,=20 > the TO field would not have been sips, but rather sip. >=20 > I believe Jon is correct, however I still think it is not a=20 > good idea.=20 > My rationale is: >=20 > 1. if upgrades are disallowed, redirecting from sip to sips=20 > works much better. Such a redirection would necesarily have=20 > to go all the way to the UAC. If we allow upgrades, a proxy=20 > in the middle could recurse and upgrade. In that case, if the=20 > reason for the redirection was that the UAS *wanted* TLS on=20 > each hop, recursing in the middle would destroy that possibility. >=20 > 2. The architectural principle behind the first issue, more=20 > generally, is that the meaning of sips is *SECURE ON EACH HOP=20 > FROM UAC TO UAS*. To me, this is fundamentally at odds with=20 > any notion of upgrade or downgrade. >=20 > 3. Things become simpler if we forbid upgrades. We can=20 > eliminate the text on double-record routing sinec a proxy=20 > would never be sip/sips converting. I think it also just=20 > generally makes overall processing easier. SIPS means one=20 > thing and one thing only and its terribly clear what it means. >=20 > As such, I stand by my argument that we should forbid upgrades. >=20 > -JOnathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHUg-0004SL-Ns; Tue, 27 Mar 2007 15:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHUe-0004Qc-MB for sip@ietf.org; Tue, 27 Mar 2007 15:38:08 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHUd-0000HF-EF for sip@ietf.org; Tue, 27 Mar 2007 15:38:08 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2RJbib26614; Tue, 27 Mar 2007 19:37:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2007 14:38:01 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FC5A422@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Other URI (Tel URI) scheme thread-index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoA== From: "Samir Srivastava" To: "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Dean Willis Subject: [Sip] Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Changed the subject. But the UAC wanted its Tel Uri Request to traverse securely on the intermediate hops. How it can enforce that? =20 =20 Thx Samir > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, March 27, 2007 12:32 PM > To: Srivastava, Samir (SC100:8826); 'IETF SIP List' > Cc: 'Dean Willis' > Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: > [Sip] sips: upgrading allowed or not) >=20 > It must not map from Tel to SIPS. >=20 > Just from Tel to SIP. That's the point. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHXN-0005cU-F2; Tue, 27 Mar 2007 15:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHXM-0005c2-2c for sip@ietf.org; Tue, 27 Mar 2007 15:40:56 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHXH-0000qx-L8 for sip@ietf.org; Tue, 27 Mar 2007 15:40:54 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.85.3; Tue, 27 Mar 2007 12:40:51 -0700 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi; Tue, 27 Mar 2007 12:40:50 -0700 From: Sean Olson To: Samir Srivastava , Francois Audet , IETF SIP List Date: Tue, 27 Mar 2007 12:40:41 -0700 Thread-Topic: Securing Other URI (Tel URI) scheme Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7Ng Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <1ECE0EB50388174790F9694F77522CCF0FC5A422@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Dean Willis Subject: [Sip] RE: Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Tels: of course -----Original Message----- From: Samir Srivastava [mailto:samirsr@nortel.com] Sent: Tuesday, March 27, 2007 12:38 PM To: Francois Audet; IETF SIP List Cc: Dean Willis Subject: [Sip] Securing Other URI (Tel URI) scheme Changed the subject. But the UAC wanted its Tel Uri Request to traverse securely on the intermediate hops. How it can enforce that? Thx Samir > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, March 27, 2007 12:32 PM > To: Srivastava, Samir (SC100:8826); 'IETF SIP List' > Cc: 'Dean Willis' > Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: > [Sip] sips: upgrading allowed or not) > > It must not map from Tel to SIPS. > > Just from Tel to SIP. That's the point. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHcM-0008T9-Na; Tue, 27 Mar 2007 15:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHcL-0008T4-EJ for sip@ietf.org; Tue, 27 Mar 2007 15:46:05 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHcK-0002Zm-7e for sip@ietf.org; Tue, 27 Mar 2007 15:46:05 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RJjxi19302; Tue, 27 Mar 2007 19:45:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2007 14:45:58 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C101@zrc2hxm2.corp.nortel.com> In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Other URI (Tel URI) scheme thread-index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAA= From: "Samir Srivastava" To: "Sean Olson" , "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Dean Willis Subject: [Sip] RE: Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Sean, That's where I have the biggest problem. This solution is non-modular. Proxy-Require (tls / cipher-suite) provides the modular solution. You keep inventing the other URI schemes without doubling the "S" suffix URIs for secure routing. Secure Routing requirement is settled once for all using Proxy-Require / Require.=20 Thx Samir > -----Original Message----- > From: Sean Olson [mailto:seanol@exchange.microsoft.com] > Sent: Tuesday, March 27, 2007 12:41 PM > To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); IETF SIP > List > Cc: Dean Willis > Subject: RE: Securing Other URI (Tel URI) scheme >=20 > Tels: of course >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:46:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHcg-000088-AQ; Tue, 27 Mar 2007 15:46:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHce-00007w-Nn for sip@ietf.org; Tue, 27 Mar 2007 15:46:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHcd-0002cM-Dg for sip@ietf.org; Tue, 27 Mar 2007 15:46:24 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RIqgV5030766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 12:52:43 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B9F716F-46C2-4AC6-BE40-07FC55D6AE78@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 27 Mar 2007 14:46:17 -0500 To: "Samir Srivastava" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF SIP List , Francois Audet Subject: [Sip] Re: Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 2:38 PM, Samir Srivastava wrote: > Changed the subject. > > But the UAC wanted its Tel Uri Request to traverse securely on the > intermediate hops. How it can enforce that? > It can't. SIP, as currently defined, JUST DOESN'T HAVE THAT PROPERTY. Without adding a new mechanism, at the very best, we can do a "the request will be sent as securely as it can be". And adding such a mechanism is, I believe, more complex than just an option-tag or request-URI modifier. One way of getting the sort of property I think you're looking for would be to add something like a Connection-Handling header field that would say "must use TLS", along with a new option tag that could be used in Proxy-Require and Require to make sure that the proxies and UAS support the "Connection-Handling" extension. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHex-00012A-FN; Tue, 27 Mar 2007 15:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHev-00011o-Vb for sip@ietf.org; Tue, 27 Mar 2007 15:48:45 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHet-0003AB-U3 for sip@ietf.org; Tue, 27 Mar 2007 15:48:45 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 27 Mar 2007 12:48:43 -0700 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi; Tue, 27 Mar 2007 12:48:42 -0700 From: Sean Olson To: Samir Srivastava , Francois Audet , IETF SIP List Date: Tue, 27 Mar 2007 12:48:33 -0700 Thread-Topic: Securing Other URI (Tel URI) scheme Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQA== Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC8@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C101@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C101@zrc2hxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Dean Willis Subject: [Sip] RE: Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ahhh, yes. Now I remember why SIPS was a bad idea. A proxy-require/require= solution might work, just be prepared for zero adoption. -----Original Message----- From: Samir Srivastava [mailto:samirsr@nortel.com] Sent: Tuesday, March 27, 2007 12:46 PM To: Sean Olson; Francois Audet; IETF SIP List Cc: Dean Willis Subject: RE: Securing Other URI (Tel URI) scheme Hi Sean, That's where I have the biggest problem. This solution is non-modular. Proxy-Require (tls / cipher-suite) provides the modular solution. You keep inventing the other URI schemes without doubling the "S" suffix URIs for secure routing. Secure Routing requirement is settled once for all using Proxy-Require / Require. Thx Samir > -----Original Message----- > From: Sean Olson [mailto:seanol@exchange.microsoft.com] > Sent: Tuesday, March 27, 2007 12:41 PM > To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); IETF SIP > List > Cc: Dean Willis > Subject: RE: Securing Other URI (Tel URI) scheme > > Tels: of course > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 15:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHfb-0001B3-LC; Tue, 27 Mar 2007 15:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHfa-0001Ap-FB for sip@ietf.org; Tue, 27 Mar 2007 15:49:26 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHfZ-0003Hu-5U for sip@ietf.org; Tue, 27 Mar 2007 15:49:26 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RItgKj030818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 12:55:43 -0600 In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <1ECE0EB50388174790F9694F77522CCF0FC5A422@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Tue, 27 Mar 2007 14:49:17 -0500 To: Sean Olson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 2:40 PM, Sean Olson wrote: > Tels: of course > Ok, I stand corrected. You could do this with a new URI scheme, provided that 1) the new URI scheme had explicitly stated retargeting properties equivalent to those proposed for sips: and that 2) we fix 3261 to provide those properties for sip:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:07:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHuG-00031C-7x; Tue, 27 Mar 2007 16:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHuE-000317-AG for sip@ietf.org; Tue, 27 Mar 2007 16:04:34 -0400 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHuD-00070W-1h for sip@ietf.org; Tue, 27 Mar 2007 16:04:34 -0400 Received: from sipx.cornfed.com (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l2RK3sO12106; Tue, 27 Mar 2007 15:03:55 -0500 Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) From: "Frank W. Miller" To: David R Oran In-Reply-To: <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> Content-Type: text/plain Date: Tue, 27 Mar 2007 14:03:48 -0700 Message-Id: <1175029428.4681.27.camel@sipx.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2007-03-27 at 15:08 -0400, David R Oran wrote: > On Mar 27, 2007, at 3:08 PM, Frank W. Miller wrote: > > > > > I think there are two distinct environments that need to be > > identified. > > The first would be something like a carrier environment, i.e. IMS- > > like. > > In this environment the assumption that the proxies are trusted is > > probably valid. The carriers are unlikely to use a path that does not > > include proxies they trust, either because they own them or because > > they > > have a relationship with the owner. This looks alot like the SS7 > > world > > where the signaling points are all assumed to be trusted. > > > > The second environment I'll call the open Internet. While this may > > include proxies that can be trusted, e.g. my first hop to a known > > service provider, I think it would be easy to paint scenarios where > > the > > UA didn't really know all the signaling hops. In this environment the > > hop-by-hop trust is probably not good enough for the security > > properties > > being targeted. > > > Hmmm, I might be tempted to argue the reverse, because the IMS > carriers are subject to CALEA-like regulations, and the open internet > services are not. > The need to do CALEA is an additional reason why they will route through their own stuff or one of their telco buddies boxes. It reinforces the fact that they need to trust the proxies. How can I be certain I can see (and therefor tap) the signaling if I'm not sure all the signaling is going through my trusted proxies? > Transitive trust just sucks, and constructing finely tuned arguments > about exactly when it is resonable to place that trust is, at leas to > me, in the domain of philosophy and well outside engineering. > > This is why I continue to be in the camp that finds SIPS of very > limited utility, and more likely to be misunderstood to the detriment > of users than truly valuable. > Well this is actually my real opinion too but we're stuck with proxies. Its a basic architectural tenet of SIP. The fact that their are proxies and that they need to see at least some of the messaging is the root cause of the transitive trust problem. The only real way to do end-to-end is to somehow force the signaling to not traverse the proxies but to be end UA to end UA. Its interesting that if point-to-point signaling were used rather than traversing proxies, SIPS would be just fine for end-to-end security. Perhaps we should come up with a mechanism that allows/forces the signaling to be end-to-end only when end-to-end security is required? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHyw-0004nH-PB; Tue, 27 Mar 2007 16:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHyv-0004mU-0N for sip@ietf.org; Tue, 27 Mar 2007 16:09:25 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHyt-0008Oq-Pr for sip@ietf.org; Tue, 27 Mar 2007 16:09:24 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RK9Ki08878; Tue, 27 Mar 2007 20:09:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2007 15:09:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FC5A4ED@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Other URI (Tel URI) scheme Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAABPy9g References: <1ECE0EB50388174790F9694F77522CCF0FC5A422@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com> From: "Francois Audet" To: "Samir Srivastava" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Dean Willis Subject: [Sip] RE: Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You can not. There is no secure Tel URI.=20 > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Tuesday, March 27, 2007 12:38 > To: Audet, Francois (SC100:3055); 'IETF SIP List' > Cc: 'Dean Willis' > Subject: Securing Other URI (Tel URI) scheme >=20 > Changed the subject. >=20 > But the UAC wanted its Tel Uri Request to traverse securely=20 > on the intermediate hops. How it can enforce that? =20 > =20 > Thx > Samir >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Tuesday, March 27, 2007 12:32 PM > > To: Srivastava, Samir (SC100:8826); 'IETF SIP List' > > Cc: 'Dean Willis' > > Subject: RE: Does TLS have the security benefits claimed?=20 > (was TLS Re: > > [Sip] sips: upgrading allowed or not) > >=20 > > It must not map from Tel to SIPS. > >=20 > > Just from Tel to SIP. That's the point. > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:12:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWI1N-00069I-6n; Tue, 27 Mar 2007 16:11:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWI1L-00069C-LT for sip@ietf.org; Tue, 27 Mar 2007 16:11:55 -0400 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWI1K-0000FV-EK for sip@ietf.org; Tue, 27 Mar 2007 16:11:55 -0400 Received: from sipx.cornfed.com (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l2RKBAO13222; Tue, 27 Mar 2007 15:11:11 -0500 Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) From: "Frank W. Miller" To: Juha Heinanen In-Reply-To: <17929.24743.108793.433934@harjus.tutpro.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> <17929.24743.108793.433934@harjus.tutpro.com> Content-Type: text/plain Date: Tue, 27 Mar 2007 14:11:03 -0700 Message-Id: <1175029863.4681.33.camel@sipx.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2007-03-27 at 21:21 +0300, Juha Heinanen wrote: > Frank W. Miller writes: > > > The first would be something like a carrier environment, i.e. IMS-like. > > In this environment the assumption that the proxies are trusted is > > probably valid. > > what do you mean by "trusted"? government of sweden just proposed that What I mean is that the telco owns the actual proxy or has some kind of relationship with any other carriers that own their boxes. They can control how signaling is routed. Its the SS7 model, i.e. I know where my signaling came from and where its going always, no doubts. SIPS will work in that kind of environment. I would be shocked if when the big carriers implement SIP and/or IMS proxies they don't "own" all the equipment, either themselves or through trusted business relationships. (Somebody from Verizon or TMobile or somebody with like a real cell phone network please shock me) FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWI32-0006tw-5Q; Tue, 27 Mar 2007 16:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWI31-0006tk-7g for sip@ietf.org; Tue, 27 Mar 2007 16:13:39 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWI2z-0000jF-U4 for sip@ietf.org; Tue, 27 Mar 2007 16:13:39 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2RKDDb05030; Tue, 27 Mar 2007 20:13:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2007 15:13:29 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com> In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC8@DF-MASTIFF-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Other URI (Tel URI) scheme thread-index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQAAAfV2g From: "Samir Srivastava" To: "Sean Olson" , "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Dean Willis Subject: [Sip] RE: Securing Other URI (Tel URI) scheme X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have stated a lot of other problems earlier with SIPS too. Apart from just doubling the URIs schemes and documentation pains everytime, It will double the entries in DNS, Registrar too.=20 Loose routing got adopted against the strict routing. Though we provided the backward compatibility as Strict Routing was DEPLOYED.=20 Here SIPS is not deployed, then why not deprecate it. (Pl correct me, if I am wrong) Cost will be on the early implementers.=20 The next version of cipher-suite draft will be more problem centric and talking about the each bit of the problem with SIPS. Thx Samir > -----Original Message----- > From: Sean Olson [mailto:seanol@exchange.microsoft.com] > Sent: Tuesday, March 27, 2007 12:49 PM > To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); IETF SIP > List > Cc: Dean Willis > Subject: RE: Securing Other URI (Tel URI) scheme >=20 > Ahhh, yes. Now I remember why SIPS was a bad idea. A proxy- > require/require solution might work, just be prepared for zero adoption. >=20 > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Tuesday, March 27, 2007 12:46 PM > To: Sean Olson; Francois Audet; IETF SIP List > Cc: Dean Willis > Subject: RE: Securing Other URI (Tel URI) scheme >=20 > Hi Sean, >=20 > That's where I have the biggest problem. This solution is non-modular. >=20 > Proxy-Require (tls / cipher-suite) provides the modular solution. You > keep inventing the other URI schemes without doubling the "S" suffix > URIs for secure routing. Secure Routing requirement is settled once for > all using Proxy-Require / Require. >=20 > Thx > Samir >=20 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:28:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIGA-0006Uv-2o; Tue, 27 Mar 2007 16:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIG8-0006UZ-DI for sip@ietf.org; Tue, 27 Mar 2007 16:27:12 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWIG7-0003Io-2P for sip@ietf.org; Tue, 27 Mar 2007 16:27:12 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RJXR2O031078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 13:33:28 -0600 In-Reply-To: <1175029428.4681.27.camel@sipx.cornfed.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> <9FA53C58-59F1-4DB4-BEDF-A5C35159FD63@cisco.com> <1175029428.4681.27.camel@sipx.cornfed.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7BA6E47B-D921-4636-8104-159B47239FDE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 15:27:02 -0500 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 4:03 PM, Frank W. Miller wrote: > > Its interesting that if point-to-point signaling were used rather than > traversing proxies, SIPS would be just fine for end-to-end security. > Perhaps we should come up with a mechanism that allows/forces the > signaling to be end-to-end only when end-to-end security is required? > like the sipsec: draft? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:28:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIHG-0007T9-P2; Tue, 27 Mar 2007 16:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIHF-0007RC-0t for sip@ietf.org; Tue, 27 Mar 2007 16:28:21 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWIHD-0003TT-Lw for sip@ietf.org; Tue, 27 Mar 2007 16:28:21 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RJYbaQ031081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 13:34:37 -0600 In-Reply-To: <1175029863.4681.33.camel@sipx.cornfed.com> References: <46091EB2.6020303@cisco.com> <1175022487.4681.16.camel@sipx.cornfed.com> <17929.24743.108793.433934@harjus.tutpro.com> <1175029863.4681.33.camel@sipx.cornfed.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 15:28:12 -0500 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 4:11 PM, Frank W. Miller wrote: > On Tue, 2007-03-27 at 21:21 +0300, Juha Heinanen wrote: >> Frank W. Miller writes: >> >>> The first would be something like a carrier environment, i.e. IMS- >>> like. >>> In this environment the assumption that the proxies are trusted is >>> probably valid. >> >> what do you mean by "trusted"? government of sweden just proposed >> that > > What I mean is that the telco owns the actual proxy or has some > kind of > relationship with any other carriers that own their boxes. They can > control how signaling is routed. Its the SS7 model, i.e. I know where > my signaling came from and where its going always, no doubts. SIPS > will > work in that kind of environment. I would be shocked if when the big > carriers implement SIP and/or IMS proxies they don't "own" all the > equipment, either themselves or through trusted business > relationships. > (Somebody from Verizon or TMobile or somebody with like a real cell > phone network please shock me) > trusted != trustworthy. We need to remember that. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 16:51:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIdi-00054K-NE; Tue, 27 Mar 2007 16:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIdh-00054E-9z for sip@ietf.org; Tue, 27 Mar 2007 16:51:33 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWIde-0000wv-U3 for sip@ietf.org; Tue, 27 Mar 2007 16:51:33 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2RKp4b07910; Tue, 27 Mar 2007 20:51:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 15:51:22 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C2AA@zrc2hxm2.corp.nortel.com> In-Reply-To: <7BA6E47B-D921-4636-8104-159B47239FDE@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) thread-index: Acdwrnkejb7VPFlaRSmhbDOT014c8gAAiiGw From: "Samir Srivastava" To: "Dean Willis" , "Frank W. Miller" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF SIP List , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIP providers have to make money also. How does SIPSEC draft provide this information to intermediate proxies without opening up the message to them ? Also how CALEA compliance will be achieved with this ?=20 SIP !=3D HTTP (Though we barrowed a lot from there). Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 27, 2007 1:27 PM > To: Frank W. Miller > Cc: IETF SIP List; David R Oran > Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: > [Sip] sips: upgrading allowed or not) >=20 >=20 > On Mar 27, 2007, at 4:03 PM, Frank W. Miller wrote: >=20 > > > > Its interesting that if point-to-point signaling were used rather than > > traversing proxies, SIPS would be just fine for end-to-end security. > > Perhaps we should come up with a mechanism that allows/forces the > > signaling to be end-to-end only when end-to-end security is required? > > >=20 > like the sipsec: draft? >=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 17:46:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJRy-0006Cq-8o; Tue, 27 Mar 2007 17:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJRw-0006Cl-Ug for sip@ietf.org; Tue, 27 Mar 2007 17:43:28 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWJRv-0002C7-JI for sip@ietf.org; Tue, 27 Mar 2007 17:43:28 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l2RLh6ek017773; Tue, 27 Mar 2007 16:43:08 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2RLgwA21911; Tue, 27 Mar 2007 16:42:59 -0500 (CDT) Message-ID: <46098FE2.8080107@alcatel-lucent.com> Date: Tue, 27 Mar 2007 16:42:58 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) References: <62B9B0847CC47543B6B3B5E26BD268E611F4C2AA@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C2AA@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > SIP providers have to make money also. How does SIPSEC draft provide > this information to intermediate proxies without opening up the message > to them ? I am not a cryptographer, but it seems that there are techniques in the cryptography world that allow limited keyword searches across encrypted data without leaking all the information in the stream. The work by Boneh et al. [1] is the one I am aware of. It works by providing a list of keywords to a proxy such that the proxy can search for those keywords in the encrypted stream without compromising the overall confidentiality of the message. [1] D. Boneh, G. Di Crescenzo, R. Ostrovsky, and G. Persiano, "Public Key Encryption with Keyword Search," Proceedings of Eurocrypt 04, pp. 506-522, 2004. So, presumably, intermediary proxies that want to bill on certain codecs or headers can still do so and make money without compromising end-to-end security. In the end, you need to pick what you want to do. If you do not want intermediaries to poke in the signaling, use sipsec. On the other hand, if this is not a constraint for you, use normal hop-by-hop protected signaling. > Also how CALEA compliance will be achieved with this ? If CALEA is an issue, then don't use sipsec. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 17:50:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJY8-00073j-FR; Tue, 27 Mar 2007 17:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJY5-00073P-V6 for sip@ietf.org; Tue, 27 Mar 2007 17:49:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWJY4-0003KV-Kp for sip@ietf.org; Tue, 27 Mar 2007 17:49:49 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2RKu7bb031468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 14:56:08 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C2AA@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E611F4C2AA@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0945E382-8211-46B1-A125-8867D995137C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 16:49:42 -0500 To: "Samir Srivastava" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 3:51 PM, Samir Srivastava wrote: > SIP providers have to make money also. Intermediate proxies know that they are being traversed, can authenticate the user making the SIPS: connection request, and can certainly bill them for the privilege of traversing the proxy, including a wide variety of possible charging metrics such as per connection, per connection duration, per destination, per byte, per time of day, or any combination thereof. SIP end points (like telephony gateways, application servers, call centers, whatever) can also authenticate the originator or terminator of a call, and can therefore bill them based on any aspect of the communications covered by the agreement between the service provider and the operator of the endpoint in question. This can all be done without compromising the fundamental security of the SIP-level signaling path. > How does SIPSEC draft provide > this information to intermediate proxies without opening up the > message > to them ? It doesn't. Once you've done that, you've defeated the security mechanism. If it hurts, DON'T DO IT! > Also how CALEA compliance will be achieved with this ? > I'm sorry, but what part of RFC 2804 did you not understand? Here are two bullet points to ponder: - The IETF believes that in the case of traffic that is today going across the Internet without being protected by the end systems (by encryption or other means), 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. The IETF does not see an engineering solution that allows such wiretapping when the end systems take adequate measures to protect their communications. - The IETF believes that adding a requirement for wiretapping will make affected protocol designs considerably more complex. Experience has shown that complexity almost inevitably jeopardizes the security of communications even when it is not being tapped by any legal means; there are also obvious risks raised by having to protect the access to the wiretap. This is in conflict with the goal of freedom from security loopholes. > SIP != HTTP (Though we barrowed a lot from there). > Arguably, we borrowed some of the the wrong parts. We got the bulky encoding and muddy semantics of the request-response model without getting the security features and transport-application isolation (yes, we have worse transport-application cross-layer binding than HTTP, although many predicted it would be impossible to do worse than HTTP. OTOH, we can do a lot of stuff that HTTP can't). There is still much to be learned from the amazing successes (and curious weaknesses) of HTTP. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 18:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJjT-0007DI-3m; Tue, 27 Mar 2007 18:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJjR-000795-BI for sip@ietf.org; Tue, 27 Mar 2007 18:01:33 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWJjP-00065H-1t for sip@ietf.org; Tue, 27 Mar 2007 18:01:33 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RM1S122087; Tue, 27 Mar 2007 22:01:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) Date: Tue, 27 Mar 2007 17:01:27 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711365F651@zrc2hxm2.corp.nortel.com> In-Reply-To: <0945E382-8211-46B1-A125-8867D995137C@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does TLS have the security benefits claimed? (was TLS Re: [Sip] sips: upgrading allowed or not) thread-index: AcdwufRw8QWdwM1tRuWJPla0KT+W7AAALO2g References: <62B9B0847CC47543B6B3B5E26BD268E611F4C2AA@zrc2hxm2.corp.nortel.com> <0945E382-8211-46B1-A125-8867D995137C@softarmor.com> From: "Brian Stucker" To: "Dean Willis" , "Samir Srivastava" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, March 27, 2007 4:50 PM > To: Srivastava, Samir (SC100:8826) >=20 > > SIP providers have to make money also. >=20 > Intermediate proxies know that they are being traversed, can=20 > authenticate the user making the SIPS: connection request,=20 > and can certainly bill them for the privilege of traversing=20 > the proxy, including a wide variety of possible charging=20 > metrics such as per connection, per connection duration, per=20 > destination, per byte, per time of day, or any combination thereof. >=20 > SIP end points (like telephony gateways, application servers,=20 > call centers, whatever) can also authenticate the originator=20 > or terminator of a call, and can therefore bill them based on=20 > any aspect of the communications covered by the agreement=20 > between the service provider and the operator of the endpoint=20 > in question. >=20 > This can all be done without compromising the fundamental=20 > security of the SIP-level signaling path. Agree. And if the proxy is using a model where this is not possible, it can reject the connection until the originator is willing to comply with the terms of use for that proxy. If the model the proxy is using is not useful, then the user will simply use a proxy that is willing to accept the traffic that the user is generating. Simply put, the proxy doesn't have to carry traffic that it's not comfortable with, and the end points may not have to send their traffic to that proxy (subject to the policies of their domain administrator). Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 18:31:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWKAx-0005Pf-2U; Tue, 27 Mar 2007 18:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWKAu-0005Pa-NU for sip@ietf.org; Tue, 27 Mar 2007 18:29:56 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWKAq-0003hZ-EA for sip@ietf.org; Tue, 27 Mar 2007 18:29:56 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2007 15:29:52 -0700 Received: from [192.168.0.102] ([10.21.152.138]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l2RM7vCi029508; Tue, 27 Mar 2007 14:07:57 -0800 Message-ID: <46099B6F.50907@cisco.com> Date: Tue, 27 Mar 2007 15:32:15 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] sips: upgrading allowed or not References: <46091EB2.6020303@cisco.com> <66C13A05-2EA8-4455-B585-293320BB1C33@softarmor.com> In-Reply-To: <66C13A05-2EA8-4455-B585-293320BB1C33@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1238; t=1175033278; x=1175897278; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20sips=3A=20upgrading=20allowed=20or=20not |Sender:=20 |To:=20Dean=20Willis=20; bh=QfKnUihcfhtI8zz8FKkf72tNGA2+MqhvDZKVOFDsKpo=; b=Wa0KMdBoIcqpRRlzFhOI4lgeE0vdiJPyLUBTTkizmbZAnSOSSYw/ZTeAeyC3/RJJzkABO4Sj 8hJUC5qSrk5vszzBH0TxPxhhl8ds95KITdROWRDvy0fz2qbaoczTIqeS; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote: > >> I believe this extends to retargeting as well. I think we clearly >> need to disallow retargeting or downgrading from a sips URI to a sip >> URI. I think that was also largely non-controversial. > > I'd say that this is arguably already a factor in RFC 3261, EXCEPT for > the responsible home proxy being able to downgrade. So "eliminating > the last-hop exception" and "disallowing downgrading from SIPS to SIP" > are, IMHO, redundant expressions. > > In any case (chair hat on), we had a clear consensus at IETF 68 to > disallow downgrading. > > Retargeting is a somewhat thornier question, since that behavior is > AFAIK somewhat scattered throughout RFC 3261, but I believe we also > had a consensus to disallow retargeting from SIPS to SIP at IETF 68. Can I suggest that this particular turd is as polished as it's going to get? If we are going to go after retargeting too, then are going start writing proscriptions against people to downgrading when they type in a SIPS URI from somebody's business card? Let's just not go here; effort would be far better spent on things that aren't such a dead 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 sip-bounces@ietf.org Tue Mar 27 18:47:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWKPg-0002Ya-Qz; Tue, 27 Mar 2007 18:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWKPf-0002XM-Lm for sip@ietf.org; Tue, 27 Mar 2007 18:45:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWKPa-0006fy-1U for sip@ietf.org; Tue, 27 Mar 2007 18:45:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 74CB120431; Wed, 28 Mar 2007 00:45:03 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-18-46099e6f5c30 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 45F8F20138; Wed, 28 Mar 2007 00:45:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 00:45:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 00:45:01 +0200 Message-ID: <7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQAAAfV2gAAWW/uA= From: "Christer Holmberg \(JO/LMF\)" To: "Samir Srivastava" , "Sean Olson" , "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 27 Mar 2007 22:45:03.0265 (UTC) FILETIME=[8EF33110:01C770C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In Prague I asked Francois whether Proxy-Require/Require had been considered, but I don't remember what the answer was. So maybe someone could repeat :) I am a little confused when I hear "there is no secure TEL URL". To me the encryption is more related to the SIP signalling as such, rather than to what URL scheme is used... Regards, Christer =20 > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com]=20 > Sent: 27. maaliskuuta 2007 23:13 > To: Sean Olson; Francois Audet; IETF SIP List > Cc: Dean Willis > Subject: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 > I have stated a lot of other problems earlier with SIPS too. >=20 > Apart from just doubling the URIs schemes and documentation=20 > pains everytime, It will double the entries in DNS, Registrar too.=20 >=20 > Loose routing got adopted against the strict routing. Though=20 > we provided the backward compatibility as Strict Routing was=20 > DEPLOYED.=20 >=20 > Here SIPS is not deployed, then why not deprecate it. (Pl=20 > correct me, if I am wrong) Cost will be on the early implementers.=20 >=20 > The next version of cipher-suite draft will be more problem=20 > centric and talking about the each bit of the problem with SIPS. >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Sean Olson [mailto:seanol@exchange.microsoft.com] > > Sent: Tuesday, March 27, 2007 12:49 PM > > To: Srivastava, Samir (SC100:8826); Audet, Francois=20 > (SC100:3055); IETF > SIP > > List > > Cc: Dean Willis > > Subject: RE: Securing Other URI (Tel URI) scheme > >=20 > > Ahhh, yes. Now I remember why SIPS was a bad idea. A proxy-=20 > > require/require solution might work, just be prepared for zero > adoption. > >=20 > > -----Original Message----- > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Sent: Tuesday, March 27, 2007 12:46 PM > > To: Sean Olson; Francois Audet; IETF SIP List > > Cc: Dean Willis > > Subject: RE: Securing Other URI (Tel URI) scheme > >=20 > > Hi Sean, > >=20 > > That's where I have the biggest problem. This solution is=20 > non-modular. > >=20 > > Proxy-Require (tls / cipher-suite) provides the modular=20 > solution. You=20 > > keep inventing the other URI schemes without doubling the=20 > "S" suffix=20 > > URIs for secure routing. Secure Routing requirement is settled once > for > > all using Proxy-Require / Require. > >=20 > > Thx > > Samir > >=20 > =20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 19:34:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWL9V-0001bN-69; Tue, 27 Mar 2007 19:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWL9T-0001bG-Ff for sip@ietf.org; Tue, 27 Mar 2007 19:32:31 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWL9S-0004y6-4N for sip@ietf.org; Tue, 27 Mar 2007 19:32:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2RNVwo00434; Tue, 27 Mar 2007 23:31:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Tue, 27 Mar 2007 18:31:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQAAAfV2gAAWW/uAAAZ9eQA== References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com> <7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" , "Sean Olson" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The answer was, "yes, it has been considered". But it has been determined that it would cause more harm to change from SIPS to another mechanism at=20 this point, because of the precedent in RFC 3261. It's probably somewhere in the archives for and various reports. > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, March 27, 2007 15:45 > To: Srivastava, Samir (SC100:8826); Sean Olson; Audet,=20 > Francois (SC100:3055); IETF SIP List > Cc: Dean Willis > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 >=20 > Hi, >=20 > In Prague I asked Francois whether Proxy-Require/Require had=20 > been considered, but I don't remember what the answer was. So=20 > maybe someone could repeat :) >=20 > I am a little confused when I hear "there is no secure TEL=20 > URL". To me the encryption is more related to the SIP=20 > signalling as such, rather than to what URL scheme is used... >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Sent: 27. maaliskuuta 2007 23:13 > > To: Sean Olson; Francois Audet; IETF SIP List > > Cc: Dean Willis > > Subject: [Sip] RE: Securing Other URI (Tel URI) scheme > >=20 > > I have stated a lot of other problems earlier with SIPS too. > >=20 > > Apart from just doubling the URIs schemes and documentation pains=20 > > everytime, It will double the entries in DNS, Registrar too. > >=20 > > Loose routing got adopted against the strict routing. Though we=20 > > provided the backward compatibility as Strict Routing was DEPLOYED. > >=20 > > Here SIPS is not deployed, then why not deprecate it. (Pl=20 > correct me,=20 > > if I am wrong) Cost will be on the early implementers. > >=20 > > The next version of cipher-suite draft will be more problem centric=20 > > and talking about the each bit of the problem with SIPS. > >=20 > > Thx > > Samir > >=20 > > > -----Original Message----- > > > From: Sean Olson [mailto:seanol@exchange.microsoft.com] > > > Sent: Tuesday, March 27, 2007 12:49 PM > > > To: Srivastava, Samir (SC100:8826); Audet, Francois > > (SC100:3055); IETF > > SIP > > > List > > > Cc: Dean Willis > > > Subject: RE: Securing Other URI (Tel URI) scheme > > >=20 > > > Ahhh, yes. Now I remember why SIPS was a bad idea. A proxy-=20 > > > require/require solution might work, just be prepared for zero > > adoption. > > >=20 > > > -----Original Message----- > > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > Sent: Tuesday, March 27, 2007 12:46 PM > > > To: Sean Olson; Francois Audet; IETF SIP List > > > Cc: Dean Willis > > > Subject: RE: Securing Other URI (Tel URI) scheme > > >=20 > > > Hi Sean, > > >=20 > > > That's where I have the biggest problem. This solution is > > non-modular. > > >=20 > > > Proxy-Require (tls / cipher-suite) provides the modular > > solution. You > > > keep inventing the other URI schemes without doubling the > > "S" suffix > > > URIs for secure routing. Secure Routing requirement is=20 > settled once > > for > > > all using Proxy-Require / Require. > > >=20 > > > Thx > > > Samir > > >=20 > > =20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 20:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLe3-00087r-GZ; Tue, 27 Mar 2007 20:04:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLe2-00087m-NF for sip@ietf.org; Tue, 27 Mar 2007 20:04:06 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWLdz-0008Sx-4G for sip@ietf.org; Tue, 27 Mar 2007 20:04:06 -0400 Received: from hkaplan [217.41.228.52] by acmepacket.com with ESMTP (SMTPD-9.10) id A0E20284; Tue, 27 Mar 2007 20:03:46 -0400 From: "Hadriel Kaplan" To: "'Francois Audet'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> Subject: RE: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 20:03:04 -0400 Message-ID: <026601c770cc$7695b330$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I also agree upgrading should not be allowed to make life simpler, but my concern is isn't it too late? I mean how many 3261-compliant boxes out there will retarget upgrade? So if sips suddenly becomes a (more) popular thing, how would the UAS know if the request traversed a 3261-only proxy which upgraded, vs. traversed this newer proposal proxies only? It will have to do the checks no matter what, no? And the bad scenario of sips contact can still occur. (or maybe I missed the point) But at least if you specify NOT to do it and why in your draft then it will help proxy makers avoid the sips contact issue. So it still has some value. -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, March 27, 2007 3:36 PM > To: Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] sips: upgrading allowed or not > > I agree with Jonathan's proposal. > > Here is a slighly different perspective on it however. I'll keep > rethorical arguments > out of it, and stick to protocol. > > - Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy would > be > a normative change to RFC 3261. Section 26.4.4 describes it (3rd > paragraph > on p. 250). That is just an observation. > > - The fact that it is currently allowed means that the UAS receiving the > request > has to go through some fairly esoteric logic to "guess" if the request > was > sent securily on each hop or not. This is described in paragraph 4 of > p. 250, > and section 4.1 of draft-ietf-sip-sips-02 also describes it, with some > modifications. > Those procedures are extremely cludgy and non-deterministic. They are > also misleading > for the UAS, and inconsistent with the use of SIPS and SIP as > described in this draft > (i.e., for the other scenarios of forwarding and retargeting). In all > other instances, > the idea is that when a request is forwarded/retargeted, the scheme is > preserve. > I'd really like to get rid of section 4.1. > > - Jonathan Peterson was proposing that the UAS inspect the To > header to see if > the request was initially targeted at SIPS. This is a subset of > the procedures > of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff like > looking at > Via and other fields). > > - This "upgrading" also forces the use of the double Record-Route in > section 4.2 > of draft-ietf-sip-sips-02. Since we agreed to deprecate the last hop > exception > for downgrading, the SIPS-to-SIP Record-Route scenario will be removed > from the > -03 version. Removing the "upgrade" scenario would also remove the > double > Record-Route for the SIP-to-SIPS, and the net-net is that the whole > section > 4.2 could be removed. > > - Because of rules described in RFC 3261, if a UAS receives an incoming > request with a > SIPS Request-URI, it MUST use a SIPS contact. This is a big problem > for the sender > of the initial request that initiated the dialog if that UAC did not > support SIPS. > If Record-Routing is not used, it will just plainly not work. The UAC > will not be > able to send further requests (like BYE for example). If Record-Route > is used, it > might work (or it might not). The reason it might not work is that > there is possible > that the UAC might "choke" on the SIPS URI in the Contact (because it > doesn't understand > how to parse it). > > - We have corrected to types of problems everywhere else in this > draft. There was > quite a few of them in previous versions. This is the only one > remaining. > > - Note that it would still be possible to "upgrade" by sending SIP over > TLS. In fact, I would > argue that we need to put a requirement to do so when there is already > a TLS connection > opened with the target (as would be the case if Outbound was used, and > the registration was > done over TLS). > > In summary, I favor deprecating the "retargeting upgrade" scenario for > the following reasons: > > - It greatly simplifies the draft, eliminating sections 4.1 and 4.2 > completely. > > - It is much less confusing for the far end. > > - It avoids some nasty protocol level problems that "break" things. > > - You can still use TLS for transport for delivering to that last hop. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Tuesday, March 27, 2007 06:40 > > To: IETF SIP List > > Subject: [Sip] sips: upgrading allowed or not > > > > During the Prague IETF, I shared some opinions on what I > > thought sips needs to look like and why, and wanted to take > > these to the list. > > > > Firstly, what is the point of sips? What does it bring a > > network that it can't get with TLS on some hops, as needed? > > The answer is that certain security benefits are afforded if > > we can assure that every single hop from UAC to UAS was TLS > > protected, and that furthermore, this fact can be > > definitively known by the UAC, UAS, and all proxies along the > > way. If we make the assumption that the UA's trust their > > proxies (please don't question the assumption in this > > thread), then SIPS provides you some very nice security > > properties - confidentiality and integrity from all > > non-trusted entities. We use this property all over our specs > > to secure various extensions. > > > > Given that, sips is broken if it doesn't provide that service > > (tls on each hop with knowledge of such by all entities). FOr > > this reason, I think we need to eliminate the last hop > > exception (uncontroversial I think), but furthermore, I > > believe this extends to retargeting as well. > > I think we clearly need to disallow retargeting or > > downgrading from a sips URI to a sip URI. I think that was > > also largely non-controversial. > > However, I also want to disallow upgrading or retargeting > > from sip to sips. On this, there was some disagreement. > > > > The challenge Jon gave me at the mike was this. As long as a > > UAC inserts a sips URI into the To field and R-URI field when > > it emits a sips request, does not the presence of a sips URI > > in the TO field, and receipt over a TLS connection, assure > > that the request was delivered over TLS at each hop? Had the > > request been sent originally to a sip URI and then upgraded, > > the TO field would not have been sips, but rather sip. > > > > I believe Jon is correct, however I still think it is not a > > good idea. > > My rationale is: > > > > 1. if upgrades are disallowed, redirecting from sip to sips > > works much better. Such a redirection would necesarily have > > to go all the way to the UAC. If we allow upgrades, a proxy > > in the middle could recurse and upgrade. In that case, if the > > reason for the redirection was that the UAS *wanted* TLS on > > each hop, recursing in the middle would destroy that possibility. > > > > 2. The architectural principle behind the first issue, more > > generally, is that the meaning of sips is *SECURE ON EACH HOP > > FROM UAC TO UAS*. To me, this is fundamentally at odds with > > any notion of upgrade or downgrade. > > > > 3. Things become simpler if we forbid upgrades. We can > > eliminate the text on double-record routing sinec a proxy > > would never be sip/sips converting. I think it also just > > generally makes overall processing easier. SIPS means one > > thing and one thing only and its terribly clear what it means. > > > > As such, I stand by my argument that we should forbid upgrades. > > > > -JOnathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 20:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLeD-0008Ew-Bi; Tue, 27 Mar 2007 20:04:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLeB-0008Er-7m for sip@ietf.org; Tue, 27 Mar 2007 20:04:15 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWLe9-0000EZ-Uo for sip@ietf.org; Tue, 27 Mar 2007 20:04:15 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2S03pG01566 for ; Wed, 28 Mar 2007 00:03:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2007 19:04:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCA3DF2@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Future work in specification on SIP Security Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQAAAfV2gAAWW/uAAAm5EwA== References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com> <7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Future work in specification on SIP Security X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At the Prague meeting, there was a discussion on Future work in specification for SIP security. The idea was to discuss ideas on what we should tackle next after finishing up SIPS. There is an Appendix A in draft-ietf-sip-sips-02 on this. For example, it could include one or many of the following: - The SIPSEC proposal (i.e., proxies that upgrade to a mode that tunnel TLS end-to-end)? - Verifiable assertions that SIPS was used on each hops? - (Bring your own ideas: proxy-require, etc.) Countrary to expectations, we didn't get much enthousiasm from the group at all in Prague.=20 It seems now that it's moved to the mailing list, that there is a renewed interest from a=20 few people that were not in Prague or didn't care to comment at the meeting. I'd encourage people to bring in constructive ideas on those topics if you really care about it. It won't happen on 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 From sip-bounces@ietf.org Tue Mar 27 20:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLlk-0005i6-FH; Tue, 27 Mar 2007 20:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLlj-0005hh-4F for sip@ietf.org; Tue, 27 Mar 2007 20:12:03 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWLle-0001RR-Lp for sip@ietf.org; Tue, 27 Mar 2007 20:12:00 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2S0BKG01821; Wed, 28 Mar 2007 00:11:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Tue, 27 Mar 2007 19:11:39 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme thread-index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQAAAfV2gAAWW/uAAAZ9eQAAAeTcw From: "Samir Srivastava" To: "Francois Audet" , "Christer Holmberg \(JO/LMF\)" , "Sean Olson" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Looks like we are recommending to use tels etc.=20 I have not seen even a single engineering reason to keep SIPS. Instead of just giving the argument that SIPS is in 3261. So we want to pursue it. 3261 has many bugs, I treat it as one of them, which is result of series of mistakes. Thx Samir PS: Email list consensus provides more matured decisions as it addresses wider audience.=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, March 27, 2007 4:32 PM > To: Christer Holmberg (JO/LMF); Sean Olson; IETF SIP List > Cc: Dean Willis > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 > The answer was, "yes, it has been considered". >=20 > But it has been determined that it would cause more harm to change from > SIPS to another mechanism at > this point, because of the precedent in RFC 3261. >=20 > It's probably somewhere in the archives for and various reports. >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, March 27, 2007 15:45 > > To: Srivastava, Samir (SC100:8826); Sean Olson; Audet, > > Francois (SC100:3055); IETF SIP List > > Cc: Dean Willis > > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme > > > > > > Hi, > > > > In Prague I asked Francois whether Proxy-Require/Require had > > been considered, but I don't remember what the answer was. So > > maybe someone could repeat :) > > > > I am a little confused when I hear "there is no secure TEL > > URL". To me the encryption is more related to the SIP > > signalling as such, rather than to what URL scheme is used... > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > -----Original Message----- > > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > Sent: 27. maaliskuuta 2007 23:13 > > > To: Sean Olson; Francois Audet; IETF SIP List > > > Cc: Dean Willis > > > Subject: [Sip] RE: Securing Other URI (Tel URI) scheme > > > > > > I have stated a lot of other problems earlier with SIPS too. > > > > > > Apart from just doubling the URIs schemes and documentation pains > > > everytime, It will double the entries in DNS, Registrar too. > > > > > > Loose routing got adopted against the strict routing. Though we > > > provided the backward compatibility as Strict Routing was DEPLOYED. > > > > > > Here SIPS is not deployed, then why not deprecate it. (Pl > > correct me, > > > if I am wrong) Cost will be on the early implementers. > > > > > > The next version of cipher-suite draft will be more problem centric > > > and talking about the each bit of the problem with SIPS. > > > > > > Thx > > > Samir > > > > > > > -----Original Message----- > > > > From: Sean Olson [mailto:seanol@exchange.microsoft.com] > > > > Sent: Tuesday, March 27, 2007 12:49 PM > > > > To: Srivastava, Samir (SC100:8826); Audet, Francois > > > (SC100:3055); IETF > > > SIP > > > > List > > > > Cc: Dean Willis > > > > Subject: RE: Securing Other URI (Tel URI) scheme > > > > > > > > Ahhh, yes. Now I remember why SIPS was a bad idea. A proxy- > > > > require/require solution might work, just be prepared for zero > > > adoption. > > > > > > > > -----Original Message----- > > > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > > Sent: Tuesday, March 27, 2007 12:46 PM > > > > To: Sean Olson; Francois Audet; IETF SIP List > > > > Cc: Dean Willis > > > > Subject: RE: Securing Other URI (Tel URI) scheme > > > > > > > > Hi Sean, > > > > > > > > That's where I have the biggest problem. This solution is > > > non-modular. > > > > > > > > Proxy-Require (tls / cipher-suite) provides the modular > > > solution. You > > > > keep inventing the other URI schemes without doubling the > > > "S" suffix > > > > URIs for secure routing. Secure Routing requirement is > > settled once > > > for > > > > all using Proxy-Require / Require. > > > > > > > > Thx > > > > Samir > > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 20:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLrW-0008Ig-VN; Tue, 27 Mar 2007 20:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWLrW-0008IZ-2H for sip@ietf.org; Tue, 27 Mar 2007 20:18:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWLrU-00030a-H7 for sip@ietf.org; Tue, 27 Mar 2007 20:18:02 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2S0Hud06869; Wed, 28 Mar 2007 00:17:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 19:17:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCA3E07@zrc2hxm0.corp.nortel.com> In-Reply-To: <026601c770cc$7695b330$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4A== References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> <026601c770cc$7695b330$800101df@acmepacket.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not sure I follow your point... If you "upgrade", you will know soon enough because things will start breaking, and you'll get customer complaints. This "breaking" part is the reason why I want to deprecate upgrades. As for the "checks", it seems to me that using SIPS as a "check" is not a good idea (at least on it's own) as it is very weak. To me, that's one of the possible topic for "Furture work in specification". I think this section on checks is misleading and it contradicts other parts of the=20 document that explain that SIPS is not an indication that the request was indeed forwarded over TLS on each hop. If people think we need a indication of end-to-end security (of of security on each hop), then bring it in. That's what I tought people wanted to talk about in Prague... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, March 27, 2007 17:03 > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF=20 > SIP List' > Subject: RE: [Sip] sips: upgrading allowed or not >=20 > I also agree upgrading should not be allowed to make life=20 > simpler, but my concern is isn't it too late? >=20 > I mean how many 3261-compliant boxes out there will retarget=20 > upgrade? So if sips suddenly becomes a (more) popular thing,=20 > how would the UAS know if the request traversed a 3261-only=20 > proxy which upgraded, vs. traversed this newer proposal proxies only? >=20 > It will have to do the checks no matter what, no? And the=20 > bad scenario of sips contact can still occur. (or maybe I=20 > missed the point) But at least if you specify NOT to do it=20 > and why in your draft then it will help proxy makers avoid=20 > the sips contact issue. So it still has some value. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, March 27, 2007 3:36 PM > > To: Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] sips: upgrading allowed or not > >=20 > > I agree with Jonathan's proposal. > >=20 > > Here is a slighly different perspective on it however. I'll keep=20 > > rethorical arguments out of it, and stick to protocol. > >=20 > > - Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy=20 > > would be > > a normative change to RFC 3261. Section 26.4.4 describes it (3rd=20 > > paragraph > > on p. 250). That is just an observation. > >=20 > > - The fact that it is currently allowed means that the UAS=20 > receiving=20 > > the request > > has to go through some fairly esoteric logic to "guess" if the=20 > > request was > > sent securily on each hop or not. This is described in=20 > paragraph 4=20 > > of p. 250, > > and section 4.1 of draft-ietf-sip-sips-02 also describes it, with=20 > > some modifications. > > Those procedures are extremely cludgy and non-deterministic. They=20 > > are also misleading > > for the UAS, and inconsistent with the use of SIPS and SIP as=20 > > described in this draft > > (i.e., for the other scenarios of forwarding and retargeting). In=20 > > all other instances, > > the idea is that when a request is forwarded/retargeted,=20 > the scheme=20 > > is preserve. > > I'd really like to get rid of section 4.1. > >=20 > > - Jonathan Peterson was proposing that the UAS inspect=20 > the To header=20 > > to see if > > the request was initially targeted at SIPS. This is=20 > a subset=20 > > of the procedures > > of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff=20 > > like looking at > > Via and other fields). > >=20 > > - This "upgrading" also forces the use of the double=20 > Record-Route in=20 > > section 4.2 > > of draft-ietf-sip-sips-02. Since we agreed to deprecate=20 > the last hop=20 > > exception > > for downgrading, the SIPS-to-SIP Record-Route scenario will be=20 > > removed from the > > -03 version. Removing the "upgrade" scenario would also=20 > remove the=20 > > double > > Record-Route for the SIP-to-SIPS, and the net-net is that=20 > the whole=20 > > section > > 4.2 could be removed. > >=20 > > - Because of rules described in RFC 3261, if a UAS receives an=20 > > incoming request with a > > SIPS Request-URI, it MUST use a SIPS contact. This is a=20 > big problem=20 > > for the sender > > of the initial request that initiated the dialog if that=20 > UAC did not=20 > > support SIPS. > > If Record-Routing is not used, it will just plainly not work. The=20 > > UAC will not be > > able to send further requests (like BYE for example). If=20 > > Record-Route is used, it > > might work (or it might not). The reason it might not=20 > work is that=20 > > there is possible > > that the UAC might "choke" on the SIPS URI in the Contact=20 > (because=20 > > it doesn't understand > > how to parse it). > >=20 > > - We have corrected to types of problems everywhere=20 > else in this=20 > > draft. There was > > quite a few of them in previous versions. This is the=20 > only one=20 > > remaining. > >=20 > > - Note that it would still be possible to "upgrade" by sending SIP=20 > > over TLS. In fact, I would > > argue that we need to put a requirement to do so when there is=20 > > already a TLS connection > > opened with the target (as would be the case if Outbound=20 > was used,=20 > > and the registration was > > done over TLS). > >=20 > > In summary, I favor deprecating the "retargeting upgrade"=20 > scenario for=20 > > the following reasons: > >=20 > > - It greatly simplifies the draft, eliminating sections 4.1 and 4.2=20 > > completely. > >=20 > > - It is much less confusing for the far end. > >=20 > > - It avoids some nasty protocol level problems that "break" things. > >=20 > > - You can still use TLS for transport for delivering to=20 > that last hop. > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > Sent: Tuesday, March 27, 2007 06:40 > > > To: IETF SIP List > > > Subject: [Sip] sips: upgrading allowed or not > > > > > > During the Prague IETF, I shared some opinions on what I thought=20 > > > sips needs to look like and why, and wanted to take these to the=20 > > > list. > > > > > > Firstly, what is the point of sips? What does it bring a network=20 > > > that it can't get with TLS on some hops, as needed? > > > The answer is that certain security benefits are afforded=20 > if we can=20 > > > assure that every single hop from UAC to UAS was TLS=20 > protected, and=20 > > > that furthermore, this fact can be definitively known by the UAC,=20 > > > UAS, and all proxies along the way. If we make the=20 > assumption that=20 > > > the UA's trust their proxies (please don't question the=20 > assumption=20 > > > in this thread), then SIPS provides you some very nice security=20 > > > properties - confidentiality and integrity from all non-trusted=20 > > > entities. We use this property all over our specs to=20 > secure various=20 > > > extensions. > > > > > > Given that, sips is broken if it doesn't provide that=20 > service (tls=20 > > > on each hop with knowledge of such by all entities). FOr this=20 > > > reason, I think we need to eliminate the last hop exception=20 > > > (uncontroversial I think), but furthermore, I believe=20 > this extends=20 > > > to retargeting as well. > > > I think we clearly need to disallow retargeting or=20 > downgrading from=20 > > > a sips URI to a sip URI. I think that was also largely=20 > > > non-controversial. > > > However, I also want to disallow upgrading or retargeting=20 > from sip=20 > > > to sips. On this, there was some disagreement. > > > > > > The challenge Jon gave me at the mike was this. As long as a UAC=20 > > > inserts a sips URI into the To field and R-URI field when=20 > it emits a=20 > > > sips request, does not the presence of a sips URI in the=20 > TO field,=20 > > > and receipt over a TLS connection, assure that the request was=20 > > > delivered over TLS at each hop? Had the request been sent=20 > originally=20 > > > to a sip URI and then upgraded, the TO field would not have been=20 > > > sips, but rather sip. > > > > > > I believe Jon is correct, however I still think it is not a good=20 > > > idea. > > > My rationale is: > > > > > > 1. if upgrades are disallowed, redirecting from sip to sips works=20 > > > much better. Such a redirection would necesarily have to=20 > go all the=20 > > > way to the UAC. If we allow upgrades, a proxy in the middle could=20 > > > recurse and upgrade. In that case, if the reason for the=20 > redirection=20 > > > was that the UAS *wanted* TLS on each hop, recursing in=20 > the middle=20 > > > would destroy that possibility. > > > > > > 2. The architectural principle behind the first issue, more=20 > > > generally, is that the meaning of sips is *SECURE ON EACH=20 > HOP FROM=20 > > > UAC TO UAS*. To me, this is fundamentally at odds with=20 > any notion of=20 > > > upgrade or downgrade. > > > > > > 3. Things become simpler if we forbid upgrades. We can=20 > eliminate the=20 > > > text on double-record routing sinec a proxy would never=20 > be sip/sips=20 > > > converting. I think it also just generally makes overall=20 > processing=20 > > > easier. SIPS means one thing and one thing only and its terribly=20 > > > clear what it means. > > > > > > As such, I stand by my argument that we should forbid upgrades. > > > > > > -JOnathan R. > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > http://www.cisco.com > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 27 23:04:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWON9-0000d0-O8; Tue, 27 Mar 2007 22:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWON8-0000cn-LR for sip@ietf.org; Tue, 27 Mar 2007 22:58:50 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWON6-0007zN-A1 for sip@ietf.org; Tue, 27 Mar 2007 22:58:50 -0400 Received: from [64.101.173.83] ([64.101.173.83]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2S24eFc032550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2007 20:04:41 -0600 In-Reply-To: <026601c770cc$7695b330$800101df@acmepacket.com> References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> <026601c770cc$7695b330$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91559587-CCF5-48C0-A555-30A7299B0895@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips: upgrading allowed or not Date: Tue, 27 Mar 2007 21:58:14 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'IETF SIP List' , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 27, 2007, at 7:03 PM, Hadriel Kaplan wrote: > I also agree upgrading should not be allowed to make life simpler, > but my > concern is isn't it too late? > > I mean how many 3261-compliant boxes out there will retarget > upgrade? So if > sips suddenly becomes a (more) popular thing, how would the UAS > know if the > request traversed a 3261-only proxy which upgraded, vs. traversed > this newer > proposal proxies only? > > It will have to do the checks no matter what, no? And the bad > scenario of > sips contact can still occur. (or maybe I missed the point) > But at least if you specify NOT to do it and why in your draft then > it will > help proxy makers avoid the sips contact issue. So it still has > some value. That's the "Verifiable assertions that SIPS was used on each hop" question from the "Future work" section of the draft, right? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 00:40:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWPuQ-0007sC-OV; Wed, 28 Mar 2007 00:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWPuP-0007qG-Kg for sip@ietf.org; Wed, 28 Mar 2007 00:37:17 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWPuN-0006v6-9d for sip@ietf.org; Wed, 28 Mar 2007 00:37:17 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id C7CC8AC368; Wed, 28 Mar 2007 07:36:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.61673.661638.60109@harjus.tutpro.com> Date: Wed, 28 Mar 2007 07:36:57 +0300 To: "Samir Srivastava" Subject: [Sip] RE: Securing Other URI (Tel URI) scheme In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C101@zrc2hxm2.corp.nortel.com> References: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C101@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List , Sean Olson , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava writes: > Proxy-Require (tls / cipher-suite) provides the modular solution. You > keep inventing the other URI schemes without doubling the "S" suffix > URIs for secure routing. Secure Routing requirement is settled once for > all using Proxy-Require / Require. and then you don't need sips either. it makes no sense to have sips without tels and i would like to get rid of both. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 00:40:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWPvq-0000cK-Tf; Wed, 28 Mar 2007 00:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWPvq-0000bx-0K for sip@ietf.org; Wed, 28 Mar 2007 00:38:46 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWPvo-0007XC-MF for sip@ietf.org; Wed, 28 Mar 2007 00:38:45 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 04F3DAC368; Wed, 28 Mar 2007 07:38:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.61779.969604.949038@harjus.tutpro.com> Date: Wed, 28 Mar 2007 07:38:43 +0300 To: Sean Olson Subject: [Sip] RE: Securing Other URI (Tel URI) scheme In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC8@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC0@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C101@zrc2hxm2.corp.nortel.com> <4C1596FBF66C67478BCFE7B3F81FC1E0178A236CC8@DF-MASTIFF-MSG.exchange.corp.microsoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sean Olson writes: > Ahhh, yes. Now I remember why SIPS was a bad idea. A > proxy-require/require solution might work, just be prepared for zero > adoption. what would be great. -- 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 chichnutaix@shawcable.net Wed Mar 28 00:46:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWQ39-0003l8-5p; Wed, 28 Mar 2007 00:46:19 -0400 Received: from s01060050bf9644c7.ca.shawcable.net ([70.77.34.112] helo=shawcable.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWQ34-00010N-3j; Wed, 28 Mar 2007 00:46:19 -0400 Message-ID: <338701c770e1$57e4bf70$4f28b272@chichnutaix> Reply-To: "Abraham Boyd" From: "Abraham Boyd" To: "Nettie" Cc: "Kirby" , "Aubrey" , "Danae" , "Marchelle" , "Renita Washington" , "Gracia Garcia" , "Yuk Gardner" , "Nu" , "Walker Lawrence" , "Doria" , "Florrie Nichols" Subject: Just talk to him Date: Wed, 28 Mar 2007 02:32:34 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_550_646B_00DEA16F.A1C85F61" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4922.1500 X-Spam-Score: 2.5 (++) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 This is a multi-part message in MIME format. ------=_NextPart_550_646B_00DEA16F.A1C85F61 Content-Type: multipart/alternative; boundary="----=_NextPart_EBD_84A8_BB8C6BB9.20767749" ------=_NextPart_EBD_84A8_BB8C6BB9.20767749 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Because it is injure sea the miniature air she jewel always breathed in = her "Ah," brush bravely chain fill said Andrea, "who knows?" "He request = laid a milk wager he would off structure tame Medeah in the spaceplay "Ma= jor Cavalcanti is remember already one, meat last perhaps; but the porter slit "Well, withheld then," describe said Monte Cristo "you have a= ll the education "Shall screw you be happy sew kiss if I do what you = wish?" "Oh, y WE marry WILL now relate average what was passing reflect = in after the house o "Your excellency, I regret get exactly soon more to say that, not knowin = identify "But still, mute if Albert from be march not so rich as Mademois= el"No politics, felt Caderousse. And steel chosen now damage that you hav= e al"You list round see my sparkle position, poison madame," said Morrel,= bestowbrainy "Not at taken shave all, cow my good friend." "That dust is sold sleep metal unfortunate," returned Monte Cristo. cost = M. Noirtier was sitting in daughter an got worm arm-chair, which mov "I o= ften trust you misspelled hung will not be displeased, list sir, that Val=   shrank "Were shame toe they, destroy then, so necessary?" "So he has; dark rain but I ornament like swung mine as well."late "How? = hid smoke rate Not at all?"steam "It seems to me," said discussion Dangla= rs, damage in tiny his coarse ton"Why, just bite think for greet afterwar= ds a measure moment; with this red handk "They were indispensable." range ant Noirtier's deep face remained appl= aud perfectly passive during spit "This communication," fall continued w= rong choke the procureur, in The angle major beat lock passed his struck hand across his brow. "Ah, pe= "Ah, madame," replied butter ticket applaud lose Monte Cristo, "you m= ust not "Certainly; your miss name is show popular, and shakily expansion does ho= nor t"I will do cheese my best," withhold less hook said the inn-keeper o= f the Powrong glorious "How so?--at what digestion period scrub can that = have been?"permit "Well, badly then, we chance will go quick into Paris. = But how will y "Certainly they program apparatus were; supposing lick lazily there were = to be d Madame thank de fiction Villefort disarm now dress took her part= in the conve While his process fit genethliac wife was speaking, medi= um Villefort had narrowl "And for tow this very reason," said Danglars yearly kick level with a s"= Wait," said Caderousse, secretary look "we chilly shall own see." He then= t"I do not name leg know; I have only eat heard made that an emperor"But= , direction vespertilian tell me," said wearily Andrea, "am juggle I to r= emain bareh "True," damaged misty said vinic the major, strip "there might be doubts = raiNoirtier's watch panicky look was furious; it meline sunk was very evi= dent t "That cycle assassination was bred chance a trodden mysterious af= fair," said "In that fragile case pencil episcopal your son would moon be very unplea= santly nuptial "Still, advise I should not think song thrived the Morcerfs would= yiel"Pooh," said Caderousse; chin aerial "it pinch is so gracefully wind= y that yourstuck "Sir," said say Monte Cristo to him, cheese "I work do n= ot recommemix grease lock "Come, come; enough of decay this," said Cavalc= anti. "It coal would slung sewn be fatal cut to his interests." death moan of= fice "Now," continued Villefort, "those amusement to whom the gui It had= been design agreed that self mad machine the old man should express =   "It might band cause threw race him to modern fail in some desirable matr= "What smoke are you waiting for?" said scissors drawn to Caderousse. "I h= o ------=_NextPart_EBD_84A8_BB8C6BB9.20767749 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"Because it is injure sea the miniature air she jewel always brea= thed in her "Ah," brush bravely chain fill said Andrea, "who knows?"=  "He request laid a milk wager he would off structure tame Medeah in= the spaceplay "Major Cavalcanti is remember already one, meat last perha= ps; but the   
porter slit "Well, withheld then," describe said Monte Cristo "you have a= ll the     education "Shall screw you be happy s= ew kiss if I do what you wish?" "Oh, y  WE marry WILL now relat= e average what was passing reflect in after the house o   =
"Your excellency, I regret get exactly soon more to say that, not knowin&= nbsp;  

identify "But still, mute if Albert from be march not so rich as Made= moisel"No politics, felt Caderousse. And steel chosen now damage that you= have al"You list round see my sparkle position, poison madame," said Mor= rel, bestowbrainy "Not at taken shave all, cow my good friend." &nbs= p; "That dust is sold sleep metal unfortunate," returned Monte Cristo. = cost M. Noirtier was sitting in daughter an got worm arm-chair, which mov=  "I often trust you misspelled hung will not be displeased, list sir= , that Val    
shrank "Were shame toe they, destroy then, so necessary?"   "So he has; dark rain but I ornament like swung mine as well."late "How? = hid smoke rate Not at all?"steam "It seems to me," said discussion Dangla= rs, damage in tiny his coarse ton"Why, just bite think for greet afterwar= ds a measure moment; with this red handk    
"They were indispensable."   range ant Noirtier's deep fac= e remained applaud perfectly passive during  spit "This communi= cation," fall continued wrong choke the procureur, in   &n= bsp;    
The angle major beat lock passed his struck hand across his brow. "Ah, pe=     "Ah, madame," replied butter ticket applaud lose = Monte Cristo, "you must not        "Certainly; your miss name is show popular, and shakily expansion does ho= nor t"I will do cheese my best," withhold less hook said the inn-keeper o= f the Powrong glorious "How so?--at what digestion period scrub can that = have been?"permit "Well, badly then, we chance will go quick into Paris. = But how will y   
"Certainly they program apparatus were; supposing lick lazily there were = to be d  Madame thank de fiction Villefort disarm now dress too= k her part in the conve    While his process fit gene= thliac wife was speaking, medium Villefort had narrowl   &= nbsp;
"And for tow this very reason," said Danglars yearly kick level with a s"= Wait," said Caderousse, secretary look "we chilly shall own see." He then= t"I do not name leg know; I have only eat heard made that an emperor"But= , direction vespertilian tell me," said wearily Andrea, "am juggle I to r= emain bareh           "True," damaged misty said vinic the major, strip "there might be doubts = raiNoirtier's watch panicky look was furious; it meline sunk was very evi= dent t  "That cycle assassination was bred chance a trodden mys= terious affair," said   "In that fragile case pencil episcopal your son would moon be very unplea= santly    
nuptial "Still, advise I should not think song thrived the Morcerfs would= yiel"Pooh," said Caderousse; chin aerial "it pinch is so gracefully wind= y that yourstuck "Sir," said say Monte Cristo to him, cheese "I work do n= ot recommemix grease lock "Come, come; enough of decay this," said Cavalc= anti.   "It coal would slung sewn be fatal cut to his interests."  &nbs= p;death moan office "Now," continued Villefort, "those amusement to whom = the gui  It had been design agreed that self mad machine the ol= d man should express         = ; 
"It might band cause threw race him to modern fail in some desirable matr= "What smoke are you waiting for?" said scissors drawn to Caderousse. "I h= o          
------=_NextPart_EBD_84A8_BB8C6BB9.20767749-- ------=_NextPart_550_646B_00DEA16F.A1C85F61 Content-Type: image/gif; name="niozkaxveeqvur.gif" Content-Transfer-Encoding: base64 Content-ID: <0294a01c770e1757fc3f10da442f96@chichnutaix> R0lGODdhPgGTAYQAAP///wCZ/wAAAP8AAObm5tzZ3L/R4KGx4mZmZm+H0cwzAClwsKysrICAgNfO wuC2hM6UWsOGSrKMW8azopt3TP/hm//PXZRgKjorO1pSWgAAgICAAP//ANtJSQAAAAAAACwAAAAA PgGTAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6DQ243wHT2xtfweckPBt1r8P0enstfW4lgViHJ4R+AImCi4yDhSKOgnyTjZhf lYaTgZxqcCOiL6CWKZ+Yh3edpK2aeKlxpH0qtKq1r7GFsLNzq6y6foCarcaUvLKjvb7MplzKyIyE y7nSwZl1ssHWip7E3YvX05Dg2Nnc35F5wMPU1fDV2OJl0dnxu+ry0vjM/P+23v3jlE+OumaX3Om7 x9DbOnAAG0bLp61YGHvmIhHEVbHjMYosBA60mCtRwYbj/hQmRGlQI0SUL0d27CYmJst5FuMxPNnP Y8icMtldixhU4kydBjPZKTbRX8STkOpxVFnUKNVbzcj5ZOkQ1cKiJhe+xDh13at9Va2y2/psEz2A It+icyWX57mWXrfO5dkTbty/QIU11YrUrtyLImG6kkfy7i+XehfjXXkzmd6hfB9DbmfWYdjIHNc+ vXuqtKW2plOrniJ5tevXrAPDnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868uXMzAqJH5yHA RPUS1a+f0J6Cew3vRMA/t8JdPA3z2FegH7E+S/vxULxrl24dwHT29+ljL28fP4n5200HYH/3iaAf ewba/gfegAoyeF126eXXn4ESJpjggQ0iCCF8Lchn4YT+TTjggh9u+CCCINYH4oMnpvgfhR+WKOOK MO53oYM01igiigVy2GF6OaK4o4UkRhjjhSoAiKOLPAqpoZAtDgkkgS8SSeWGVUrp449VMjjjiCq+ GCV+6ykJJYU9SknikmCGiWWOEJpYoHQVbsllk0e2qeWRVDI55pRY6gmkl0h+iSegKYIZ56Bh2qle loTq+aeaQwo6ZaItmhelePxZ6amNfc4I56GTOhoghhkiimaI//E3X6ehsupqeWluut1+tNYp5p8Y OtjjgYSaSkZ7sO7wnrDIZnmrsjkcm+yz0EYr7bTU/lZr7bXY0jDAACZwK4K3LngLrg/bgrttC+eu kG62aqz7rbjjsiBuEOWO4G4K93abL7tlnOtvuQAD8K+95n4r8LwHJ0zCwAK/u3C99b67LsMHuxvx v9xOHHEJAUsMr8L89gBxxh9XrPDEBmOcsMoDj/ywyieTbHLMKcNLsszp3ptzySvvG/INO9MsNMc1 m9zy0UaP62/DJTO8c7wyC+001E2by/PPOgQd9NALF51xz0yD/bXFYzdcscsgd1y1wz13TDDbGrON ddYfb7010WaPbPXNBPP9sNFyw031zWhrHe/fQ989Nw6GCx51zgZLPHPSeyftMMSCt53521I/7vnm /povnoPddUd9cuRpW8156lKj7jbFbm9O+t2vK2266EX43JzquBuh++4b9y788MQXb/zxyCev/PLM N+/889BHL/301Fe/mrPO06n99tx37/334Icv/vjkl2/++einr772Da7v/vZBYG89b/LHUP/8ud3/ gv7428b/nSwgQAEGSID+0eZ/LDiWAAtAgAYS0ICvQeCjVmCAClrwggYoIARTI8EkqaAABwihCEco QgPUAAElQKEIVLjB+MQvBQZIgAxnSMMaHoAGLFwhG3LFqi8oQA0d7E4KDrCAIhqxiAk44gJkqEEZ sDCHT0QAFFGoQiquUIpPmNOTmOQDBXhxBT9k/oEXwyiCMZ7AjCNAYxDCyMZl/QA9RFSiHI2YgALg cARQ1KEeq8hHPQIgh0kI1BZnVas3iTGNKiBjCn7IyDIyUpEA+OIXI/nIIrSxUT1ADwGSOEc5MqCJ MXgiCQD5Rz9W8QSkDOSZxiSgL2EPkmxU4yUjWYJGmmCSaawkJXdZS15Skoy2RCQuLwlJPhlLBQRg QCeN2IBP2sCKo8SjFE+5x1FOM4urjFGmzuQCWJYRkbQMpzgdictc1lKXkizmJIMZy1sS85vjdFIm WWCABnSyAQ7AATTxaMp+ltKfTcARKz8VrEX2UpyzDCYJxqjIcjqSl+m8pTAZCs+DhvOdmKQO/jIL UEEG2JOZDKggKO+Ywj1SE4v//CdKA5rNRBFUR4dcaEUTGk9hmtOdENWlTL+pzjOCE6OXmicKCIBB AzDgqCG94EidaIIophSL1LxiSpnAQ5hWqlVcNOhMf7rTXtrSoRFdp05vys6KLhSjs2SWRofawLa6 9a0NZEIqORgDNSLUrMUkZy7RKNaGOpSnwBymTwV7UTf6IIhJmOZcLUEnS2q1izTIKwCF2kIZSHYI lwXjeV5YWeEgtrPK+Wx93kfa0pq2sadNrWpXy9rScha0vxFtUGG7G9mqlbb5ey1ua6vb3eYWCLb1 7bB6K1z/EbcEAnSAchm41OKeIbjGFAEB/hzwgOpat7oOYGBxGzpc4KaAug+AwHXHm93m6gZYaTKC XX0qxnKuV697xSw8iwndrBaguuIdb3j3i13zuuCa/ERBVMmzxayuEZwoyCxPLzrWXYrVl0JIa3Sb hQLq5le/EMjwhR9gxxmIkgWLvYIgUZAdVLXyBd78JTC3KtO8ghWdDablMAXrTe4WdrbHNAEBwrth DWuYv/v1cEmfutKoArgKIw4QpRQEgxSv+MbxpOg5p/zgv67zrhB+6I0lbGAciGfHEIhABDI85jCT ucwZlsAEhIxKf540wFOwFYlfOmH2cnW+NnWne9UJ4yzflaFcxjJQ5blWE0wgzBSgAJrR/kxmCVCA AR0OpYCbWs2pUmFJy5JzlyW60yevWLLsdHGfrZznrnYVrRnNsQkcIAFG+zjMjpYAAybg3xXMNYoo JeWRowAr9GyTSPV7sqBNbdN2ntXB7bRyGz19RlTXtL7oYYCjxUztRFNA1gxwQK1BPGQjVzqavG5s quaspRM32b13NutZA8vXWPrVxb6U5WCZ/ezjStej1ra2rCcQ6Rt8WKVSBfhTVVNfYhtcBwp+LAyg nYLpTgCpR53ABJTb1hzs2qlvvmKI0YAqICT8Bx+388LtnVzlmrwAyzV5ebftXPeQHK4wh2vLxcDw E8T85nGdeRhqrvMDxq+1QA+60IdO/vSis9bePaerd5M+G54z3TVOfzrBkS51QUS96qW5OtYZS/Wt h3wLWh8BzmHubxjomsBkWsJ7LZrIPYv63fKFMqFVjdyxx/yEllbBxsPNzSMIW+QJlvFDX5xTP4Nc 3Zu2gXluTkCYD/COgKRiH0tZZGmKcqXhCZKv22cj+TlZ3lgu9bGPXeWezvjTXqU3fY/r1gG63vUO hH1yIZ/CyUu+0h/ONRIwbR0T8cjzB1U9gsnJZyonu/iCny/ynX1bHXy5ra9/fewbj3I2T/Xf+8y4 wPMuBN4zSvNNDn66FbpXv+K0r6QGLF/tzPy5O9/mzLW7W5XrYcWCe+C517ju/VgE/u93SVTA12nj V1MLpmXGN3g9VYDEVlZblmrvp2PZFX0SGH0OAGnWl0f9lH9592/913cqImfppVksJnfw9lWwVEml h1PJJ3dkhWf1tnQmUAAPB3E0WIPZZn0AdXkZp4Hcp1sd93+Yknh6dmp4lWCn92C/tG7zFl+IJ2PC h2MPaHMqN4VUmF0kBWfYR3nYV3n8111xB3g78HVstz9dtzji9oVIIIYHl0BluHUc14ZuCB1wGIde eFh0mHVzeIc7l4d6+AVh14dyCFz0YXSEWIiGeIiISFp8CIhc8IeMOAaO+Ih7CIOS+FyLWIki1obT B3uYKAWRuEATKFKdiE2UqGMV/jSBrieKo7gEf0hURfWKqshU90c8aogFYeeKIWQAB1BBu6iLvGhB eNeFlhgFa7eG5wR3Q8iEB8aCQrhZJ6CLB5AAISSNJFSNLDdp/Hdkt2d5AEVV+iNbf8dpiZR8EUV6 x+dYL/hGKACN1diOInSNk4aBKqV9p7R3Q2BIbHiGMBKAPwV64Uh+BoiAApl6ykh+OjVodXYD5uGO DBlC8IiNbTZw3daDqrRwvgds4SeALviP70V4KThlK2hso9d+Cal460hCMjSNKSlCCeBMtGdN+0dk XOhCI7dkzahuNPVnzbZn53eOFvVIZvRXw8aMYVeBNXSUNcQAwSiR2+dtlMdr/vZDZzcZZSyGeoN1 UweIbOIIkPC2kYh3iwyAlGLpkhcYYDF5UvUIlTUJgsGGYPTWhI0kkgL5kSM5lCBJklMZlUPlUWJJ QxZ4haYETVv4lMKoBPXza/toWejmgk2YhMRnbHa1dgdJWATplVBIYQ3nUQ0gls30kD5ScMM3hmEY WTPgiER1AJrZAKqpmkeVQdKij8uYBLXYmBOkjkP1etB4VL04QAbQb6t4BLeIisLpm7+ZeaUodvL3 VsW5e5e4nKRom87phz+XiNRZndZ5nYSYlzUZnV4Qidx5ac35nYYZnuLJnMdZnmgHnehpi+RpcfZX mC1gj3pnHLOZnnYIA3e3/pTbJ2nAUYyhaYTIB5IqVp/dxJjuh5knUAEngHJTOHH6WY9TpIMaN6E6 ZEW5lpaYt2vqkR9nCJs9EI6iKVEK1ZHKho6rd54AoKBSKIE3iIO252Y7aJa2h6H0eCfFAppUqWID 2GKVWX4C2mLsJnpOeGcnqp4kUAFImqRJmpoNoFgNgEPvKZE8WKNMeXlSCmcu0Gu3oo/m1gJORqSh KWWA1aMB2YKetnyW2XwIWgIW0KZu6qYXgAFyOqdymgGeiaVYqH9OyUcAloUVKqVRmkA32isXySIZ uaNWeYzEJGqjt5UDCpdgmo73iVxvWqlxmgGYmqkYgAB3Wpg8mKf7mYP8/pR98Gmj5HZVQeKl4seY AFmAgBaghqeTIfqERTqpJVBdldqmFJCpvJoBSomDoDql3zZgeUqqTJmlE9YmmlagI5hWJRhlIsmT zaaAgXZlDXiZXlZhDvBqGdakiiVFfymLQyaTwcqnoIp/VYp5HvQpAOgphlpXi0mCAKqCM9aoPQp6 92qgJfkdQ+UAEvevEmeDs9apHKRFwNYpm4KPhxd4C2tZpcmHwkmwzYGjBGoD9Tmb3qlj+ZksHuoc OLqe7ImiIKuWRjqycdaey/mx2KqQJpuJgoidMBuzMjuz5aOdZNiySIayOEtZtrqzNFmybMWJPtuz hdZw1AWwD6BtQ1u0/jxrcw8gcRAgcddFnMOhsshhmtU1AU8rtVlLa0u7pk1bAqyWaFGLXxKgZk9b ta1itcXxh9QlAc3EAGkWt1oLAVT7X+M6kd3pf2FQsScrsgRwts40ARFwAZ9EAIemZvrZg/J5snx7 I4Wknf5Jm0qojJULX8vIZW57toobuA1QQA/Aub96hbhmlm72R5PHUqLSe0sWguNIuQkXlwNpTnQZ YV+JdKzGuXZUfQXAuY/2TKaLezAacI0LnQXlrh4YU/1IWP9IgB7pk0BakFTJvLcrsr17tr8rXbFW uKNblnq7p+fKiskLhI/LsIg6gsSngrQLvWbaj/SapgearUPlaNY2/nHbmm8XsGbAG6ExOqx4WpGp +n0jwo+sulVvZ35ZWY5ECGiQapm1GrYkMAEXMMEXgL8VfAENcLcvYKwCB77dOJ5pJ0TlprAKB2U0 BWoIxai1a8DiSITXqqbyO1QUQME0TMG+anHgtn8efKxAVFdumW7OS44nqJVEXJdvWZcvHL8sqwIS XMM2/Lk4bE0dbHlOSZE794PtZWPyupPlB5lut4SYW4JPCMNLPFQT4Gg1jKmdCUGX5bcljGIPK7IA 4HoPt5oNIGvZlU/948YzcLFxDLTI2Xrx51ZfW8ZESwKEDABLJbGFrMQm2ciqC8iQ3IFyPMndp7OW LAMZm8kQ7Hw0/vvJoBzKMsvJpFzKpnzKqJzKqrzKrNzKrjwDAHM4UyDLKhA7k3PLtNyHsfw7TcDL HBPLfaM19rKKcRPMgaMx+1LMthzMNpPLpAM3rkPMtLzLrOMx+aLMy3w2u+wzz3w6kPObwaMvicM7 iHM6IPPLknPOv0w7NoM64KwzwMzOwIzOl7M69FzM+oLP15zO0sw5KEM2tcw75HzPA+3Pa4M3S1OJ +swz4YzPcvPN4fzQ7SzOndMtkZPLdLjNzFw5LxPRGq3NJxDP85zPF7PMBePLbjjSl6M0IR3RkgM5 v1PSMR08Hv0yr0zPN70FKJ3TT7DTPP3TQB3UQj3URF3URn3U/kid1FK3zUzd1E791FAd1VI91VRd 1VZ91Vid1Vq91Rgj1UeQ0Ept00KA0WEdODxA1mU9zCKT1i+A1jDg1myt1owT1zEA17VM1zJg1yig 13jtznWdLD6NLnJNL8gcLmgd2EnA14PdHR3rjCKsKbXJhmRs2CHdNeGy2D+wMS7d0vKi2Ejg2W5d LI8swqQdw0zGOIfj0Hft10AQMNnM2QHt2V8Ny5PFImtSVSYmKXyraYM4J+Z2Ir4NHlPT1SuzOidd MPy8N8h9zq6t2TRtOrHz3JbDNJsd3SWtznjz15JdYPKBmLyCvKgK2aNSKKRSI0n20gzdzAw9zE+T zjI90QA9/jYHDTN2w9wsc9CIs9C3bNF5XdsBLCl5IsBGQm6W4iHkbSZH0s00s8+uwzdH8zlo8zby LTtVAzX2TeFmPc4GrS79vd0HrioFLuBr+9hQois0IlCwqeCNk92qM+FLA+HUjc4Trs34rTbHPN8q DTrYzOHaHdmhYuCtG1SIya5A6CcuguAnji81Xjr8bTZn8+TN/TSEI+NTQ9HwTDg7zjVWTs6KU9k9 vq5SaShE/mtkHl0gWGDahFU/TtASbc317Nd60ze4TN+l8zkLruAXXtF6rt+bjdny0iFcml6+8iqg oiYCBSjo9a46MishnN9cjjMSvtj6feMbbs7IbDupA8+O/i7RCw3QEk7Wih3agV4kK+LbhZ6wLVXi wQ1TBnsjjV7prAPWso7Tk97mrZPpmH7pOK3nT87pmP7pPP7WawDkhgxdiM0hvBzqwz7ZyMrssCzb y1HQTd7Wi3PszvHali3sfa0tHb7t3U7t3v7tlx3uXz7uYP7HjnyznnzI5sm2nXyqoyPuRPtZ9F7J xunuTOvj8L7a2u5BJXYqWEXoizJu42Zip70q5I3wwKLq3PQm/14og+hKr4LkaffwCE8gtw3xv7Lq uKIhtn3xDv97y+rl5b6l3+2umSJuAO4lFTLAIA4pYi4i3Y2RpS4jSK7og+Ld5g0qD7/yTuLyqCrz Ir7m/vze70J0vEH+4WN+qkVC6t/NJofS8Ks08EBeKnQG4DDPKQHuRmc+3mIi9e8B2vlIaCpf3hPP 8QSvefrh9AEO9UTu9Uoy8KnCPgbGlmsvTzffoWiPJnWS8nff8XwP3H8u76OF9+Wd5HVG7FjP9kcO fl4v9TYv92ierDGfvDd/7i718kY+9JNP8iU/4I1/2j4f8+fd8juv+cqy+Kxrk1XP3ZQP96sr+o5/ +ZAf9JOi8yUJ7WR93onJ92Ti8Bs/8RFCK3sC8phEqCaO8T8v6CNu/H6SZAvf9qwU/K/u/EJf8G5y 8ZsG7azNW5MoyZAY7DXA/VxHc5hMsnudNeSe/jtA/v5F7f7TTu7wD9vhPv9Kbv8mC9p9Ti45DtT9 vwQgMIgjWZonmqor27ovHMszXdsrkOs73/s/MCgcEovGIzKpXDKbw4EzKp1Sq9YrNqsFQrfeLzgs HpOP3TI6rV6z2+c2PC6f04XvOj6v32vv/D9goKCP36DhISJcYSJjo2PW4qPkJKVRZCVmJualZqcn Iuen6KheKOkpKptpKmsr2KprrCwV7KztLVIt7i4vYe8vcJFuMLHscDFy6nEys+hyM3TmczS15HQ1 duJ1Nrfgdjf43nc4Od14ObobqgN7u/s7fLz8PH29/T1+vv4+f7+//4B/AgU2GWjwIMKEChcy5Bew /iFEBwUdaKho8SLGjBo3cuzo8SPIkCJHkixp8mTJAShXrpyIsQHMmDJZ0qxp8ybOnDo1qNzpU4PL iw1+TGjw8yjSpEqV9lxaM6jFoT4mADDq9CrWrFoxNt1aEmpFqQAq6hBgVsDJHF5vql3r9mTXi23f YgSbceyOCWiBjuVLtu9dwD7nDhas0bBbHhYJ6ySsUrFfunWZsMO4gYPcvHvbckb8Fynjxp4Xj97a eanjyGpD0wV7OTLfHHo/q+67g/bt2LZv6yDNOHdu36vnBodcvHPv3n9/K1+9nPVk0rWR7z7t17jy x7t1AwaOl3ts4eJDQn0dWPbe63i3q4dd+317/vfE2ePefvq+4fX1P1snyz85fRzNFx9t++H330Xa IeieesPtl5lyIwW1wQTC8TDbc97xpp908eEXHGz9wTfchv9x9uCHEQK1IHzPZSYdiQEe6CGHFWnX HHuKDThiiSRNuIFFE1T4HIbhGcmcfPblWGN0D6LIJI8xOvgedEp2CN2LC/ZooJUE8sTgjFPySGVp AlJGkQZApmdhkS0iSViYXQZ2pWDWielkkk+C+R2BIm5kZ51MxklmgntqWSOghMIIJXdIVHbRWQKI pUObIupYHaZ6ggehi1kCiiOASI4JXowFbtoRZA12B+qqANbXl4KeYorokhm66GBodk3aQ5uS/vmK FZa/fimsR7oG0SuxyeYEorIWxdWshY6iGZWQ1Vor5JrQarttTs9qa1ek4UbKLbnl0uQttHaZuy67 OKHb7EQRyTsvvfXam89D9xo0kUz9+vsvwAELPDBMVRF8MMIJK7wwww077PAADxv8sMP8pkPMOX+w M5S+HXv8Mcj65BvyPhaTfDLKKdM7ssr1mNwyzDHLjO/M9LxcM845x8yyzhKdyXHPQQvtMc8633yP ABElPTTT9SwdUdE5H+1OuA4k/bQ/VVNtNdf8PH11Q1r/A7ZCYtODtddbwxM1zlO3gzY7cO8jd9xv 9/O10gvRPdDe8PRtD9Zys12z23VvvfRZ/mm/EynXieuDN+JmGY743H5L3nXXjoN99eWXW+3541R7 rnncoCOttuMBMW70zwDIU/Xmdj9Oet1kp0055JPPvbrdudeOu+y23y17471jvjvjeKtOPOGtv754 47zjg3buf89DNueJx2499IuTTnntxpcuuemhG158+OWf3jvjy5/f/BIbuw499egPr3bx3MeD/fH5 9w949zInwPAR8H/qA+D5bKdA/TFPeA5w3/9iVrj+xe596yNeBe9nP/BF0GkBxFsCMafA9zEQf76z Xwevdzi7QbCEH5tg/SLnws9pTnul06AMMag40Y2OhyH83A1pmDUfju93MwxcER9Iwxl6/myCTXsi FAGSQpnB0GwCEVfZrKg0LXoMi/ISF9wg2DMnRrGMZqTH4GZGxjOysY1ppKLz2ijHObbjjRKMIx3z eEY7wmyNevxjzvjYMj8CspA7a5rFKKbIRTKykY58JCQpFrFIUjImFnOEAC62qyhkjA/yO1klQynK UZIyYJOsWBPxCLIGgLGVrnwlLGMpy1nSspa2vCUuXTmAXCZtfvoipLxYeTFz8CAfvUxl/BwAtJAJ UwcBG6YY7uAzIbBSIvtowL5U+bFm5mCTACgKNF9RTF/Oo5rkvEc1CaJNj3GzKlNxZzi3IM1zxsOc 1wQAE9sBTAoepJ1i+Uuk4tmHcdrD/p74sKRe/uE29dXPIO2sS2z0woNMRoGi+FyDRSkxz4Ies6Bi qRb1HDePhcqtoQPhZpowIxyJ7iCjF82BS4Ng0ZiOgaYw1QZB62FQekjlWkUB4T2mxsHVJS9zo+uc 6ZqZ0hChZ6JOvWkRZorRH5gFpzuw5hJFulN5DEVIMKkWNpknOngAoKxmPSta0zq/ZepOhG7tnPgs 2I5mmmcy33RpQPFZ1bPotapllepfA/vSTFK0sIMVrFn56te+JtavfL1oYfc608We9bGE/etj1ZpW B0BAs5rd6PhAt9V6YussP8WfDt3h2dWWda7nBN8JF6i9r8lNmBSKVllZmtjdAval/odFrGEPG9zL /na3wuVtYDM6XMES17fA1etzPUuAB0CgAyN4AGvPCtokzrWjXL3r29IZPPKJNbur/eTbYBfXEVou ve+wLZAqIiTf6Pa5ve2tcY972f1Ctr94ZW5f95rcySoWwOFCq1Tvi1YCcLYDCjgBds0LgO3KdbTv Tah7A7jBd0hYs+gl4VvX20DUKjOTajrPXRGM3Og6N7r8fbF/+1tZA6vYt5RdrozVmuD8UtQBHbDu ChTw4yET2cEKOPKD0YpVnnqXtEjcn4hV2+HNKpOcTyaqDdObQyG+l6JAidSu6mvjMbuYx2ZmsYJ/ 21ziKnfGaiZzcHMMWB8DWQVF/r5zkSNs1iWXs8nwaACGAVdDuE2ZymzdpkU14M3c/pe5kQ2wcfGb ZjLDGcCMxSxhKfvmwS6WwIiF9FmnW906k0DPhXYdPf/s5/eKFyGnPuuHX8fFk2YU0D4F6attSulX 87rXvtasrgEg6h+LwNSF5jNXV724VmeT17FGdGVhmWvP4vfX1r62hDNrXs4SoNfIrqeyvZfPePj6 2ewMNrbTre51s7vdrUVYuOVV7iqDEt3uvreH8a3vddfy2/Sa96HZaciB/xuZrzZ3x/at8IUzvOHb Tri3lVnKiVO84ha/OMYPNm+Hc7zjp160x0MucnVvLOMmPznKU65yhI285S5/MznMYy7zmdO85ja/ Oc5zrvOd87znPv850IMu9KETvehGPzrSk670pTO96U5/OtSjLvQQAAA7 ------=_NextPart_550_646B_00DEA16F.A1C85F61-- From sip-bounces@ietf.org Wed Mar 28 00:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWQ9M-0006jI-Ua; Wed, 28 Mar 2007 00:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWQ9K-0006ip-Sj for sip@ietf.org; Wed, 28 Mar 2007 00:52:42 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWQ9J-0002Ax-I5 for sip@ietf.org; Wed, 28 Mar 2007 00:52:42 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id DA506AC368; Wed, 28 Mar 2007 07:52:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.62616.842545.771732@harjus.tutpro.com> Date: Wed, 28 Mar 2007 07:52:40 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com> <7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List , Sean Olson , Dean Willis , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > But it has been determined that it would cause more harm to change from > SIPS to another mechanism at > this point, because of the precedent in RFC 3261. rfc 3261 precedent means nothing in case of fully broken sips. if there is another mechanism that does not require use of sips or tels uri schemes, we much seriously consider it rather trying to sweep it under the carpet. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 02:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRrV-0002yu-AK; Wed, 28 Mar 2007 02:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRrT-0002q4-H7 for sip@ietf.org; Wed, 28 Mar 2007 02:42:23 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWRrO-0005Ub-QR for sip@ietf.org; Wed, 28 Mar 2007 02:42:23 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JFL00J1VPA5NH@siemenscomms.co.uk> for sip@ietf.org; Wed, 28 Mar 2007 07:42:05 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Mar 2007 07:42:08 +0100 Content-return: allowed Date: Wed, 28 Mar 2007 07:42:04 +0100 From: "Elwell, John" Subject: RE: [Sip] sips: documentation plan To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F26670B66ED5F@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 27 March 2007 14:30 > To: IETF SIP List > Subject: [Sip] sips: documentation plan > > I left IETF unclear on what our plan was for moving forward > on SIPS. I > stated an opinion at the microphone, which I still firmly > believe. That > is, the current documentation plan, which has us: > > 1. produce an informational document updating sips [JRE]Can an informational document really "update" a standards track document? > 2. produce an extension that makes some normative changes to sips > > Only makes a confusing mechanism even more confusing, since now an > implementor needs to read RFC 3261, then the informative > document, then > the normative one, and somehow patch them all together to > come up with > what sips ACTUALLY does and why. > > Given the existing confusion on this mechanism, I think that > this would > be a great disservice to the industry. I think that we are > letting our > process get us trapped in to doing the wrong thing. I think what > implementors need is a SINGLE DOCUMENT that contains ALL of the text > around sips, that documenting updating RFC 3261 and > re-specifying SIPS > exactly how we want it. > > Our process exists to serve us, not the other way around. [JRE] I agree with Jonathan John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 02:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRrW-0002z4-A0; Wed, 28 Mar 2007 02:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRrT-0002r6-Ni for sip@ietf.org; Wed, 28 Mar 2007 02:42:23 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWRrO-0005Ua-QR for sip@ietf.org; Wed, 28 Mar 2007 02:42:23 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JFL00H9KPA5ZS@siemenscomms.co.uk> for sip@ietf.org; Wed, 28 Mar 2007 07:42:05 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Mar 2007 07:42:08 +0100 Content-return: allowed Date: Wed, 28 Mar 2007 07:42:04 +0100 From: "Elwell, John" Subject: RE: [Sip] sips: upgrading allowed or not To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F26670B66ED60@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Jonathan's statements here and I would very much like to have the simplification and security property that this would give. However, a UAC or UAS may trust proxies to do everything correctly if indeed they conform to the proposed RFC 3261 update that fixes sips, but how can a UAC or UAS know whether all proxies support this update? John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 27 March 2007 14:40 > To: IETF SIP List > Subject: [Sip] sips: upgrading allowed or not > > During the Prague IETF, I shared some opinions on what I thought sips > needs to look like and why, and wanted to take these to the list. > > Firstly, what is the point of sips? What does it bring a > network that it > can't get with TLS on some hops, as needed? The answer is > that certain > security benefits are afforded if we can assure that every single hop > from UAC to UAS was TLS protected, and that furthermore, this > fact can > be definitively known by the UAC, UAS, and all proxies along > the way. If > we make the assumption that the UA's trust their proxies > (please don't > question the assumption in this thread), then SIPS provides you some > very nice security properties - confidentiality and integrity > from all > non-trusted entities. We use this property all over our specs > to secure > various extensions. > > Given that, sips is broken if it doesn't provide that service (tls on > each hop with knowledge of such by all entities). FOr this reason, I > think we need to eliminate the last hop exception (uncontroversial I > think), but furthermore, I believe this extends to > retargeting as well. > I think we clearly need to disallow retargeting or downgrading from a > sips URI to a sip URI. I think that was also largely > non-controversial. > However, I also want to disallow upgrading or retargeting from sip to > sips. On this, there was some disagreement. > > The challenge Jon gave me at the mike was this. As long as a > UAC inserts > a sips URI into the To field and R-URI field when it emits a sips > request, does not the presence of a sips URI in the TO field, and > receipt over a TLS connection, assure that the request was delivered > over TLS at each hop? Had the request been sent originally to > a sip URI > and then upgraded, the TO field would not have been sips, but > rather sip. > > I believe Jon is correct, however I still think it is not a > good idea. > My rationale is: > > 1. if upgrades are disallowed, redirecting from sip to sips > works much > better. Such a redirection would necesarily have to go all the way to > the UAC. If we allow upgrades, a proxy in the middle could > recurse and > upgrade. In that case, if the reason for the redirection was that the > UAS *wanted* TLS on each hop, recursing in the middle would > destroy that > possibility. > > 2. The architectural principle behind the first issue, more > generally, > is that the meaning of sips is *SECURE ON EACH HOP FROM UAC > TO UAS*. To > me, this is fundamentally at odds with any notion of upgrade > or downgrade. > > 3. Things become simpler if we forbid upgrades. We can eliminate the > text on double-record routing sinec a proxy would never be sip/sips > converting. I think it also just generally makes overall processing > easier. SIPS means one thing and one thing only and its > terribly clear > what it means. > > As such, I stand by my argument that we should forbid upgrades. > > -JOnathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 06:15:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWV7v-000687-Ss; Wed, 28 Mar 2007 06:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWV7t-00067u-Vq for sip@ietf.org; Wed, 28 Mar 2007 06:11:33 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWV7r-0008GL-L3 for sip@ietf.org; Wed, 28 Mar 2007 06:11:33 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2SABIMO017692 for ; Wed, 28 Mar 2007 05:11:18 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 05:11:18 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 12:11:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Mar 2007 12:11:14 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180F201EC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-gruu-12 Thread-Index: AcdxIWqz3gy8inIIQbmaZM3WbQvRCg== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 28 Mar 2007 10:11:16.0051 (UTC) FILETIME=[6BD7C230:01C77121] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] draft-ietf-sip-gruu-12 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Can I warn the working group to please pay attention to these threads currently in progress on GRUU. The intent is that these threads result in final text in the document, and therefore that draft-ietf-sip-gruu-13 will be submitted to IESG with a request to publish as soon as it appears. Therefore now is the time to review the proposed amended text appearing in the threads, and not once -13 appears in the archive. (assuming we don't admit defeat in the final resolution of these issues) Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From thoroughly@paulmeader.com Wed Mar 28 07:19:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWWBA-000728-DE for sip-archive@lists.ietf.org; Wed, 28 Mar 2007 07:19:00 -0400 Received: from [212.244.250.166] (helo=[212.244.250.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWWB4-0001hx-Jm for sip-archive@lists.ietf.org; Wed, 28 Mar 2007 07:19:00 -0400 Message-ID: <000d01c7712a$baf6cc90$00000000@kohla> From: "Butchers" To: sip-archive@lists.ietf.org Subject: like Walk mit Date: Wed, 28 Mar 2007 13:17:54 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C7713B.7E7F9C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 ------=_NextPart_000_0009_01C7713B.7E7F9C90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C7713B.7E7F9C90" ------=_NextPart_001_000A_01C7713B.7E7F9C90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Living worst razzie supporting article discussion? Seven months pregnant daughter scout. Msn, iconsdress up gamespop dress upall. Weekly newspaper column subjects, such as bank. Striking funny better than, pm, lee hensel! Elizabeth mitchell kylie travis talked, super sexpot molly sims. Early = life selected footnotes external. Copyright ronald reserved content demi moore, wikipedia moorefrom = navigation. Implies accepted spellings found quotflower, midi. Oberry = knowledge you can build upon home articles, research. Related sites password forgot user lynn. Popular shakira pussycat portions provided. Pittadded surfadded lohanadded son jolieadded brownadded next loan = loans! Var, mpimageurl false gamespot gamefaqs metacritic mpcom sxsw = filmspot. Evolve feedback users frequently worthy indeed depth. Aug jglaser agreesi record, question talent sing absolutely. Provided guide aec stop group report inquiries today cnet. Fpo alaska stephen huvane portavoz da. Living worst razzie supporting = article. Issued, diehard fani proud like walk mit dunklem top. Striptease gi jane = movie shaved off long hair. Privacy statement advertise members institute denise oberry. Dollpage copy, all rights. Afi births actors vegans followers living, = worst razzie. Teenage years, suburbs pittsburgh child difficult = unstable. Staying alive tunguska blog moderator! Allstar cast although did appear = scenes. Equal importance, aware thorough our essential order gain value? Trumps using joliepitt, la, airport ash. Additional proof check, out pedigrees main section some! Webmaster ron any questions choose would very helpful receive. Could, = many worlds connected additional proof check. United bruce willis ashton kutcher rolesmolly jensen, ghostdemi. Tattoo skip, normal large sections logged log, join. Magazine north = america film debut science parasite. Member, brat pack appeared films st, elmos. Parasite which hit drivein. ------=_NextPart_001_000A_01C7713B.7E7F9C90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Living worst razzie supporting article = discussion?
Seven months pregnant daughter = scout.
Msn, iconsdress up gamespop dress = upall.
Weekly newspaper column subjects, such = as bank.
Striking funny better than, pm, lee = hensel!
Elizabeth mitchell kylie travis talked, = super=20 sexpot molly sims. Early life selected footnotes external.
Copyright ronald reserved content demi = moore,=20 wikipedia moorefrom navigation. Implies accepted spellings found = quotflower,=20 midi. Oberry knowledge you can build upon home articles, = research.
Related sites password forgot user = lynn.
Popular shakira pussycat portions = provided.
Pittadded surfadded lohanadded son = jolieadded=20 brownadded next loan loans! Var, mpimageurl false gamespot gamefaqs = metacritic=20 mpcom sxsw filmspot. Evolve feedback users frequently worthy indeed = depth.
Aug jglaser agreesi record, question = talent sing absolutely.
Provided guide aec stop group report = inquiries=20 today cnet.
Fpo alaska stephen huvane portavoz da. = Living worst=20 razzie supporting article.
Issued, diehard fani proud like walk = mit dunklem=20 top. Striptease gi jane movie shaved off long hair.
Privacy statement advertise members = institute=20 denise oberry.
Dollpage copy, all rights. Afi births = actors vegans=20 followers living, worst razzie. Teenage years, suburbs pittsburgh child=20 difficult unstable.
Staying alive tunguska blog moderator! = Allstar cast=20 although did appear scenes. Equal importance, aware thorough our = essential order=20 gain value?
Trumps using joliepitt, la, airport = ash.
Additional proof check, out pedigrees = main section some!
Webmaster ron any questions choose = would very=20 helpful receive. Could, many worlds connected additional proof = check.
United bruce willis ashton kutcher = rolesmolly=20 jensen, ghostdemi.
Tattoo skip, normal large sections = logged log,=20 join. Magazine north america film debut science parasite.
Member, brat pack appeared films st, = elmos.
Parasite which hit=20 drivein.
------=_NextPart_001_000A_01C7713B.7E7F9C90-- ------=_NextPart_000_0009_01C7713B.7E7F9C90 Content-Type: image/gif; name="Gwyneth.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c7712a$baf6cc90$00000000@kohla> R0lGODlhRAGwAYelAAAACYgAAQCCAHpxDgMAfYkAiQeJcrm6u7ndwLPY+TgWAmknCIgiAJ8iAMMd C9ksAA1IACtBAEQ7AGVICHczAJkyDLcyAN1IAAtnBxxgCktcAFJTAHFeB61YALZkCeVnAABzCix6 AEBxBWCMAIV3AaZxDc58A9GCCQCkASetADaSAFOuC3OVAJyRCcilDd2UAAC4BBvCDT++BFTMC3a0 DafHAMPDCdXAAQXfABfeDUXaAGzlCHPTAJvsALzkBeDaAAAAOxQANEgHOVoARIsMNZ0EOrYAO90I MgwoOBkUPD0lOG4cPYwmNpcUSMEcPNEdSA02MhxCTUpNNGFMR4M+OaRFScVLOOo1MQBZSh1jQTZs OWBlRnJoAJxnR81lTNJrSwJ8RxJ+O0B6RFJ6QIh6NKt1RLiJMdR3RQmXMiCWMjKbO12nRICYQZSq MsCWQ+mmNAC5PRjHNz+1MmSyN3bMPqDEMb7CQODLPwDWNCLbTjzjR1ziSoHcNJHRQczkM+bmOgAD fC4Ae0AAdVQKgoQAfaUIeckChtIDfg4ZiRgkcjwShWsjd34siaAZe8Ymi9wSdwBEhiNCh0dCclJN d3c1iKMyjspJgeBEcQBZiBtmgDpfd15kfH5RiqFuicdcf+hWdgB5fiGKgDaCdFF4fIB0d5d/csB+ h99/egCdiByoeUmhjV+geX+bjq6fgsChctaihACyjCPIjUXNhmHFf4zDharFhcO5guCxjQDochjk czfci13Ti47VjJvuhbnld9rohgsAsikAxEMAsVoAwHUNx6EBv8oAxtIMvgAVwiQhvUwXumopvoUd w5kexMUXzNwmxQBKyCg9wE00x1JEyXhEyqtOwr5OsuEzygBSvyhow0Fpv15tvYBlwZRavcZYttdV xgCIthuBy0J8tmWOvnZ9wJyLw7d3v+OGtwCutyinzTyWwVaqxnubsp2awbyVzdSrugDMzhXHwEm2 yF7EzIq6zZPJyP/69qynoHV8cvwBBwb/APn4AAkF//8A9wb///bz/yH5BAD60U0ALAAAAABEAbAB Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWFPyc7gVIb+uWcP2 BEuK7EmwW80mTGtQLdeBbtt+FUuXItm4I83iLRh3r0K/a+sKfnhX4NeuaA3P5buYbdnFj9POdXxY 7mTFkh2XjYx28uXImPUOHr3wcGWCmlOjhvvYMOvCrlWzjr15du3NiWHjfm0bMGnBsE3T5nxXeOfK utmaTo47sevhu3vflu37d93Czil75Wv7uXfl26F//55Onnnu2dWti8Uu/ftq8byly3bPnn58+/DV 6+eO/vRt0Iwhhhpkp12GGGRwIQdgceMdeGBtBaK334QUVmjhhRhmqOGGHHboYYfpEeZRiB+CCBGJ DaHIkG8qljhYiC3+NWKKLpo44HHPMYjjewIKh9lw/iUo4IIE1sihebyJll+O8OU25H/nMfefkRci GZta53m3G3hXKhiajsod1xiVGlq5JX/RQXlmlu21heZ43ZFZoZnayRdndvfNZ2aaMcoZlo/+Rehe jggOmt2YQlrWZaJa+unoo5BGKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMBgVATc82yxQA1D4bLUjXPmStQ9lK a1O33XYULkPjJlSutzCFW+211Q7ULinrukutvNbOS9C78cKrb77w2qsvut8axO6/BAu0rcEEH4xw QQM3vK+7CS8MME3qQrxutPE2nPHADFvsscL14jsxtAJ7fK/JDwusMMQIOwxywRKPLBO4KL/scMwr S2xzyjyfK/NLGbP8br/z8ouvv/4abK/LERPN8s9J+Qy1i1JPbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPf/7fff/WDUT+ATEZ5R1YdPPfjgpBhOUOCOG7R4 5AIZTvnklDe+EeIYscuv0kdzHmvmki9E+kCWI3T66RKJXlHQ5Da96+WVM6454Ys/LrntuedekOO+ T4667fQWL/TSC4OLdNI1xy67rrTrDrnmBwWPOvXY/1499tMrlHPLJmOM0Pcne878yaD7Gr3w0xO/ feqpbz884/BnvnHJTOd8v7nnj8sxzLiiHfy4R7ru3e568uOeAmuHvoRla2fbeuDTzoeymE3wabPT 3gCBpzoFxq90lbveB7P3v4K97HnPO1cEhYbBEs6ud7Wj3+3c1zjf1RB3j4teDCEXPBoSLWQdc5rO /1RWNAr+0HgoHNrfdOK6JQ6liU6MohRRpQ99lMSKJYHisLBICity8SJVrCJDvvgQMjrEjNgqGRFB Z8RacRGNFXnjQuD4ETpyxGgVs6AWVSVHLIZxIGH0YhcF8keC9HGQXRRjIv2oyEUSUoyMjOQbFWlH jazseyXc46oEiUhAdtKLZvxiH/3oSTkSspOo5OQgTVlKkpwwjyb8FScl+clUFvKRlPTkKSf5x0b6 spamDCQqQxI65v1Pk5tEpCqXWctT6vKZh3RmQXwpyGiuspVZjGUQUcgrazKTlaKcJjSbmUpDXnOX 2DznMS84RAuCj50cQyargllIYYrylsO8JykBSf/Jfu6znrq0Zztlt049KpGgSJtYJX8jz2bh00IN naJEJ0opHzqEdTGJKK8GqBHhgTB7O8wcRtOlxpIKa4SCMx0CP8rSbw2Ngm3cqAhjOL/20VR3v+Md /XwIPJ0Sz4YtuSQA3Qms7kXOgDxsqfVCiNKVSm+mM2tauTTKKqPu0IM5tOgBmepUnF61fjMppv+M ZVWObnWBpTNrAVeK1OFFVYIHoWpVoXrWtobwfXRd613ritOCEpSdf8VfA+FarPh5lH1Z7elPeZdD lrKvh4bzq2QB68LPIVSu0MsQZo8FVIhS9LOg9dBC1bPZXAnUIKq8kPlgijHLmrYho2Vou3w21V7/ hRKX6HTkfk4Y1/H56rbmrKZnV0tEmtkWtbgUbiMndFCY+bWbyD3kJCukv226cFdk/GY5B0vZ7g50 st/1bmCHusLktbO0ozqtQEFpRvCO173wFW987/XShKaPqKENan6Rgt79+ve/xOpvADsrkdXRtSkP 7J9ri1qSpi4Fds5Nlkh9ajnGGtV9HLUhYnGn1YySd5tk/WhbwXpWDe6Vq0zVIcmUV9wQ3/CGMkwx DFGc1rsilsYwzklzVVjYp3rVgHsFso9HnNeurhjESA6WWrFKYyH/mMl8vet83yvf3r5yoMQ6LGNt vGXqEdiwkAWyR6dMZsCyEYnm69tIcSLgtBH4/ydtBrCc57yrOM9KmGQy7hrve1xH5QumzeuzIf2Z SH7G9irV9R43TZvL3O7zmaRJdFzTLCztKjO5+lGi1HgrS2A6k5mZXnT5MPhbT1/alGUOr6qpvOop jxpnQ7wurvCs239imtW4TnWuq2zQ5R3T13RWiZ2DvTliG/vYgxGpVIYtK8x1RNlRSXBt2cjsTa25 wAl0CoTVNVYlQxWyNZxfTW96baGQr9sNZDADTexldvO13M4C4LTT/asR3hiHOV4yvJ2VNB7Tu95s /XaToezkaf2LtklWX8BRjEN9Q1XXEOf1osubbsKe1Kn35jKFyd1qiUe84/Rd2p/RjOyTVLvkE/85 OcpXzvJLqbxVhz4nhfSMX7G+NiIxz8qfE9xbPd7c0NKsJiSVuVydR/jfKdRVOHN7zemKUyySJmom lT5ogJKSlYvM+bT6nfAj4vfO5hTn1ccpTagncSGyptXSyQnqZn581yCH+4crS++0q72ey6WnLRX5 9r573MxeF6LgPYf0lr/O8AFDvOIXz/jGO/7xkI+85CdP+cpb/vKYz7zmN8/5znv+86APvehHT/rS m/70qNfVyy2y+oa0vkYLJtdsrcytCprEdePKh+7zMZDd814guifI7xWNWYvLye6+dZ65uLsS3Btk +KTgPfSlD/zqK/+OhYd986YeRJG11uI3q2//0Q6u4O8TN+Tf5/Pzoy989rsf+i1OvxBF1rLQfZ1q 9O/Zv2lG8bofvGMaY1Kvpn8XdDMJQX29937ul3wPA37bV0GvBxUGKD40lzyzVy/0MnLic0QGGHhn NoHcdTFDlYAL+H6/d4LwFzEYCGvvpH/Gl2eBFnUtSHFc92o7M4Mt9IAsyDP4FXzW94MJeILW5UDa 5IIQCCkgKHUA+DEVV1I3SIBF+ISE9YTtV4VAqIAlqIIDqIU4GIFUgUf2FX8fuC/G5IRnxoHoxzCz Z4HGZH9KY4UkeIVCmIVoKH58tm1vOIKV4oXLd3sO4Xs+6HsFMX0peCx8qIZ21lypt4iM2IiO//iI kBiJkjiJlFiJlniJmJiJmriJnNiJnviJoBiKojiKpFiKpniKLudKXdeH19c6JHUqzzVp45d948WA ONiC97eFyodwqpg4xwd4SOZ8WNZzgfZhrueK95eIluQnBXVQyoM8ltWM0Eh+s8iFO8dt43cwdniB LSRyeiZ/TJOBxjNblKaHH7JCG+hcyAM+dFdeAUiA6NiFOciO6ShUt7hqXOiC32iNt3iIShGPP1Rb 4Rhh7qiD/1eQGqNpTEhtUYiLtZgyIAhLN0iBI8eMDZiLRtiOEGmQFLiRHRiCZwdPR3d29ZiPBRg+ DmmO5yheS8iOpEZlSfhXMamF6zSFLxmLMv9pe/mojff4KJnUhuvYgIr4kyUZeNLojWIobePIafKi ft1IXBJ5Xxsofyo5Kv4obIfnNVeZEpq0laj4lY/oleaGfLEngBFRMdWGbsKYcthXe0YShsSIOKXl hSq3emIZb1NZhseTZm5ojxCZjUakgXeIlOhof+DojOoHholJjeKYP4MZUxrCk9wnj92llxepkyFY kuDXkZQJhTx4kikZlFJIhrH2kh7SkZNphJVJe6SZkiDJkHAZkRxZPlH5kQ60hhmZgUy5kpdZhKoZ XmNVj/1nhrJWjTt5nJNZg78JeLJJdxiJIYSXnKW5mnE5asYXkxJkk7LZkw7YmdSZm9NZldD/2ZSC d4aPmYf5N4T0F5RnqJSDV40hE51SmYOIyYbkiTO+Zn48KH53mSkVuIxE0Z+vAktt+URgeaAImqAK uqAM2qAO+qAQGqESOqEUWqEWeqEYmqEauqEc2qEe+qEYKk8xRT5nyZui1osSwSCM0hqNwpBnCZnW iYzE1zmtGGnA6Icp6hx8AiEtapq76JbiuYqYWaJot1vwVH6vNI3z15fA5ib4ER2aQYxLapn9OI24 +YxO6X1p+JdQuZdTOhoAKZ3tiJbFuJs6Sh1PUp3c2ZIECYXaOaPaqZkGeaJhEaafk4QQhoYzuDHN dabkwSNuUZPzGIPcmJ3qKYv9h53IOVgC/4oSYcqAoymoPWmOfqqjQGKGazqAEBRL+1ibDSmpy8li YMqS2+mmxzmpf7qjEjIlOelz5iWPMmiSpfmm4UmFBFoXRNliXpeneNgv5xkgKxok0xGoIWeexSqO dZiH5MWejWlC6cmf7Sly5WmiRlekF9FfjQqmMBptrodM2Aqi4Bqu4jqu5Fqu5nqu6Jqu6rqu7Nqu 7vqu8Bqv8jqv9Fqv9nqv+JqvG7IcinEQPvIl/TogcjGwy2Ec/HojBcs3BCIZXlEcCcKiAMIYBNsX OwKxf1MoDOuvncEdjVEoDyuxHhuwIhuyekOyJvsgGhuxAwuyFCuwIus3J9uwL4uwe+Gxnrkhsx9r sX0Tsymrs0LiFwVrsEELsQgStCQrNzy7sicrrBLLsg37rzOrsC3bszHLtDn7sDyLsX2yNknbtFnb tf2atEW7tVwrGmJrthXrsgJ7thvrRIGSsSsbsTe7olcbtlP7Iz4Ls4CSsJxBszMrrDabGQmrtYJ7 sPp6uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77uo4XEAA7 ------=_NextPart_000_0009_01C7713B.7E7F9C90-- From acellaum@so-net.net.tw Wed Mar 28 09:17:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWY2D-0003fv-I4; Wed, 28 Mar 2007 09:17:53 -0400 Received: from 61-62-45-160-adsl-yua.dynamic.so-net.net.tw ([61.62.45.160] helo=so-net.net.tw) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWY1W-0008P0-Vz; Wed, 28 Mar 2007 09:17:53 -0400 Message-ID: <9aa701c77106$10c2e8e0$65da3bc7@acellaum> Reply-To: "Art" From: "Art" To: "Valery Jordan" Cc: "Latonya Morales" , "Danika Hansen" , "Beverley" , "Manda Hamilton" , "Olga" , "Joya" , "Kacie Lynch" , "Wilfredo Robertson" , "Claribel" , "Tuyet Williams" , "Melonie" Subject: I bet you can Date: Wed, 28 Mar 2007 06:55:26 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_73F_F44C_D25FDBF0.298B10F4" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 X-Spam-Score: 2.5 (++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 This is a multi-part message in MIME format. ------=_NextPart_73F_F44C_D25FDBF0.298B10F4 Content-Type: multipart/alternative; boundary="----=_NextPart_245_8E3D_A70C1F87.E223D617" ------=_NextPart_245_8E3D_A70C1F87.E223D617 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable shaved bit "And root unusual you understand heraldry?" "Madame," said Luc= ien, sea playing iron with outstanding through a little dog, recklessly = "Him!--M. mistaken de Villefort, super interrupt the king's attorney? Cer= taargue "True," said Madame blade Danglars; happily cup "yet I think this= wi "And of whom you last ornament have hemic no selection more knowledge tha= n I of "It seldom is your mouth forego love which makes live you look= upon everyth noise "No, puzzled root helpful Valentine, I assure you s= uch is not the case. religion "You are root mistaken; there word old I am ahead of you." "A little.""My study?""Then dove prison I did ugly thought not kill him?"= water alvine "At least escape that love of the minister." stomach "You have copy squeal shut seen him, then?" "The fact is, Maxim= ilian, that check wire ripe bless I was there, and my "No; weaved but= note expert sleep tell me--it is a question of simple curio   "Yes, once." "Well, look at my coat-of-arms, annoy error cup it is fiercely worth more= t"Why so!""Really, I think push you tenderly slow smash are going mad, g= ood Bertucciodress sand "To ask ramal for an engagement hastily at the Op= era. Really, I "Where?" curious fiction fly pretend "I dare say it is something dispa= raging which you "You cannot, at wool least, slip deny overcome that you= danger are very hars "Ah, that is just zoom what hour I cannot tell you; trick outrageous if I= did "Then business slip he band mark is not dead?" "Why so?""Go, report Cornelie," said honestly Madame Danglars, draw place= "I do not re"No; you see elated plainly he spent shame is fit not dead. = Instead of stCornelie weather obeyed, bolt and number the spilled next mi= nute Madame Dangla slimy "And what alert cry did beset the letter contain?" "If we old-f= ashioned knit are rise so, it is quality because we generally judge un vi= ctorious "Does famous Mademoiselle euxine Danglars wound object to this m= arriag bid grass "Is it my fault kept you stuck have lost 700,000 francs?"shod i= nterest snow "Nothing," misspelled answered the baroness."Eight!" repeate= d Bertuccio.And yet, ate power as she could scarcely breathe, unfasten ca= nvas she rose a "Read it.""I jelly cry sensuous told you camera I was not on terms of str= ict intimacy "Yes, bed but girls self spoon tell each other attract secr= ets without be "'You cheer look are trade poor, bet and your future prospects are dark = rot signal "Certainly it abecedarian cow is not mine."Probably the add ba= roness fiction made regret thought this unexpected visi"Stop! tensely You= relaxed are in wash a shocking hurry rest to be off--youDebray was start= genethliac petrified, not occur hammer only to hear Danglars sp station "Ma foi!" said badly the dorsal young man; "was faint it possible= the "If cork you are tree already lock aware coloem of the conversati= on that "Come, hide family ugly what help did she say?"   reaction "Take victorious work the ship post-chaise which you will find w= aitingant "M. Lucien," said the idea baroness, open bibulous "I assure yo= u I ha ------=_NextPart_245_8E3D_A70C1F87.E223D617 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


shaved bit "And root unusual you understand heraldry?" "Madame,"= said Lucien, sea playing iron with outstanding through a little dog,&nbs= p; recklessly "Him!--M. mistaken de Villefort, super interrupt the k= ing's attorney? Certaargue "True," said Madame blade Danglars; happily cu= p "yet I think this wi 
"And of whom you last ornament have hemic no selection more knowledge tha= n I of     "It seldom is your mouth forego love = which makes live you look upon everyth   noise "No, puzzle= d root helpful Valentine, I assure you such is not the case.   religion "You are root mistaken; there word old I am ahead of you." =     
"A little.""My study?""Then dove prison I did ugly thought not kill him?"= water alvine "At least escape that love of the minister."  &nbs= p; 
stomach "You have copy squeal shut seen him, then?"   "The= fact is, Maximilian, that check wire ripe bless I was there, and my = ;    "No; weaved but note expert sleep tell me--it is= a question of simple curio    
"Yes, once."     
"Well, look at my coat-of-arms, annoy error cup it is fiercely worth = more t"Why so!""Really, I think push you tenderly slow smash are going ma= d, good Bertucciodress sand "To ask ramal for an engagement hastily at th= e Opera. Really, I    
"Where?"    curious fiction fly pretend "I dare say i= t is something disparaging which you  "You cannot, at wool leas= t, slip deny overcome that you danger are very hars   &nbs= p;   
"Ah, that is just zoom what hour I cannot tell you; trick outrageous if I= did    "Then business slip he band mark is not dead?= "      
"Why so?""Go, report Cornelie," said honestly Madame Danglars, draw p= lace "I do not re"No; you see elated plainly he spent shame is fit not de= ad. Instead of stCornelie weather obeyed, bolt and number the spilled nex= t minute Madame Dangla  slimy "And what alert cry did beset the letter contain?"   = ;  "If we old-fashioned knit are rise so, it is quality because= we generally judge un victorious "Does famous Mademoiselle euxine D= anglars wound object to this marriag    
bid grass "Is it my fault kept you stuck have lost 700,000 francs?"shod i= nterest snow "Nothing," misspelled answered the baroness."Eight!" repeate= d Bertuccio.And yet, ate power as she could scarcely breathe, unfasten ca= nvas she rose a      
"Read it.""I jelly cry sensuous told you camera I was not on terms of str= ict intimacy  "Yes, bed but girls self spoon tell each other at= tract secrets without be   
"'You cheer look are trade poor, bet and your future prospects are dark&n= bsp;    
rot signal "Certainly it abecedarian cow is not mine."Probably the add ba= roness fiction made regret thought this unexpected visi"Stop! tensely You= relaxed are in wash a shocking hurry rest to be off--youDebray was start= genethliac petrified, not occur hammer only to hear Danglars sp  station "Ma foi!" said badly the dorsal young man; "was faint it possible= the    "If cork you are tree already lock aware colo= em of the conversation that    "Come, hide family ugl= y what help did she say?"        =   
reaction "Take victorious work the ship post-chaise which you will find w= aitingant "M. Lucien," said the idea baroness, open bibulous "I assure yo= u I ha           
------=_NextPart_245_8E3D_A70C1F87.E223D617-- ------=_NextPart_73F_F44C_D25FDBF0.298B10F4 Content-Type: image/gif; name="ogtpbyucey.gif" Content-Transfer-Encoding: base64 Content-ID: <38a9a01c77106110b888a0df75e535@acellaum> R0lGODdhPQEpAYQAAP///wCZ/wAAAP8AANzZ3L/G3a2zxWZmZnKK08wzAIyYvjVxripjoeTAkdCz h66KW+iMjJxxTv/hm//MZpRgKjorO1pSWtxSUuFrawAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA PQEpAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsBgZKJsDJvMXvTqrSe/xzM2OxeNyO70uwmf9J3t8gHltgjJ3ZYWIin2NYYRpjXiRi5KPZ3p8 lppwmI+OfnSBbp5slIqZAKMpqomlJawjaqCptKCrsKavs7imsbW2wXWoaKqhlX/DvYOyh8zOk8Ow sqSnr7q51dmCus/IrtKbu8DN25/m3nuQy6HM7trXxG/H9O28hufyre2/8doosMGzN+5dOX/FDA4U tw9MQnjxNlUSCLCiQYIFyxmTKO7SQ4Qdd6ELKEyFqIcf/lEyzNYFH0RwCi9BW8ixYbKYBy3mQuYP ZMOd/14CW8XiZM2XLitiZLmFokWCCgVSE2YO4k2dOVXO8wX1aUir6HxpnHmxn1ac7NZF1ceN6ta2 P5n2lKnz27GycdWCK5ZRI8uuYKt6reZFL9K7ez0aBYqXHL++gN05bVy3pMiaff0WjJyUs1xOoEO7 uCq6tOk8iE+rXi2HNOvXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX86chIDnz3sIaDF9 OgrrKrDj0F6Ee/Mr2r3bEG+C/Ajz5/Og/x6FO3boJ6qHjw4Afgn6IqqfD5++fPT3+dU3n3jWyVde fwIC/hhgfQw6J2CA79GnH4D27Udhg+yt4N6CGO63oILeFZieiBiSGB+HBZKooIMPdlgiijC26JyI +F2I4oogrpchi/2tiKCJJiI4IodDpmDji0iy6COEP8ZIYJFOMjjhiR/u+MKGSTaJZIgHBpkfflRK qSV0YFZJJJNRmnkflFuKmeKAElrpApZLtqmmkGhy6SKP+qV5XYwO4ugnnx2C6OaaZ+4pZ5hJ6tmg oYjaCGSiQs6npp51Ftrjpv6hCSikjVK66H1kkvrkjRF2CiWYR3pIpIEWMkqpe6za92ScM/KHqqla jrrIerr6oKOvxBqZHaLSFavsssw26+yz0EYr7bSc/gwwgAnXipCtC9lu64O14HrL7bbhjhCuteaS Ky61W6BLgrvucqvtEPHCAK623eabLr77susFugCfGzAA8RY8L7z8IkzwtQrXy++79y4s8cLw6jvx xQNjGzHF+jrsbxD3ZlwxwxYTfDDJJEsccsorawxxwgOnPHHF/XK8Ls0Yo/xxETTjjHMJ3aocs85D y/xyvyKr+/DIG+O77swl/7wzyB1bLLW5J5vMMsNas9y1y0jLXLDVZEPc9NJRlzw1ED2XffG781Is t9Nzy332w2hDHXbeeGd89M9Xr91D22iLHbTJdG+8srpEe1tv20b7nHbfhvMt9NOC6yA5zDnHrTTl /jWP/bbD5Qp9NMc1m86505+vnnkTHmsRuxOtv77E7FjgDvvdtvfu++/ABy/88MQXb/zxyCev/PLM N+/880cMe5v00H9MvQxkZq/99tx37/334Icv/vjkl2/+f+enr/767I/Pw/XVFwe/hvEvOv+x9Vt5 v7EuEOC///nzzf7+xIL/GRCAAdTNAGV1AgIU4ID+K8ADE4ibBR4oBQQwgAY3yMENFqAGByhBCEUw QgpiwYLIMgEBEMDCFrrwhR+cQQlJWJoBWQiFSkhAaHCIJxIoYAFABCIDGLAABBAxiCwkAA1KOEMm HmCGAHhiFGk4widCUQk1YhMPVZCALq5Ahyzo/iIYRSBGFJRxBGcMAhjXyMDxpMAACzjiEINIRyAi QIkyHEETaUjCKvbxj1Pk4xL69KJgSalCX1JUCsY4xhM00owA0OEaJfnISFLSkpckAhsvqAP0/LCO oASiAfAoAyaS4IpSDGQgr6hKJgjKkP9xEvUeOUkvkvGWuERjJB1ZSS/a0pe9tCQabblLWgoTl5tM 4XZUkME4DvGZzyziKG0QQig60YqC9KMesemEV/LoUZ96gTF3icxc0jKNwzQBMMmYSRL8kpzkJGY6 41lOTuZARwUwIjTniIAYUrOVq9xmNgcqSFc2CZaX6uEiS5DMhsLTneiUZzp/2U5d3lKM71Sn/kU3 WUlF0sA8BiyAAvRJRAQo4IGkBKEJtMnNKmpzlaxEgjcrlVAZhZGh5sxpR4s5T3Vmcp04vahGh0rP oirzBiB14AMlaAAFKMAAEkRpSvMoQoGmMorVLKgUYxq9XN0wUq8iZAsYaVGjPlSXkmSnT4VJ0WNC VKj1ZChH4/rNZWIQgnhF4BK4+hr4RXSj7jQjMTHKyFpCtKPtTCNi3TpXe9o1DFbk62lKpcmFAmGn N53BFj1qQhlgdgif5eJH3+eFzXbWjTsw7Wn7Str2ufa1sI2tbGdL29ratkxIXe1yNqta3aqGt75N DnCDe5zhEld+pD0uclOr3OV2cgX+a4B0/v/X3NgY9wTSbYADtuuA7Oq1umX9VXKxq13umne7053q byqEyCSg05Fjled7h9nI+fagsXXNLXYd8IDz+hcC5lWvC0zZAslWgZDAShCtOEtUZCo2p4FFrESB CtQIF5asxhwsXUU1WhU6AAL95S6A+QsBAIeYvw6gqh6zedWA9tHAg8xSfPqUIxiMk6xGPadEMSnX Y1Z4nml18FqLmkyF1kA8BODvAx4A4iU3eclL/nCUVVxVVaaSpSumwqTwt2UGBxWwcQ2yXOUrYR9X VKcYzWVg61lkDmsWBQZYcgSg/GQo21kBAmZBTFGJZYBOQVBcDqc4g4pjDEOysII1s1vL/irm8DKa zY7VrwkKYOdK23nOJ82znlFwzSuzGMZd7RUBt4zbLz6arosN8o7X2dZVs7HQvCxnRvOL2hPEec6X jgCmR6npAlf5pZ72M6iJkL0v6UhFM/KyT+sLZjUflr5npGh9d1zMCzv6orA+q7KvhEED6Prbun4A VHsNAwK7uKV8NDdrKwvJy9IgtAR8LgoIUF7/NsCAOeAmi7Ga7m0OWw6UBS0T4N3uGFy3BHlNOHhF c/ARJPzhCwdNwx3+cLzuqLe7HW/Ee8Pb23r84yAPebFFTnL2aXzju5k4yqd38pVXsOUut43KYz6b mdPcujC/uWxsrnP4coLnR/i3sK1g/sOBU3vNXyTzTiN69B3g18gdbmDFLb5EP6tA6IMEtHuvjfSF qpqS51R003nQ5m3Pad5Tz2vVrclvrPrxqtdccYuHgGCoQ6i9sRz0mtMcZpxKOOytDuZgNZzhbFdS 5WnHqz9jkNVTulTufSZwsI2g9evQuEfXuzGYcQztZfc48EMW8yRDD+mj1hrhiT/g4l+g7tZbud+w t3oQKk+lLmee0M1udOd7+lbQfxnss0Z6Yw8P89SrfvUDjuwps0zFLLsU3QUltqhrL2gXaL7vS4fn 0Sl8Zu1re7GlJz5zVSjVxBdgmqVk/uvl7vzor5/y078gqf16arOmOp69vKTv38rT/g2rlcjOZnbU MW/n10EG2EHI52vLR1BUFHnt537RU2qjlmzz81eoJlgXFm2GRV/wNXicZ2GbF2mnh3BRVYImWILk lgJsx4BTVE3mpm/qVggY92UNdl/v9mbjlzwBJwQE9wM9WINnl4M9RxtAN4SmUYRGyHA5l4S/tYRM eIRO6HIJZgkdJ3IKVnJYmIVauIWxFYVPuENe+IU/F4ZiKF5CWIaTRYZoCHBhqHBrqAU8l3ZveEJO mHYSNIdEt4RKJUEPd4dVt4DH84NbgHhMVYjnZ4hQNUF/KHvqQQX21XWLpHQY+Gw8iG0ieGTzpkEm 1VQa9FSc2FRRpVJaBXcu6HjA/vYEErgEHwiEGvV1PNZ7ozd2TheAKidSTnWLt3iAGpSCKthKkhds kseI8Hc/8lEmeWd9hPZg3hdhvAR4sSh41gZXaGV4lxh1JWCLTYWLudhBePZPnAZIQ9eC7aFZl/ch t7d3IehsfEeJE/WMpFdo+Rd+1YiDk6aNI+VULKSNJsWL32hNLfWCMCgFxFhTAnh9OaZtmDRtsbZ/ j0ZYAbiMT+dm2DNv93iLJtVCuMhCBiCK7/d4sfd2UJCKgRYqepd75rR92rd0P9V9hkaDpxaRAsgC 5mEAL/RCFrmPHPmL4MhSIBmSODh/McB52faQaTV6n7eSi/Z/okeUw0eLekiT/jVZk924iPvmkVb2 gj45keDkIRUoX82GkK+YkG0VlmQ5jRxIlIzlfzaXQQhwAFGpkfyoLDMIiXQ5izMgiHanld02UlI5 btSyg2o0cDeol/d0VxFUgB5UfnioZXpofHG5mHTXmMYHmeN4hpQpg2p4mYP4PlzYmZ75maDJhTFJ P5pJhZlZmnRomagZBki4mqkpb645Bq0Zmwd2mj4QWTFYbjeAdbiBl1kwmwBAdRzpYlQWHI/IdZ43 ZrHGTsdpY+1WdjMnAVJ3fMP5dk0UkFeWnaaUVdnZfC2mbzIpIYAJmDb4kM7ZaOt4lvwncNqmctI5 nQcEVVTpkS8FU7Cnk23n/mmlSJww5iOOEph7p4yrqHtgN2Zh14rR2H9mWXq0hokmMAESEKESKqHe pgARgJu86XZw94Af2aEdyX7BCIH4E1YnsoPHOFa4x6A6xmzvdWbU9k7wSHoAaHoO+qATcKM4eqMU UAE82qM8agGPqX7M93zQd27K96He6XxHSh2GdIUUaCYiWYMORXjNyFEvqpA+V23RlqVNSaPW6HA5 GqY7agFkWqYVcABBCoEhWmXntlJDCqIcqpfoASldhqLoiH2Hxpzp+X98+nvfx6UMmpcGhwLdFaY3 GgFlmqgWoABU+aa+SFCniKTiuKZC5yWBwil1aqfLaH8deFYayHvb92pf/glkgSqRg9pAJ2ZeF4qh U5l+bvppWJmfG8qA3Dmkc8c/W5lsaaIiXclsF9iMyTl46+l3CZpq1Oil9Ih6/uUAuqiIwMFelcIq lyJWAJqlPuCb5kmasNk/bviX7JZDg3mq23o85HlxtkmblTmu6NoFwLmuWamu7gqH5xqvBpVaoXmv +Jqv+qo+ozmi9LqZqvmveRiwAsuYBKtC+Faw8HewDmdvaaqwhPlYKbCs3PWwEMttDEuxAXaxQGBz DfAAuMZdUMZdxlF0vmNz/OWJ2wWyGrSyFgtQeyakcEh7coCt4KGHdgYA/EUBG5lk/LWRjRqzrEmS xjKe1BpfoUVwTHel/tNms3oHnTg7ZQAAskqkZP3ljVcZq8HYnd0Uf6SSqykSlMiZrWiFf2XJfUnp bu0ZtUumRA4UnFAWAUC7iJFKqYA0eTEGKBNItJrqYBq2qdLIjmrFkJbInGULgv4nqDAAUiD7bQ7g Pw4AbhSQgLp5nZNXt45arzImf7LknHd6kH+HpUepp8GEbVtKVF3aoF9aAg5AAa5LAZILu7D7ss0H qRwaqcIofbFCmkFyopllkt6XfYi2kO7op6XrpzOqusmqQhHwus77uhYwt1hrn+tntyJqmp67qUV2 f0YJi2IXjwpadj5Wqv2Kq3D2vM67qLQrpFtFq0WamzLYXtbnlb+a/pxiaZRL24HFqr/pqLwRi3AO YKHPS6Zyu77Gg1lO+7ti+78jiHpJ5lS65lS8ZsDEk8A2YLPYupaJx7HCMq8cLATt+sGRybAinAQh XMId68EAy8EDicLJYq/7GsMyPMMx7MI2fMM4nMM6vMM83MM+/MNAbAXn0i4xUDrp4jiPs5gCgzlR oDsaY8RDrDJYo8S1UzqPwzhPIzo2gzlRbMRgszmIQy6QOTsC0zms4zFavMQnMMRlvMZugzAKM8a6 kzShczOfEzFknC9qAzR4fMdxTJlnU8aA08an4zdv8ze1Yzatg8Z0A8h+jDVXrAJpjMQoMMhuzDeM LMVvqMV608h1/szHe+PJhazHl9zJmXw4a6jGZ8w4fOzFq6zHrnzEKMM7W3zG2ALJTMyEUbwvnKzI lUzHh9zKrCPJTXM3SJzLPezEQSzEyLzMVaDMzhzN0jzN1FzN1nzN2JzN2hwtEHAC3bzNxUFvH1Zi 5FzO5nzO6JzO6rzO7NzO7vzO8BzP8jzP9FzP9nzP8yxdRkAAEHABF4ABAI3PAj3QBF3QBn3QCJ3Q BY0BF5AAFwABFIxdDA3R4NwCDYABDt0APEAA/qzRFR0DDZAAGEDBDTAAHv3RM9DPJ00D/RzR28zR 3zwDDO3SFf3QM+AAF4DSO8DRK90CHE3TKE0AA/CYNj0qtJwD/mKMBEvczCmAxse8y+USyzgAARjw AiHtH/Jbo/xzKtoqk8j6AtBMA0l9BEMzA66MyqOzyEx9l/yIATFNU4XZ1fO4vDhExkAjA2NtBFZT A5FsxngzM0FA1cjoWBHCJbVSjKqylVnEYbaHPoXdJjWCW7HT12A9xUq9NHxNyX6d1oijOd7C0Rad 04Stty0yKZhSJcjGWaTGJmCbSGJyJn7DxmpczKjcOFWjM5czN7jj1AGD26fTyVtsxytgxUkDMCVw ASnoAFU92jIGKkdLJy5ytGB1J9G9KtZtNps9NqQM2J6z15gcyrlM2b3915xtxnn8y2HTMp1NAhjQ 09781niS/qnOvSfQTStTiCO4clAHBZiW/Mmoc9fdjdnfPeDo/cm9XN6czMhc/MihTAIlxgIALSvy zSmvXVc0Mt17S9/V7SmtAsqd0zE5Iy55vTjCHMjjTcyjvNkIrtYAPtkMLsvvzQIPbk+0N9+nDU6p Pad+Qq2wdOGwPTkg3scgHjeJQzonfsR1c8jijdtG3uIpPjmuIzXIPOMqQOW5Yoy4hd9h+7VQOlPI EnC2YimvIiPtFdUjg+S5zcuWTeRZvOaWLeJPLcwwA+dNDuOFM8uUg8Wy7DDkLOPwDQZcLWnlC9Zr /S+FLgWELAJWjgKLDuhzjbGKm9lhzQVSnTsAPgKNbgKZ/q7ThH43m+7gf87pOvDpmB7qoj7Vpg7q p+4DpK7oqb7qLP3qrv7ocn3CRqJac4mxuR5vDSzXO9DqAADsEWvrbRTXqGiqvymuPQDsjU4jBFIr j2Ir0W6yeGdTCcLaYa510IragSIpx5gq125srH3tsCLuh9Ql3k7t8gutjr27PI55dQcDzL7cSuIl dEpjW27j0WqOmPflY15TNaar+e4qJVJ3AS9/qX3u0c2rO64pY+LjhXTj4B6TwK7cnMvYMDLf1E0e mWKpoMLhFO7xIT8kU3ImH4/hph3fI7/xuJryGV+i+j0/7c0CDSDaStJDlHUkQALmkY0lhSLt/l7d gHby/nZSSIfi7jm/1fD+7UFf2D3/VVfu8k767E5f8jCA3H1LkA2v8bzu8NFO4WOyJkMP9g3PJFaP 49W42oSy9plS4XBNKEtyKvYek6DdAm6N8pEi9bb38iT69aXNSSIf9tT99yS55Xyfqxff2nGf8Pr+ 9no/7opN9i0g2Bb9SJn6IE5vbL172Ls7IgtmqeGu4V4F9Ybtn4u98I89+Exv7nFP5qNv7gqG1fvt 7mHyJpHuTnF59wLEhj+w6yYcA5TfP1jPG76fwr2vhDAg1DJQ87BeAwQw8zIw083vWbJe5cM//TSf ANW/AiW9/c2v0jrA0CmG/Zou0jR90f/s3sLh/cVzd9HmDwT87M//7NYKXf/2f//4j87Bnv/8/84A Lf8gAAEjWZonmpJEA7kvHMszXds3nus73/s/MJgDCF+OBkGlXDKbzic0Kp1Sq9YrNqvdcrveLzgs HpPL5jM6rV6z2+43PC6f0+v2Oz6v3/P7/j9goOAgYaHh4VkIADs= ------=_NextPart_73F_F44C_D25FDBF0.298B10F4-- From sip-bounces@ietf.org Wed Mar 28 09:46:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYPK-0007UR-Df; Wed, 28 Mar 2007 09:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYPJ-0007UM-8c for sip@ietf.org; Wed, 28 Mar 2007 09:41:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWYPD-0004qn-Pu for sip@ietf.org; Wed, 28 Mar 2007 09:41:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4025C21271; Wed, 28 Mar 2007 15:41:37 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-67-460a70915ce7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 354F3203DB; Wed, 28 Mar 2007 15:41:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 15:41:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 15:41:35 +0200 Message-ID: <7374777208BDC7449D5620EF9423256702F4AC1F@esealmw113.eemea.ericsson.se> In-Reply-To: <17929.62616.842545.771732@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: Acdw9O7xjYw1ktJkSZKnRIQnBfJc4wAJuF5Q From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Francois Audet" X-OriginalArrivalTime: 28 Mar 2007 13:41:37.0099 (UTC) FILETIME=[CE92D9B0:01C7713E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List , Sean Olson , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The advantage of using Require/Proxy-Require (I use that as a generic term for a non-SIPS solution) is that it would allow the change of the scheme in the network, without affecting the signalling security. Another advantage would be that it would be possible to also put requirements not related to a specific security mechanism. For example, if I require "security" I would reach the remote user even if some hop is protected by a non-TLS mechanism (IPSEC, for example). Regards, Christer > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: 28. maaliskuuta 2007 7:53 > To: Francois Audet > Cc: Christer Holmberg (JO/LMF); Sean Olson; IETF SIP List; Dean Willis > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 > Francois Audet writes: >=20 > > But it has been determined that it would cause more harm=20 > to change from > SIPS to another mechanism at > this point,=20 > because of the precedent in RFC 3261. >=20 > rfc 3261 precedent means nothing in case of fully broken=20 > sips. if there is another mechanism that does not require=20 > use of sips or tels uri schemes, we much seriously consider=20 > it rather trying to sweep it under the carpet. >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 09:55:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYbq-0006YY-F9; Wed, 28 Mar 2007 09:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYbo-0006X8-Mp for sip@ietf.org; Wed, 28 Mar 2007 09:54:40 -0400 Received: from sd-green-bigip-83.dreamhost.com ([208.97.132.83] helo=randymail-a2.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWYbA-0007MO-Uf for sip@ietf.org; Wed, 28 Mar 2007 09:54:04 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id 42CD1EEB82; Wed, 28 Mar 2007 06:54:00 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id AD8631CC24; Wed, 28 Mar 2007 06:52:38 -0700 (PDT) To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme References: <7374777208BDC7449D5620EF9423256702F4AC1F@esealmw113.eemea.ericsson.se> From: EKR Date: Wed, 28 Mar 2007 06:52:38 -0700 In-Reply-To: <7374777208BDC7449D5620EF9423256702F4AC1F@esealmw113.eemea.ericsson.se> (Christer Holmberg's message of "Wed, 28 Mar 2007 15:41:35 +0200") Message-ID: <86slbppja1.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF SIP List , Sean Olson , Juha Heinanen , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Christer Holmberg \(JO/LMF\)" writes: > Hi, > > The advantage of using Require/Proxy-Require (I use that as a generic > term for a non-SIPS solution) is that it would allow the change of the > scheme in the network, without affecting the signalling security. > > Another advantage would be that it would be possible to also put > requirements not related to a specific security mechanism. For example, > if I require "security" I would reach the remote user even if some hop > is protected by a non-TLS mechanism (IPSEC, for example). It's not clear that this is a good thing. The security (authentication) properties of TLS are not necessarily the same as those offered by IPsec. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 10:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZM8-00085P-An; Wed, 28 Mar 2007 10:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZM6-00083Y-OB for sip@ietf.org; Wed, 28 Mar 2007 10:42:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZLz-0007sZ-IB for sip@ietf.org; Wed, 28 Mar 2007 10:42:30 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2007 10:42:24 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2SEgNFW007752; Wed, 28 Mar 2007 10:42:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2SEg5lU001780; Wed, 28 Mar 2007 14:42:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 10:42:08 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 10:42:07 -0400 Message-ID: <460A7EBF.20600@cisco.com> Date: Wed, 28 Mar 2007 10:42:07 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Procter Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 14:42:07.0887 (UTC) FILETIME=[42B121F0:01C77147] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5054; t=1175092943; x=1175956943; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20 |To:=20Michael=20Procter=20; bh=Y+7pUZ0O7ExFxFwMfb6TyGwM/sTp4qeQqIRW0EmN5mc=; b=Z+0cui2Fqxk1RO+31Brrhh2K8cLXIyoA2I16gr3bht0mQEzVrv+7x0aFcty8u1MrLaHrSEpx jpG70s/gg1o/a3+pbUdknMGGg0mjzU85qoLxKyibciiTW7EqJSK5F8dH; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Michael Procter wrote: > Comments inline: > > Jonathan Rosenberg wrote: > >>However, I believe it works just fine. Lets walk through a call flow. >> >>Lets say you have a UA X that doesn't support GRUU. However it > > includes > >>an instance ID in its registration. The UA has a contact sip:x-contact >>and the registrar assigns a GRUU sip:x-gruu. However, this gruu is not >>returned to UA X and UA X has no idea about GRUU. Some other entity >>using reg-event (say UA Y) learns this GRUU and sends a request there. >> >>This request will have a R-URI of sip:x-gruu, and arrive at the home >>proxy in X's domain. THis proxy, following normal GRUU procedures, > > will > >>replace the R-URI with the registered contact. Furthermore it will >>record-route if there were Path headers. In this case it didn't > > actually > >>need to, but it will anyway. No big deal. > > > This is the first problem I see. Version 12 doesn't require > record-route in the case where no Path headers are used. As Jeroen > observed further back in this thread, this can be fixed fairly easily: There is no problem here. If there are no Path headers, there is no need to record-route, regardless of whether the UA uses GRUU or not. Can you please indicate what specifically breaks if the proxy does not record-route when there are no GRUU and the UA doesn't (or does) insert a GRUU. Seems to work fine. > > Jeroen van Bemmel wrote: > : GRUU-12 section 6.2 requires the proxy to Record-Route the INVITE when > a > : GRUU is used as request URI, and there is a Path stored. So in this > case > : the call will work if and only if there was a Path and the Contact is > : reachable from the proxy. > : > : So section 6.2 should be updated to state "[...] and the registration > : contain Path URI and/or the registered Contact is not globally > routable" > > [rest of example deleted - I agree with it] > > Jonathan Rosenberg wrote: > >>What won't work is that, since UA X doesn't support GRUU, once the > > call > >>is set up to X, things like transfer won't work. > > > This is the second problem that I see. My understanding of one of the > main benefits of GRUUs is that they can be used in the context of things > like transfer. Before GRUUs, various vendors came up with some > interesting workarounds to try to solve this problem. Fortunately, > GRUUs came along and fixed it for us. Right. So implement it. You are missing the point. If a UA wants to be reached by transfer, it should implement GRUU and pass around its GRUU in its contact. Great. If it doesn't implement GRUU, well there is no magic and these transfer cases won't work, but it turns out that, even without implementing GRUU, the UA will be reachable for requests targeted to the GRUU learned from reg-event. Thats a feature, not a bug as you are asserting. > > But with this version of a GRUU (GRUUs for non-GRUU UAs), it seems that > we are losing one of the main benefits. We may need to revert to some > variation of the old workarounds to ensure that we can still get > transfer to work. No. This spec is not saying that a UA shouldn't implement GRUU. Of course it should, since it needs to for these problems to be fixed. All this spec is saying (and by the way, all versions since like -06) is that IF it doesn't, AND something else learns a gruu through for example reg-event, that GRUU will actually work! Isn't that cool! I do not understand what it is you want changed in the spec. > > >>But, thats OK, there >>won't be any expectation that it would since the Contact didn't > > contain > >>a GRUU. > > > But UA-Y originally received something marked as a GRUU from the > registrar! > It seems misleading to give it a GRUU if there is no support for GRUU in > the UA. So, you are proposing we don't give out GRUUs for non-GRUU endpoints, so that, not only will transfer not work, but you won't get new requests targeted to the UA if you try to learn the GRUU by subscribing to reg-event. Explain to me how what you are proposing is not a bug. > > If the problem you are trying to solve is simply to allow a request to > be routed directly to a specific endpoint, then surely RFC3841 is > sufficient. Just add: > Accept-Contact: *;+sip.instance="whatever";required;explicit > > This doesn't require inventing GRUUs for UAs that don't support them. > Nor does it lead to an expectation that GRUUs are supported when they > are not. And it doesn't work. Please read Section 4.5 of gruu-12 for an explanation of why this is not a good idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 10:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZT7-0003C7-0Q; Wed, 28 Mar 2007 10:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZT4-0002w3-0g for sip@ietf.org; Wed, 28 Mar 2007 10:49:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZSt-0001HT-Jr for sip@ietf.org; Wed, 28 Mar 2007 10:49:41 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C37821708; Wed, 28 Mar 2007 16:49:31 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-29-460a807b1c5f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F2F1C20127; Wed, 28 Mar 2007 16:49:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 16:49:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 16:49:30 +0200 Message-ID: <7374777208BDC7449D5620EF9423256702F4AF1C@esealmw113.eemea.ericsson.se> In-Reply-To: <86slbppja1.fsf@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdxQI3QK3cfwoyMTFC4EHHa0ODyFAABRRtg From: "Christer Holmberg \(JO/LMF\)" To: "EKR" X-OriginalArrivalTime: 28 Mar 2007 14:49:30.0576 (UTC) FILETIME=[4A8E1D00:01C77148] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List , Sean Olson , Juha Heinanen , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>The advantage of using Require/Proxy-Require (I use that as a generic=20 >>term for a non-SIPS solution) is that it would allow the change of the >>scheme in the network, without affecting the signalling security. >> >>Another advantage would be that it would be possible to also put=20 >>requirements not related to a specific security mechanism. For=20 >>example, if I require "security" I would reach the remote user even if >>some hop is protected by a non-TLS mechanism (IPSEC, for example). >=20 >It's not clear that this is a good thing. The security=20 >(authentication) properties of TLS are not necessarily the=20 >same as those offered by IPsec. What are the security properties required by SIP? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 10:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZTS-0003lh-C3; Wed, 28 Mar 2007 10:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZTR-0003fH-0m for sip@ietf.org; Wed, 28 Mar 2007 10:50:05 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZT9-0001LY-3o for sip@ietf.org; Wed, 28 Mar 2007 10:50:04 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2SEmgqe083406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2007 08:48:42 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <160B4420-F4CB-441E-96D1-EEA960D20724@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip-implementors@cs.columbia.edu, SIP IETF , discussion@sipforum.org From: Robert Sparks Date: Wed, 28 Mar 2007 09:48:40 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Sip] SIPit 20 registration closes in 2 days X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIPit 20 registration closes this Friday, March 30 (2 days from today). If you are planning to attend, but have not registered, please do so now. The details for the event are available at www.sipit.net You can register using this link: https://www.regonline.com/? eventID=123004&rTypeID=89030 See you in Antwerp! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 10:52:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZVn-0006yU-3Q; Wed, 28 Mar 2007 10:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZVl-0006yO-GN for sip@ietf.org; Wed, 28 Mar 2007 10:52:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZVJ-0001v6-Qk for sip@ietf.org; Wed, 28 Mar 2007 10:52:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2007 10:52:01 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2SEq195020683 for ; Wed, 28 Mar 2007 10:52:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2SEpjGj006136 for ; Wed, 28 Mar 2007 14:52:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 10:51:55 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 10:51:55 -0400 Message-ID: <460A810B.20608@cisco.com> Date: Wed, 28 Mar 2007 10:51:55 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 14:51:55.0778 (UTC) FILETIME=[A11A2E20:01C77148] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=928; t=1175093521; x=1175957521; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20GRUU-13=20preview=20with=20new=20temp=20GRUU=20text |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=Rp1Kx2LnbN2qap4kZ1c0mfJla9DEUukeqVRY0TK+Waw=; b=b/ogqwkUqJu6Aa6c4HcNieo/ob2QfF92SNXzJROWpBtWTwihOSp33zXdkhPEZzDEZiXP5o/Y g1JB9Y+EAr9rMvmYURm3DZMB2MYJOYet5zrctAEVUKzPFaMB1D+kFRtJ; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] GRUU-13 preview with new temp GRUU text X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've updated the GRUU spec with the new temporary GRUU construction algorithm suggested by Ekr, along with the other comments and suggestions made on the list since -12. Please take a look at the new appendix and send any comments now, I'd like to submit in the next few days. The new text is more or less what ekr suggested, with consideration for counter rollover and clarifying how it works in a cluster environment. http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt There is one remaining open issue buried in a thread, which I will send a separate note on. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 10:58:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZb3-0001zg-Tn; Wed, 28 Mar 2007 10:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZb2-0001zR-En for sip@ietf.org; Wed, 28 Mar 2007 10:57:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZak-00039L-ND for sip@ietf.org; Wed, 28 Mar 2007 10:57:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Mar 2007 10:57:39 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2SEvbfC017565 for ; Wed, 28 Mar 2007 10:57:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2SEvLla007217 for ; Wed, 28 Mar 2007 14:57:37 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 10:57:33 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 10:57:33 -0400 Message-ID: <460A825C.4050902@cisco.com> Date: Wed, 28 Mar 2007 10:57:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 14:57:33.0247 (UTC) FILETIME=[6A3FDCF0:01C77149] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1738; t=1175093857; x=1175957857; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20One=20remaining=20GRUU=20issue=3A=20GRUUs=20for=20non-GRUU=20 UA |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=tWrsppFr4uozuyBb6wWlqp37sG4sa5fD3/rPvLHPiXI=; b=KegBPMICoMtXLRTWpZycL7NtolmB25Jjk2x7eT2XDxYnuO/xz6SAKUSbS8DnJyRK8K3kA6Q0 YZqs1Z8kCOieBBWj/gumhRBEAF/7idLtgYdAmUdOLsnPlcKBiEnASfXw; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is a debate going on buried in a separate thread that I wanted to escalate to a new post and a new thread, so folks who have not noticed the other thread can participate. Since around gruu-06, the registrar will construct a GRUU for an endpoint that includes an instance ID in its REGISTER request, even if it omitted Supported: gruu (and thus does not itself support GRUU). This allows other entities to learn the GRUU through other means, such as reg-event, and then direct a request to that UA instance, even if the UA instance itself doesn't support GRUU. A complaint has been raised that this is inconsistent. Should an entity use that GRUU, learned by reg-event, the request will be delivered to the UA instance, but it will include a non-GRUU in its Contact, and so from then on, GRUU-enabled features like transfer won't work since the UA doesn't support GRUU. The argument was made that this is effectively false advertising since GRUU isn't REALLY supported for this UA. I disagree with this perspective and believe that the current text in gruu-13 is fine. I believe our ability to generate GRUU even if the UA doesn't understand GRUU is a feature and not a bug. I'd like to settle this in the next few days so I can submit gruu-13 and we can move on to other pressing issues, like rehashing our debate on the viability of sips. Again. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 11:04:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZgt-00072p-00; Wed, 28 Mar 2007 11:03:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZgr-00070a-2N for sip@ietf.org; Wed, 28 Mar 2007 11:03:57 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZgH-0004DE-JR for sip@ietf.org; Wed, 28 Mar 2007 11:03:56 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l2SF3GSL011389; Wed, 28 Mar 2007 10:03:16 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2SF3GA10567; Wed, 28 Mar 2007 10:03:16 -0500 (CDT) Message-ID: <460A83B4.3050108@alcatel-lucent.com> Date: Wed, 28 Mar 2007 10:03:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme References: <7374777208BDC7449D5620EF9423256702F4AF1C@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256702F4AF1C@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > What are the security properties required by SIP? A stab is in S13 of domain-certs: The goals of TLS include the following security guarantees at the transport layer: Confidentiality: packets tunneled through TLS can only be read by the sender and receiver. Integrity: packets tunneled through TLS can only be modified by the sender and receiver. Authenticity: each principal is authenticated to the other as posessing a private key for which a certificate has been issued. Moreover, this certificate has not been revoked, and is backed by a certificate chain leading to a mutually trusted trust anchor. We expect that appropriate processing requirements of domain certificates will provide the following security guarantees at the application level: [...] - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 11:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaK7-0001XR-Tt; Wed, 28 Mar 2007 11:44:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaK6-0001XJ-Iy for sip@ietf.org; Wed, 28 Mar 2007 11:44:30 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWaK5-0003xP-Ac for sip@ietf.org; Wed, 28 Mar 2007 11:44:30 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2SFhlD25571; Wed, 28 Mar 2007 15:43:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Wed, 28 Mar 2007 10:43:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCA42F3@zrc2hxm0.corp.nortel.com> In-Reply-To: <91559587-CCF5-48C0-A555-30A7299B0895@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not Thread-Index: Acdw5QVuIxnRAml6SFupWGkc9+KAqwAasBWA References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> <026601c770cc$7695b330$800101df@acmepacket.com> <91559587-CCF5-48C0-A555-30A7299B0895@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, March 27, 2007 19:58 > To: Hadriel Kaplan > Cc: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF=20 > SIP List' > Subject: Re: [Sip] sips: upgrading allowed or not >=20 >=20 > On Mar 27, 2007, at 7:03 PM, Hadriel Kaplan wrote: >=20 > > I also agree upgrading should not be allowed to make life=20 > simpler, but=20 > > my concern is isn't it too late? > > > > I mean how many 3261-compliant boxes out there will=20 > retarget upgrade? =20 > > So if sips suddenly becomes a (more) popular thing, how=20 > would the UAS=20 > > know if the request traversed a 3261-only proxy which upgraded, vs.=20 > > traversed this newer proposal proxies only? > > > > It will have to do the checks no matter what, no? And the bad=20 > > scenario of sips contact can still occur. (or maybe I missed the=20 > > point) But at least if you specify NOT to do it and why in=20 > your draft=20 > > then it will help proxy makers avoid the sips contact issue. So it=20 > > still has some value. >=20 > That's the "Verifiable assertions that SIPS was used on each hop" =20 > question from the "Future work" section of the draft, right? >=20 > -- > Dean >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 11:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaRk-0006pJ-7v; Wed, 28 Mar 2007 11:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaRi-0006pD-EN for sip@ietf.org; Wed, 28 Mar 2007 11:52:22 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWaRg-0005Ox-54 for sip@ietf.org; Wed, 28 Mar 2007 11:52:22 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2SFpmD27263; Wed, 28 Mar 2007 15:51:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 10:51:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCA4327@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256702F4AF1C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdxQI3QK3cfwoyMTFC4EHHa0ODyFAABRRtgAALK/xA= References: <86slbppja1.fsf@delta.rtfm.com> <7374777208BDC7449D5620EF9423256702F4AF1C@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Chris, I have a problem with the process here. We have reached a decision many months ago. The problem has not changed. Please go back and read the archives.=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, March 28, 2007 07:50 > To: EKR > Cc: Juha Heinanen; Audet, Francois (SC100:3055); IETF SIP=20 > List; Sean Olson; Dean Willis > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 >=20 > Hi,=20 >=20 > >>The advantage of using Require/Proxy-Require (I use that as=20 > a generic=20 > >>term for a non-SIPS solution) is that it would allow the=20 > change of the >=20 > >>scheme in the network, without affecting the signalling security. > >> > >>Another advantage would be that it would be possible to also put=20 > >>requirements not related to a specific security mechanism. For=20 > >>example, if I require "security" I would reach the remote=20 > user even if >=20 > >>some hop is protected by a non-TLS mechanism (IPSEC, for example). > >=20 > >It's not clear that this is a good thing. The security > >(authentication) properties of TLS are not necessarily the same as=20 > >those offered by IPsec. >=20 > What are the security properties required by SIP? >=20 > Regards, >=20 > Christer >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 12:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWac0-0001DG-Mp; Wed, 28 Mar 2007 12:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWabz-0001DB-R9 for sip@ietf.org; Wed, 28 Mar 2007 12:02:59 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWabu-0006oZ-8F for sip@ietf.org; Wed, 28 Mar 2007 12:02:59 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C0A720A3E; Wed, 28 Mar 2007 18:02:47 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-f3-460a91a706d5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7B95A207E5; Wed, 28 Mar 2007 18:02:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 18:02:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 18:02:45 +0200 Message-ID: <7374777208BDC7449D5620EF9423256702F85CB9@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCA4327@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdxQI3QK3cfwoyMTFC4EHHa0ODyFAABRRtgAALK/xAAAC69YA== From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" X-OriginalArrivalTime: 28 Mar 2007 16:02:47.0029 (UTC) FILETIME=[870B9A50:01C77152] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois, You wrote an e-mail ([Sip] Future work in specification on SIP Security), asking to bring own ideas, but I missed the part saying that it should be about what shall be done AFTER the SIPS work is done. However, it does seem that some people (Juha etc) don't agre to the decision which was made months ago, but I will let them speak for themselves :) Regards, Christer =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 28. maaliskuuta 2007 18:51 > To: Christer Holmberg (JO/LMF) > Cc: IETF SIP List; Dean Willis > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 > Chris, >=20 > I have a problem with the process here. We have reached a=20 > decision many months ago. > The problem has not changed. >=20 > Please go back and read the archives.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, March 28, 2007 07:50 > > To: EKR > > Cc: Juha Heinanen; Audet, Francois (SC100:3055); IETF SIP=20 > List; Sean=20 > > Olson; Dean Willis > > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme > >=20 > >=20 > > Hi, > >=20 > > >>The advantage of using Require/Proxy-Require (I use that as > > a generic > > >>term for a non-SIPS solution) is that it would allow the > > change of the > >=20 > > >>scheme in the network, without affecting the signalling security. > > >> > > >>Another advantage would be that it would be possible to also put=20 > > >>requirements not related to a specific security mechanism. For=20 > > >>example, if I require "security" I would reach the remote > > user even if > >=20 > > >>some hop is protected by a non-TLS mechanism (IPSEC, for example). > > >=20 > > >It's not clear that this is a good thing. The security > > >(authentication) properties of TLS are not necessarily the same as=20 > > >those offered by IPsec. > >=20 > > What are the security properties required by SIP? > >=20 > > Regards, > >=20 > > Christer > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 13:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcAM-0004U5-Ln; Wed, 28 Mar 2007 13:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcAL-0004Tu-1b for sip@ietf.org; Wed, 28 Mar 2007 13:42:33 -0400 Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWcAJ-0002IV-Jc for sip@ietf.org; Wed, 28 Mar 2007 13:42:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Mar 2007 11:42:19 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: One remaining GRUU issue: GRUUs for non-GRUU UA Thread-Index: AcdxYG8v+zf2KOsLQBSv2Deo0ysLUg== From: "Peter Musgrave" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: sip@ietf.org Subject: [Sip] Re: One remaining GRUU issue: GRUUs for non-GRUU UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1403373151==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1403373151== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77160.3752498F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77160.3752498F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I agree this is a feature.=20 =20 I have a clarification question w.r.t 6.1 =20 In the case where a proxy targets a gruu reference to a UA which does not support gruu should the proxy keep the rule in 6.1 =20 processing proceeds as it would for any other URI present in the location service, as defined in Section 16.5 of RFC 3261, except that the "gr" parameter is not removed as part of the canonicalization process. =20 =20 So a UA which does not support gruu will get a "gr" parameter.=20 =20 1) Do we risk confusing UAs which are not supporting gruu? 2) If it's a temp-gruu reference will the UA understand it at all? (since it is only RECOMMENDED in 3261 that a UAS accept a To: header it does not understand) =20 Should a proxy which is sending to a UA which does not support gruu, strip the gr params (and replace a temp-gruu with the AOR from the UAs REGISTER) ? =20 Thanks, =20 Peter Musgrave =20 =20 ------_=_NextPart_001_01C77160.3752498F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I agree this is a feature. =

 

I have a clarification question w.r.t = 6.1

 

In the case where a proxy targets a gruu reference to = a UA which does not support gruu should the proxy keep the rule in = 6.1

 

   = processing proceeds as it would for any

   other = URI present in the location service, as defined in Section = 16.5

   of RFC = 3261, except that the "gr" parameter is not removed as part = of

   the canonicalization = process. 

 

So a UA which does not support gruu will get = a “gr” parameter.

 

1)    = Do we risk confusing UAs which are not supporting = gruu?

2)    = If it’s a temp-gruu reference will the UA understand it at all? = (since it is only RECOMMENDED in 3261

that a UAS accept a = To: header it does not understand)

 

Should a proxy which is sending to a UA which = does not support gruu, strip the gr params (and replace a temp-gruu with the = AOR from the UAs REGISTER) ?

 

Thanks,

 

Peter Musgrave

 

 

------_=_NextPart_001_01C77160.3752498F-- --===============1403373151== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1403373151==-- From sip-bounces@ietf.org Wed Mar 28 13:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcPl-0004O8-JZ; Wed, 28 Mar 2007 13:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcPk-0004O3-0R for sip@ietf.org; Wed, 28 Mar 2007 13:58:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWcPd-0004EN-Da for sip@ietf.org; Wed, 28 Mar 2007 13:58:27 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D647720577; Wed, 28 Mar 2007 19:58:18 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-32-460aacba8e92 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CD15F2013B; Wed, 28 Mar 2007 19:58:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 19:58:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 19:58:17 +0200 Message-ID: <7374777208BDC7449D5620EF9423256702F85E54@esealmw113.eemea.ericsson.se> In-Reply-To: <460A83B4.3050108@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdxSjscYe5v2SSATDyleD85MwNIgwAGDQuQ From: "Christer Holmberg \(JO/LMF\)" To: "Vijay K. Gurbani" X-OriginalArrivalTime: 28 Mar 2007 17:58:18.0245 (UTC) FILETIME=[AA5F3B50:01C77162] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I am not a security expert, but aren't the security properties rather similar for IPSEC? And, IPSEC also works for UDP. However, the point was not to compare TLS with IPSEC (IPSEC was just given as an example), but to find the signalling security requirements for SIP. Regards, Christer =20 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 > Sent: 28. maaliskuuta 2007 18:03 > To: Christer Holmberg (JO/LMF) > Cc: IETF SIP List > Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 > Christer Holmberg (JO/LMF) wrote: > > What are the security properties required by SIP? >=20 > A stab is in S13 of domain-certs: >=20 > The goals of TLS include the following security guarantees at the > transport layer: >=20 > Confidentiality: packets tunneled through TLS can only be read by > the sender and receiver. > Integrity: packets tunneled through TLS can only be=20 > modified by the > sender and receiver. > Authenticity: each principal is authenticated to the other as > posessing a private key for which a certificate has=20 > been issued. > Moreover, this certificate has not been revoked, and=20 > is backed by > a certificate chain leading to a mutually trusted trust anchor. >=20 > We expect that appropriate processing requirements of domain > certificates will provide the following security guarantees at the > application level: [...] >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 14:04:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcVa-0000Js-R4; Wed, 28 Mar 2007 14:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcVZ-0000Jn-EC for sip@ietf.org; Wed, 28 Mar 2007 14:04:29 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWcVY-0004yx-4a for sip@ietf.org; Wed, 28 Mar 2007 14:04:29 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id CE9411E8C28; Wed, 28 Mar 2007 11:03:50 -0800 (PST) To: "Christer Holmberg \(JO/LMF\)" Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme References: <7374777208BDC7449D5620EF9423256702F85E54@esealmw113.eemea.ericsson.se> From: Eric Rescorla Date: Wed, 28 Mar 2007 11:03:50 -0800 In-Reply-To: <7374777208BDC7449D5620EF9423256702F85E54@esealmw113.eemea.ericsson.se> (Christer Holmberg's message of "Wed, 28 Mar 2007 19:58:17 +0200") Message-ID: <86slbpur55.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Christer Holmberg \(JO/LMF\)" writes: > I am not a security expert, but aren't the security properties rather > similar for IPSEC? Well, it depends on exactly how you're running IPsec. Not if (for instance) you have a VPN tunnel tied up between VPN concentrators between the sites, no. > And, IPSEC also works for UDP. Cf. RFC 4347. > However, the point was not to compare TLS with IPSEC (IPSEC was just > given as an example), but to find the signalling security requirements > for SIP. Yes, and part of the object is to have some predictability about what those would be, which isn't served by saying "you must do some kind of security". -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 14:18:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWciP-0006ct-60; Wed, 28 Mar 2007 14:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWciN-0006a0-6M for sip@ietf.org; Wed, 28 Mar 2007 14:17:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWciI-0007JB-SX for sip@ietf.org; Wed, 28 Mar 2007 14:17:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F5AF21146; Wed, 28 Mar 2007 20:17:36 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-31-460ab14066e4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C5F220180; Wed, 28 Mar 2007 20:17:36 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 20:17:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 20:17:34 +0200 Message-ID: <7374777208BDC7449D5620EF9423256702F85E63@esealmw113.eemea.ericsson.se> In-Reply-To: <86slbpur55.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdxY41VBOfuloHSQDOWQ3rohannpwAACW9g From: "Christer Holmberg \(JO/LMF\)" To: "EKR" X-OriginalArrivalTime: 28 Mar 2007 18:17:36.0196 (UTC) FILETIME=[5C908840:01C77165] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I am not a security expert, but aren't the security properties rather=20 >>similar for IPSEC? >=20 >Well, it depends on exactly how you're running IPsec. Not if=20 >(for instance) you have a VPN tunnel tied up between VPN concentrators between the sites, no. >=20 >>And, IPSEC also works for UDP. >=20 >Cf. RFC 4347. >=20 >=20 >>However, the point was not to compare TLS with IPSEC (IPSEC was just=20 >>given as an example), but to find the signalling security requirements >>for SIP. >=20 >Yes, and part of the object is to have some predictability=20 >about what those would be, which isn't served by saying "you=20 >must do some kind of security".=20 Well, that "any kind of security" would of course have to be compliant with whatever security requirements we have for SIP. The security requirements COULD also be depending on the type of "link". I am sure there are environments where VPN tunnels are used, and provide sufficiant security, so should security mandated requests not be allowed to use such tunnels? The question is: IF we want to have a solution which requires security between all nodes, UA-to-UA, will a you-must-use-TLS-only solution be feasible? Calls could fail, OR people could choose to use other security mechanisms anyway... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 14:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcuk-0007wa-G2; Wed, 28 Mar 2007 14:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcuj-0007rZ-1t for sip@ietf.org; Wed, 28 Mar 2007 14:30:29 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWcpW-00006o-Ky for sip@ietf.org; Wed, 28 Mar 2007 14:25:10 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2SIP4x25395; Wed, 28 Mar 2007 18:25:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 13:25:03 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611FA920B@zrc2hxm2.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256702F85E54@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme thread-index: AcdxSjscYe5v2SSATDyleD85MwNIgwAGDQuQAAC7QqA= From: "Samir Srivastava" To: "Christer Holmberg \(JO/LMF\)" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The worst part of this, SIPS will enforce the double encryption between two SIP addressable entities if there is IPSEC tunnel between them. I agreed only on the BCP/INFORMATIONAL doc.=20 There has been earlier poll on the list before San Diego, what people wanted. I have discussed in details the demerits of SIPS during that time period. Please wait for the next version of the cipher-suite draft, before proceeding to make SIPS as STANDARDS track document.=20 Thx Samir > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, March 28, 2007 10:58 AM > To: Vijay K. Gurbani > Cc: IETF SIP List > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 >=20 > Hi, >=20 > I am not a security expert, but aren't the security properties rather > similar for IPSEC? And, IPSEC also works for UDP. >=20 > However, the point was not to compare TLS with IPSEC (IPSEC was just > given as an example), but to find the signalling security requirements > for SIP. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > Sent: 28. maaliskuuta 2007 18:03 > > To: Christer Holmberg (JO/LMF) > > Cc: IETF SIP List > > Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme > > > > Christer Holmberg (JO/LMF) wrote: > > > What are the security properties required by SIP? > > > > A stab is in S13 of domain-certs: > > > > The goals of TLS include the following security guarantees at the > > transport layer: > > > > Confidentiality: packets tunneled through TLS can only be read by > > the sender and receiver. > > Integrity: packets tunneled through TLS can only be > > modified by the > > sender and receiver. > > Authenticity: each principal is authenticated to the other as > > posessing a private key for which a certificate has > > been issued. > > Moreover, this certificate has not been revoked, and > > is backed by > > a certificate chain leading to a mutually trusted trust anchor. > > > > We expect that appropriate processing requirements of domain > > certificates will provide the following security guarantees at the > > application level: [...] > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > WWW: http://www.alcatel-lucent.com/bell-labs > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 15:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWdW2-0007ww-4i; Wed, 28 Mar 2007 15:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWdW0-0007vw-HN for sip@ietf.org; Wed, 28 Mar 2007 15:09:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWdV0-0000jm-5j for sip@ietf.org; Wed, 28 Mar 2007 15:08:03 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 28 Mar 2007 12:07:59 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2SJ7vom016790; Wed, 28 Mar 2007 12:07:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2SJ7exH005711; Wed, 28 Mar 2007 19:07:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 15:07:53 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 15:07:53 -0400 Message-ID: <460ABD08.6070904@cisco.com> Date: Wed, 28 Mar 2007 15:07:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Musgrave References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Mar 2007 19:07:53.0268 (UTC) FILETIME=[62E12F40:01C7716C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1499; t=1175108877; x=1175972877; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20One=20remaining=20GRUU=20issue=3A=20GRUUs=20for=20non -GRUU=20UA |Sender:=20; bh=Bka1NDoVeyYAmBKMtccg/2cUEhbDaXmoLq1H7Q+JNj0=; b=wrpTFgXs6AScyrUydXF0JdIGnKNUAmEskgkUZXAqlolYqa6LziDimHRTd2nmeMyp6mnkVmST ACF0P0sf5atn7kz/0HOTobmhPRbqdmS96m9PNcNLD3KtszF1ujv9i1fL; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org Subject: [Sip] Re: One remaining GRUU issue: GRUUs for non-GRUU UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Peter Musgrave wrote: > Hi, > > > > I agree this is a feature. > > > > I have a clarification question w.r.t 6.1 > > > > In the case where a proxy targets a gruu reference to a UA which does > not support gruu should the proxy keep the rule in 6.1 > > > > processing proceeds as it would for any > > other URI present in the location service, as defined in Section 16.5 > > of RFC 3261, except that the "gr" parameter is not removed as part of > > the canonicalization process. > > > > So a UA which does not support gruu will get a gr parameter. No, sorry this is confusing. Its not removed as part of the canonicalization process; that process is used to look up the gruu to obtain the matching registration. However once you find a match you rewrite the r-uri with the resulting contact and of course the gr parameter is not there in the registered contact. So a UA that doesn't support GRUU will never see a GRUU in the r-uri, it'll always be its registered contact. SOmeone else had the same comment privately so I suspect I need to clarify this text. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 15:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWddH-0003mn-PF; Wed, 28 Mar 2007 15:16:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWddF-0003me-UL for sip@ietf.org; Wed, 28 Mar 2007 15:16:29 -0400 Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWddB-0002eY-GT for sip@ietf.org; Wed, 28 Mar 2007 15:16:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Mar 2007 13:16:15 -0600 Message-ID: In-Reply-To: <460ABD08.6070904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One remaining GRUU issue: GRUUs for non-GRUU UA Thread-Index: AcdxbCo3+GQvRivSSHGnyzYFkgPrkwAANEtw References: <460ABD08.6070904@cisco.com> From: "Peter Musgrave" To: "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org Subject: [Sip] RE: One remaining GRUU issue: GRUUs for non-GRUU UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok. So that fixes the r-uri If the To: header has a gr in it's URI what happens to that as it is proxied? I am concerned that if it's a temp-gruu the non-gruu UA recipient may decide to reject it. Peter Musgrave -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Wednesday, March 28, 2007 3:08 PM To: Peter Musgrave Cc: sip@ietf.org Subject: Re: One remaining GRUU issue: GRUUs for non-GRUU UA inline. Peter Musgrave wrote: > Hi, >=20 > =20 >=20 > I agree this is a feature. >=20 > =20 >=20 > I have a clarification question w.r.t 6.1 >=20 > =20 >=20 > In the case where a proxy targets a gruu reference to a UA which does=20 > not support gruu should the proxy keep the rule in 6.1 >=20 > =20 >=20 > processing proceeds as it would for any >=20 > other URI present in the location service, as defined in Section 16.5 >=20 > of RFC 3261, except that the "gr" parameter is not removed as part of >=20 > the canonicalization process.=20 >=20 > =20 >=20 > So a UA which does not support gruu will get a "gr" parameter. No, sorry this is confusing. Its not removed as part of the canonicalization process; that process is used to look up the gruu to obtain the matching registration. However=20 once you find a match you rewrite the r-uri with the resulting contact=20 and of course the gr parameter is not there in the registered contact.=20 So a UA that doesn't support GRUU will never see a GRUU in the r-uri,=20 it'll always be its registered contact. SOmeone else had the same comment privately so I suspect I need to=20 clarify this text. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 15:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWeAL-0000Ek-BE; Wed, 28 Mar 2007 15:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWeAD-000096-5V; Wed, 28 Mar 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWeAC-0007jY-Kn; Wed, 28 Mar 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8DB48175AD; Wed, 28 Mar 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HWe9i-0004Zs-B4; Wed, 28 Mar 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Mar 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Author(s) : R. Sparks, et al. Filename : draft-ietf-sip-fork-loop-fix-05.txt Pages : 13 Date : 2007-3-28 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-fork-loop-fix-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-fork-loop-fix-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: <2007-3-28100721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-fork-loop-fix-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-28100721.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Mar 28 16:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWex3-0005OD-O0; Wed, 28 Mar 2007 16:41:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWex0-0005Nw-3c for sip@ietf.org; Wed, 28 Mar 2007 16:40:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWeww-0007dc-La for sip@ietf.org; Wed, 28 Mar 2007 16:40:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2007 16:40:53 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2SKeqVN021259; Wed, 28 Mar 2007 16:40:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2SKeWHF026632; Wed, 28 Mar 2007 20:40:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 16:40:18 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 16:40:18 -0400 Message-ID: <460AD2B1.3060205@cisco.com> Date: Wed, 28 Mar 2007 16:40:17 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Musgrave References: <460ABD08.6070904@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 20:40:18.0188 (UTC) FILETIME=[4BE8D4C0:01C77179] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2271; t=1175114452; x=1175978452; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20One=20remaining=20GRUU=20issue=3A=20GRUUs=20for=20non -GRUU=20UA |Sender:=20 |To:=20Peter=20Musgrave=20; bh=vJCTe/Pry60+55FFE8DI7OLBSoubqvjQ6nGOA4d2sec=; b=b9738iCAeHGU8oc/lfdQulFtl9ZouiBC5thfzDE4ofqyOT5AydXzVhxQPOHZkALch/syNYwB Y8VePC48+Ad+fM+7t5h5Kep3kEpDO33bFHVWBXKhRy+d/RsqzjolQ4g2; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] Re: One remaining GRUU issue: GRUUs for non-GRUU UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The To header field would still be the GRUU. However this is no different than a UA which receives a request because a call was forwarded, the TO header won't match its own identity. -Jonathan R. Peter Musgrave wrote: > Ok. So that fixes the r-uri > > If the To: header has a gr in it's URI what happens to that as it is > proxied? I am concerned that if it's a temp-gruu the non-gruu UA > recipient may decide to reject it. > > Peter Musgrave > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, March 28, 2007 3:08 PM > To: Peter Musgrave > Cc: sip@ietf.org > Subject: Re: One remaining GRUU issue: GRUUs for non-GRUU UA > > inline. > > Peter Musgrave wrote: > > >>Hi, >> >> >> >>I agree this is a feature. >> >> >> >>I have a clarification question w.r.t 6.1 >> >> >> >>In the case where a proxy targets a gruu reference to a UA which does >>not support gruu should the proxy keep the rule in 6.1 >> >> >> >> processing proceeds as it would for any >> >> other URI present in the location service, as defined in Section > > 16.5 > >> of RFC 3261, except that the "gr" parameter is not removed as part > > of > >> the canonicalization process. >> >> >> >>So a UA which does not support gruu will get a "gr" parameter. > > > No, sorry this is confusing. > > Its not removed as part of the canonicalization process; that process is > > used to look up the gruu to obtain the matching registration. However > once you find a match you rewrite the r-uri with the resulting contact > and of course the gr parameter is not there in the registered contact. > So a UA that doesn't support GRUU will never see a GRUU in the r-uri, > it'll always be its registered contact. > > SOmeone else had the same comment privately so I suspect I need to > clarify this text. > > -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 16:49:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWf5A-0008Qq-19; Wed, 28 Mar 2007 16:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWf55-0008Pu-KJ for sip@ietf.org; Wed, 28 Mar 2007 16:49:19 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWf53-00069k-U7 for sip@ietf.org; Wed, 28 Mar 2007 16:49:19 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2SKnH9s027104 for ; Wed, 28 Mar 2007 15:49:17 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 15:49:17 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 22:49:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-05.txt Date: Wed, 28 Mar 2007 22:49:14 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180F20492@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-05.txt Thread-Index: Acdxcpd6dzn9qc9QQEyXCRIMr+ze4QAB3zow References: From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 28 Mar 2007 20:49:15.0395 (UTC) FILETIME=[8C1C1D30:01C7717A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have just made the publication request on this document.=20 The following is the submitted PROTO writeup. --------------------------------------------------------------------- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-fork- loop-fix-05.txt: " Addressing an Amplification Vulnerability in=20 Session Initiation Protocol (SIP) Forking Proxies" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication as a proposed standard. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-lawrence-maxforward-problems-00 was submitted 16th October 2005=20 and expired 19th April 2006. * draft-ietf-sip-fork-loop-fix-00 was submitted 1st March 2006 and expired on 1st September 2006. * draft-ietf-sip-fork-loop-fix-01 was submitted 4th April 2006 and expired on 4th October 2006. * draft-ietf-sip-fork-loop-fix-02 was submitted 27th June 2006 and expired on 27th December 2006. * draft-ietf-sip-fork-loop-fix-03 was submitted 7th September 2006 and=20 expired on 7th March 2007. * draft-ietf-sip-fork-loop-fix-04 was submitted 21st October 2006 and=20 will expire on 24th April 2007. * draft-ietf-sip-fork-loop-fix-05 was submitted 7th March 2007 and will=20 expire on 8th September 2007. WGLC was initiated in the SIP WG on draft-ietf-sip-fork-loop-fix-01 on=20 10th April 2006 with comments requested by 7th May 2006. Review was made and comments were received from: Christer Holmberg, Jonathan=20 Rosenberg, Vijay Gurbani, Cullen Jennings, Jeroen van Bemmel, Ravishankar=20 Shiroor, Dale Worley, Scott Lawrence, Samir Srivastava, Peter Cordell,=20 Thomas Froment, Juha Heinanen, Thomas Leseney, David Benoit, Kasturi=20 Narayanan, Atul Kumar Jha, Theo Zourzouvillys, Paul Kyzivat, Dean Willis,=20 Michael Thomas, Eric Rescorla. Key discussion issues have been: * Selection of a hash algorithm to be used. Section 4.2.3 of the=20 document indicates the results of the discussion in this area. * Identification of a more optimal loop detection algorithm (see draft- campen-sipping-stack-loop-detect-00) which was not proceeded with, as=20 it could not be shown to provide significant improvements for a=20 standards track solution. Some elements of the original proposal were split out in draft-sparks- sipping-max-breadth-00 and draft-campen-sipping-stack-loop-detect-00. There=20 was also further input in draft-srivastava-sipping-loop-avoidance-00. These=20 documents have not been proceeded with. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document defines mechanisms that are entirely internal to the Session=20 Initiation Protocol (SIP). The document shepherd considers that no external=20 review from an external specialist is necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document provides a correction to the existing SIP protocol defined in=20 RFC 3261. The problem has been identified as part of the SIPit=20 interoperability testing. The document shepherd has no concerns with the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The proposal has had wide discussion in all aspects in the WG and key be represented as having consensus amongst all key individuals. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Normally SIP documents should conform to RFC 4485. However as this document=20 identifies a correction to RFC 3261, it does not need to follow those=20 guidelines, but merely has to state the changed to RFC 3261. There are no conformance issues with RFC 3427. For ID-NITS the checks against idnits 2.03.16 report no NITS found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has appropriately split its references into normative and=20 informative references. All the normative references are now published=20 standards track RFCs. There is one informative reference (draft-ietf-sip-outbound) that is not yet=20 published. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? There are no IANA considerations for this document, and none are needed. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no entries written in formal language.=20 (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document normatively updates RFC 3261, the Session Initiation Protocol=20 (SIP), to address a security vulnerability identified in SIP proxy behavior. =20 This vulnerability enables an attack against SIP networks where a small=20 number of legitimate, even authorized, SIP requests can stimulate massive=20 amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when=20 they fork requests (that is, forward a request to more than one destination). =20 It also corrects and clarifies the description of the loop-detection=20 algorithm such proxies are required to implement. Working Group Summary The document was produced by the SIP working group. There is consensus in=20 the WG to publish this document. Document Quality The document has been produced as a result of an issue identified during SIPit interoperability testing. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is=20 the responsible Area Director. ------------------------------------------------------------------------ - Regards Keith=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, March 28, 2007 8:50 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-05.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : Addressing an Amplification Vulnerability in > Session Initiation Protocol (SIP) Forking=20 > Proxies > Author(s) : R. Sparks, et al. > Filename : draft-ietf-sip-fork-loop-fix-05.txt > Pages : 13 > Date : 2007-3-28 > =09 > This document normatively updates RFC 3261, the Session Initiation > Protocol (SIP), to address a security vulnerability=20 > identified in SIP > proxy behavior. This vulnerability enables an attack against SIP > networks where a small number of legitimate, even authorized, SIP > requests can stimulate massive amounts of proxy-to-proxy traffic. >=20 > This document strengthens loop-detection requirements on=20 > SIP proxies > when they fork requests (that is, forward a request to=20 > more than one > destination). It also corrects and clarifies the=20 > description of the > loop-detection algorithm such proxies are required to implement. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-f > ix-05.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-fork-loop-fix-05.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-05.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 18:09:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgHy-0000p2-50; Wed, 28 Mar 2007 18:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgHv-0000oS-OG for sip@ietf.org; Wed, 28 Mar 2007 18:06:39 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWgHu-0000om-If for sip@ietf.org; Wed, 28 Mar 2007 18:06:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007032822063701400bni9pe>; Wed, 28 Mar 2007 22:06:38 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2SM6bLv001647 for ; Wed, 28 Mar 2007 17:06:37 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2SM6bsq001643; Wed, 28 Mar 2007 17:06:37 -0500 Date: Wed, 28 Mar 2007 17:06:37 -0500 Message-Id: <200703282206.l2SM6bsq001643@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (PMusgrave@newheights.com) Subject: Re: [Sip] RE: One remaining GRUU issue: GRUUs for non-GRUU UA References: <460ABD08.6070904@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Peter Musgrave" If the To: header has a gr in it's URI what happens to that as it is proxied? I am concerned that if it's a temp-gruu the non-gruu UA recipient may decide to reject it. But it will often happen that the To URI has no visible correspondence to the request-URI. A UA should never reject a request based on the To URI, unless it is syntactically invalid. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 18:12:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgNM-00079d-Rc; Wed, 28 Mar 2007 18:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgNK-00078S-K2 for sip@ietf.org; Wed, 28 Mar 2007 18:12:14 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWgNJ-0001nP-Cq for sip@ietf.org; Wed, 28 Mar 2007 18:12:14 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc13) with ESMTP id <20070328221212b13009jr0ne>; Wed, 28 Mar 2007 22:12:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2SMCBLv002090 for ; Wed, 28 Mar 2007 17:12:11 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2SMCBEL002086; Wed, 28 Mar 2007 17:12:11 -0500 Date: Wed, 28 Mar 2007 17:12:11 -0500 Message-Id: <200703282212.l2SMCBEL002086@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <460A825C.4050902@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA References: <460A825C.4050902@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg A complaint has been raised that this is inconsistent. Should an entity use that GRUU, learned by reg-event, the request will be delivered to the UA instance, but [the response] will include a non-GRUU in its Contact, and so from then on, GRUU-enabled features like transfer won't work since the UA doesn't support GRUU. The argument was made that this is effectively false advertising since GRUU isn't REALLY supported for this UA. I agree with you and Peter that this is not a bug. 1) This situation causes no additional failures relative to the situation where the registrar does not construct a GRUU for the non-GRUU-supporting UA. 2) It's not false advertising if the UA making the initial contact is paying attention -- the response does not contain "Supported: gruu", and the Contact it provides in the response is self-evidently not a GRUU (due to the absence of the "gr" parameter). 3) Indeed, if the UA making the contact desires a GRUU for the other UA, and the Contact in the response is not a GRUU, *the UA already has a GRUU for the other UA in hand*. Being self-evidently a GRUU, it can be safely used for all GRUUish needs. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From Joslyn.Konrad@BOARDSOLUTION.RU Wed Mar 28 18:30:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgfB-0001Ra-70 for sip-archive@lists.ietf.org; Wed, 28 Mar 2007 18:30:41 -0400 Received: from [87.110.2.192] (helo=[87.110.2.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWgf7-0004kC-LA for sip-archive@lists.ietf.org; Wed, 28 Mar 2007 18:30:40 -0400 Received: from ahil4es-bhnx38r by BOARDSOLUTION.RU with ASMTP id 32FC4008 for ; Fri, 11 Mar 2005 06:03:25 -0800 Received: from ahil4es-bhnx38r ([107.190.109.170]) by BOARDSOLUTION.RU with ESMTP id 4483D290C180 for ; Fri, 11 Mar 2005 06:03:25 -0800 Message-ID: <000701c52643$0dbbc140$c0026e57@ahil4esbhnx38r> From: "pros" To: sip-archive@lists.ietf.org Subject: Webcam Check daily follow Date: Fri, 11 Mar 2005 06:03:08 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C525FF.FF988140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c ------=_NextPart_000_0003_01C525FF.FF988140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C525FF.FF988140" ------=_NextPart_001_0004_01C525FF.FF988140 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Planlg, att wnew band gsm. Website choice slightly larger load contains? Action wednesday th deeper driving decisions. Led virginia trying steer sale, kind. Hill suggesting led virginia. Acfivation sureemens actkvation siwmens actication siaumens vation. = Hours, firm secunia cto same, flaw existed, browser, apparently. Auction bonus mylaptop handhelds needing chance month per? Jobnews = loginad carexperts homesell valuesad rentalrent. Activatiin sismens cideemens siemions siemsns activagion siemouns = activtaion sieemns. Allowed thingsif banning owning ballclubs, just they = few woowoo. Review march, linux ed unixtype, operating system! Pentium earphone pass friendly buzz, hard, period instantly log. Pla = saemens activatoin activztion activatin plarn actevation. Guides books monitors mp networking albums archive. Events movies bars clubsad noticesad jobpost jobnews loginad, = carexperts. Letter editor know reports rolls. Pm, comcast, sportsnet newsfood. Feeling, insecure despite deepening = measures companys had browsers according? Automatic november wars = dominant market although efforts. ------=_NextPart_001_0004_01C525FF.FF988140 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
3D""
Planlg, att wnew band gsm. Website = choice slightly=20 larger load contains?
Action wednesday th deeper driving = decisions.
Led virginia trying steer sale, kind. = Hill=20 suggesting led virginia.
Acfivation sureemens actkvation siwmens = actication=20 siaumens vation. Hours, firm secunia cto same, flaw existed, browser, = apparently.
Auction bonus mylaptop handhelds = needing chance=20 month per? Jobnews loginad carexperts homesell valuesad = rentalrent.
Activatiin sismens cideemens siemions = siemsns=20 activagion siemouns activtaion sieemns. Allowed thingsif banning owning=20 ballclubs, just they few woowoo. Review march, linux ed unixtype, = operating system!
Pentium earphone pass friendly buzz, = hard, period=20 instantly log. Pla saemens activatoin activztion activatin plarn = actevation.
Guides books monitors mp networking = albums archive.
Events movies bars clubsad noticesad = jobpost=20 jobnews loginad, carexperts. Letter editor know reports = rolls.
Pm, comcast, sportsnet newsfood. = Feeling, insecure=20 despite deepening measures companys had browsers according? Automatic = november=20 wars dominant market although efforts.
 
 
------=_NextPart_001_0004_01C525FF.FF988140-- ------=_NextPart_000_0003_01C525FF.FF988140 Content-Type: image/gif; name="tourGet.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c52643$0dbbc140$c0026e57@ahil4esbhnx38r> R0lGODlhYAH0AIcAAAAAAHEAAAB7AICMAAANhHgOiQmEcsCytr7Oza284UMRC10XAHkgBaQiAM4X DtwVBwc4By5CC0pDAGVJBoMzDaZEAM40BtZEAAdmACRgAEFjAGtgDIpSAZFZAMdZCdpcAAB/CBON AD2IDGqBAYZ/ApZ5ALeKAN94AAScAiStATOXAGaTA3SdAKuaALmoANedAAi8ACK8DUu2CWTNCoK2 CJvIAMK+De2/BQXmABLsAEniAGXaAITdAJHdALnlANzlCQENPCEJRzsAMm4ASYcATasMM7gARO0A SAArRiwTM0EZM1knOYcoNaYrM8kgS+sjTQNONy0+TU5IO2c2MYVIQ6tCMrc5PNk4SwBUPRhhNjNs TlRlTYhsEpZrQ7xaOellOwCBRCFyQk2CSFZ0M3R0NKJ4Sbt+MuN5PgCaRy6SNjGuRmCUPIWaRJ2n O8CoNteuOwPHNxa4Tk7OM2PBMnzAPqa2Nc29S9jFNQziTRPdSEHUNVXeNnLWOJnZN8bbR9fYMgAA iCQKfT4Ch2sDfYQJdJwJgsMKhuEAjQAocx8pfTothl8fe38Se6ISc7oUie4geQA2fyw2hE1FhG4z jXxKjZVNibg2eN9JdQ1ThxtRhjVehF1SfHNYhphnfLNTe9JSiAB0fxJ7fDh5dGV7c4F0ipV3esOE gtmGfQ6gcxGod06lf2qpeYChdJWfg7iTh+2RdwO5hx3BjjS1e2vNhYy5hJa7jri+du7MjADkfhLV h0LTd1nZhH/kdp3UjLbscujfeAAIziEAzTILxl0Eu30HzKQAwbsIwesAug4utxomtDwdw1YeyHIp s5sfwrobvOgRwQBOuB0/vzVMsl81u4A3yKdNu79HuNhAyQBkxhVuwTlsxWhkxIdcw6BqxclZt+pm zQhzsR50s0qIsleKxHp6xp5xxL6HvOiHvACrzBemvUKZyWGbsneaxKiTxsGkwtSpvgzHxxy0s0vL vFfJtHSyvKLBu/Hw+5efpXOCef8ABQH/AP/xAwAK+P4A/wf/////9iH5BACU8JQALAAAAABgAfQA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqtPevo8ePIEOKHEmypMmTKFOqXMmypcuX KzfKnEmzps2bOHPq3Mmzp8+fQIMKHcoQptGjSJMqXcq0qdOnUJ8SnSo0qtWrWLNq7Ui1q9evYMOK 5bi1rNmzaNOqvTq2LdC1cOPKPeu2rt27eOfq3YsUr9+7fAMLFvm3sOHDiDcOXsy4sePH/xJLnky5 suXLmDNr3sy5s+fPoP9CHk26tOmYoVOrlni6teulq2PjfE2bq+zbuHPr3s3bbu3SvYMLH068uPHj yCf+Xs68ufPn0KNLN6kagPXr12Nbnzl9sMXsBMEP/8S+XaD4m+Sx4z1vnnxB9/bYK+ze+nv58ffj p8ev3iB7+QwB2FZ//O2nX3r5JVeXUdd91KBH2P3zoIQIgjRhRxemlKFSGzIYIYQTPthgevR1d5F4 5wkIHoHtAcDfRP+Vh+J2CIZnoH0p5rciggkuVKJpFwUg5EBCBjBQA0gmtMCSBC25QEFFChSlRDG6 eOBATmapJZFFTgmllwyBqcCYCghEZplSdglmVT9GdVE+cAoEZz4EkZmQnQOdaaOLAoY55J4tDuTA oIQWOmiBVxbYY0LnqdnlnWMq6NdRSDbQUaUeFVlShhk6+pKTIBHakaijimrqoJkK2ZGml1aKaUqv ev9kKKkhkdnmrS2NaJ1HoJJk60e/gvjhSXN6VOxHrLL6T7KqKvtrsA9E61KvqzKrakhrNpSkpIad GWme3yI0Z0HjkltuQ05iySRBU3rZ7pBelnvujQ3hmaaRXOJL0KyE+qkvt37RWylBA9/LbraJNlSo PQsTFO0DAj185LYDF3wli/Z4+1C/L3a8L7+HKrQuwD0hxcDJKH9UaKmosiwrrSq3rBIENNdMc6j8 evTsmP8Em7NIwZ5Ea8Z46lkQyijbkzTJYCVlc0hII42so9dCfbJLUYtEwdZcU+AR1x2BDXZHHJRt NkhRX31S12P/Y/PTIInNttdaMc2TzQdhoLfeee//vTdCNbv190EoFG64Q4YnTpDffBsUuD1v2y25 QAJU7tbhkzONq1U4dL7556A3B8PooZdu+mmVC/B55qyzfnparef1+uy0YxW7ZrXnrvvuvPfuO0m7 KkUAASXxw09j5JWE0KI1wdeQjlYuBMT01AcYfXBKAQPMUsYXf/xiwVPIUvhMHSTj9QpB/xDz/qHP G4cALDX8pvEPRr74Kt0fVfj6izS9g/VDSf9EMkDQZQRj1AMCRDB2oPucb0/Rc95AjMeP9rnPfO67 j/Y2+B6MUZAgG9QeQRLYkOkNxIQDGd7wCoJCgbTwIBYKIIaG9Q/t1Q4jNLpeDtfHJ/SJ0B4/tAcK /1u4Q4Go0B4rHIgIgyhEBb4QIUwUSBAl+EAlAgOIV2yRA3v4vAhGL4lJbI+NeNhBLrpQgbcbo/oi UkQxutGIR3TjFt+4qCqmL4Ne1A9+9ijHPM7RIf+YXyCJB6IZAvCQKRGkRwSpyAKuDkdV4iGL/qhF Pv6RkhC8YPs2+UY+6lGLOrxgn8qYIDt+spMLKaWVMNmbo/BPhoYUYABfWUhhzbJ+tMSfLgEIS/rF EICcPKV82Mc+NaLPlGvsYgfpqMnceAiR0PRlLXV5P/IFL5fYvGUsR+JJVQbzknlcXjPHeMpPJrOc qTzmKsf5PphY85aOjOY7abhLCn3omjKkJz3pt/+h/pHIltGcYTynOU9YvtMjdySQHYt5m9859KEQ jahEJ9qYNEqKohW1qEY3ylGfYPSjIA2pSEXa0eKMNCQlzclJX5PSlmLvJRAISUxLooCmVA1bWEne SnfqoJD08ipe29pa6EY7l1oEBQVB6k8wMBCmCsWpRrUoBAgy1YF0DgcFEUBSlUqQ0TmkqgIBq0C4 SjnLhRVyVYVBVx+iVoJo1axUFWtUi6NVylF1IGKFKuTO2lSB6DUhf9WrXpXKVcvVlaxkXQhWF+dU wfp1rp5hEIR6iqGPqK4jlwXJTN0mQAt9ZLOz9AgMOjJazJp2ZiDJrGqBBNmIHGW0pfUIDmRLWQn/ iQQD/9BbSnD7Ed6e9h8o8EhwfztZ26LWsh7JrD4Q2lrOHGW2s/1IdP8x3X9k9qekU0lsSfuR4XK2 I5v1rnSri5LNgtcj4SVgSpobmrbela92hS9YI9iQusZ3PPg1D14P4lWIyBWsYHWve9npFp6aBQgE rOZHwMDgGP50JAxuMEgQLCzjZhYkYFBJ6irnkQx3xMMCNbCISUPIx7D3xA9Bo+xGzBjiqFgyLNYL cQiMkBjb+MZwQXGNcczjH+n4x5bpsZCH7FAge4XI0THyWEZpPRq/Bcn1WQ9D0+lkC5aRlFscZyR9 A2WX6LQpHcrfQEfCqYKG6Mu8dHCXncMjp4RZ/0NjTnA+w9fAhPHIyoFS8mWYjMMpJ7QiMwqlJnfU I0Lr+cgeerAs41chW3YIzSGu8KIlbU/gzVPNb2bJoTHiyjiLhGpq0pm3eAasUYMkaEGjKalRTWqR UOsfWXJwptcMO4uAuk7hIhqaQNawOrOoX73WdUXSZQ9i22NNp251R1LtKVo3B9SUrrQ9Gb2rCSlL WbGKVc+U3RJNKethJTmWseDE3GMjbNOVIdC79MUxYIfM3PryksQiFq2D/Usio27SyA5yLjnFySD2 Qndm3PUnguMrSl4ytrHP1W+OUSTf6npSxD1W54IEPMgkrci8B7Jxezys4wWr2LaKva4s5ctIj/+i uMMZ8vF6g+tbRiO5xGU+c1yj6SHOzopFkDYQnvc8anGtauAep7S0MaAg/LJ4ri++kGCD8jy8PgjT Bc4mmLwNbh/pGkj21hGucz1sc9Oa1jV7M6NIzaf7dNvVyy2QpVF9KkhZu0g2nPO6w4Qno3Pv2/cO w6zUzO6AHwyHA0/49eokdXxPfN+vMmueKv4uUIDC4y8i5MlbvmS0vvxXCs/5nDe+8wbMDZ+LAvra /XPSalGhCkVCwe4lUpEdUb3spbP3GjXkg0HhEfpkH0aFqB7LDNQ8YrITfLDYviBxjGNC3ad84Ycl 0ZEGX7X1N6xMp73RbHf+k18iold+ucz9hPT/53XVywtZf4BtdszboV/905v/9NOm4fjTH31py1mf +PS0zrXPRnodP0c9JGh5RhF3NoAJY0FUlGWl9xzwV2lnBk9kNn2fZxKN9n6K9oCWJkP8ZxgqUkdZ Jk4ShCOJAoCM8oEguIFEAX1ytoL1x0v6dxLkJ1C49GYYGIGKtoBrIYIYJEpZFoCI0kmjR3w3Ymgl mEMmOHooeBMqiHY/ZYHyh332x09QSH9ROIVQmGNJ+BBTB29Sl2u65oVfeHMUcWtfknL5QhbLdia1 4i04SHjK0oZw+BTiRhdZyF7n5lpxmId6uId82Id+2Hl1GIiCiGgw+IeN4VuuNDvmxWIWAVWB/9U4 9gCJVkUQi7UQf2UR9nUR+pAaKLFcoOdd4lVasUVtIDFc4qUVi2h1cEFeITFdsFVaeCVXCkF0ioMR NPMTfKJfTSWJB5GJiBcWAjYQmZhf8eFW97UQYoWEtGhVnROLcvWLkTg4eqd3CIE5B0gTZmVfQvc8 uhiMF9FW1JgTtziO8pU+kzgbRhFc3pWKHSFe4sVoKRFbp2gSolhc1nWP1EVbp3VZmzVT08WKkVEQ WLVY9DUQ/SUQVxUexBg9XAVg5ZhK+eWNlViJaFVVTAWJshiNl8hfeXdlxYhfixWSfAVWb6WNt6iL Y6FWA4YQvkhODSFWktcQMWkPM2lf1wMHAv+BkyhpJd5oD+A4EJtCWTJEYRQWWh0BB+iVlOfFXUwJ YiBGErFVWv3YERT2D1XpYR42eJfVS1NJgfaIlP8AlkY5U2QJXmVnlkuJj8k1GBkGYhf2EVVplaml EnGpliVRlVW5Wh0mYZXVl3r5D22pIXD5Px5Rl4D5YQsGl3LZYYyJmIfpmAF5EGAwEJMpRCd0mSqW mfdVVwVZV8O4PPlVkPZQmZWJRqbpQpf5kar5Ysf4FQSARClEEK+JmrQZmw8xmyPEELi5m7ZZm2hU kLyZQri5EFnkmy4UEqunmIW5mFS5SM7ZESGEEhtUQ1RJPcuJl8vJnFWZnFZJmIXYlyVWYgj/hp2L uZ2KtD3QmZ3daZh6UZet54IhwZ4kgZ41ZEMosXqEVGKwxJ3/QEH9WZ3eSZ0pQZ8d4Z/peaDf8599 aY+xl0hMkaCB9Jz0SaATpp7z6RHoaZTbtBIaeoOlR6FHMZ3RZlCe9Z1LYVDVFqENShL8mYFzBo8L yhIT+pz7p1FV5pq9JxlVdqOD+B605qEMaogm4hlOxqNNI6ROkXiF16M6ihxIuhU9YaRMCproIaUH 5GcQsRVAahZbqjyrYaXcaBNgikHmqJCqKWV+tmUbMaZR2hU8SoLvgR4yYUb+EadnymkqSIoLCqQd uqfXtEsW2ILqhUtpVlmXxn1y0aV7Olnw/wSBlNZ433eoXhmjhiqUc0Go+IOpxhWUm9qnM9iXRll+ siQ+mvqpxhWqtWWD0cZ9f+qnhDpmfWqPpcqolGqinUqrtppPMTqBOVVcqFqrTFhbGnqrp5qqm8qp mPqrxUqsxwo8spqIs9qsrcqpzEqsmiqtHCqsQUqtxyp/zaoWyhqt1Cquugqq1GesZAaqi2qtCvat 6lVZKEmAZqqaOkSMjLKQ87pOx1SnDlGvO7k++Wqvq9QVN4cm8XZyXXQ9doImYniw9GqnGROmA3ts RCIlFfuwFntv92qxHFsR/9IAR1In+eWuIfFqAaCtzPpTJ4sSlpIpLrtsKlFTMMugAbQAvP8CGx4L LxgrpiJrJoLybgHnAOgiEBI3c+JBJ3LycubiEEI7sz1zFA6AsjqzrkgxLEHTsi6TEvmQbDLrtCfh KsbqoYoKeFGbEitbLWcLE12LtitrbS/7pA+1tXBbFijGplOqeHZ7t4A0tyCht37rI3p4O3w7uIQ7 GjiRWEQXIM6UiEy5Em9JEogYF/rHjupXEQd5EBT5kXkbFJ8JaDghVrlSFpH7EgBpEpQrHa8oEjFl XtdaEttlOCmROqDjWzIEu4YaQLZrusIFXPM4En9pFKn4d6SVXcL7I/9YorXbjru1lvkDrJ7Vurlr Xnk3XpmLEFA1VSdpkHpnjR35g6ppX5z/ObF3ClgDUThj1RCVuJEQcVXNeL72oFSfubk/YRQXVr+y W5gBahL1K5jO+xGR9w//CwWi1bix+g+whRKZlV2juKCwtZkODF+kmZqWmZMOAb7C2GRnlb2jyWAA u1/wNYwZCRgw8ZRO2ZiI+ZT6W6EnUcImQZTNyazkqZ0qwcKPScNxiZUmDGJ4GaAx3KVuybwmocMu LMMo8ZQx/Jj922IVMZy4+WKaOcG6aRCseRDBWaYTW8VY3JtoOBIxPMTMWWKDBMbhSaPkqaHyiZw0 CsYk0cUvfMY+pZzM+cJxbLiei5KsqWJV7HsUpxDVM8UFkUWA/K/GWZtVlsVApESIjK/2/1BBAsHI UGxnIwuhJVFiM2qi5NmiJkGh+FmfBOrGiwFJTaq5VnRFWXQ9zafGJUGfHTohasyfabcXY7yiw3qX hStZZoHKv1HAvNomduPHWwxmtfwSTCO/GJwRwXzMyIzMmpfMzCxkL7it3pFGjzG2WiGqiMqh04oW 37EekiOaU5FBddyvuihKz/fGSUyyWUHNp6POvVqiFOh9sPrGzwwX7HwW9QwVOnim+qpOAws9DoRf 3qS4omyAKOK9G6vP4sxJokmnB1iDXnmtThik1sSo9yxteiqDufysKeursUSutaSszrqsnsrR51yt XdqEGm1Ogryv8SpOeiS+MC2wgqzSBv9oxXI0013hTpQ60era08u60T7Np6Sq0dharem6q/zrzgsd mvHqrzQ2sVCtyDsbsONsr1Q60FhNzHjqEm9YLcjysjbbEWEd1rC2Km97tl0rs2RN1iRxss0ytU4L SzKb1idxtmmLtSaRtitr129L18tyLT3LhQ1xcBwrJnly2B0b2A4rvgrhsCArEI9dsEfK1X0d18Xl 134tt/+g2WX7D51dtnx9Eg/wD6M92k7btWm7LB2h2ZpdEuCmMioxJ5rt109r1rb92SDRttB8ajMr s7it2rYN3P+AtVjbtUb5ajQF12vdEaZN2ssxIc3t3H99U95W29Y9LGgN19vGbUcNS6//vdOixt1r cbYaGisme1Mhrakwo4aXUmprG0DNbdqsjRKmMtwegbUrI2M5odUOobF/i4STgRWpnRVs3cwlohMQ wxMW87cM3uCcaODc5OAPkVht0bk/ZuEH/RnV/BinGxWj+xtf9xKPO3ce8eG/YV48geFgob40QZLm QxVHYYowUbqatbvQgeI4kXfuBY32kJB+xYsJ4eMJk7gJUZJSXU5IWIkENjgU4VgaWRDdW5ER0VhB VxBE5zfFvIn6sInMWL0Hgb15BeQ+EY4UEeWJ4pB7BV8DCV8NweVc7pNwPtWAs43vW74eXFVv/uYJ 8TgDSZFvTuYSMZHuW+cC4eb7FcJF/35fVfVdBsyUvwuVwiXj+dgRNP7R6yrp3jW9KKHpq2teWBeZ EtGTSKVUaP6TFzyvCyHqaxXnC8FVSuWNaM7YZeqTpm4PmQjoEUHndL6zUnq/lP7rjVtaoNhZwa68 wLXpAzzp01WW39XhrQjsZTdTs/wSAtwR1Y7ERJwhqQiWk7qpF6bpJ6GXXWmUEXZcjd64bzni47Op kXftaplZMUUl+pwfT+zNiS4Q3mjmCmHBtD6NtM7q9qCTDCHwOonm/H4RT/zIBSmafqziD/zIB3/Q VlKZoykQFF+aEszHUu0+FF8RHPzAF5/xKcYRbEzEj+67OUy1JMHCqJqicDyucuzFcf9ZEQlfnJUE R8PpxE+UEH1sRMiXowhR8xyE80288wjRxBKMx0A/EcPZRC92RLN5xw0Ry+v5EZscxriMxiuqomGM EjHMn+M5x1y/xtl5yTR6FNa529HhyWRfoB6RoFnPuCL1PRCa9jCYoj18Ia3D3zjB9yhGUZjcGHEP 4c2sZ4T/h+t3+IYn4QWh+I6PEh01UvP8ETDCGfb+4rIhUhUNZ8mD0nsRpjh91fJqGO28FmdmziV9 zpgv71a9Z63Pr+GM6rfh97Dv1ADN0k89ScQ0+vqlI4CSSkJZTc+crDSr9gDlZawFaAJY0yfY+0V6 5Ecu67Ne1XkG4KguI9A/6zFN/df/iPnbH/qr70W57/suCeM6/dPT/q6n2rpH/dPu3K3ojPrWKv/Z StTlSuzET7UwGpQuj9QlDRAA/g0U+K+gwYEJFSY82FBhwYMLJU6kWNHiQHsZNW7k2BGAxo/2QobM SLLjRpIjQZ48+TElS5MxTbJEWbPkSps0acbEKZLjzJ0+SwLgedOozptEhR5dCtQjTpVIm/Z8KdXq VZ0XLTr8p8DrQgVa/y1ISBYhQbEID4adaHag24EB0g5kO7BBwrsMFQbA+jMnSb4cFVz1qnGB4YyH E2tsgHXw442DNUq21xhpVa+UkVquPNlzRs19RY/u+0Cj6akZ81ldrfqo05OmUXdm/4x4cWTRikEq NUk5NNben+050BjAOFbOGY0HztjAOe3fNCWH1ky5tc582a/7lsqcOXfQpMWPl+rAPPGMD9Tjtqp+ dtXu9piLJCpTqeC+YjPvndvf/0QH/vsnHwELnGs5sZaTK6EFBzovwLgMlHDChSCk8EILL9TwogY3 FJBAD0MUUcC6RjSRoohOVHFFFjUssUUYN3wgRq3Gy4w8HHPUcUcee/TRHho9rC/Ii3408kgkkwSS SCabdLI/JaOUckoqq7TySiyz1HJLLrv08sscnxRzTDItAvNMNNNUc00223STpjLj1PBNOuu8Uk48 n7RzTz779HO8PAMVlMg/C11zUCZEE1V00QsNdfRRSCOVdFJKK6WTUUwz1XRTRi11k1NQQxV11IkC AgA7 ------=_NextPart_000_0003_01C525FF.FF988140-- From sip-bounces@ietf.org Wed Mar 28 18:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgsz-0002BB-9h; Wed, 28 Mar 2007 18:44:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgsx-0002B6-3R for sip@ietf.org; Wed, 28 Mar 2007 18:44:55 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWgsv-0007xe-Rl for sip@ietf.org; Wed, 28 Mar 2007 18:44:55 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007032822445301100kd3dne>; Wed, 28 Mar 2007 22:44:53 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2SMirLv004496 for ; Wed, 28 Mar 2007 17:44:53 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2SMiq2S004492; Wed, 28 Mar 2007 17:44:52 -0500 Date: Wed, 28 Mar 2007 17:44:52 -0500 Message-Id: <200703282244.l2SMiq2S004492@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> (michael.procter@citel.com) Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Reading into this issue more carefully: From: "Michael Procter" Jonathan Rosenberg wrote: > EKR wrote: > > This doesn't seem right. "+sip.instance" at best means > > "I want to do outbound". More likely it means "here is my instance ID". > > It's "Supported: gruu" that says "I want a GRUU". > > No, its instance. It used to work the way you described, in fact. > However, we ran into an issue that a UA might register with an instance > ID but not support GRUU, and then something is subscribed to reg-event > and wants to learn its gruu. So you don't return the gruu to the UA, but > you still need to generate the GRUU to deliver in reg-event. Strictly, +sip.instance means "here is my instance ID" and Support: gruu means "I support GRUU". If both are present and the registrar supports GRUU, the registrar will return a GRUU. IMHO, the registrar can return a GRUU *anyway*, as the UA should ignore unexpected field parameters in the returned Contact headers. I'm interested in how this 'one-sided' support for GRUU would work. My initial reaction is that it would lead to odd failures. For example, take the case where UA1 doesn't support GRUU, but registers at R1 which does. R1 generates the GRUU, but doesn't deliver it back to UA1, as you describe. Let's also assume that UA2 has subscribed to the reg-event package for UA1 at R1. This leads to R1 sending UA2 UA1's GRUU. So far, so good. Now, for some reason, UA2 wishes to call UA1 using that GRUU. The INVITE gets routed to UA1 as expected. UA1 answers the call, and in the 200, includes a non-GRUU contact. The ACK from UA2 now can't route correctly (as UA1 can't provide a contact that is globally routable!). The upshot of this is often (in my experience) a call that seems to work for 30 seconds or so, and then gets torn down. Similar things happen for subscriptions - the SUBSCRIBE/200 works ok, as do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it fails for the same reason. Let me see if I understand your point here by trying to restate a more detailed example. I'm going to use an initial SUBSCRIBE to avoid the complexities of INVITE. UA2 sends SUBSCRIBE to UA1-GRUU. It gets routed to the proxy, which routes it to UA1. UA1 sends a response containing a Contact which is not a GRUU, and is not routable from UA2. But it seems to me that in any such situation that works without GRUU, the proxy or some intermediate system must be aware of the addressing boundary between UA1 and UA2, and must consistently Record-Route itself. And just because an incoming request uses a GRUU, doesn't mean that the proxy can omit Record-Routing itself. The risk is that the proxy implementor will not think of this problem, and omit Record-Routing because the request uses a GRUU. Following Jeroen, we need a statement somewhat like: So section 6.2 should be updated to state "[...] and the registration contains Path URI and/or the proxy does not have positive knowledge that the destination UA(s) will use globally routable URIs as Contacts." Hmmm, that's not right, either. What I really mean is that if the the addressing situation is different on "different sides of the proxy", the proxy MUST Record-Route itself unless it *knows* that the Contacts will resolve correctly on "the other side". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 19:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWh8q-0005Lu-5N; Wed, 28 Mar 2007 19:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWh8p-0005Lp-Gv for sip@ietf.org; Wed, 28 Mar 2007 19:01:19 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWh8k-0002yO-NC for sip@ietf.org; Wed, 28 Mar 2007 19:01:19 -0400 Received: from hkaplan [217.41.227.142] by acmepacket.com with ESMTP (SMTPD-9.10) id A3AC084C; Wed, 28 Mar 2007 19:01:00 -0400 From: "Hadriel Kaplan" To: "'Francois Audet'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> <026601c770cc$7695b330$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF0FCA3E07@zrc2hxm0.corp.nortel.com> Subject: RE: [Sip] sips: upgrading allowed or not Date: Wed, 28 Mar 2007 18:59:26 -0400 Message-ID: <055d01c7718c$bd8d6970$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCA3E07@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hmmm... then I think I did miss your point. Your point then is to remove the upgrade scenario from the draft, and any attempt to make it work, and instead disallow it - and thus any legacy-3261 proxy in the path still doing it will be found out if it breaks things, and subsequently fixed to not do so? So my only point to that then is that it won't mean you can remove section 4.1 of your draft (though it should be reworded I guess) - because a sips request arriving at a UAS is still not known to have started as sips, because it may have crossed an upgrading legacy-3261/2543 proxy en route. -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, March 27, 2007 8:18 PM > To: Hadriel Kaplan; Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] sips: upgrading allowed or not > > I'm not sure I follow your point... > > If you "upgrade", you will know soon enough because things will start > breaking, and you'll get customer complaints. This "breaking" part is > the > reason why I want to deprecate upgrades. > > As for the "checks", it seems to me that using SIPS as a "check" is not > a good idea (at least on it's own) as it is very weak. To me, that's one > of the possible topic for "Furture work in specification". I think this > section on checks is misleading and it contradicts other parts of the > document that explain that SIPS is not an indication that the request > was indeed forwarded over TLS on each hop. > > If people think we need a indication of end-to-end security (of of > security > on each hop), then bring it in. That's what I tought people wanted to > talk > about in Prague... > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, March 27, 2007 17:03 > > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF > > SIP List' > > Subject: RE: [Sip] sips: upgrading allowed or not > > > > I also agree upgrading should not be allowed to make life > > simpler, but my concern is isn't it too late? > > > > I mean how many 3261-compliant boxes out there will retarget > > upgrade? So if sips suddenly becomes a (more) popular thing, > > how would the UAS know if the request traversed a 3261-only > > proxy which upgraded, vs. traversed this newer proposal proxies only? > > > > It will have to do the checks no matter what, no? And the > > bad scenario of sips contact can still occur. (or maybe I > > missed the point) But at least if you specify NOT to do it > > and why in your draft then it will help proxy makers avoid > > the sips contact issue. So it still has some value. > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Tuesday, March 27, 2007 3:36 PM > > > To: Jonathan Rosenberg; IETF SIP List > > > Subject: RE: [Sip] sips: upgrading allowed or not > > > > > > I agree with Jonathan's proposal. > > > > > > Here is a slighly different perspective on it however. I'll keep > > > rethorical arguments out of it, and stick to protocol. > > > > > > - Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy > > > would be > > > a normative change to RFC 3261. Section 26.4.4 describes it (3rd > > > paragraph > > > on p. 250). That is just an observation. > > > > > > - The fact that it is currently allowed means that the UAS > > receiving > > > the request > > > has to go through some fairly esoteric logic to "guess" if the > > > request was > > > sent securily on each hop or not. This is described in > > paragraph 4 > > > of p. 250, > > > and section 4.1 of draft-ietf-sip-sips-02 also describes it, with > > > some modifications. > > > Those procedures are extremely cludgy and non-deterministic. They > > > are also misleading > > > for the UAS, and inconsistent with the use of SIPS and SIP as > > > described in this draft > > > (i.e., for the other scenarios of forwarding and retargeting). In > > > all other instances, > > > the idea is that when a request is forwarded/retargeted, > > the scheme > > > is preserve. > > > I'd really like to get rid of section 4.1. > > > > > > - Jonathan Peterson was proposing that the UAS inspect > > the To header > > > to see if > > > the request was initially targeted at SIPS. This is > > a subset > > > of the procedures > > > of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff > > > like looking at > > > Via and other fields). > > > > > > - This "upgrading" also forces the use of the double > > Record-Route in > > > section 4.2 > > > of draft-ietf-sip-sips-02. Since we agreed to deprecate > > the last hop > > > exception > > > for downgrading, the SIPS-to-SIP Record-Route scenario will be > > > removed from the > > > -03 version. Removing the "upgrade" scenario would also > > remove the > > > double > > > Record-Route for the SIP-to-SIPS, and the net-net is that > > the whole > > > section > > > 4.2 could be removed. > > > > > > - Because of rules described in RFC 3261, if a UAS receives an > > > incoming request with a > > > SIPS Request-URI, it MUST use a SIPS contact. This is a > > big problem > > > for the sender > > > of the initial request that initiated the dialog if that > > UAC did not > > > support SIPS. > > > If Record-Routing is not used, it will just plainly not work. The > > > UAC will not be > > > able to send further requests (like BYE for example). If > > > Record-Route is used, it > > > might work (or it might not). The reason it might not > > work is that > > > there is possible > > > that the UAC might "choke" on the SIPS URI in the Contact > > (because > > > it doesn't understand > > > how to parse it). > > > > > > - We have corrected to types of problems everywhere > > else in this > > > draft. There was > > > quite a few of them in previous versions. This is the > > only one > > > remaining. > > > > > > - Note that it would still be possible to "upgrade" by sending SIP > > > over TLS. In fact, I would > > > argue that we need to put a requirement to do so when there is > > > already a TLS connection > > > opened with the target (as would be the case if Outbound > > was used, > > > and the registration was > > > done over TLS). > > > > > > In summary, I favor deprecating the "retargeting upgrade" > > scenario for > > > the following reasons: > > > > > > - It greatly simplifies the draft, eliminating sections 4.1 and 4.2 > > > completely. > > > > > > - It is much less confusing for the far end. > > > > > > - It avoids some nasty protocol level problems that "break" things. > > > > > > - You can still use TLS for transport for delivering to > > that last hop. > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > Sent: Tuesday, March 27, 2007 06:40 > > > > To: IETF SIP List > > > > Subject: [Sip] sips: upgrading allowed or not > > > > > > > > During the Prague IETF, I shared some opinions on what I thought > > > > sips needs to look like and why, and wanted to take these to the > > > > list. > > > > > > > > Firstly, what is the point of sips? What does it bring a network > > > > that it can't get with TLS on some hops, as needed? > > > > The answer is that certain security benefits are afforded > > if we can > > > > assure that every single hop from UAC to UAS was TLS > > protected, and > > > > that furthermore, this fact can be definitively known by the UAC, > > > > UAS, and all proxies along the way. If we make the > > assumption that > > > > the UA's trust their proxies (please don't question the > > assumption > > > > in this thread), then SIPS provides you some very nice security > > > > properties - confidentiality and integrity from all non-trusted > > > > entities. We use this property all over our specs to > > secure various > > > > extensions. > > > > > > > > Given that, sips is broken if it doesn't provide that > > service (tls > > > > on each hop with knowledge of such by all entities). FOr this > > > > reason, I think we need to eliminate the last hop exception > > > > (uncontroversial I think), but furthermore, I believe > > this extends > > > > to retargeting as well. > > > > I think we clearly need to disallow retargeting or > > downgrading from > > > > a sips URI to a sip URI. I think that was also largely > > > > non-controversial. > > > > However, I also want to disallow upgrading or retargeting > > from sip > > > > to sips. On this, there was some disagreement. > > > > > > > > The challenge Jon gave me at the mike was this. As long as a UAC > > > > inserts a sips URI into the To field and R-URI field when > > it emits a > > > > sips request, does not the presence of a sips URI in the > > TO field, > > > > and receipt over a TLS connection, assure that the request was > > > > delivered over TLS at each hop? Had the request been sent > > originally > > > > to a sip URI and then upgraded, the TO field would not have been > > > > sips, but rather sip. > > > > > > > > I believe Jon is correct, however I still think it is not a good > > > > idea. > > > > My rationale is: > > > > > > > > 1. if upgrades are disallowed, redirecting from sip to sips works > > > > much better. Such a redirection would necesarily have to > > go all the > > > > way to the UAC. If we allow upgrades, a proxy in the middle could > > > > recurse and upgrade. In that case, if the reason for the > > redirection > > > > was that the UAS *wanted* TLS on each hop, recursing in > > the middle > > > > would destroy that possibility. > > > > > > > > 2. The architectural principle behind the first issue, more > > > > generally, is that the meaning of sips is *SECURE ON EACH > > HOP FROM > > > > UAC TO UAS*. To me, this is fundamentally at odds with > > any notion of > > > > upgrade or downgrade. > > > > > > > > 3. Things become simpler if we forbid upgrades. We can > > eliminate the > > > > text on double-record routing sinec a proxy would never > > be sip/sips > > > > converting. I think it also just generally makes overall > > processing > > > > easier. SIPS means one thing and one thing only and its terribly > > > > clear what it means. > > > > > > > > As such, I stand by my argument that we should forbid upgrades. > > > > > > > > -JOnathan R. > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Cisco Fellow Parsippany, NJ > > > > 07054-2711 > > > > Cisco Systems > > > > jdrosen@cisco.com FAX: > > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > > (973) 952-5000 > > > > http://www.cisco.com > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 19:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhH1-0004fK-GH; Wed, 28 Mar 2007 19:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhH0-0004fF-5A for sip@ietf.org; Wed, 28 Mar 2007 19:09:46 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhGz-0004C4-IR for sip@ietf.org; Wed, 28 Mar 2007 19:09:46 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2SN9D425976; Wed, 28 Mar 2007 23:09:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Wed, 28 Mar 2007 18:09:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF2B3A@zrc2hxm0.corp.nortel.com> In-Reply-To: <055d01c7718c$bd8d6970$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vwAADh4RA= References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> <026601c770cc$7695b330$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF0FCA3E07@zrc2hxm0.corp.nortel.com> <055d01c7718c$bd8d6970$800101df@acmepacket.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Hmmm... then I think I did miss your point. > Your point then is to remove the upgrade scenario from the=20 > draft, and any attempt to make it work, and instead disallow it Correct. There is no way to make it work in real life. I mean, if you want to ugrade there is a way to do it that does work: you Redirect instead of retargeting. > - and thus any legacy-3261 proxy in the path still doing=20 > it will be found out if it breaks things, and subsequently=20 > fixed to not do so? Huh? Legacy-3261 proxies doing upgrades? I've never seen such a think, and I'd argue that it would be broken anyways if it did. > So my only point to that then is that it won't mean you can=20 > remove section > 4.1 of your draft (though it should be reworded I guess) -=20 > because a sips request arriving at a UAS is still not known=20 > to have started as sips, because it may have crossed an=20 > upgrading legacy-3261/2543 proxy en route. We could leave it in there for "theoretical" legacy 3261 proxies doing upgrades, but I think it will just encourage people to do evil (and it will still break things). Note that there was no SIPS in 2543, so it wouldn't apply there. > -hadriel >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, March 27, 2007 8:18 PM > > To: Hadriel Kaplan; Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] sips: upgrading allowed or not > >=20 > > I'm not sure I follow your point... > >=20 > > If you "upgrade", you will know soon enough because things=20 > will start=20 > > breaking, and you'll get customer complaints. This=20 > "breaking" part is=20 > > the reason why I want to deprecate upgrades. > >=20 > > As for the "checks", it seems to me that using SIPS as a "check" is=20 > > not a good idea (at least on it's own) as it is very weak. To me,=20 > > that's one of the possible topic for "Furture work in=20 > specification".=20 > > I think this section on checks is misleading and it=20 > contradicts other=20 > > parts of the document that explain that SIPS is not an=20 > indication that=20 > > the request was indeed forwarded over TLS on each hop. > >=20 > > If people think we need a indication of end-to-end security (of of=20 > > security on each hop), then bring it in. That's what I=20 > tought people=20 > > wanted to talk about in Prague... > >=20 > >=20 > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, March 27, 2007 17:03 > > > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP=20 > > > List' > > > Subject: RE: [Sip] sips: upgrading allowed or not > > > > > > I also agree upgrading should not be allowed to make life=20 > simpler,=20 > > > but my concern is isn't it too late? > > > > > > I mean how many 3261-compliant boxes out there will retarget=20 > > > upgrade? So if sips suddenly becomes a (more) popular thing, how=20 > > > would the UAS know if the request traversed a 3261-only=20 > proxy which=20 > > > upgraded, vs. traversed this newer proposal proxies only? > > > > > > It will have to do the checks no matter what, no? And the bad=20 > > > scenario of sips contact can still occur. (or maybe I missed the=20 > > > point) But at least if you specify NOT to do it and why in your=20 > > > draft then it will help proxy makers avoid the sips=20 > contact issue. =20 > > > So it still has some value. > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: Tuesday, March 27, 2007 3:36 PM > > > > To: Jonathan Rosenberg; IETF SIP List > > > > Subject: RE: [Sip] sips: upgrading allowed or not > > > > > > > > I agree with Jonathan's proposal. > > > > > > > > Here is a slighly different perspective on it however.=20 > I'll keep=20 > > > > rethorical arguments out of it, and stick to protocol. > > > > > > > > - Disallowing re-targeting "upgrades" from SIP to SIPS=20 > by a proxy=20 > > > > would be > > > > a normative change to RFC 3261. Section 26.4.4=20 > describes it (3rd=20 > > > > paragraph > > > > on p. 250). That is just an observation. > > > > > > > > - The fact that it is currently allowed means that the UAS > > > receiving > > > > the request > > > > has to go through some fairly esoteric logic to=20 > "guess" if the=20 > > > > request was > > > > sent securily on each hop or not. This is described in > > > paragraph 4 > > > > of p. 250, > > > > and section 4.1 of draft-ietf-sip-sips-02 also describes it,=20 > > > > with some modifications. > > > > Those procedures are extremely cludgy and non-deterministic.=20 > > > > They are also misleading > > > > for the UAS, and inconsistent with the use of SIPS and SIP as=20 > > > > described in this draft > > > > (i.e., for the other scenarios of forwarding and=20 > retargeting).=20 > > > > In all other instances, > > > > the idea is that when a request is forwarded/retargeted, > > > the scheme > > > > is preserve. > > > > I'd really like to get rid of section 4.1. > > > > > > > > - Jonathan Peterson was proposing that the UAS inspect > > > the To header > > > > to see if > > > > the request was initially targeted at SIPS. This is > > > a subset > > > > of the procedures > > > > of 4.1/draft-ietf-sip-sips and of RFC 3261=20 > (they add stuff=20 > > > > like looking at > > > > Via and other fields). > > > > > > > > - This "upgrading" also forces the use of the double > > > Record-Route in > > > > section 4.2 > > > > of draft-ietf-sip-sips-02. Since we agreed to deprecate > > > the last hop > > > > exception > > > > for downgrading, the SIPS-to-SIP Record-Route=20 > scenario will be=20 > > > > removed from the > > > > -03 version. Removing the "upgrade" scenario would also > > > remove the > > > > double > > > > Record-Route for the SIP-to-SIPS, and the net-net is that > > > the whole > > > > section > > > > 4.2 could be removed. > > > > > > > > - Because of rules described in RFC 3261, if a UAS receives an=20 > > > > incoming request with a > > > > SIPS Request-URI, it MUST use a SIPS contact. This is a > > > big problem > > > > for the sender > > > > of the initial request that initiated the dialog if that > > > UAC did not > > > > support SIPS. > > > > If Record-Routing is not used, it will just plainly not work.=20 > > > > The UAC will not be > > > > able to send further requests (like BYE for example). If=20 > > > > Record-Route is used, it > > > > might work (or it might not). The reason it might not > > > work is that > > > > there is possible > > > > that the UAC might "choke" on the SIPS URI in the Contact > > > (because > > > > it doesn't understand > > > > how to parse it). > > > > > > > > - We have corrected to types of problems everywhere > > > else in this > > > > draft. There was > > > > quite a few of them in previous versions. This is the > > > only one > > > > remaining. > > > > > > > > - Note that it would still be possible to "upgrade" by=20 > sending SIP=20 > > > > over TLS. In fact, I would > > > > argue that we need to put a requirement to do so when=20 > there is=20 > > > > already a TLS connection > > > > opened with the target (as would be the case if Outbound > > > was used, > > > > and the registration was > > > > done over TLS). > > > > > > > > In summary, I favor deprecating the "retargeting upgrade" > > > scenario for > > > > the following reasons: > > > > > > > > - It greatly simplifies the draft, eliminating sections 4.1 and=20 > > > > 4.2 completely. > > > > > > > > - It is much less confusing for the far end. > > > > > > > > - It avoids some nasty protocol level problems that=20 > "break" things. > > > > > > > > - You can still use TLS for transport for delivering to > > > that last hop. > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > > Sent: Tuesday, March 27, 2007 06:40 > > > > > To: IETF SIP List > > > > > Subject: [Sip] sips: upgrading allowed or not > > > > > > > > > > During the Prague IETF, I shared some opinions on=20 > what I thought=20 > > > > > sips needs to look like and why, and wanted to take=20 > these to the=20 > > > > > list. > > > > > > > > > > Firstly, what is the point of sips? What does it=20 > bring a network=20 > > > > > that it can't get with TLS on some hops, as needed? > > > > > The answer is that certain security benefits are afforded > > > if we can > > > > > assure that every single hop from UAC to UAS was TLS > > > protected, and > > > > > that furthermore, this fact can be definitively known by the=20 > > > > > UAC, UAS, and all proxies along the way. If we make the > > > assumption that > > > > > the UA's trust their proxies (please don't question the > > > assumption > > > > > in this thread), then SIPS provides you some very=20 > nice security=20 > > > > > properties - confidentiality and integrity from all=20 > non-trusted=20 > > > > > entities. We use this property all over our specs to > > > secure various > > > > > extensions. > > > > > > > > > > Given that, sips is broken if it doesn't provide that > > > service (tls > > > > > on each hop with knowledge of such by all entities). FOr this=20 > > > > > reason, I think we need to eliminate the last hop exception=20 > > > > > (uncontroversial I think), but furthermore, I believe > > > this extends > > > > > to retargeting as well. > > > > > I think we clearly need to disallow retargeting or > > > downgrading from > > > > > a sips URI to a sip URI. I think that was also largely=20 > > > > > non-controversial. > > > > > However, I also want to disallow upgrading or retargeting > > > from sip > > > > > to sips. On this, there was some disagreement. > > > > > > > > > > The challenge Jon gave me at the mike was this. As=20 > long as a UAC=20 > > > > > inserts a sips URI into the To field and R-URI field when > > > it emits a > > > > > sips request, does not the presence of a sips URI in the > > > TO field, > > > > > and receipt over a TLS connection, assure that the=20 > request was=20 > > > > > delivered over TLS at each hop? Had the request been sent > > > originally > > > > > to a sip URI and then upgraded, the TO field would=20 > not have been=20 > > > > > sips, but rather sip. > > > > > > > > > > I believe Jon is correct, however I still think it is=20 > not a good=20 > > > > > idea. > > > > > My rationale is: > > > > > > > > > > 1. if upgrades are disallowed, redirecting from sip to sips=20 > > > > > works much better. Such a redirection would necesarily have to > > > go all the > > > > > way to the UAC. If we allow upgrades, a proxy in the middle=20 > > > > > could recurse and upgrade. In that case, if the reason for the > > > redirection > > > > > was that the UAS *wanted* TLS on each hop, recursing in > > > the middle > > > > > would destroy that possibility. > > > > > > > > > > 2. The architectural principle behind the first issue, more=20 > > > > > generally, is that the meaning of sips is *SECURE ON EACH > > > HOP FROM > > > > > UAC TO UAS*. To me, this is fundamentally at odds with > > > any notion of > > > > > upgrade or downgrade. > > > > > > > > > > 3. Things become simpler if we forbid upgrades. We can > > > eliminate the > > > > > text on double-record routing sinec a proxy would never > > > be sip/sips > > > > > converting. I think it also just generally makes overall > > > processing > > > > > easier. SIPS means one thing and one thing only and=20 > its terribly=20 > > > > > clear what it means. > > > > > > > > > > As such, I stand by my argument that we should forbid=20 > upgrades. > > > > > > > > > > -JOnathan R. > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 600=20 > Lanidex Plaza > > > > > Cisco Fellow Parsippany, NJ > > > > > 07054-2711 > > > > > Cisco Systems > > > > > jdrosen@cisco.com FAX: > > > (973) 952-5050 > > > > > http://www.jdrosen.net PHONE: > > > (973) 952-5000 > > > > > http://www.cisco.com > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > > > > Use sipping@ietf.org for new developments on the=20 > application of=20 > > > > > sip > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > > > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 19:20:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhQY-0002Ep-QL; Wed, 28 Mar 2007 19:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhQX-0002ET-8A for sip@ietf.org; Wed, 28 Mar 2007 19:19:37 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhQV-0006Sm-WE for sip@ietf.org; Wed, 28 Mar 2007 19:19:37 -0400 Received: from hkaplan [217.41.227.142] by acmepacket.com with ESMTP (SMTPD-9.10) id A8050120; Wed, 28 Mar 2007 19:19:33 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'Francois Audet'" , "'Christer Holmberg \(JO/LMF\)'" , "'Sean Olson'" , "'IETF SIP List'" References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Wed, 28 Mar 2007 19:17:58 -0400 Message-ID: <055e01c7718f$54c90270$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdwo2p71t4qOzMoSrK+r8XD+YdxqAAABcXQAAAx/yAAAEAzUAAAJSbAAAAqegAAABAOoAAAP7NgAAAJGAAAADUQQAAAfV2gAAWW/uAAAZ9eQAAAeTcwADDy5dA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey Samir, Inline... > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Tuesday, March 27, 2007 8:12 PM > To: Francois Audet; Christer Holmberg (JO/LMF); Sean Olson; IETF SIP List > Cc: Dean Willis > Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme > > Looks like we are recommending to use tels etc. I don't think that's what people are saying. I think they are just saying that for sips. > I have not seen even a single engineering reason to keep SIPS. Instead > of just giving the argument that SIPS is in 3261. So we want to pursue > it. 3261 has many bugs, I treat it as one of them, which is result of > series of mistakes. Well I can give one: it has the same semantics and security property you get with a syntax of Require/Proxy-require:tls. So the argument was made that if you have the syntax already in place for those semantics with "sips", and it's in the RFC, and a crap-load of other RFCs reference using it, then fixing the mechanics but keeping the syntax is less work and time than a new syntax. It actually has another property which requires/proxy-require won't as easily: namely that you know the tls requirement before sending the request, because either the user entered sips, or it was discovered through DNS. > Thx > Samir > > PS: Email list consensus provides more matured decisions as it addresses > wider audience. ...and seems to create discussion loops. ;) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 19:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhm0-0001L5-4b; Wed, 28 Mar 2007 19:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhly-0001K1-Hx for sip@ietf.org; Wed, 28 Mar 2007 19:41:46 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhlx-0003Vw-AY for sip@ietf.org; Wed, 28 Mar 2007 19:41:46 -0400 Received: from hkaplan [217.41.227.142] by acmepacket.com with ESMTP (SMTPD-9.10) id AD280470; Wed, 28 Mar 2007 19:41:28 -0400 From: "Hadriel Kaplan" To: "'Francois Audet'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <46091EB2.6020303@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FC5A439@zrc2hxm0.corp.nortel.com> <026601c770cc$7695b330$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF0FCA3E07@zrc2hxm0.corp.nortel.com> <055d01c7718c$bd8d6970$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF0FCF2B3A@zrc2hxm0.corp.nortel.com> Subject: RE: [Sip] sips: upgrading allowed or not Date: Wed, 28 Mar 2007 19:39:53 -0400 Message-ID: <056501c77192$63e98240$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vwAADh4RAAAJO+QA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCF2B3A@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > - and thus any legacy-3261 proxy in the path still doing > > it will be found out if it breaks things, and subsequently > > fixed to not do so? > > Huh? Legacy-3261 proxies doing upgrades? I've never seen such a > think, and I'd argue that it would be broken anyways if it did. Yup, me neither. I wonder if openser or one of those did it. > > So my only point to that then is that it won't mean you can > > remove section > > 4.1 of your draft (though it should be reworded I guess) - > > because a sips request arriving at a UAS is still not known > > to have started as sips, because it may have crossed an > > upgrading legacy-3261/2543 proxy en route. > > We could leave it in there for "theoretical" legacy 3261 proxies doing > upgrades, but I think it will just encourage people to do evil (and it > will still break things). Yeah, I don't care much - just thinkin' it may be good to check such things at the UAS regardless. Rejecting the request for such will be a fine deterrent, imho. > Note that there was no SIPS in 2543, so it wouldn't apply there. Huh. Yup, my mistake. Maybe we should make 2543 obsolete 3261, at least on April 1st. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 19:48:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhsH-0003po-3S; Wed, 28 Mar 2007 19:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhsF-0003pj-5W for sip@ietf.org; Wed, 28 Mar 2007 19:48:15 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhsC-0005pJ-Hq for sip@ietf.org; Wed, 28 Mar 2007 19:48:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2SNlm429890; Wed, 28 Mar 2007 23:47:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips: upgrading allowed or not Date: Wed, 28 Mar 2007 18:48:10 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E611FA97FC@zrc2hxm2.corp.nortel.com> In-Reply-To: <055d01c7718c$bd8d6970$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips: upgrading allowed or not thread-index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vwAAJl/yA= From: "Samir Srivastava" To: "Hadriel Kaplan" , "Francois Audet" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, Sorry I am still catching up this thread. My understanding was that this document will just state what SIPS provides as per 3261 . Nothing to modify the behaviour of 3261. Looks like, we are patching it for STANDARDS track doc. Let us stop worrying more about upgrade etc, till we see at one place (in the next version of cipher-suites) ugliness of the SIPS and the need for the clear defintion of secure protocols etc, and then decide do we need to spend cycles on this stuff.=20 BTW, there is no SIPS in 2543. I don't recollect which bis got it added. Here legacy should mean 3261 only, if SIPS doesn't get deprecated, and we start working on 3261 bis etc... Thx Samir >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 >Sent: Wednesday, March 28, 2007 3:59 PM >To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP List' >Subject: RE: [Sip] sips: upgrading allowed or not > >Hmmm... then I think I did miss your point. >Your point then is to remove the upgrade scenario from the=20 >draft, and any attempt to make it work, and instead disallow=20 >it - and thus any legacy-3261 proxy in the path still doing it=20 >will be found out if it breaks things, and subsequently fixed=20 >to not do so? > >So my only point to that then is that it won't mean you can=20 >remove section >4.1 of your draft (though it should be reworded I guess) -=20 >because a sips request arriving at a UAS is still not known to=20 >have started as sips, because it may have crossed an upgrading=20 >legacy-3261/2543 proxy en route. > >-hadriel > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Tuesday, March 27, 2007 8:18 PM >> To: Hadriel Kaplan; Jonathan Rosenberg; IETF SIP List >> Subject: RE: [Sip] sips: upgrading allowed or not >>=20 >> I'm not sure I follow your point... >>=20 >> If you "upgrade", you will know soon enough because things=20 >will start=20 >> breaking, and you'll get customer complaints. This=20 >"breaking" part is=20 >> the reason why I want to deprecate upgrades. >>=20 >> As for the "checks", it seems to me that using SIPS as a "check" is=20 >> not a good idea (at least on it's own) as it is very weak. To me,=20 >> that's one of the possible topic for "Furture work in=20 >specification".=20 >> I think this section on checks is misleading and it=20 >contradicts other=20 >> parts of the document that explain that SIPS is not an=20 >indication that=20 >> the request was indeed forwarded over TLS on each hop. >>=20 >> If people think we need a indication of end-to-end security (of of=20 >> security on each hop), then bring it in. That's what I tought people=20 >> wanted to talk about in Prague... >>=20 >>=20 >> > -----Original Message----- >> > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> > Sent: Tuesday, March 27, 2007 17:03 >> > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP=20 >> > List' >> > Subject: RE: [Sip] sips: upgrading allowed or not >> > >> > I also agree upgrading should not be allowed to make life simpler,=20 >> > but my concern is isn't it too late? >> > >> > I mean how many 3261-compliant boxes out there will retarget=20 >> > upgrade? So if sips suddenly becomes a (more) popular thing, how=20 >> > would the UAS know if the request traversed a 3261-only=20 >proxy which=20 >> > upgraded, vs. traversed this newer proposal proxies only? >> > >> > It will have to do the checks no matter what, no? And the bad=20 >> > scenario of sips contact can still occur. (or maybe I missed the=20 >> > point) But at least if you specify NOT to do it and why in your=20 >> > draft then it will help proxy makers avoid the sips=20 >contact issue. =20 >> > So it still has some value. >> > >> > -hadriel >> > >> > >> > > -----Original Message----- >> > > From: Francois Audet [mailto:audet@nortel.com] >> > > Sent: Tuesday, March 27, 2007 3:36 PM >> > > To: Jonathan Rosenberg; IETF SIP List >> > > Subject: RE: [Sip] sips: upgrading allowed or not >> > > >> > > I agree with Jonathan's proposal. >> > > >> > > Here is a slighly different perspective on it however. I'll keep=20 >> > > rethorical arguments out of it, and stick to protocol. >> > > >> > > - Disallowing re-targeting "upgrades" from SIP to SIPS=20 >by a proxy=20 >> > > would be >> > > a normative change to RFC 3261. Section 26.4.4=20 >describes it (3rd=20 >> > > paragraph >> > > on p. 250). That is just an observation. >> > > >> > > - The fact that it is currently allowed means that the UAS >> > receiving >> > > the request >> > > has to go through some fairly esoteric logic to "guess" if the=20 >> > > request was >> > > sent securily on each hop or not. This is described in >> > paragraph 4 >> > > of p. 250, >> > > and section 4.1 of draft-ietf-sip-sips-02 also describes it,=20 >> > > with some modifications. >> > > Those procedures are extremely cludgy and non-deterministic.=20 >> > > They are also misleading >> > > for the UAS, and inconsistent with the use of SIPS and SIP as=20 >> > > described in this draft >> > > (i.e., for the other scenarios of forwarding and retargeting).=20 >> > > In all other instances, >> > > the idea is that when a request is forwarded/retargeted, >> > the scheme >> > > is preserve. >> > > I'd really like to get rid of section 4.1. >> > > >> > > - Jonathan Peterson was proposing that the UAS inspect >> > the To header >> > > to see if >> > > the request was initially targeted at SIPS. This is >> > a subset >> > > of the procedures >> > > of 4.1/draft-ietf-sip-sips and of RFC 3261 (they=20 >add stuff=20 >> > > like looking at >> > > Via and other fields). >> > > >> > > - This "upgrading" also forces the use of the double >> > Record-Route in >> > > section 4.2 >> > > of draft-ietf-sip-sips-02. Since we agreed to deprecate >> > the last hop >> > > exception >> > > for downgrading, the SIPS-to-SIP Record-Route scenario will be=20 >> > > removed from the >> > > -03 version. Removing the "upgrade" scenario would also >> > remove the >> > > double >> > > Record-Route for the SIP-to-SIPS, and the net-net is that >> > the whole >> > > section >> > > 4.2 could be removed. >> > > >> > > - Because of rules described in RFC 3261, if a UAS receives an=20 >> > > incoming request with a >> > > SIPS Request-URI, it MUST use a SIPS contact. This is a >> > big problem >> > > for the sender >> > > of the initial request that initiated the dialog if that >> > UAC did not >> > > support SIPS. >> > > If Record-Routing is not used, it will just plainly not work.=20 >> > > The UAC will not be >> > > able to send further requests (like BYE for example). If=20 >> > > Record-Route is used, it >> > > might work (or it might not). The reason it might not >> > work is that >> > > there is possible >> > > that the UAC might "choke" on the SIPS URI in the Contact >> > (because >> > > it doesn't understand >> > > how to parse it). >> > > >> > > - We have corrected to types of problems everywhere >> > else in this >> > > draft. There was >> > > quite a few of them in previous versions. This is the >> > only one >> > > remaining. >> > > >> > > - Note that it would still be possible to "upgrade" by=20 >sending SIP=20 >> > > over TLS. In fact, I would >> > > argue that we need to put a requirement to do so when there is=20 >> > > already a TLS connection >> > > opened with the target (as would be the case if Outbound >> > was used, >> > > and the registration was >> > > done over TLS). >> > > >> > > In summary, I favor deprecating the "retargeting upgrade" >> > scenario for >> > > the following reasons: >> > > >> > > - It greatly simplifies the draft, eliminating sections 4.1 and=20 >> > > 4.2 completely. >> > > >> > > - It is much less confusing for the far end. >> > > >> > > - It avoids some nasty protocol level problems that=20 >"break" things. >> > > >> > > - You can still use TLS for transport for delivering to >> > that last hop. >> > > >> > > > -----Original Message----- >> > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> > > > Sent: Tuesday, March 27, 2007 06:40 >> > > > To: IETF SIP List >> > > > Subject: [Sip] sips: upgrading allowed or not >> > > > >> > > > During the Prague IETF, I shared some opinions on what=20 >I thought=20 >> > > > sips needs to look like and why, and wanted to take=20 >these to the=20 >> > > > list. >> > > > >> > > > Firstly, what is the point of sips? What does it bring=20 >a network=20 >> > > > that it can't get with TLS on some hops, as needed? >> > > > The answer is that certain security benefits are afforded >> > if we can >> > > > assure that every single hop from UAC to UAS was TLS >> > protected, and >> > > > that furthermore, this fact can be definitively known by the=20 >> > > > UAC, UAS, and all proxies along the way. If we make the >> > assumption that >> > > > the UA's trust their proxies (please don't question the >> > assumption >> > > > in this thread), then SIPS provides you some very nice=20 >security=20 >> > > > properties - confidentiality and integrity from all=20 >non-trusted=20 >> > > > entities. We use this property all over our specs to >> > secure various >> > > > extensions. >> > > > >> > > > Given that, sips is broken if it doesn't provide that >> > service (tls >> > > > on each hop with knowledge of such by all entities). FOr this=20 >> > > > reason, I think we need to eliminate the last hop exception=20 >> > > > (uncontroversial I think), but furthermore, I believe >> > this extends >> > > > to retargeting as well. >> > > > I think we clearly need to disallow retargeting or >> > downgrading from >> > > > a sips URI to a sip URI. I think that was also largely=20 >> > > > non-controversial. >> > > > However, I also want to disallow upgrading or retargeting >> > from sip >> > > > to sips. On this, there was some disagreement. >> > > > >> > > > The challenge Jon gave me at the mike was this. As=20 >long as a UAC=20 >> > > > inserts a sips URI into the To field and R-URI field when >> > it emits a >> > > > sips request, does not the presence of a sips URI in the >> > TO field, >> > > > and receipt over a TLS connection, assure that the request was=20 >> > > > delivered over TLS at each hop? Had the request been sent >> > originally >> > > > to a sip URI and then upgraded, the TO field would not=20 >have been=20 >> > > > sips, but rather sip. >> > > > >> > > > I believe Jon is correct, however I still think it is=20 >not a good=20 >> > > > idea. >> > > > My rationale is: >> > > > >> > > > 1. if upgrades are disallowed, redirecting from sip to sips=20 >> > > > works much better. Such a redirection would necesarily have to >> > go all the >> > > > way to the UAC. If we allow upgrades, a proxy in the middle=20 >> > > > could recurse and upgrade. In that case, if the reason for the >> > redirection >> > > > was that the UAS *wanted* TLS on each hop, recursing in >> > the middle >> > > > would destroy that possibility. >> > > > >> > > > 2. The architectural principle behind the first issue, more=20 >> > > > generally, is that the meaning of sips is *SECURE ON EACH >> > HOP FROM >> > > > UAC TO UAS*. To me, this is fundamentally at odds with >> > any notion of >> > > > upgrade or downgrade. >> > > > >> > > > 3. Things become simpler if we forbid upgrades. We can >> > eliminate the >> > > > text on double-record routing sinec a proxy would never >> > be sip/sips >> > > > converting. I think it also just generally makes overall >> > processing >> > > > easier. SIPS means one thing and one thing only and=20 >its terribly=20 >> > > > clear what it means. >> > > > >> > > > As such, I stand by my argument that we should forbid upgrades. >> > > > >> > > > -JOnathan R. >> > > > >> > > > -- >> > > > Jonathan D. Rosenberg, Ph.D. 600=20 >Lanidex Plaza >> > > > Cisco Fellow Parsippany, NJ >> > > > 07054-2711 >> > > > Cisco Systems >> > > > jdrosen@cisco.com FAX: >> > (973) 952-5050 >> > > > http://www.jdrosen.net PHONE: >> > (973) 952-5000 >> > > > http://www.cisco.com >> > > > >> > > > _______________________________________________ >> > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > > > This list is for NEW development of the core SIP Protocol Use=20 >> > > > sip-implementors@cs.columbia.edu for questions on current sip=20 >> > > > Use sipping@ietf.org for new developments on the=20 >application of=20 >> > > > sip >> > > > >> > > >> > > _______________________________________________ >> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > > This list is for NEW development of the core SIP Protocol Use=20 >> > > sip-implementors@cs.columbia.edu for questions on=20 >current sip Use=20 >> > > sipping@ietf.org for new developments on the application of sip >> > >> > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 28 20:23:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWiNC-00015M-Aq; Wed, 28 Mar 2007 20:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWiNA-00015H-KM for sip@ietf.org; Wed, 28 Mar 2007 20:20:12 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWiN9-0007W3-CP for sip@ietf.org; Wed, 28 Mar 2007 20:20:12 -0400 Received: from hkaplan [217.41.227.142] by acmepacket.com with ESMTP (SMTPD-9.10) id A61D0BA4; Wed, 28 Mar 2007 20:19:41 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'Francois Audet'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <055d01c7718c$bd8d6970$800101df@acmepacket.com> <62B9B0847CC47543B6B3B5E26BD268E611FA97FC@zrc2hxm2.corp.nortel.com> Date: Wed, 28 Mar 2007 20:18:19 -0400 Message-ID: <057401c77197$c2697500$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vwAAJl/yAAAH3yYA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611FA97FC@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Sip] draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading allowed or not) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org But the cipher-suites draft does not show me the ugliness of sips. I believe your draft is trying to convince me what's broken about sips is that you don't know how "secure" the links sips forces you to use are, and thus the UAC/UAS need to control and know the level of that link security. (whereby you define their security level as the used ciphersuite?) Right? If so I think we are in a 180-degree opposite view of what's "broken" about sips. To me, making sure the ciphersuite is "strong" enough is like adding reinforcements to the Maginot line. -hadriel > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Wednesday, March 28, 2007 7:48 PM > To: Hadriel Kaplan; Francois Audet; Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] sips: upgrading allowed or not > > Hi Hadriel, > > Sorry I am still catching up this thread. > > My understanding was that this document will just state what SIPS > provides as per 3261 . > Nothing to modify the behaviour of 3261. Looks like, we are patching it > for STANDARDS track doc. > > Let us stop worrying more about upgrade etc, till we see at one place > (in the next version of cipher-suites) ugliness of the SIPS and the need > for the clear defintion of secure protocols etc, and then decide do we > need to spend cycles on this stuff. > > BTW, there is no SIPS in 2543. I don't recollect which bis got it added. > Here legacy should mean 3261 only, if SIPS doesn't get deprecated, and > we start working on 3261 bis etc... > > Thx > Samir > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From urbainmargalo@iamidle.com Thu Mar 29 02:34:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWoDP-0007oq-RN for sip-archive@lists.ietf.org; Thu, 29 Mar 2007 02:34:31 -0400 Received: from [62.118.164.230] (helo=13a4cc9eb2314f8) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWoDM-0005qZ-Uz for sip-archive@lists.ietf.org; Thu, 29 Mar 2007 02:34:31 -0400 To: "ulick nikolaus" Date: Thu, 29 Mar 2007 10:34:15 +0400 From: "javier nahum" Sender: "javier nahum" Subject: Loyd MIME-Version: 1.0 Message-ID: <575801c771cc$45ac3810$0901a8c0@13a4cc9eb2314f8> Content-Type: multipart/related; boundary="----=_NextPart_000_55EA_01C771ED.C60B84E0" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.3 (+) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b This is a multi-part message in MIME format. ------=_NextPart_000_55EA_01C771ED.C60B84E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_55EB_01C771ED.C60B84E0" ------=_NextPart_001_55EB_01C771ED.C60B84E0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable To listen, by the sputtering, smoking fire, visitors' dugout. The osprey whose nest is atop Upon from the right by far trees, that white place Green lilac buds appear that won't survive Like some poor wounded wretch=97long left for dead From there. Toward . . . End of the comedy. And up there I cannot tell if it is still He is harsh, dismal, ice=97that is, exiled; Wheezing ravens, when Of a far barn, just where the road curves sharply What can we know of whatever picture-plane Of the matter of snow here. Both of us have grasped P=E8re and M=E8re Chose could be in conversation whose soft bristles graze the top-racks. Silent patch of ultimate paint. You are In dense bare branches, or the ubiquitous Clear-voiced despite its years, strong, eloquent=97 The edge of that other square cut from the right ------=_NextPart_001_55EB_01C771ED.C60B84E0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: 8bit
To listen, by the sputtering, smoking fire,
visitors' dugout. The osprey whose nest is atop
Upon from the right by far trees, that white place
Green lilac buds appear that won't survive
Like some poor wounded wretchlong left for dead
From there. Toward . . .
End of the comedy.
And up there I cannot tell if it is still
He is harsh, dismal, icethat is, exiled;
Wheezing ravens, when
Of a far barn, just where the road curves sharply
What can we know of whatever picture-plane
Of the matter of snow here. Both of us have grasped
Pre and Mre Chose could be in conversation
whose soft bristles graze the top-racks.
Silent patch of ultimate paint. You are
In dense bare branches, or the ubiquitous
Clear-voiced despite its years, strong, eloquent
The edge of that other square cut from the right
------=_NextPart_001_55EB_01C771ED.C60B84E0-- ------=_NextPart_000_55EA_01C771ED.C60B84E0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000b01c771cc$3edfc84e$_CDOSYS2.0> Content-Disposition: inline R0lGODdhvQEBAuMAAP///wAAAPz8/PLewuj0+87S0+DAm9Cqf5ilsbOHW3tYOAQEBBs5XlVuiwQE /AAAACwAAAAAvQEBAgAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjo+QkW4BlJWWlC0BHJg+nJ0inn2aFKEnpRaYp3SXrKMqqhWwN7I2tBi2q64SuCCynLxt wCjCnbo7xLvGeqXIG77KeM0k0jrUK83WaszQJc9+wpe3lhOtGaHlvcrqo7+V4u6x7PDm6Mnz5Mbb 98n23BfhqACS0gQv1blx/xACQOfpFDFVDfMpjNdu4MKD+5DwarUOYL2A/vg+bpIokR+rgAJNpkTp UeRBihMvXoz5LiZHmO0UipyJkKErh/4SCuXXj+ZJjAV3GsF1r2nEn0GJ7stIj2K8fiEHQtWlkylX jBaJZrWndauzp2PJplWb1qlZsWK3hZgake1MrSG/6sWrhOM8oGtlwhU3uLCGcwvD3lUM9C2+kYof S5Zr1a7gd1cX870sufNYup45v5xbcvK6yJo5q15dxK+tuoejCqZK+jHs1bcZnz4L2fbuzLiD0oKV ezBEebwjj04HnHXn46gJ95WNMzTI5DxpYzf4/LdrqNdj03Pb+Gbh4cK5FVf93TDq5dSKH/8LbXlC 7UKAmXduPXx2/ITV/mVfXK5Z5xVLE51UVj2AVeVgeA3m5RN2xiE3gnx6CQRdf/tpRF1X/UXnn4TU WSTgVxDKFuGDWMFVkYjNuSejc+tRxuJQob0ICni63bbhefQtcSBwr6kYFTLcqRTdeiPy59mKuQ0J 44zE8fjekVjGKJM1SYYV4Y/s/eZhbz0SaaRh2CRGipoGOtZdk/5B6VhGNaZXGp11VualjTbmZUKX psVJ0pVwEuHVVii2dWZqjHZAV2nKodUmmZolmChbThX6pKR2rYipfUEuCeBZeH4KVosVIirkhx3+ l6E/Tyk4Y2CgxeiSmDXJ81Gft2pKIkkreVpUeeRZqKeT9+HoF04E/l36azY16BeqhCyx2Kuj/zRJ rLasxvrmZtlx6yhN/4l7X5V46khoOvVlmGNSIoIoSYmSjOFQa/TWm62+k6jDA5j8fgBtwFUIW8up BPeScBpGFaPUwhDHMeoxK0Vs8cUYZ6zxxhx37PHHIIcs8sgkl2zyySin/MfA53aRbxNKvSxeiDiw DInNC3KBMxAFTrmjzwePvPOsVAxdDEpAM4ev0DJTuoXR/6rH5DRNzwC1GPc2V7FBxroo67nFgqRd Tn6CDXasY+taNoLXkeuBNxNq2ZOz4SJY4tez0ZZS1knDPGiPNrUU6cOu/srseOHgXfiCc1f8bLnM lqT420YKbmuH/kg96njkKCrO4N80Q6FPZvTtpRu4jV7p5qilr87po6Gb6vrsbrLrtJyqdjcnwskq ymml6jJ6dTVcsZk36A32GTrvwI97Oa3BE3g7pI1BT/Xkyl8Ge6CVGTypZb8vhhjdVpzIvZlid/Qz h1bO/C77lvlaIfopyk9qsJB+q3XXpr2M35ftkt7UpmA+qQQQSFQhXKSUxarnoQlRpaJQmJ41rdix i24AxNHx9jO5s5mLNTrq0vAopr1mwQ+BCVSgaA6IrPmdTlBfk5ILXSWvvtluhvpbIA2LtZEYeoeF IjShzoS4pfbl0ICxcZvXGOi8dYFQahWUzvuI5r3xuC97TBrN/kOUyDYgnbCIvnEZEYPIRPpJcH9l lCCfWChFGU6QirgaSXqm+EI0tlCDlPveE8OoJJcZLzGmU1SKjEilQH6qiXTc3o/cuMYf2g+PdUyV 6va0myoGR4/b28UfCfKFTJpKVGVC3eVch0gclg56hBwRr35nScQda3SoAh58Xse8V+bJd8dKHRY8 Oaz8zXBZ7jNc35Snj8DtSonEBFatdCjHW7UOUOUCFd5adbYBhWlrsPRCfXL1Qdmxrl0RVKMv6xa5 akkRh0Xp5hYdZ6nozU1185kY5PRIrX3FQmX4zKc+98nPfvrznwANqEAHStCCGvSgCE2oQhfK0IY6 9KEQjahE/idKUYOOcxqUqtoLjMbFJGj0jDL4aFnu19FcaOlCi7pj0FiwuelsdIQn3RGAqJmH7KG0 NvkR6SPHlAl5poBlPTSETdcnMJ1ew6g2PAJHfToMowZ1EHFz2946WER28m1TpYLX4P7nQ6M0C1Zi ygmWpspUMI4rnP3rKFm5iA21xTJnpCtrzRTENc11paV1TSHoCIS/d2IVr7JqFVXlNM9qCvOsd7wW JdkaWKpWtVuJwyb+CrsUYOFyLVJCz16Ph9k1gouremqn01YYPlWWVjqH6qyg5KjaZpa0dZ2lXWAM tdlbwtGC46NkaCs5TvSIMorn9Npm9zfc+iVxt6s97mZS/gu0ZLapdjD9U2+zhNtUog82izxN9ZTm ngGC8osaBFgagys9O96ovMFcni+zSMjodmO63KyufPuYt/Gm026lrJIFLwne5Ma0U9Q146ZA6l2Q 0pGvHIzjELCozExtp4EF3CMK4zlT8qE3vSuEJDOnZCkCt9fC8bJuKU1rJmDyV6nwXZs1jcubCGe3 bXbybYgK7MX+mpfD7SFvCf2rYxqf14kXJq97qSa3DyfNx2RkLyZTGl6p7ZewvlrxM3qmYdsi68Ue Tq9nzzjkm373xC30MSDvacjmlZieMEQa0a6JuiK1GUljRe5n47xcJpNDnGcW8JqjVmTfgTiSykVl a5np/hYte+vJh0ZVhXcrM+amBrbVJeX08Dy4Qe83alrd6lrBWk8r/naauELbojn338O9xLH3XRxO SUosIpLTsDZU4RvfNdlS8yzTtG4fMt3lDHtWp891fi040Xq/JfKEcpkj8lnRxT+1erWoE3Pur79c 0QUjtdrYDum1s83tnnb727QFt7hvPe5ym/vc6E63utfN7na7+93wjre8590vM3T5zj/16b21oWsR 72HfR5trvuUpV0BE6c813faqFD5aLyOb4QkHsiggXtmCSzffFyTYgABePgsn+yrPZPDhWAuOZ8O4 palWdVWkFc6SDgvYIw1OVmVs8gzb2qRfdGZSjglD/pQjcdnLXCxXNYRqd/RwsrLGXKgjy7hi+hbU A775HKQtyzkjDIBlxnDvHs1GRzu4N17/uC4BbGQ/x1aULQNw1JP6Bk+5E0P23bHU4Yi8rtNZkGQq Ut0VvGQem3nDgT6ksefe9qU/MNcYPm1RG67k2GH5wVk+vKeFnEo3X/rxUqa4GNOYY5nX/K9tZXzl ES7hMJP+8c3FJothNNU8sjjzE+c8lSn89Vwz1Y1BHnyP/c31yJcecbXP/TVbP2L0wp4P+l2xrYle KJ8fGYh2973eaSr535O07z1fu/T7rWE7JJ/0KrVy98ef8+hrvcCdh1PjuZvB1ev+/FY6/r+dXEu4 /rsfuCVnbZ1hkvq6ExUz+xdljjRncgZ4kzd48rcMYKU+ahdzn6RotfRjasZ1EPR8ksZdkxd8hRRI kCY7Znd5p5RD4hUNUARrzwVq45A5t3c3nmM5KWc3F2Vg5RRirOZ0rhZNr9JhzgN172dzd+ALwKd+ 2INrlNVw8WVOw3d9hAeCxEZ3esU/x5aEwjcUNWdNyicxmkdvrvdSXLgyWaiF1ecCSxUIHOduhRYD Y0iGXwiGJtaFRwVVa6iFbSiGCleGuxSH9IZqGPeGYNiHfviHgBiIgjiIhFiIhniIiJiIiriIjNiI jviIkBiJkjiJlFiJlniJmJiJmshtAgAAneiJ/p34iRnwiaIoiptYMqbIAQJAiqt4AaEoAaToibA4 i6eIirDYirK4igNAALs4AL44AAVgAAXgi8PoiwSQirJYiyCDixQQiqsoALz4i75oAANgANZIjdeY jda4i8/Yja6ojBbDirioi9OojQdwjQhwjdU4jNkYjNvIjc9oAcgIjgRjitBIjNpoAAeAAPt4jsT4 i8KIjdbojtc4jMlIjxvjjACZjf2Yju9YjdZ4ABI5kRRJkfx4jgZwjPaIkBHzjAXwkdeIkRj5jyGp jxipjyZZkRJpAPyYjgVwjBMwjxx5CBt5kPcIkSZpjQgQjOwYkSsZkPmokhSZjcA4AK/IijP5/gik iJMRGZA9yZQD+YvD6I4SiQAJcJUHgJXnuJIOyZOtWJNJWQjd+IzAyJBRCZFQSY1SWY0SeZVumQAK oABYmQBWuY/tKIy7WAHMGJaE8JUAAIxVWZAAOY1ouZD6+JZwCZdy6ZYVeZE6KZh5yZc0yYwCAJgr WZSGGZCEaZKM2ZaI+Zk/qY8OuY5RCZMyKZl8MI5s6ZKFuY3qGJJtmZX8mABZSZe0CZoTqY3SyJTD eJqouQekGIz8iI3F6JoPOQAUyZi22Y9CqZK0uZInqZN0eQC96Zu/aQfdyJYHsJvlaJw+GZsX2Zzi mY8CCZuMiQADcJ1+gIvVmI7cmZbfmZUq/gmbzDmU5DmYhFmNVzmcBqmewOmJBICSZVmNTHmSW/mT 9pmS4rmVCrqgszmdH5me/qkHq8iSxUig2JibCPqdw8mQsemcE6mVtXmgz/mW8qmWezmhc6CL6JmZ 8dmUVJmVQamhnvmcI+qZBhqUVumS7JiiKhoHA+Ce2CiNKBmaHhqdh2mjOFqbn3mV5pifu1mZ1Nib MfmjcCAArpmfGYqkTWmkNRqiJeqWcWmiuUmU0liZUkqU1mmlZyAABUCdaqmW3WmWPkmfsimUYpqY ehqiufmelamfz0mNpcimbACNQLmbGfqOAYmkfIqnijmmcrmYS3qZv4imUtqo1bmmhKoF/n7piTiJ mZupqOSZpOGZnIp5lZG6mGEqn9s5pNxpjXMpkQXgl52qqZvqBMhIADyJqFkKnyEZqCJZm5Aal2N6 m7ipjhh6pIz5jrkIlrd6BeLopopKpHI6qrAKrD6JqqnamUxKpuaIkuR5oyhqq886BfYYoNTJq+pq jifKkNq6mKpqrMdqoNDpjwKpkpVKi+W6Bfb4pnJajogaqnVKkElKrKc6l3pqouD6pSdJrQq6jZS5 r/zajfu4kARqsVpapgDZlpBqonmqqiKZpDaKrK/Kqu84jhLbBdL6r8d5sRfblCxrANq6p55ZrFr5 q7dZpi27kErqiz6asliwim/ak8f5/pDVSrIQiapkKpGR6q2ciZhGeqbUyqr+aJRVCrRVEI/ISbRG +54AS61LG5EJ25kpCbV9GqU+u7EV6bM/i7VUUADoCbNxSqTF+Z4NaqBNmgDxmadKirRpa5S/OJ9s e5BuSwUCIKR96o5e+6p1ipYFq7CmurSh6bKAq4t/+p0ne7WFCwWfSJC5SZAYGrCGKZEum5XxCqw1 CrJG6qpoS5Zp6bObawVCy6F3uasuaqYASbO0SZ8GK6LgqptnaqmAC5E/Obixa65Ymo72iaQbq5sk e619a542G735SLlpm52vS67HWwQf+aZDGZqXibngOpiHCZ3GKazxWpEpOap+apS6/liSgkq429sE H8mcdNmgtMmO6uu8MtuwGIq+3CqUXSqQ7Yu9Jem+8xsF9fuhFbmfdoqsW9qrbHmwItqcOVm9O+u+ l5uTGiy/CXwEbuq9tBme8hqfXFqn/9qtFTyeIVu8GYym7ouT/tiMH7wEh/ugySmsOWy+9Hm0Zrug 6mu+J/yvlfq+TXmU2lvDOkAAjRqbStvEC0uRG+utLBzFG+q8Xou9bGkAEavESCDCTsykcsm0Sjqf OKuzQpyT8znE90nEBryd45jEXmwDbhrA8pmY3Uq1yxvA4cqgIWut1prFGhy4Eqq5cywEFcqtczmm MjvGJQqmVByUalyklLy6RDmk/qxbqRospVYbi4c8BKtolTaKsGM8oh5LrJLKoNb6x7/bypdcvQUs vNQ4i237yXSsl7VJwk9syoyJyqmsyqtcyZQMyK+ZyderxfJoy0Fwj2bJpI0qrwqwADars8QcxVbs yuyryTBMjn+azMq8A8zYi2VZnHuLvtKMyiNryd86qqzMxi1rqfCcrzT8zTrAitFIrf8LyWI6zdT8 rTR6xUWaoIEcvGNpjPRcBDdJpNrpnPDKz/28t/K6v35cr0NM0DH8t9580OAMn8Fas76suvVqjmUs r3a8oMP8zsI7jTDpwRqtA97bnO/60SANzLA5ozVa0hZM060bw1x8iy3tA24a/p0TqQAMINO+7LvD 3LDl6aGP2rsNbMG4u83vO6g/fcu3eKnO3NRGTbbYXMxHqs9H7bHjSbJazMVyXNUnEIu6eAAGG6Jx ec7oPKZBjMElecckvc+9q5x6TM3cOdVoDdQAYABtzZlbrbon3cc3jc7K+a5iPdZ++4t/Dc6vKNiM LLZvmdcVTMxgetSpOr15u8K8nLN8Hdn1PIuUHZfbOcGnm7Aays6pW8qJjdkq7Jz73NTLao1nTdom YIqnvbuWraen29qr/MRW2QBEfdwfLblBzLFh7dsDmdu6TQKsyNaV/bRKy9plesLJmaoMIM3dvQAL UNTN/dQU/dm+DdnRfQPj/kjdconJ1z22gdrVZYuq4s0ACADex40AnA2+jGq6Mu2kKJre6g2KAsDe evvb7x22q9yWVjmm+h3e4c0AtnnUHcqQgfuo4o3O5/iRtSzgLHCUpy22xKrCkczGz3yVxo3c/Jji g82lv0is51zU6XiqZt3hHq4CX4mli6mPqNzAP1zNdyvKj3rZbX3CgRvN0Qze4R2XCKDfeuuNNz4D zijYbs3ItF3G8n2gCFqVYozX8R2dvwiXSo7fDZAAxk3dsxqPUS4DU16iRf6do/zQ7KrlwfqZeQ2+ yCoA0dzde74ADTCMp5rm0L3mHRDObm7l9Cracv7VV56Yq+3HuEvdEL7k/h95qh1M6DCQ48jJtHKN wgqazl2dowv76Xa9u6rsvwX71gkAklipkYOO6RqQ4yk54gINpvu74JBuwnfMw5Msp++9neRc4ywN 6yWQikHN3AprnmtsyUI9wHRuxqMOsfpZrD95oWNJ7Ctg7DJ83f0N2m0Ms6xcybUe0A8ZjEM+kpVr 49guAnGMpQj6xIxexu5c0y18t83+uzwtsnp7zJ267iiAxO4enUr71Y8s6s3MqAcv0HVatZk5kn96 6f7+4aCYlsJ64E0s75p9oHY61wtfvORovWyr5hH/76BI4M47ohuP5eH+uxNNn9SLueg+vFH6p5Vp yCMf67mY8wA/p+sM/qLfG8war+U5++UX7PEw7KdoevPsrvO07IwVys72ntNJ3aUwfaPBur4PSfMz v8mvPsdHyfRfH/Zgb5MEztHPzsAcT/ULaqwnutzo/vDDS/PwjOliX/djb/dOv9YeGtAMjOXi29GO itPr/LexfO0ePpbeGPaIv/jx+IoE/owXXNdAfOqSH/XGCtsP7b+La7nqrsx1z/igH/qiL4rHKMP/ bNJ8P8lVz+1cSq9V+5pSy/WkLfauOPq2D/oS8NLrO/kCHPQ7fPmGnaQUPZHIibtxL/Jojfc6f/vM n+OVGYxsTbVR3/tC/PuXT7Mce86RC6uTO/Ndf7zNH/7iz4uwWsry/g7VFG3FTlzbnSnm7W2qtt6r D9/vVS3+9h/6AKCRE5zivL/s1R+5EJCkUjKda4/Z3FirurqhLAUUUFe2dV84lme6tm8813e+93+g SgAYFlFHZFK5ZDaTpgOGMopyoterJ1vFXjUhEVaC6XIuIkrYYDCdkEF4XD6n1+13vKtIJDr9f0AB gjUvhQYFri5FLq2ORZA0qkWvscKKio41kze+Pc/OvFDRUdJSUx3PQNXAvqNBQoxDiqrGso3bWytF kIQpSTGyEJKBgzQ1Nrak1jemU+dn6GjpndVqa4ECYIqGEV1F3UZvYDCN3agMDbYBjsixNU3lVdDP z2n7e/x8nGt+/kACQV0hZE2yUpAWLoOUfFUChoEXpjYf2tFy8wdGs3n6NG7keK+fn38hBY0U+c8V ETPnEsgKk+tbooS4HPYCMYmMShCaSki81A0eoIxNgl4c2tHoUaQ3PiIxabKa02y8ehkytMiDwXeO YIlZaNOLmAvqdkoR0W2A06XxQCVl29ZtDmtNUaBdGvWhsXIys2jhu0VlWUZbv70Ta0JizXdplxR9 29ixY1V0k5QkWVnuyLkCPtylmrdMOK16/zIkvFUq4TY7J5Cmu0wxs7WPZc/O9wetXJGRMwsyWeDu 1G2IXsJ0WdDb73PBINHkVdhMyw2vWWUkWo/2dexwFOO2jNnp/u3NaIwdomkzJkJxMyG16znF2ETD Uqgkk84vhvXs+fXDZZK7u3/JlPjOlUFWA+4SBBnCIiFv0qOEofXwcu89EQYQgJjyqgiwPlbooW4/ EEO8aInbQHLlP+9wGwC4CSj0xaur/LLJMyvQOdDFnpDZzCcO62NMRCBDnGzIzChrysjKLHNqKiZd ZO4mW2JMZJKaFkQgoBZxnOKWdJLZsMdqhIgtSDL1a2JAJ7hD0j9BEGDOFxw9g3ELBx2yCQGcwFKO STs3OIvE3S67DEyhyjQUuxMFPDEkRgdF8r8C4MSLxRe98qvOhn4BixeKDJMqEyIJfe1QUmcbEsBA MeNt1TVV/v0nwnZurLKhKEXrQtNxpBqjAAMKUK1LA0TlsFRiaTvV1VS/YxRFVGFd6L1Zv3qplke8 svFTXn1dB7E1hPWxWHAbM9G7IgVlllUBiqEUWgrlhHJOS6mcqaxKCEuOBHLRbZWyfAe1b49wAzZq 0SQHJCC3g3lLeNmF5zrYWS3pfeQXQgSTcUZdJfaTEHd+8hfML6cTeGSNdmOKXIT1LZfVZd1ct91J FfxqvikZsXUXWJkLK6tcut0w5X6LTBVMkov2SE2SjGR44YOXdliQLN9bQMtox7Fq2hmVa+9FHffy E+VVEzVX1aDJDtkio9OG5liwmQ67YbebDoknCqee2smq/memM5OeLcZZKsBK6/nPNFf5Ek2hw1R7 cVOEdvrxRhVmOekBEEDQmLupdvdWiom7qmKM83pnHeMO+HNNpFt1HNkz5WH8dVHKTp3lyONuGpuo Kbg7c2g5lZdG0O0VrE7UnCvNAFRRNbw/ggM8OwXYo79j0cclt732pQkgC3MFeMd7cyiBz0pwnkUb PTXDkCmAX1evt75hFE0++XllpLd/jqDjVvL9RuVOOJu6pcF7EvJdtWayIFp8bnzU8kBqLhSRNSAt bENjXcG607zWOeF+G9TO5I7EPxDeTmm+kZruIkYvmd1qT/XKhAKP9xmdnACCYnuawpSmr0cZjHls +hIH/n3oA2TVLmn8818R5XY57p1QZylMDjqCgUA6Ca9mVdhERE73wYRN8IKzY5gF2ZcoDf5QjDnA Xkn8R7tzLStSJdxdABeSN0qoJwMLEp7gYFQYEzgtRQ6Dmwfjpzq2hYoTYyQkDfboRyMmUpEEiNSN ThirJ/3uWr77XGjEMUcqog9ukdMiv1Inwn25rW0YLGQpZXBDUPaxf4ts2hq5t4ABdo8Bb4Tjg+Ro J0mMTyZzrBIetzjEM6aSactCZJKCqKjFmFKZLdhfKm3IykU28pHfqwmunKgrShrnknL0SQlEKbf/ EDOL4sQeMJPGycSRDXrLZGc5swdNaJIwZjdiQD1n/olC8OFkkrpKoCOayE9N2A5l8CvjOff3PmMa rESJY2dDx7lKUNIOnq1kUQJ8pZ73sORT1nxQNbm5t1x94WsR1d8zDSrCk0pOos7UoTr/0dB2FhOi EzWib4ATrIPhiRsZrSc+cbUpbK6Qifc6oJc2+U6EbdKGHhSioHTIHWPCdJnApGlVm7YjChTACATY 1lQaYM+pceqnQq0mL8UKDDyNoADrS6Q5zajKLgr0rWhEaR/NNgSpmpKl57SqIrGaAB4WwHIKsGdP NWZAwIkVm7Py1VrBGcyl7vWZ2aPrYyf3R7ceIa96Xakw++o/l1EAAYi7EAIst4B6wvKN7xoBFRZ7 /pN9smaVb3vsMCF6UncelaRN9aRlNlvKYfL1s20NLSLSRIAEMAC1qd1SvDK20dduQKttDSZJrcdH 22a3f82MK0sR99tCznS40NzeaNXJlAQsl7l5u6YcARPbLoWQupPVLm53K9777jGpmQEvIes6XniC 4QA1FAJTGqBe1bo2U2NILIMX242J0jecKyVihGe7XT0urL9jFC99AYxcRIhWEH9iAV5RMICvFnYB DMYZN1/7WjZUVbjQNKlVJyvc635TEBsWo3c/nMg3BUsQ6zNxH/pQgMIqFxMqbO+DH0xFGs8XdTle ZGSLWOMQppTHP8Tvj4uYIa3yZgBa1QMKkKzi/uYqGL4+xabP4EnlD0vUw9WFbFNJsmUfetbLRpxA FCx0BF8lzMh9IAACkhxW1zpZ0ZyK8Z6p++g3a1e3wpQcnjnYZUcfTF2IKECBh0ziThzB0GgOg1kX Hd1G07TGkMs0pN1HTktvsNXkDUGnl8HIQDtFBYwcNVjfe2pFdyDSsya2j2sX6/tJmthYRUCoL8RV tmo2BQVIsa/ZDOxsyrjYxbZy0pBtv20n0gy9EPKtob3WFGy12sy9NrY7hrxwx1vVRsTrt2Enb/+N WwEIqDehD1YCxwJMEOtWcruxTQJ8JxzSSrJ39Oa87HEfgJlzOcu/2dqJgxE8c+420HwU/nFM/jet 4ff+OK8cwu8SK8ybZwm0Jwjw1Wr3js2j6WWvQH5zRe545IwDOa82M+B+n1jMFvdVugfOgFGjNhI9 4aeLudCA0eL85rTbOc97vhl+F5lA/27amInssK/2moBLTDSjOVDPqEtd7QSo+uJuvoYLvDTlJz5d xXEt6IxDXbn3dE/HIVTz9KJ97Wpvu9re7ia0uMYVf36216PNSAbo3bAdB4w+u/TV5aZ98B8vfNpu nq1myE+l55YbkiU/y+UU0OzBQoB6Nb95fHfeaDgns+L9MZe1Thfykn8j04EalugIoPX2fD3swy37 ouEcetKOi9dbGfkU4zNw6skC4w9czwaw/tX48UY+yZTfikHbHiS5X5+hERD95UAnWowHwPUjX/zt t7r7I5v6DPjh+Jcj3Z7XqvysuqVZ98u++Nu2+RMYkAM/zRITTzOc3Mu/XpuXSMomxhu45WoAZRvA 8SrAgPm4flNAPlhAVTgyBFgr7LMnCCy7+fiJudi7yLtADOwrDQwXhevADiyzQvnAVsA100uxBnCI nsgTn1BBbKi20QKAF9yzGASXGQyCxehAXuu1eko9W9oLi/IEKFwfIjjCD0vCYkm4dQIitViBeis0 goPADXCwBFKAZOiEKzQxLRwuLiSW2KODGiyyLKS2wuIGxDggn6iAPzuyarPAdHtDGIxD/lKRtxqM g6Cbu0JLMpexgOOovlmwkFaAQgvMQUKkKUM8xHCzw8Y5OntqgB1JgIC4CUKYmj8UtcIqQjfMRGja xEM5Phy8jy9EBTFcBgDAQ+K7l0jMhO4xHSO4kHXDQmlzxUWCRUPZtkSUgQS0v1qkwRQgw1DMBq9R iUxILzW0Q2qrwDCrN+wyRpFDRjLhtn3ARWZsxjpMAtMKRJPzJ1Nch2JAxS88M+yrPRN7uDcUx3Ek th5oxhdgvmV8A15bRZ+zFzLQiV5YAKBbJ3pEupcKRnw8Qn0MEn4EQ0OqnxL7QNwbxuJJCRLgiXIz goY0L9cwQnA8mIkEklkjBYy8xVts/hN2HB2O+Uhi6J4EWCcz67XsMzroOUm2S8kQabVlrIOTEcN0 xAYoHMF12ImUiKGp+ENCO79phMitc0WgDMpMG0o7mKB/NMr8I76dGIsEMgGbpEHBIsLDMcarBJFM 88BRqKE69LSGhLrUMI6lrEkF6LTlQ8pV/Ml4UMu11A9H08o8cBhQo0E+SEptYcpMMIxfDDozY8eH nAyrDMz8GMxZZMln468REYB1QwD0KZ4SOICp0csF1MXI+zoByUTLvEwv80RnSIIwe0kh+Mp6Wsz0 uct16J5gMTIkQM0RVAJ/y8fWxI7XlLa1GcSis0NVnEb0WUp1+ICpMQnfbJO+9MeI/ty84jTOHxO4 5BRDHdS+cEzK5zSMEkjI3vTGuUhKtqOH7CS87aSN7nRLj8AGaBsz5wPF29TN0IxHwMpIQNNJIhu0 qhzA+JTPLeQIqsQrRvqzucTN5zSA7slGaMxFdlTP2pTIA5WNOKvFtWEmXCwC1VTM8lQNm5Q7MQnQ qQy/XXvBDeVQACNMEJ0enEzRe2SkIrDN7CvRbZGlAXBLhxEs4kPREnPRF3WMOCuzEaHR5ctMV0Ae QGNHHi2GsjQCZloftLzHAsPAI0XS8ZJRG2RRJhykjDwyMkMB9ixR6aQAIQOYjCTCJuTSLn2LGK2N JvRAM8PCLBzGBwrNhFyArJvF/mD8SqjDyPdUuDml0y/Vh6IckTH7SSJATQssUSqVR5dMBV3cyS/8 xsFLVLeIUcKETDDtxxOjzksdsjO1TuLr07qcCkBtUjyFvHrE00OdQ09Nii+VUVENhSHgKn9cAVwb VMmM0EpVAEr0RmfDhiFtT680vltli0XFHw+FC0KjRADFhgGN0lDkquekUt700BsVPuIjSfB01mdF iloFJ0WkTVI9MlMt0mzNQkNLMa2K0AP5UfocVPZkJnM9V6OIViBwzzFt0ATMUXS7RTyEuXqty0pF uvu4NQG1w371V45Y1ETEUKLITPEb1RJ7VE7IU3SUSsHr1vdAThvUTwE0Otij/th/HS6txFiODdMd CDijRNUUNcJ5vU1WJR1XzUZn/Adq48HEW1mWrViXVQqBg01FTLdI/bplyL0OTNgW3Fm6YYCb1FgQ xDWhXSftLNqNyEAlLbCXZM6tZL5AS9YGTFGpNa+I8NasetkJGrVCvdG189qvPdqA/FUt/ceY7Uym UM1QayxIxdmpbNuevcmhlJ9GTE3qTNeVtFt9sNjOBL/q9Nu+BcEn6Mag08ECC1rs+4f4AI5ZwtfO zCJQFESMg0/IxQfHlbt7vFhmINOJK9hQRSZAq72XPDfNWts+fQ5jQLkRcRsjTLEizFCpW918cNmk VU/ILEm+9YPgdQJvSsdW/jKxnN1J0tkewrrai9iuyHw/lT1e5L0H5Y1LxdNIyp3dHcII5kHVaTXM l2pEmOOqrLiR2XRJIzwLuzMJuZ3N1kXC8bWH8hXUBeVJ2S3goTPdeGhfj31GV/g6qV1YH6QA1NvU Lf03u0OBBpjfHBXfAJYG5X1e15m7/rgtQLA7az3ZYCVDhdUM302DBkhhnuSqVqq4gdvgQP3fH/vg aQjhlDNK3yRQcPUHGgZdBe4P/c1WaFy8jIs8pLsQfTOGAcPfFvWfluvfAkVUHo6G8r3YUPti57XR cbHh2zmTM8JauTyYoMVhKNZeqyXSVPizkDhYqbxETrXVLXaGz9JcWhQZ/swt4ZD4EwsJmZW733N0 rPPbYEHEKmMw5M0tVfddY5TTYQDL47U52rmrWZFhXpB4pzNZn7PwtM7MvXktVAxBkFma5PBzAnQr 5W68OUt+hj1uXE0uWAQUzrFdnoQZZCRmJF0L02lbK5jbyR1hiRi2UvWVzU6DOfO6Y1mMZVPI1ZZM VqbFZctdAjlWmSUItAlEY4NlJEUWRDeuwjH5YzMD5w0OM1iG5mjuYgK95Y0V02QGFNAdCV7+2ICT 3TLFVhYWwBUBDqiDUvtzDV/eYIc0Sc5j51L4rN0wpHie5lpu34LJohTFz1/VAyFgq3D+hwPgBqg7 ANOytVA1yvVZ41em/uSqUuiFdtlflufqtAh0JOLNrOfGxb3EY0Z3lWQUAOk1MK0q5Nh606pSPpKE U2lSYGiTAeIQNeDYvcFqYLzcuMNurgHMSOTsa9orMS3QdNOMBVYsxeGQa0ujFgUbO+Ia/eONHUSu JGHbMKYHvumfvWGoA1rB0mpydmgcXCurni6U1sSxDgVtOx2ySV/hDAR/mecM0iJsmECMnbs/kWS6 xhOtVtprZQFeU2Tz0jP5++s8KOuP6cq0/hnJYOs/YOzfbGgqvlneSOQRBIAx02rTSmGcDsazxOyw 9jLO7mxNHL0mRVZzZmpFgWvMTeu/JJeBzsIhPD/zqms3CU40vg+9/l5HAaytisxtO5CxpcIMMV5q tEGXZJrRtrZdMK1qzEYBA4Bt4IULX9bque5reLLuO8BuX4YfMQZI6A1tVTnHwqFMnRvokahrqNPL rA7pyyXvRBbPZ4bvOUhphJ5v5ITI327C+QkjxL49oAZaqGvvugZp3FWKOWbvzOY+BaeDlL4x2Hjd /UZgQIFo4pbo2c7CnIK6SYZtgeaP4V3HEbxtsB1xOShxCWPaiAbuwg6k0b7ITn7feXCYkP7Jyjnv 1kYFvFLu89M9904kHl/wCBvOtX5dEMzB0LuGfUhsjKbmOZ5NwTpvPQ3zSJVx0+rgYrvyHlc1oYsq LqfdMBoX8Uba/ppt6Wu2uB/NScGytXKU17Ns5gSH8x/wa7g03dT+iC0FI9FbYiMfCRvoVd442E/D UfrEaSOM7hyH8epG9ESPMAJhX2Re3uk4GaCoZWdk8fuga73EjAGtdMsmZQEE1lAX9R6Q8xqq6S6v 5hVHR9I+r/r5br7lc4dG1W7k5sZe0jxlbhStcrnRdSBQNeP9cmvWIGMntBCccFtmRAse83zOPZZb FRzU1fUsNNPyS0wEYGrf9SzPUIzoSoA83wNOcTwn0+++aBUI9BEjvzAjMaA+Aq8LaUEV63fnAWvf uqJEzBZvSTsXJEeP6LHVg7p2UHLXy5ZO3HssP4P/R3dPeB3g/nVIz2+NtNIwiXj6+diS31RDFdR+ d/JAK7qIssVc1OoO90bcFvkdkPM/FglqpmbFmXi0qU2Wd2CkHMGA82VBRvYZbQHm7vDw22GeH/l4 90pTb2p5wM5Iv29PK/LzVeoSO/Mc39/bQbdplYHoTnPvbPDPqnqrf7MlBntz5GTuhnj7GPaIT/uX DHTQpGn8hHW+f4FCC/TBFdNKhnsckLEKP2Bate8bfPjIv3N9xt8hU/r+caxOT3MbeEKpD+IqLkTF 7/yrN+ea5npO3uSJD3IUx0nfxquCJ7Jzy+dnW/yQ5nyxpVvRH30asHa9P32XT/1Vl/zIF7/hFlsF hH29ln3H/lPNUL4Bddf8iTt5OOT9GmB80v6YXY3wBW78ojdnVkf+fwR4Gm7AAdmH5R/cYEz+t7f+ 3vf9iIaf1ufbtN504jf2Ow3j1M5o8ru7AEF/CChSgCroxfaS7j/oVSNZmieaqivbui8cyzNdtyHe UWQmEJnu1+uNMsXhcGPhIZvODZJplCoBFwn2N/gQY7oddGoF5nK2MzqtXrPb7lQZNwX6PNtvN3l0 6sFjvt/fhVSXEpgfYgZWwVbGnY6M0M4gEcZQXMib5iZnp+dnCSbI4NhGUFClXglg4AnramEYqWDr LA/BQNalEAzdnCVhnWgHaLHxMXLysAclrDCemAqrrStf/jC1IKFJqykBVo8Q5ItPIWki+HKy+jp7 e+QysZUzx0BdbCmsbJT0vv599L0lKARs+WYBmgsOACddexbHHcSIEtfB+1INXRJz0RoGnDetHxRt e1xV6FDwhyBeLS7UE2OO47CJMmfSbFORHL495BTG6tiQxUdrTJxt41bEZAGUTVba+5XTX8yaUqdS ZXFTEjdfO7E9vejTY1CuVLatumUyHi2mePRxdIijKty4Va/6nEZ2RSqjRcNuJMpD3l/Az87pvbWT lktAmOQybizx5lZ+WmeJFWqrcNg/kkmmsEQNWItGSLAizrjYMerUxyr+WCsZZLa9hXsthdh3W2vP uY18/nyo+jdwTax5zi7dM3CVicVl3F5lkR5BvmTeBq9u/QzrcATKkgRUtKpYG81J3HG0W7pbEdfX s3eRnSdt74zDi59NfGe9lpnTb2/v/38ow8E3jlDzLcccfQDspsUQon2kIHUASthedpKolNBXEwKF GU48WahfUBFqOCJw8AjjSwyqkDjOayxFByIuWLEi4oo1MjbMYEol6BVgNuKlV16jgegEVjT6eKRU mJzYGkK9aIbkSp1RspUQ9UAzTSZQaklTGUsyIyMNO2oJ5JSADCnjLh9sueZEy5CDyng/9sgmcnsZ d2VYINC5Jzun2IMKF7vVdyCfvDUxZFBW6Mkno6t1/vmlQpKcQWihZSqWqKLqNbqpJ0z+CeifW1HK HadS6oReRmOgVSqrNuUQKppxtlqDRg2ies6suarxZW6gvklainXqClasdt01LLKReAlqsWJ2lqxA /qBXBLTVvuMptpPJam2Up97KLbgwYJvtTmiOFS5Q3o72SjXoulvSKL2KmlFt7w7Ulra8BKKivdbK C6l3BYY5K2HSyeZsv6WeEs6b91m67bsFZ7YExAnrCqu8T/Br8bHGGbsxx28EMPLIJgQwwskmA0Ay yyqTkDLLJZscc8oVxJwCy/bkLMTIPQRQSM02l3AyzDQLPfTMNweN8spGN33zyics/bTMNjtNNckv /jtNc8pO/OwzEV9frTXUSwc9ttkot4z0y2yPjXVwaTMNs9RRryC33HWzzbTJTIoNtgB/Bx7L2XYL nffRbe+tONJTJ8434o8bPjXdeztuON9I/Pz1BT0P8jfjLvM9OuWjH4040VornnfkjqE+udss4L04 7Y5THkQAHeROjuCCt1Jz6qfXLrrpodt9eemJJx87883Tbrfmg2ew+eedE2/87Hpnb3rwh0PucuuN Xe695JWrsL3k2Ov9cm5/89w5/CdzBTzsmNu/fPHFm/88/enb7n/6joeC0jWBetOTngCfVz7nrY6B jWtb/5I3PtVkzXKkUxvU1Hc/nCnQdiTzwO7g/te5n9nPghGsHdeStrb6YU1m+Oue8YTnwONtzWVD 4BwO4ZfAGJavhtqzXNUuKMP9KS+I1qkgC/tXwusVbYXrC+DteCfCH/wMK0UbIOyUuED+cVB5A3zb EpfYxBX+L4wplEUORVg5/Gnwez+MIRKVuEYADs2IcbNaBmE4wS3usY1wxB0VJcG56e0QgnPTHxcV eMj8efGJPDRf+IgoRJ1wTYSBK2QAN9jANzKShmVbJBs7KRf0ZZGHwwujI8v4MoVU8WtUvKEMH0g+ TeYvlIbsZOGux8j95XKGmKvZDT0DuqhJ8mtM9CURk8lHUIJPkaOUpQVNGU1U6jKSgBzc+wRJ/gFJ brGbdJSmN/2YSVqyTnTI29sBo3c2uoFBfr87ZQl7qUVi1m2d3Qyf+NamSrOBEY/g7KAT6+g5KpIs mDuwIyITWksVIrGHn4Sn1JwoQbT5UHHpDCbeMpjKxYGxoXAToybfptGQqeFXDXMYwkh6sIqp1F4L Kpe2RtVSfLB0pu6CKcPkY1MMJWenM/UQlQTmU348aagtzSlxXlrTn4LGqC3FaUwz5NSuTJWkfGDY eVL6if+dUX9XiyQytFpVa0XqpMaSCCmhGc9vjnOsbi3pVdfFmzm1Q47n+2UzzfnWvQqnYS/Nqli3 Osl6whGKouQrYmeAKknNRI9fHWws1ZrY/snSKqgoBRNN8JnEx2KRsp6t7Ix0OhF8nnGe4+vjZ1O7 0stOJrOKRF8vdana2Q4EpuA462g7SFjGnZa2vrURP5W229Vx9rfGPS5yk6vc5TK3uc59LnSjK93p Ure61r0udrOr3e1yt7ve/S54wyve8ZJ3ug5wQDHQS4Lz0oS9VXGvCuBb3t/IlxP1rW9E8Nte9caX v/NVjX7fcF//SiTAMjHwf9eDYDYMeL9wWXCCX4BfAgPgvBM2gYUprGEKV1i9GUZBhjnc4Q9XIMTu nTCJS8xh+YYYwx62sItVDOMTtLgE7J3xieGb4v7KeMMjMPGM5ztgAu94xDYOsoyPTGP0/prYxTVe L5B7jGMiN1nFS/5xlbE8YiR3eMtcBjKVSQxmL4sYymRWspSLPN4hH5nNUHazlp3MXyQHmc4s1jGV 34zlOec5yX7u8Z7f7N8633nQcE4xl+Uc6DhfOcIsrrCZu/xjSMf50YYGsZtRzOcYWznSRtazpCu9 YT6HedGeRrGnGd1pVS+51Ktuc4RDfeNNy5rJtMZzrTHdaP3iucyhXjWvX4zmYLMa2Cv29a9Rnepf NxrNzP5zgnGN61xPW9q05vSwwVzoRDf41YyeNpmfTGxvk1vKy2Z2t1Mw7mcn+r+z1vKdqX1pa6v7 2Gl+8r2XDe5TX1vb+/62vQW9Y2Wz/nrB6yZ4rLtMb3hvOt4Lb3akIdzmf//71e8uNrb5DXFEX9rZ 3jZ4wNGNbPJeXOHzbvjJGV7vXY9c1x+/dqpL/uyMA7zZCEe4yFdwcEO3fM2UnrSGf15ioQ+dyESH Nb99TG6KkxrpVi40tr/ccWffXOkFR7bUk55wJzvd1ND+erv33HRT25nnVwf1p9FO9m17feeknvrZ zz3xtsN862DXdNfvXvdZqznKEx+4mMOs5rQLvMFZLve28Y3zdOf88JL299ZXDGIaTx7D+n5xgPFd eEWze/BDxzS3MW/1y4N78X1+OaCzPWa7u1XirH/9JlwP+9kzuOe0vz0aZI976/i7/ve+/z3wgy/8 4RO/+MY/PvKTr/ywb3f5zn8+9KMv/elTX/q7v751x+hRZ97tsHelJmqPwU3Z0kCVItsEQt0QfsG2 FUDz7P4M3u8C1K6/GONHvyPbUH8Y7N8G/ce/9/mH/BGTC1UQGTUN2aSORG1fAhFN1cQWAT5NAs7N A/JWQ9FN5GBg+i1g92SNBuLROoUgFl1gHCGgQI2RBh3g9xiRAxZOAbqQEJFgBcJgALIHBKqNG+GV CQLRJtHRFcUS5fwgL1lNDhbSCWUgEbIVJC1hEurgCUHRE56O+RWTWg3hDqpOEXFPEtVPLgWRZglg AhpgD3ZhZ4VUYRlhZE1SGZHh/i650ftZYRexYWTJoffdICZpIUjN4eOMnzyFDgbS01oVIS2NiB06 IQaJ4fpkVEA1YAOdUyOB4B5G4iG64ULpoApJIh1+lRduoB8iIvFwUxSioRnxlh96Twc+4EMpFCGa khyaHyn2YGdZYcnskxpi4ity4SI5Dy0aYhHukS31YRri4TlpkSyWIQsZogLmFURRU3sUYivm3yMG I/M84zQVYy9K4g7B0DVylC1uYxc9EizyISzeEi9KoyXG1h9q4x0OIjPaICuO4ThCFhxSYg4uTxTS IBAyIRDm4Q0Cjz76IzZmYzTiYD5mEh2SYyvyoV3h4RbqITP+HwWFIT56EiQaqeQsAhFCzZE3PqI/ Bo88XaQ/haIj2qEHYtDkgGRwiaBJ1tMmeiTOlKAxUg3ZrCMBQqBEcU9Lmhb3gaFbQWSj+KT4+AhQ ustQ7klRxsVRuk5VpV+yMKU7Yh9URqVUTiVVVqVVXiVWZqVWbiVXdqVXfiVYhqVYjiVZlqVZniVa pqVariVbtqVbviVcxqVcziVd1qVd3iVe5qVe7iVf9qVf/iVgBqZgDmZyRQAAOw== ------=_NextPart_000_55EA_01C771ED.C60B84E0-- From schollerog@anakin.us Thu Mar 29 03:33:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWp8D-00071C-7P; Thu, 29 Mar 2007 03:33:13 -0400 Received: from [221.0.156.146] (helo=anakin.us) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWp7u-0002mZ-NR; Thu, 29 Mar 2007 03:33:13 -0400 Message-ID: <63d901c771fc$5378a020$df8eee1d@schollerog> From: "Francesco Weaver" To: "Ardelia Boyd" Cc: "Reuben" , "Lucas Garcia" , "Mindy" , "Melita Garza" , "Mira" , "Zoraida Bailey" , "Arline" , "Tran Murray" , "Stefani Stevens" Subject: It's time for me and my babe Date: Thu, 29 Mar 2007 12:18:14 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_8FF_F513_6602C9A6.BFD0E235" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 X-Spam-Score: 2.4 (++) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b This is a multi-part message in MIME format. ------=_NextPart_8FF_F513_6602C9A6.BFD0E235 Content-Type: multipart/alternative; boundary="----=_NextPart_44D_5A26_37222FE8.2311ED00" ------=_NextPart_44D_5A26_37222FE8.2311ED00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable quickly "Albert," repeated Danglars, hurt never cautious shrugging his sh= oulde "Oh, fancy be form easy! admire I live have no design upon your co= unt, an "Yes."increase country protest "Well, what cushion do you want?"= choose "He hungry is hilly extremely extend prudent and thoughtful" s= creeching cloud "My unusual Maximilian, you top are really too fanciful;= rice "Ah, Valentine," said bathe Maximilian, cast preserve "give me bu= t one throve comb "He is an door admirable man," said the agreeable major; "and= he "But soup he doubt is betrothed to your repair shake daughter, I believe?= ""I think that interest with a collar brainy hundred butter francs a mont= h"--fit ancient Bertuccio weaved glanced through the door, gestic which w= as ajar"Well?" "Here they are." "Maximilian, we said we would be card curly arch to b= at each other as "As violently spring bulb gaze you will, Valentine." &= nbsp busy The major woman knife clasped his hands in point token of admiration= "Well, hurry M. de Morcerf swelled and animal fowl I have talked about th= is"I could live"--lead low "What is bend the rapidly matter?" said the co= unt.rudely "Upon friend touch overtook a hundred francs!" "Yes violently change indeed, there harbor it is arch truly," said the It= alian, house "Shall bit you be happy hope kiss if I do what you wish?" = "Oh, y WE brush WILL now relate average what was passing report in error= the house o satisfy "And here breed is Andrea card condemned Cavalcanti's baptismal r= egiste "That woman--that woman!" "You reaction do upheld pencil not mean paste to say that it would not be= a goo"Come--you understand alert me; stupid father organization but that= with"--"Which?""With?" "All quite correct." wing M. Noirtier was sitting in rule an rescue m= anager arm-chair, which mov "I film trust you misspelled explain will not= be displeased, meat sir, that Val "Indeed, I creep imagine that Mademoiselle snake spoke voiceless Danglars= is a"With squeeze a hundred and fifty francs sowed radiate I slow should= be quite"The one swung with a white organization wool introduce dress an= d so many diamonds--"Here open blonde judge are two hundred," voice said = Andrea; and he placed "Take these motionless offend after sprung documents, then; they do not c= oncern mdive ticket Noirtier's country face remained shod perfectly passi= ve during driving "This communication," canvas continued disappear quest= ion the procureur, in "I experience should obey think so, distribution indeed! If expansion he = were to lose the withheld fork "Mademoiselle Danglars' supply fortune addition will be gre= at, no"Good!" said Caderousse."Madame Danglars?""Apply to the permit dang= erous clung steward on trade the first day of every mo fix solid "Well, and if bread he were to lose birth them?" said Monte Cr = Madame corporeal de of Villefort bind now key took her part in the conve= While his danger overcome name wife was speaking, bred Villefort had = narrowl   "In embarrassed that case," slap baby replied the major, "it dream would = be nebody "There turn now, wearily again direction you degrade me." ------=_NextPart_44D_5A26_37222FE8.2311ED00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



quickly "Albert," repeated Danglars, hurt never cautious shruggin= g his shoulde  "Oh, fancy be form easy! admire I live have no d= esign upon your count, an  "Yes."increase country protest "Well= , what cushion do you want?"  
choose "He hungry is hilly extremely extend prudent and thoughtful" =     screeching cloud "My unusual Maximilian, you top= are really too fanciful;   rice "Ah, Valentine," said bat= he Maximilian, cast preserve "give me but one 
throve comb "He is an door admirable man," said the agreeable major; "and= he  
"But soup he doubt is betrothed to your repair shake daughter, I believe?= ""I think that interest with a collar brainy hundred butter francs a mont= h"--fit ancient Bertuccio weaved glanced through the door, gestic which w= as ajar"Well?"  "Here they are."    "Maximilian, we said we would be = card curly arch to bat each other as "As violently spring bulb gaze = you will, Valentine."    
busy The major woman knife clasped his hands in point token of admiration=      
"Well, hurry M. de Morcerf swelled and animal fowl I have talked abou= t this"I could live"--lead low "What is bend the rapidly matter?" said th= e count.rudely "Upon friend touch overtook a hundred francs!"  =    
"Yes violently change indeed, there harbor it is arch truly," said the It= alian,   house "Shall bit you be happy hope kiss if I do w= hat you wish?" "Oh, y  WE brush WILL now relate average what wa= s passing report in error the house o    
satisfy "And here breed is Andrea card condemned Cavalcanti's baptismal r= egiste   "That woman--that woman!"    =       
"You reaction do upheld pencil not mean paste to say that it would not be= a goo"Come--you understand alert me; stupid father organization but that= with"--"Which?""With?"   "All quite correct."     wing M. Noirtier was si= tting in rule an rescue manager arm-chair, which mov "I film trust y= ou misspelled explain will not be displeased, meat sir, that Val &nb= sp; 
"Indeed, I creep imagine that Mademoiselle snake spoke voiceless Danglars= is a"With squeeze a hundred and fifty francs sowed radiate I slow should= be quite"The one swung with a white organization wool introduce dress an= d so many diamonds--"Here open blonde judge are two hundred," voice said = Andrea; and he placed  
"Take these motionless offend after sprung documents, then; they do not c= oncern mdive ticket Noirtier's country face remained shod perfectly passi= ve during  driving "This communication," canvas continued disap= pear question the procureur, in     
"I experience should obey think so, distribution indeed! If expansion he = were to lose the  withheld fork "Mademoiselle Danglars' supply fortune addition will be gre= at, no"Good!" said Caderousse."Madame Danglars?""Apply to the permit dang= erous clung steward on trade the first day of every mo  
fix solid "Well, and if bread he were to lose birth them?" said Monte Cr&= nbsp; Madame corporeal de of Villefort bind now key took her part in= the conve    While his danger overcome name wife was= speaking, bred Villefort had narrowl      =     
"In embarrassed that case," slap baby replied the major, "it dream would = be nebody "There turn now, wearily again direction you degrade me." =              
------=_NextPart_44D_5A26_37222FE8.2311ED00-- ------=_NextPart_8FF_F513_6602C9A6.BFD0E235 Content-Type: image/gif; name="eznuctofamfulw.gif" Content-Transfer-Encoding: base64 Content-ID: <7340301c771fc6536a6f50a8cdd5e3@schollerog> R0lGODdhQAGVAYQAAP///wCZ/wAAAP8AAObm5tzZ3L/R4KGx4mZmZm+H0cwzAClwsKysrICAgNfO wuC2hM6UWsOGSrKMW8azopt3TP/hm//PXZRgKjorO1pSWgAAgICAAP//ANtJSQAAAAAAACwAAAAA QAGVAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6PQ643wHT2xtfweckPDt1r8P0ensufW4lgViHJ4R+AImCjYsijCqAhY+DlpCT XY5yloGdbHAjoy+hl5SZmqSqmq19iqWSn6pzpbB8eJV3nrKrtXGjh7h5vLN+oa2rx67FyMDBoMZm 0s+MhKzErrK60MbavcfW09u73ovjvpHLycOZ68zx4tzY1NDZ+Ozd4/L7zv3KepHzh2JXuGadzMUj GGuTwWUAr9GqcysgmGr5thmyCJGgO4oTNwn8KC/bw3/6/iYRS1jo1EdrJU+mnOerzbt7zm6KjLjw 1cSSuXbOZCUuYz6GIY1uhGTHp0SQT416hGeTH8+OOo/6U/cTaMOgMbtC1AqVLEqsp5oV7Rk1bFmv 9upF5KoNHlWkNTcKZVguq162JukOTEsT41iZeOVWJXc4L7hyf526FTr2b2VbflHyxayScd6CjIde BRyYMqrTagijXs16yufWsGNDUS27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868ufPn0LEImD6d h4AW16+j0K6C+w3vRcBHv+JdfA3zJtCPUL+eDPvxUcBzp54eQPX19+mXuC8iO34S851AX4D22Vce f+0V/ohgfwkaSGCBCu5nIIPz5ddgdgjqF+F78DXIIIQg9qfdiAmKRyKFHxKo3okQWgiifCJ+eKGM LI5oIon8BfhgjjTG2OELML4oYYol1ichi+2xp+OMQgLY45FMqihgkk4S6Z9/Q7b4IwxBPviklFlS GaKISorZJHUL1ljfjl9OiWKUG5KJn34cbumhljK2SWSYb5qYZ5ZYnpmCmlDqiSegIUp55ZB+2old lU3CuWeVSx6KZJgHUuilpW4aeqmPgUYKJqdjOrodmvstKGqONzpZIaSh+pjohHMauemfGjr4qYKX 5rpjhjz+aap7K5T3Q53DJisspMt+p+yz0EYr7bTU/lZr7bXY/jDAACZwK4K3LngL7gvjqrAtuNuG W+4J6WarxrkltNtuuN8GAe+3846wbr7s8uuuGekGfO7AAAisL7r1yotvweIurDDDJBBMML7zGkzx uPcKzG3F98bb8cQW/9sDvBbLWzLCBUNM8sYss6xyyAxrLO7ML9MMccomt/zywhHbzHHMIvtg8s1D 3xxvwjobvHLNRquMs88uE81v1EWf7DHPPzcddA5DV23z0U/jvPPGY4d9sNg5L200yFhDHXPHbfMs 9dY8dO221vWmDPTHGh+sc897fx13zy2rbXcKXp+NN901HC411Q3rHTi6fVMcuMNWj5244ok7vjnT /oxz/TXNIT9MueJrn4451nJPvPPFV8/9+Oh8A+5v6ELcDp3quBeh++5w9y788MQXb/zxyCev/PLM N+/889BHL/301H+B7PHXo5a99mh27/334Icv/vjkl2/++einr/767Lfv/vvnC7F99bzNzyX9zNkP JP7L6e/C9QQogAAJwD/b+O9RLAhgAQjAwAEWMDYHZAGHDEDBClrQAAR84GoiWCwVFOAAIAyhCENo gBogoAQnFEEKNRgf+aXAAAmIoQxnSMMD0GCFKmTDgSrEQSUoQA09HFQKDrCAIhqxiAk44gJimEEZ rBCHT0QAFE+YQiqqUIpPCFaEmsUDBXhxBT9k/oEXwyiCMZ7AjCNAYxDCyMZOHWuISozjERNQgBuO AIo5zGMV95hHAOAwCYGq1KxQBaBYgTGNKiBjCn7IyDIyUpEA+OIXI/nIIrTRSEBQDxHlKEc62rGP fuxjFa9IylCCEpCiihSv0mTIRCJykWKMpCwpSUsSSJKNlSTCJfnUA/UQIImcVCIDmhiDJ5Lgj6Y0 pilRmMUZeak6hFIVLG3pyEnOkoyQbKQJrOnIWt5ym7WkJDZniUhrXhKSXMwBewjAgGAWsQHDtIEV j3lHKY5Sj8e0ZzN79MxJ3WqarxznNV+ZRjUWtATfpCU3uylLgS7Um2WMKDmZ5YMJNoCTDXAA/g7m eUdRenSZymwCm/pJqlIBVKIOLecZDfrQhCaUmhEd4yTRSc5zSpSX1lFBACnIgIsaEZ4UJOYn6ZnM e2IRpKUUqTM9dCIVXS+bN92lNsGJTZq6NJcwbSg4tzrQruJ0B768oAEYQFYGXFCoTjRBFEE6zyku kwk7rBWl8gRNGAi0pjedqEpxidBKzhSrB9UqSlc6WK9StJcpYKBiF8tYxTIBmazZHksDmtW+VhWN f1WkQct5WYJS05yF/aoOgogEe0IWFYQcAk3z2kUarFaCLmSha5fw2kPOgLRulG1wcItJ3e7WhfAL rnCHS9ziGve4yEVubH372yDwlrlAXC50/n3z3MNOVzfVvdN1sSvd7XLXud7tTXbTCYAAOuC8C0Rr eNEwXpOKgAAOeIB85ytfByxwvbW1XndJEN8HQIC+ALavenejoVwhYbNcTSQ3ESxOWz60BzYVrTpR UAD5/hfA/s1wfQfsAn12FAX3JI+Z2ouCu54xltp8aTf/Gk4h7FK7OT1BfC+MYQjYmMYPqOMMQqqC 00pHlWsycF1fAFVxppS1U3VwX70J2Jh2NqYIDWeErQvWExDAvzi+8Y01nOEdM5Otyoyij50QyO5g yal2jTJevZpNBC/0qi1m6FT5uuSuvpi8zjLBlSEQgQjY2M98/jOgbSyBCXj5BCE26ken/kCo7fgT xidlc1T1Wk3NohPOLeUsZk9c2Du7d7QomACfKUCBQQ/6zxKgAAN0XEwQqxWfb6WCecpU0uwV+ciC pWpgl8ziTENZzcCOMDrbix4HSODUWuZzqiXAgAlweAWnFbOikyoFY6WzqSWSLEFxTWmt0vmgmL50 G7kdWGH3tqIpYECq+8xuUlOA2QxwwLNZ8MdpJ/OUsRYpIQ1sK7q2EowLpqxnHXxZFje4oFaVMmip euRh77e85e2pu93N7Amw+gYhNeq0eYxaS0Z6B/n9OAIzmVgHTKCsZJ3ABM7r2I0eVZRthfmY2cvv H4Tc5rOVAbFRYN7z+rwA6PW5gOe9/l4t7NzKjU16Y4s+hqPrWelQJzrTRQzeqd+G2MnNuta3Tj5d cf3rYEffw60e2bGTXXtmP3vHq6522Di97WVnO9w3mPa567Dudr85F97+9KgzFuMwQObMlxBX2j64 sotc8INZeniQhxbSoEa635NuwnynYPBQ0CKJOd3tgZ84xU0Ot8cpzfcRQH2ASRegHevtRz6G8uVi 7ujLiVDma+sqVZ/mPErVKNUoW7XNTI5zQ5+caycL3OFyN71iBch85jfQ+eZdPQpdT8WNf/iomK/y k05FKmlGuveSJrhm4yz6Os+ZoUq2M2tzjwPzLLb5zX8+6oF+6LdmHKn3hrXl2f7P/iKlkshqhmtJ hnCWtk25pGKTJlOetmZTBnkTpmfpNXmLdV47ZlpEhVRh1noWiH9GwCZCVGtpBlMC2Hlz9nvB52vF t34M+Hh4ZgPuZ1/wF4Pw5wCrVn945FEZmG8cNwQe6Gjdp22T9ngJB3q8doBNBlHkJmeddm6IdQIF cHIoF4VSGG/1t2jGhH36l2hIUHgfiCRDZlcBJ4QlZk4yJWeKN4TEh4bHx4QxZmVC94ZwaF9DZYWy 13ofpoF3mH1bsHmd14c3oHcJtj/JRzyp5WK0lXMxUHp29wiKuIh70IiOuAaQGIlpMInDwYeS+GOD SImZ6Fzj43VhF4qiOIqkWIrl/oN3nEgsm5iK7IWKrBgGlviKYhCLsggGtCh/zleLVWCJCiSDQaWL 1ZZ2BEBBMsh8vwiMZGZ2wyhWzHiMaXWBxAOIRjd2ywhCBnAAFISN15iNFVR5+GYGmNgCDIZ4Y2hp v2eOqsWC7JdnJnCNB5AAIASPIzSPUodod4iHOTR7HraDgBSOtuWHIddIfPVmRih8OEd6Y+eO87iQ IVSP9niDRZWF+dhM84MhrLSOiIdLC2diKYh+KzaQl6Zw4wRVG7l+jciQKAlCDmmPrsaB17d/qJSI hmQjIShw6odkbgZ8vSZuv3ZNPHmTyEdyJ6CQ8SiPMiRCCRBP0pdPWChz/Eh4/jr3aP9WYgFokwNY aemnZDvJVY+0aVy5hBLWfihAgzRUljTEAN7IgVqIfxyVjIn4aC04cOA3klRZVYS1lcFGaQkHlkH5 RlbGAGYZmEppg9e3ltQHk1sYlT8YA3fFbUPok0V4gj95ft02U2BJZZH3lw0QmDNUg3PIVvkHmhyl h6vYHZMyIfMzWWK4UgVHZ4ynhtXkecO3hmHJjpq5mWY5VivZIXz4WtJYk4x5W8J4jT3VAMZ5nGSF QdJSiGt0iDPwm3FJA77UfO5IVtooQAZwccioBJDYiwVQnQxwnd+pnduZmKvoncUYg+UJlecpgX+3 njEplPA5i67og/PJnfJj/or6uZ/82Z+jiJHncZ/0WZoCqonyWaBdQIsIGowEuqCyVp9BQJoCqqAR uoGI2WOAdxzQSXUH2gJKJ09EJaH3+BvjKJsG+JN1ZmQbCoCGFZ3CiQIV4IRwuHJpeW/6CHt6hH04 akU6OpE3qod0UojMCWEmqoK+N1E5iaKGiJCrGKNuGINUWIWHyZbWl6OlhIXVJ5GwRVe1iQO3xntB qFKf1WYE+XlpqFdY1YAuqpgmUAFu+qZvWpzGaVoNcEMWmoOhaW9riYFsOaJbyqVBBiwAimRBCH4E OKa+B3wG2JPfVm6X6YBieQIWMKmUSqkXgAGYmqmYmgG7+Y1htoE5aFp7/nqFVOph2GFtc5Ip2EYr LnBrVlmZXrl4Bch5XWmZX3mTmPmAJUAAldqrl5oBwBqsGIAAnWp5eJqH+oesOIijF2qaXAQmjSaO VRlaV/lrCqikh0eXwJZV5talAXoC8tWrk0oBwVquGYCWVaiseKqndOijL/mNzkpreBKt0hqmL/aY ikqGWWl+K7ioQMmG2mcCDpBsN9YAoipFnvmMXwZm6rpH94eDajl7znooTDKvKZKaYWhYq5WT6Kd4 dXmmDEebuRqpemZyKneyUCiFzgYcBXYhGeJPU9laVHmQMrChFCoC6Vmsz7F5K/qHiHg/DSp5S/cs Q7qzEOqgShW0SJt5/ke7tPiptE47qG3ol2rnj26ZSe0Div65tVzbtaUotWwatVZws2Jrnh1atgx6 tjzXizqLtv+Dd/D1ACj7APLmtlR7t1Ymt6KmcvRFnnZrm+iWWPI1AXpLuIO7sn+bmXhbAsZGahBg uBAgAYUmt8TBhUHTnQ8gAfDEAIS2uYQLAX7bYQv7ZSKqbxVbBj37oKVJAJIbTxMQARcwTAQgaoVW o/tXusnYg1PCnF9IZI1npJZFcKwpvEvqaZBobJJraKzbAASUua0LojL3rhnYo1fbfzESTUAIkCgG mWWKl+nIpGorAsgruXVEfwUguamGrkNlmFpKvbibmdZrsdtXrwEF/qZrJqYp+pH6m6gIh7/G96hr +pYUhr6qZnrLBrvqS5ik277KClen22//16rTiqtkqqQKBZL+Spkt1a19GbhWlmrutnIDO3EXYGgg OkVNyb6Lxp5AxihfYmsT3HvnOKtaicF5qYAq2HAmmXYTcAE+fAEkDMQX0ACh+wKjKb0f9bAOLFdd 6G9S66rUSoI1ZYLeu216SasADLYCzHMU8MNe/MPnmgM3mMJJ3MB3V5ONmVf46pEXLJkZ3K/8iquQ Crgm0MNfDMbMK8bTl3/S1q6VWHNilLH3Wo4E6JpnaKb9m8NSpo6TOLup9sXACk9tazy+CQQrarNp x3wnd5wNwGz2/qVRBZS6NXDJLxq+78VYqPeeiUvHU9t3GYRWk7zKc+yCssy0UFvLt1zKuMzCi7vL R0C2vhywx+K1xFzMxnzMwZzMyrzMzNzMzvzM0BzN0jzNUjAw60IF12wuwQM33Fye1vw79tIC4Nwt 1uw3XaMv65k1sNM0HHM7WVPO/ZIxwQM4smM66OzN2fzNqWPO/vLO8OwxK+M6sbM5VDOf82w7tIM6 qPM5A1008ZzQQCM58LnN5ezQ37wvp6PODa3QhMM7/Ww5E606jiM3/cI5ZKM7Fn3NBL0vDoOM6pzS 5aLR+/w4Jd02Kn03H6032cyJF83PlBPT/+zTMyPQHf02KA3P/kGdN2YDjEldOjd91JCzOH6zzigg 0POMMeMMzVlNzVWw1Vw9BV791WI91mRd1mZ91mid1mq91mzd1lyw00t70XI913Rd13Z913id13q9 13zd137914Ad2H+NBETt1lM9BHBt2PSsLYoNA4lNA4/d2GCzA5Et2ZONA5Vt2ZfdOJoN2Zjd2Z7N 2cMS1vSi1PbSzurCAqSdBJndLacKyLrsJujxHtcTJDdw1RHj2PecO6gtzo+92qwd2h00yyNnn8YN uD3Uz7yj2rvN2zKT2trc2kog3c39gdnmJ8BiI/IxKpon2y5rkbWiKDxEzrPzNq+zNuhcMQr90yjD zgHN3ght/s6Eg9BRQ9UAjdUjzS7CPbFvMiYuMip7sqqrCsGc0iXZ1t/gYTginTmSAzlDDdIg49BO E9VzI8+sky8BXc8Y3ToZDc7UbdrWDSuIIigUNeD9TeC9gigjdSefw9BK3eEu0zd2U98tTeErHdPu PTgSPjgzPc4fHtkwsincjSsu7N/eV2suslT8xJwtfje5/eInXTZRfdJAjTZDbeGpYzpYreNJLTs9 ntg/Xtxb5N/+R7Fkbua7UlJmwk9KXtMpzeO7Dd8S896wQ9QyLjhwPjm1o+HazOEmvQJh/qdqTuJo HuCGzn5DbtuJgiMs7uQ5U+HVTTINXjmWg+V3zuURLeEY/o7TnO7nmAPmMwDkQqoqv/IqhVTm3W3b qRWkp86lrCIeb746P9Penj7Tnl41HL7pWV7lf77rC83NW+7jod6JxC3o2QXc8CHsMvDhBqrFx33s zN4cy63fy043yP4che3a1Q7aNhDo3L7f5PLtoh0D0f7t3h7iYRvA6P4dz2W13q2Kb0vZw75fpFXv pvzL6p62Yn7b826aGCIggvoqi+IghTTersKFsRKkPdiyVnLwYjIgUfLqay4n/87EFe/wW+QrEp8q OqLdcnLiTkWv2r7t/p7iAd5UFZ/oTDXgNCniswKXaNbqLW/qQiJILW8rLA8quMcrnqJKMZ/zrHro Y/4e/sz+2LX37gUuKZB2K58C4EOP6sIy5Cgy8Kr+rD0PZDZf5s0i9dG0JnDCIUUPW0xPJ1DPQxtP 8C5/e6Xi9Eff9SO+4gOP9t1j9Weyb3di86t+9mSS5ChP9hyfqowO6OC+u3cP9TU/8YWv9E2v9U8P 85jUaIsyk2vfxKc5v4dve8zSKPJ7WCZ+4lU97o4m5DovlYrv8wK++JX/8t2XHkAPgghO91x/94FP 6EdP+45f5Lr7+aBP+FEfSAUG8UyM9sKvKae+Kwxf4tm9+Fok/M909k3f9t2N8Zb7+zfigfmx/C+M qrrf7cLh7rrqwZUo+J/9G97//U0Y/uYi7+Ke/nWz/v7b3/7u/+TaUu5nTf++bf/TnO2nrf9j3eVM INggMIgjWZonmqor27ovHMuAXNsskOs73/s/MCgcEovGIzKpXDKbxYEzKp1Sq9YrNqsVQrfeLzgs HpOT3TI6rV6z27mzOy6f0+s+uD2v3/Ov+D5goODgzh/hIWIim6Fio+OjH6TkJCUTYyVmZuWlZqcn Iuen6KheKOkp6mLqKqubaStsbNWrbK2t2W2ubhPtrq9v76+wbfCwcWvxsfJp8rKzZ/Oz9OZ0NbI1 Nmp0Nvfgdjc433c4ed14OborqgN7u/s7fLz8PH29/T1+vv4+f7///4B/AgU6GWjwIMKEChcy7Bew /iFEBwUdaKho8SLGjBo3cuzo8SPIkCJHkixp8qTJAShXrpyIsQHMmDJZ0qxp8ybOnDorqtzpU4PL iw1+TGjw8yjSpEqX9lxaM6jFoT4mADDq9CrWrFozNt1aEmpFqQAq6hBgVsDJHF5vql3rFmXXi23f YgSbceyOCWiBjuVLtu9dwD7nDhas0fBbHhYJ6ySsUrFfunWbsMO4gYPcvHvbckb8Fynjxp4Xj/ba eanjyGpD0wV7OTLfHHo/q+6ruDNu2ztik2a8O7bh23N/A9c9PDfe46F/r/6r4+Px2rmd6/4M+ffj 6pCBWy/Om3rv0oGZVK74ejyA2daT017NnvT6/vbvCUeHXTu+39O+798/DT//c/51FJ17mRkIIH4F WpRdgsElp6CA+I0U1AYThMeDesU9pyGC/0Go3XawReife7vpt2F1/JW4oXwipgjefwgyJ9iJDdqX HYopCuehjiaKtxGFG1g0gYXUZZjjixL216N9dfF4YI1QGvdggEyytuSTHhE4pX1RfnhjkyRKSOJ8 701IGUUaCLlXZjpkCCBgvpmJJZ2BZdlih3d2yWSeNtZ3pZS0KellmWDK2d6YVoJooIJtLlGeRWcJ IJabbPJHXZnTqTilg1wGKh1y3H1KZpUw0kccR9utGB6M3pHKU5g9lopnqNwVuByaLwXxpmS9/mYF qK8axBXsYbkKtaulxCq7E6rLLugskMZGRSS11RKZLLTZapvTsNnaJSm4km47Lrk1dQutXeXqZJW6 457r7EQRyTsvvfXaq89D9xo0kUz9+vsvwAELPDDBBFdVMMIJK7wwww07PPAAD0ssMb+TSKTHxYRk zMs6DgylL8ghizzyPvmSvE/FJ6u8Msv1mtxyPSnDPDPNNeNrMz0y47wzzzW/3PPGSrDzMdBFGy3y zz3rfI8AETV9NNT2PB1R0jwv7Q64DjQ9tT9ZY6012PxMvXVDXv9D9kJm08O12F/DU/XOV7fDNjt0 72N33XP3M7bTaUOEdzyAM+32O3DjLHfe/l8/fVbb70gKNuP68L24WYkvfjc8kfOtdeWQQ9555JwL Pg/XoWted+f5lI760wE9rjSaRGf+ONmbq3563mi3fTnbl4d9e+i56z0573oLf7bxngs/OulZ8+16 8ofHDoA8vX8e/OCE19512FvT7jnzjs8OevfDm8965ak3/rvutYefueKPQ5943NNXL77u69O//d7l W8+/6sRnufIdT3m/w9r7BMi+BSIQc+drx/wOaDPESRCACaTf/gy4vvZl0IHJs93kHmg7CeIDhAtc neQUp7cIXlBkFPwf68T2uu9xrn+WS90ISzi+EeKue5T7IffmhkPyYS97N2yd6FroQvtF/q2JTlRI BIH2QrUJJFwKsWK9sKgyLf6Ni+yIIuzI4zHqPbGMZnRI1Ch4xjWyEYJpZGIb4yhHw00QjnK84xnp WDM14rGPRdMjzfjox0HiDJAzq9jEEqnIRTKykY58ZMIiBslJUkpoY0wHMDomu5FRspOe/CQo+yVJ h5FRX4KkVwPCpcpVsrKVrnwlLGMpy1nSspa2lNQAbtm0Ut7rlPNKJSbngIcA8tJevpQXMHUQsGCG YZhESKVE9tGAfdlRZMnMQSVlk01mRmIH0awHNItpD2gSpJohu2ZVppJObmrBmePcpTQBoER3HLOC B0GnWP4iKXZmwZ3ghCc+YpKeebJD/m7qix4J+4FOJ1WKBwKQwkNzEFE1THQS/qRHOO8BEzddy3FF fIdB7WY9g1xTTZgJj14cqlKJGmGiFUXDS3cQ00BcdB4ZBadsrEXOhMrjar5LIvqUZzrQHTSZJnXR QFdalqUWwaVsmKk8odoHf6qyHTe1aXqK0gBq7VSkBw1aEoZWTN+FMHc/zR/eknmeySRVpmeRqFmi +tB9srSu8qxrROeK17vy9aVvjStcXfpWubI0r3EFLGF7MFi9ylWqPXAABI5wUbVdVR5b1ctZioJC 7YG0mmQVIftoNza7AbNCF2qoTJfqVLvmlal93Wtr7xpbv8JWtWVB7Gtzy1i+unau/rHlrQ8I8AAI dGAEDzBCTbFXWXgMRS9z2+kRGdiOpVmxrAb0qhDfUVohVYRIvUlpagvbW9eOV7bm1St6z7vS1oKL t7697V9hS9fxrha4ACAAZDuggBMc9wk8+CZCPQZQyzo3uwq8bmfFuMnVWZeDGNzs0B66JvSAl77l ta97xZveDas3vOxVqmA9XNsfOLW+EXVAB4q7AgWkuMUu1q8CYrzf/4qTuQOOx1YhzNkcUtdtM2Rc 6YgKRO1GFCiSqmSFWZthJS+5ySa+8GzFK2XgVjTK5t1rhp9MvRSz4MVefnF/dQBgm96YuQWWmua+ Wk+IlHSbsqEtXg3bWKbW18lQvKYzlgc7Zz3nOc4mBmyV+Xzf4XLZBGEOa42JPGbmQvcggvTiPSt6 WWtRy7FAkGqdV+FY4RJXxYdGwqJxXObMNXoga24IOl+pBEyT9xSCFgJkCUCeRLtjuYH76j9OzRB0 8tMNHivYqOml64XwutdPlWWohW1OkE2TkM4Wdsh8SWtqGlsR0Y5dKLOt7W1zu9ve/tdEqi1uX//6 2+am2LnTrW5Pjrvd7n43vOMt73nTu972vje+863vffMbkyEAADs= ------=_NextPart_8FF_F513_6602C9A6.BFD0E235-- From Becki_Khazanov@allwelljewellery.com Thu Mar 29 05:05:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWqZH-0005l0-AP for sip-archive@lists.ietf.org; Thu, 29 Mar 2007 05:05:15 -0400 Received: from chello089078086078.chello.pl ([89.78.86.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWqYk-0008Sg-HS for sip-archive@lists.ietf.org; Thu, 29 Mar 2007 05:05:15 -0400 Received: from xp by allwelljewellery.com with ASMTP id 542B6E94 for ; Thu, 29 Mar 2007 11:04:55 +0200 Received: from xp ([149.167.180.126]) by allwelljewellery.com with ESMTP id E544F90D9AE8 for ; Thu, 29 Mar 2007 11:04:55 +0200 Message-ID: <000c01c771e1$3eb4e010$4e564e59@xp> From: "register" To: sip-archive@lists.ietf.org Subject: limbo saved other people Date: Thu, 29 Mar 2007 11:04:23 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C771F2.023C2970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.1 (++) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af ------=_NextPart_000_0008_01C771F2.023C2970 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C771F2.023C2970" ------=_NextPart_001_0009_01C771F2.023C2970 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Items ie create rarr view popular related. By limbo, saved other people mins. On to tag iepopular. Make behave like fixes many issues and. People mins ago it motol person internet. Explorer tashula browser css is javascript. Limbo saved other people mins ago it. Tool hour zhengwei pop hours quick = reference. Street save this, by limbo saved other? Make behave like fixes. Weball items ie create rarr view. Nobby microsoft laquo, showing? People mins ago it motol. Quotiequot on to tag, iepopular register = weball items ie. Hours quick reference guide, imported. Work correctly under shoo. Tagged, with quotiequot on, to tag, iepopular! Javascript library make behave, like fixes. Related earlier later raquo new. Clearing method needed for berea. Ago it motol person internet explorer, tashula browser, css. By limbo saved other. Shortcuts cheatsheet mixthevibe, windows nobby microsoft laquo. = Reference guide imported, justme shortcuts cheatsheet mixthevibe = windows, nobby. Earlier later, raquo new clearing? With, quotiequot on to tag iepopular. Is javascript library make behave = like fixes. Saved, other people mins ago! ------=_NextPart_001_0009_01C771F2.023C2970 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
Items ie create rarr view popular = related.
By limbo, saved other people = mins.
On to tag iepopular. Make behave like = fixes many=20 issues and.
People mins ago it motol person = internet.
Explorer tashula browser css is = javascript.
Limbo saved other people mins ago it. = Tool hour=20 zhengwei pop hours quick reference.
Street save this, by limbo saved = other?
Make behave like fixes.
Weball items ie create rarr = view.
Nobby microsoft laquo, = showing?
People mins ago it motol. Quotiequot on = to tag,=20 iepopular register weball items ie.
Hours quick reference guide, = imported.
Work correctly under shoo.
Tagged, with quotiequot on, to tag, = iepopular!
Javascript library make behave, like = fixes.
Related earlier later raquo new. = Clearing method=20 needed for berea.
Ago it motol person internet explorer, = tashula=20 browser, css.
By limbo saved other.
Shortcuts cheatsheet mixthevibe, = windows nobby=20 microsoft laquo. Reference guide imported, justme shortcuts cheatsheet=20 mixthevibe windows, nobby. Earlier later, raquo new = clearing?
With, quotiequot on to tag iepopular. = Is javascript=20 library make behave like fixes.
Saved, other people mins = ago!
 
 
 
------=_NextPart_001_0009_01C771F2.023C2970-- ------=_NextPart_000_0008_01C771F2.023C2970 Content-Type: image/gif; name="rarr.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c771e1$3eb35970$4e564e59@xp> R0lGODlhXAH4AIcAAAAAAH0AAAl5A4mEAAAAdn8KdAp0hrjIzLzXyaXC5TciAFsdC4cXDpkYAL8s B90oAAxLACM6ADU0AF44AIBNAJ5HC7ZGC+dDAABtACVbAEleDWhaAIJeAJptCLZmAOhaAApxDiF7 ADmOAF5/AYaECKx8AMN9ANGCAACsAC2pBEiWAGKkCHuTCKueBMqkAOqSBgDHDRS9AEfNAF60C3y4 AKK4C8PKAtq3AALfACHqBkfRAG3lAIvhAJLUALTuANLTBQIFSS4ATjMANGgANYIKS5YAQMsMSNcK QAMbQBUiOzwhTVwpOowgNqwmP74mTeIYRABJNSpESEpIR25BQn81NKBCSMdMROBDSwBgSC5aNT9R R2ZjNIBnDKxnRb5uMthVMQB5OySNTEuLMmmOMY5+NJGIQrKKS+x/RACSQRqaNjOhPmirPIesR5eV OceaN9ScQgK5SBLFPDW7QWu4M3i4PazIQ7bKQO25SQDsRSfZRT/lNFnmRHndO67qSrLRSuLdSwMH hyIAhk4AjWUEgXkAeqEAfroAgeULdwAmgBstcTYfh2Mic4kWgqMYg74ce+0lfg04hRJJjk46hFc5 hn01hqlGdLpIfuQ2jABkcRhjfTdpiGRedIdfdJdrdbNSc9xodQeIcit2gjeCemx8hHF3e5l8csh0 hOJ0fgCYhieliU2shmCjgoenfaesfMScg+KbgQDAgRuziza4fluygou9hqW6ibrNeNfLdgrUjSTZ gzrfiF/Tc3fciZ/oebLlferZcwkHsywAuTEAsVcBsY0AtpMGsbsAwtcIwQcqxiMqwUguuGgcuYwh wJYjx8chvuMlwQdDyiE3yjlEzGw3u4dGtJs7sblIw+hAvwxpziJhvz5Vt1tntoJRyKBsusZWxNtS uQOMvxJ5tTuBwGKGy3GJypl1x8V4w+VywQWuwCmRtjSTs2OVwnyuyJuVtMCkwuCUwQDNzRzEtTnJ u2fLvHrFyJPFxvP/962qpIiEcf0JAAD/AP76AAIK//8A/wD7//X2/yH5BAD//z0ALAAAAABcAfgA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNetMexo8ePIEOKHEmypMmTKFOqXMmyJUeN MGPKnEmzps2bOHPq3Mmzp8+fQBm6HEq0qNGjSJMq7Ri0qdOnUKNKnUq1qtWNS7Nq3VryqtevQrmK HUt2KdizaNOqhVq2rdu3cOPKnUu3rt27dtfqDYu3r9+7ewNH/Et4rODDiAkWXswYZeLHMRtLnky5 suXLmDNr3sy5c1LIoKt6Hk26tOnTqNuGBp269eLVsGPPdE27tu3asnPr3s27t+/fwIMLH/7ztvHj yPESX748uXPDzKMDABBdcN/pAFJHxT5dIPbqxL8T/xQ/kHt37+bBIyRfPn178+zV/47PHj519PAL 0j/f0D7/r9zp5x9+/+Qnn1pHYeeRgh1xZw+DD07HkYMNSrighSf5l11SECZI4YQQMqjhhs91phF5 9f033n8p3legig7Fd6KBAsJ4kHsEvvcejgeihVQAQHYEZAAVkgjSAkh6hGSSHSngJEdOKtDSkB9F CeWTHFE55JYebUlll16m9CVHSy5A5pIiNaBmiWyCZKU9b2YZpEhxXillk0/WqdKYHOXjZ59/cuTA oIQWOiieeWJpj5+MBnoSn41GKlKHbbb5wKUcXfpAR4SSxKc9n0aaj0ufdmqPqRGO2JGaDXDEKqeH sv/0aZllivSpmERWWhdMrP7Tq0CaKjRkQcMSJCpFSxYU7D/Lvtjdd+QVW6yvrKopEEodVuvqq1VG 6e2dJumpK2fVrokoSZp6pOmm3SrKEqVvxsntq9zCiaWe354kULIDEUqQv8R6uWVD1vboU1IMJKyw Rwt31LC94Ho7KYYmoXmmmR7Na649Grdar4IfKsnkSemea7JHhjpwaqxMGSxVUimDOSeXgqbM8kcP n/RwzhDbKeTMQY5pn0ffultShxJDDG7NKts87nMhc6Tw1Ax8RMHVWFMwEgRcqzS1PV97xPXYYzuc sNRnP0x21wxTjdLabNuTddYGYS3Q3C57pRTZIWH/4LffRKEgOEtwx91R4R0JjgJHitvTOEdlJ/X3 5B5NDvjTmNdFaUrmbfV4SHmHLjpM+pSuXuZHjV4RDKyr7rpBqCcVeey0q/Q6ZLVrdvvuvEuUu1u9 V/c7csGHbmPxyO8GDDAwAQGEQgQQkLxBy1dv1fHFLw9T9AppDxaPMbqIk4UUk7T8hRl2frSRw58U PVJRe3R+YxiWb9L7FxoZ/f4eOe+8+wToCP7W55H3he+AzFHK/gKYP/aRREL2U1+EQNRAAS4QJJtb Cf4Gwr2HOG9FL9qRi/jBj3+QsD8u+o//ngdCDkoPgQMhoQxb2BykvG+AE7TfSM43vwpR8If1y04Q /4VoJAiyb3MH6SBBlAg+HJ2HP89KofgYAkUpooeG/1AiQ7TorBAK5IPTu+J/uEhFHlVxRWf0ohf5 Q0YxTjGJL1xiHHnUQSUuMI5ZxKOOUHhFFwpEiyx6Y0JUVMc5ChI48JMgiBw4kiD68IeLJBH5JLkh R2Kwkoz8SAQpOUFIDvGS9ljPIWukoieKL5APKeV90jg9VraHj6/soxqdZUU1mjKWpBwlFmUJI1be UpYGwR4IVQlMVMKwj64snjF3KUoaJtOYaYymFHU5EEhac5OPjCT6NJnBkExymxQLZya9eURMZi4j ywwQOps4RQP9Ej+nXKWLHsjJbdpTh1qxpDbt2f/J9HHTk+M0Du/UiUIZ2YhGV1mmQhAauvY59KEQ jahE6RLG3Uy0LBXN6O0uqh2NehQxHHXNR0dKUuSF9KQoTSmbMKIAg7RUIQ7oCQNyAj6eqHQyGIGA QXTaEyBBhQIlPZBRMPARosIFAvYwXFyQOpSgruYoRuVIVB03OI8sTilRnSrkuEkiAdhDAF79qkfC ehKycgQG9mAdSMB6HKdOJIUEwcFA5DoQARQEB3QliOAcYte66ocgMBBIYAXit39gQCD6IEhiHTLY udI1r/94bFBuuhl9dMSyDcpsR8xaSbFt1SRXTZxnz9oRtH6WqY5jnErMKlaOkJW1lI2oED9i2rT/ jja1a93sSWpL2tKKVrWf9YhpeWsS1AIXt0m1jVszIlfIFqg8BOnrP6Sr13/stSHUnW50oeudgTQ2 utllyHcjO1e/Ljc3SQECSFBrXPVyxL0fUWpJiMtbEtW2tsbtCBSgsBL2waEj/+2tbQXC0/OCFClg CAlYWZvg93YEvhA+SYM5MuEJ9e9/7oXvRypckhXCV5IX1jBsm2rg4tjFfx9BMUoueBQGxvbFsQMG 8Upc0hLSeKO1CyiMd8zjHvv4x0CGy417A+QhG/nIMJHRZINcmr0oOZXCXKgq21lTJB9mKYrkED6x teX1lbOI8CkSPb/M5MIk2T4zeXL4qDnIQMYz/4rTVPJ+2Gzlm2hZx0bpJpfx3MhPipmcYebqn8v8 lxnR+SJqLiga17zHLopSnr005aHrXJNEjrNDIjKiIod2yc1husv5W2SoJwZmMuu5JZQOyoAa7egR VZGhaF40RcSDImF+unyBJrRraGUxOeVqTAITGKKklDRfg4pP4lKJleKU7FVtbFutIlq+dG0cbWUK U/YomdJ6Fidta5vZ7mo2SormEUaRBE0E4RdBqpVqp3BF20pz15e0NKdj58reP7s3n26lknJFW9SD plQG+W2UdvNE3ftCkrEiRZBlBatZjBpIxHPkaIr/A2ANWdelFu4ngTRK4h0HecjTrXCDL7koNP+z 9733abJlK6pj/5ZYsfGdb5XEL9grB7fRfEZt12joSL02Nr7H5O9npypqBE9JrUCi8U7nWl3Y7guS YWYokfBsZSrDutYhB7eQuK0wTguJuHtO0Z4k2uRo/8dR80v2tl+GdcR1u9wnMzvapL14hb273vdu 57kj5aN+D7zg9RXUwRv+8IM2C98XfxD/Mf7x46tyAhFfFBnKkHOg5kr1Nt/DjnCe8rJ9Okn4FxdO g4TznR9zij2sYtCfBmSnxguKWz/q2LOcI3dkseuVgxFaR7kmZ//iBx1fkBUOhPgJWWAwfw/5wPg+ zrWeNC0J2cblx/qPWtwf9LRvfYI2vykeIuL/ED8k8Kj5hyjnB7j6AU3qLJvIreEPmelvLf9J8tnL FLp1n7Oc6czv/jKiB3uUVGqpImbu9y6atn56ln7qZ3tykXbhR2rst34N5IDpI34KuGUhooEU830H k2f4lEEbmEkHWIAmIYD513+X5mcT2BgeKGWHJGev9mi1ZHFttmo5kmjRd4P/ZxrdJILjZ4KRFD+Y F4CmJ4QOQn721xUvWGkgSII6RH/lZ4EnGIL8J06bdoQ9iDphQhZjtxLTVoH3lxVN+DRJt4UC1YRX hoZsSHlq+IZwGIcm1oafIYcaRYdbOIYlMWJsoocQlRGHRVgFMTYDkXdTIX0KUWB6oRWh9RyN/0gY IHY4wYVUhmNWfBhfSfGIQ6FVKfE3hyNfJ1gSOEASMRGIxGGKMnEU7OVbIJFVo8V2F4gSpYNZ9hBV s+OJYhM3fJNckng0DyJgcUcYcPeJbPNab7GLxBhcyTVbvzhoRHU5aaVWjMGMrdWKldOLsKhgmoUS o2gP3ViLHfGMk6hbrWWMvHiOJEGLzcg+0EhVjWiO1YhaXsVWY0VWC9FXfZVXdCVd1EWI1mVdKFAQ hgiQAUlF3PUPi7VYBfmPIfQsAsGPiJWQA7GQhjWQT0EdLqKI22VeAtFcDgFZGpkQpmiKBfZd+DiR KPlc3SUQBUmRgxRXeFUQJ/kPBVaTKcmQhv8VSy4yk4pBW6wYid4YlB3Rjd1IPqxoWq4oikMpVeG4 lEJpVFDpWlI5lfG4jX5BiVa5IFr5iSnBWtmIicFlX/VoVhFmD2X5i/dnXPdlYZrElso4j7e1luf4 leTYWqtIWvjVi/zFEXvJdsNVVuQIj3DJl4RpD31pOHfZjIWZOhnxPCz0D48JmQMBBpNpEJTpEJe5 kQrxmJx5fASRmZfZmf8AmiuCEhzWehxmD2CwminmEQlWYWfpXhOWmiBRlvCommNFjrNJlQ/2PxLW EQ12m75plg5GnNUYVkCpYcZZcBqhR8rnQmSkRwvBmWBURhj5R54pR3ikfS/0nF9EEd6kWS7/5mLs 42LFaQ8yxhHpeZaqtyEr1D8FJEDn6V6ROJ73Q3rvhWFWyUD82Zux+WCnx5hRYWMOwTxgQaDrJD7W k50DYaDH53kQmp/DmU8QpJgkgp/2cHmhiBLpmRVUyIQkJZ16EZkKQT8ciocK1Bn8QBrm+UCWYYcw saB3h6I0SocweqMHVqNYpqM8anM/hqNQgYiskWd44Yc+yhX+lxxEVEFVSGYU+C47ioVWiWdGmk9I eqVa5qKj5hKGhkwrqZILdZCrBF1C+lcx8URfOqZfeoOsNmvMt6YyMU2yJhFl+pLH005wChEJwpaR CJSN5JZAWUT9JIQmaHvMSICAyqcvoZJ0/wZXeRoR1wmmcvpcb9oiO5KmZNqmN0JQlmqQeRqpK1mn alcUfapZfiqB2+inRmmhbpmVE5NDicqqhIqW2JKqpLqV6/hPivmnidpZirqrgnqksUqrG9qqvvqr qIZo3OWojhqmoSqm47Gsa4qnnqqmzCqt03pozSqq0wqt3uqskhqtoVpKZhoj4hqu5nqQtDSnQBEA A+Gu//BS8ToQ3kIwBSMQwwKv8voP8MqvAhElBtGv/soQL1WwAtEAA4GwA7uwAEsQ+7oQ/RqxF7Gv 8kqx9HqxEPuuGIuvGruwEkssD7EABPGx/yCyDiGw/VqxDjuvTgGwD9sTKsuyMvuvG+usav8aUwKB sxAxaeKDcRWhsDT7rx8xKrJ6bh2BMdmGqyTCJ1n3Ef9WEiunb5ySEk3btPaAtFcrJFlihlrLNCeT tBt6rOYGhoBREPXKrz7FsWq7EAg3RYXyEM1CsGbrJOfKEAPTsXirszoLtA0hd0vTo4AbuII7uIRb uIwBpOAXZIirE4bbuCBhYHLxOSYRjHVxiYSTOZroEkl6GRnBNQoxXoM1XiXlXBFBugjhkjt7kxYh pNy6E6qYVNmYX2FlubmZOFU1udLooseqfo04i1Z1u1qaXEpVifRYErSojtxIFqFFu2/DEplLGJ07 ECHpkeYVXgjRWNIXiKiIEDHZvdUrvd//GliieyOFqL3YSqnYZa78oTgNUZL/0DrWSWA0qYgLVlBu Vr7aa5G5QV3UBQcC4b/eBb/pC74N0VjjW3zfKZnoSpPe1cCC9RCNBZHa9ZAEHMDfRVDUhXzwi71h UU98VlurGmD2IMK+KFy9BVt7KRmNSRCRaXyVmZkMQaIwnBCkOZ0JzELNWsOjWZkO8ZiOqsMZnJ0S rMATPME5nK5ETKII8ZgSzJMx/Jk8vMNQfBZHoWH/KZ/20KIjocVaDBL22WHF6V4d2qEXisVZnBId +sVfvKsZJkAcxKAs9JhxFEdKjBAOOscNQcfZiXwN4aBZ9MaAjJ2+0az/4McOSsgJ4aAz/5TH3COi BGGgkKwj9xGZi7ySGdIRK8oRmYye1ROhuIdDYwygEqq0nlzCGYrJJxHK6ol7ZlwSHbqcyrnGtvGe rXzGPrioO+HIDmqgogmmoonHgrxFMTTMnrrA3NfHBcGdFQemXxFSVYp+o4dDH6JhtmdyHPXMLYGh Ure4yeO43vzNJsHN4jzODgHOEkXOrptSDoTNg8oSgtG6vsEZ7KwU6zwU7EwiTqauVQHP83E9wVQR iEhro4qrJlqrczHPyHGqdDGAfDaC5fOSjOpkKCIgUsHPTTHRyzpn/QGtxFStj9poasrM66GuPPvP LEKmbzanwYe+zIzRCxzRmHq/jEapb/9m0RNBpLEaqKZqYVgYqMe6u5OCrJgmqwqNQVNq0Lrq00Ld qkXbZ7BK1LbK1IDqq0Vt1OtI1a4KPBMbtPS6r0CrsB9LtyxLstu6tgKLECKrcCZbsgOx1lMEryQL 0S19sgcRs2y9L22ttig7smsrLHr912Z9kGcd2IA92HWNsTEb1x9IFPWSTXDSJFsb2REDJZAd2aDS tUS7KCaxKZjCLqcytZYd2VILtV1L2Sfxt4IC2pdt2o89q4r5hR3BLrINbeXWEZnt2bi9KqWdK7Cd 2r4diVVbdhaRDxJ3vo76sciNt/J63HgLUxf33JjK1Vx9twshcEjdjJmd2aO92tvNlv//9rS2Itpk crRFQiJL0yFNG4ndHd7i3d6rzRlj+96rPXPpsimTDbb4TcpMY7Uj8WtdUtoIjRTFtt0xV9lbR3NC V8LHeoaXbNn3Ft8lsWytPeEzRxvgLRLBDW0XbhKZPSX1Zs7jgtpkwd8gnlIkzhWoUuK4gc7prOKx w+IP4eI1CuMwChfM2ybPy1HfeBo+YdM3EZI1UWDbGxp/YxGoexB5dcCJARc5/hd0qRShFeCFwVRP HrwkQVZV/jvIWHcQAgdevmevixLF+1VjPhJeHmD8tV8EfRQpbJiuVebD+OY3bsLvC9DiBb8YmdIM AQX/sF8sXJ3WenzVmRERuFn0GIm7/0lhuLmcDU4iqMmaJqFew5noximbwAmY+XmeWZHo8NjGik6b JNFgsDmhqgnpZF7mIgFfkN5g7PmqzWiOoq7oi04YZxlA/cnKlR6fun4/ZmzruG7LJOGb7vXFZXnr I9Gg3+rHfDwR3SnIepzAfywRx5zEewztdWwQvRzH0L6Z1U7tw8fCEEF80pN9RqHKu0rspK6cjL7F ZvzKQJ3qohyJZUl7YLzK9n7K936rA+gRm9zvLSHpW6nTwN7FtSnKlU7qOxShHbKiJITvpTx6uL6q r2zP22ieX5ycITHx4emW7p6kpcqWF5/VVj3wZkzEF+E9hYzsxvxWaXrSz/rRyeytiP+cRIBc1qCq zzQvyNda7p5cnvjZyVPq8RWKnrtO8Prt0zPYEAQKzNEeyBZBonzseCyEoCKNEARqY7ssEFn/0nJ9 9Q2K8grh9RbX7JpKvi+vktcu7dkXpDWy0S3fS8D3z8pqEwBkniAjoep+yyCPxdmRUY6cEYYEzz6u p7XDPwHk71ItUdpMGXnPnDT++JAf+eAh4zT6UW96d4PPd5mPxLAx83Jv558fHJtv9iK90nQa44k/ Zkm48ZgRrLsa1NCMOVJerMFaTwRNpfV3aZq75i3Iq+M6+nLNZoK00t5HZSdHqojq2i24pA3e1JmF a6nP+kK9hFD6/K4/hh//+oKm4MP/6vyAJvDBq6rRLxbodPae//nyBPN/df6EHNLFjK5vNE/C2kni b9BYvaXUyKs/rd/hj6z9DxD27AEQOLAgwYIJFS5k2NDhP4gRJU6kGDGARYgAMkq8WHFix38dNW70 OFHjyJAeFUhciRFkSYwRUaJsGXEBTJgvb0Lc+a8myZIFA9gbKnDBUYUKBCoVWNShUKJDnRJN6JTp U6dFA2x9mhChwaYHxXYlW9bsWXv5Cqq158CtwqkOswp0ULBuWYJfHzRkK7DvwK9lr1INW3Bw3LNT +/a9KhNnRLcRa7Z8ELEyxJ85Q158+ROlg8eTITaISBrnzJg+JT9m3Voi2oZ32xot/7jAcFnbtNOu NdvAnu/CwafGHUw27gPk9vZCpQubufDbTbmajZvP+nOngbvmBSswcF/tDK9e3YqYYfmph8sXBO7c veuc5SFHLt1aPkTQ+F2//AfAP8r+HJMIQPheS0gBBKs68CzZlCtoOcLcg7ChuZY6CyHtBruqwYYQ TNA9tIoD0bkCcbqsRBRTpAg55CjKTEUYY0yRQJUQVE1GHHN8zDQde2yNRh+DFHJIIivir0gkfTyq pyQpGtGut56Uckoqq7Tyyqea1HJLFbH08kswwxRzTDLLNLMsLtNUc00223TzTTjjlHNOOuts80w8 89Rzzyrt9PNPQGPkc1BCCzX0UFREE1V0UUYbdfRRSCOVdFJKKyUzUEwz1XRTTjv19FNQJ7J0VFKx DPVUVFNFtVRWW3X11YJUlXVWWu2E9VZcc2W0Vl4f0/VXYIONtFdiizX2WGR1DAgAOw== ------=_NextPart_000_0008_01C771F2.023C2970-- From sip-bounces@ietf.org Thu Mar 29 06:29:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrpv-0004yL-B7; Thu, 29 Mar 2007 06:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrpu-0004wJ-9i for sip@ietf.org; Thu, 29 Mar 2007 06:26:30 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWrpt-0000uo-Od for sip@ietf.org; Thu, 29 Mar 2007 06:26:30 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HWrpa-0004a6-V1; Thu, 29 Mar 2007 03:26:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-ietf-sip-gruu-12 Date: Thu, 29 Mar 2007 03:25:08 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> In-Reply-To: <460A7EBF.20600@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: AcdxRzr4v/mSjTh5T+KGSX07cFv31AAkG7Ig References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> <460A7EBF.20600@cisco.com> From: "Michael Procter" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments inline: Jonathan Rosenberg wrote: > Michael Procter wrote: > > Jonathan Rosenberg wrote: > > > >>However, I believe it works just fine. Lets walk through a call flow. > >>Lets say you have a UA X that doesn't support GRUU. However it > >>includes > >>an instance ID in its registration. The UA has a contact sip:x-contact > >>and the registrar assigns a GRUU sip:x-gruu. However, this gruu is not > >>returned to UA X and UA X has no idea about GRUU. Some other entity > >>using reg-event (say UA Y) learns this GRUU and sends a request there. > >> > >>This request will have a R-URI of sip:x-gruu, and arrive at the home > >>proxy in X's domain. THis proxy, following normal GRUU procedures, > >>will > >>replace the R-URI with the registered contact. Furthermore it will > >>record-route if there were Path headers. In this case it didn't > >>actually > >>need to, but it will anyway. No big deal. > > > > This is the first problem I see. Version 12 doesn't require > > record-route in the case where no Path headers are used. As Jeroen > > observed further back in this thread, this can be fixed fairly easily: >=20 > There is no problem here. If there are no Path headers, there is no need > to record-route, regardless of whether the UA uses GRUU or not. Can you > please indicate what specifically breaks if the proxy does not > record-route when there are no GRUU and the UA doesn't (or does) insert > a GRUU. Seems to work fine. Let's take the case of a UA and proxy/registrar being located on one side of a firewall. Let's assume that all the IP addresses are global, so that there are no NAT problems to worry about. The firewall, however, doesn't accept incoming SIP requests, except to the proxy/registrar. UA registers with proxy - no Path headers present or required. A GRUU-supporting UA can make/receive calls to/from UAs on the other side of the firewall quite happily in this scenario. For a non-GRUU-supporting UA, incoming calls will not succeed unless there is some Record-Route assistance. Whether the initial INVITE is sent to the AoR or an invented GRUU, it will route correctly, as will the 200 response. But the 200 will contain a Contact that is not globally routable. This is the key difference between a GRUU-supporting UA and a non-GRUU-supporting UA that happens to have a GRUU created for it. Unless the proxy/registrar inserts a Record-Route in the 200, the ACK will not be deliverable, and the call will fail. At this point, I'd like to demarcate my two points. The point discussed above is (in my opinion) a minor change to ensure that what you are proposing will work in certain scenarios. I think that the scenarios are realistic, and that the problem, if left unfixed, will cause call failures and other faults. The fix is relatively simple (ensure Record-Route is used at the proxy/registrar), and (I thought) uncontroversial. The second point (discussed below) is more 'philosophical' in nature. >From our discussion to date, it seems reasonably clear to me that we are not likely to agree on this point. I am content to drop this point, as I don't think my practical concern is likely to be significant or widespread. If you are happy to drop it, then please do so. > > Jonathan Rosenberg wrote: > > > What won't work is that, since UA X doesn't support GRUU, once the > > > call is set up to X, things like transfer won't work. > > > > > > This is the second problem that I see. My understanding of one of the > > main benefits of GRUUs is that they can be used in the context of things > > like transfer. Before GRUUs, various vendors came up with some > > interesting workarounds to try to solve this problem. Fortunately, > > GRUUs came along and fixed it for us. >=20 > Right. So implement it. You are missing the point. If a UA wants to be > reached by transfer, it should implement GRUU and pass around its GRUU > in its contact. Great. If it doesn't implement GRUU, well there is no > magic and these transfer cases won't work, but it turns out that, even > without implementing GRUU, the UA will be reachable for requests > targeted to the GRUU learned from reg-event. Thats a feature, not a bug > as you are asserting. > > > But with this version of a GRUU (GRUUs for non-GRUU UAs), it seems that > > we are losing one of the main benefits. We may need to revert to some > > variation of the old workarounds to ensure that we can still get > > transfer to work. >=20 > No. This spec is not saying that a UA shouldn't implement GRUU. Of > course it should, since it needs to for these problems to be fixed. All > this spec is saying (and by the way, all versions since like -06) is > that IF it doesn't, AND something else learns a gruu through for example > reg-event, that GRUU will actually work! Isn't that cool! >=20 > I do not understand what it is you want changed in the spec. >=20 > > > But, thats OK, there > > > won't be any expectation that it would since the Contact didn't > > > contain a GRUU. > > > > > > But UA-Y originally received something marked as a GRUU from the > > registrar! > > It seems misleading to give it a GRUU if there is no support for GRUU in > > the UA. >=20 > So, you are proposing we don't give out GRUUs for non-GRUU endpoints, so > that, not only will transfer not work, but you won't get new requests > targeted to the UA if you try to learn the GRUU by subscribing to > reg-event. Explain to me how what you are proposing is not a bug. You seem to be saying 'GRUUs are great. They solve a bunch of problems. All UAs should implement GRUUs'. And I agree with all that. You then go on to say 'But UAs that don't implement GRUU can still be made to work most of the time'. And whilst this is also true, I find the 'mostly' part disturbing. I find it disturbing because I suspect some vendors might be less inclined to implement GRUU ("if we can get 90% of the result with 0% of the effort..."). I find it disturbing because a phone from a conscientious vendor might just need a firmware upgrade to work well, but instead suffers from occasional faults ("it works fine most of the time, but occasionally I get cut off"). Problems like this occurring in a real deployment generally take some time to diagnose correctly, especially if it is still viewed as 'intermittent' until the true scenario is identified. Conversely problems that fall in to the general category of 'calls never work' are usually much quicker to troubleshoot. Therefore, given a choice, I'd prefer faults to fall into the 'easy to find' bucket. However, I am happy to concede that the problem may be relatively unlikely to occur, so may not be worth fixing. After all, I don't know what proportion of UAs that support 'sip.instance' don't also support GRUU. Nor do I know how many endpoints like to retrieve GRUUs via the reg-event package. The intersection of these two might be so small as to not be worth worrying about. > > If the problem you are trying to solve is simply to allow a request to > > be routed directly to a specific endpoint, then surely RFC3841 is > > sufficient. Just add: > > Accept-Contact: *;+sip.instance=3D"whatever";required;explicit > > > > This doesn't require inventing GRUUs for UAs that don't support them. > > Nor does it lead to an expectation that GRUUs are supported when they > > are not. >=20 > And it doesn't work. >=20 > Please read Section 4.5 of gruu-12 for an explanation of why this is not > a good idea. I have already read that section, and I saw the point you made. I don't happen to agree with it, which does suggest that RFC3841 can be read multiple ways. > -Jonathan R. Best regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 07:20:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWseq-0002HB-W6; Thu, 29 Mar 2007 07:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWsep-0002Gx-KI for sip@ietf.org; Thu, 29 Mar 2007 07:19:07 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWseo-0001XN-9f for sip@ietf.org; Thu, 29 Mar 2007 07:19:07 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HWseo-000594-12; Thu, 29 Mar 2007 04:19:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-ietf-sip-gruu-12 Date: Thu, 29 Mar 2007 04:18:25 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCD2DB1A@sea02-mxc01.citel.com> In-Reply-To: <200703282244.l2SMiq2S004492@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: Acdxiye+5XrjWKR/TqCIA6hOw1IzCQAYvHKA References: <20070311173655.DF5EE1CC24@delta.rtfm.com><45FDD909.6030906@cisco.com><76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <200703282244.l2SMiq2S004492@dragon.ariadne.com> From: "Michael Procter" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dale, Dale Worley wrote: > Strictly, +sip.instance means "here is my instance ID" and Support: > gruu means "I support GRUU". If both are present and the registrar > supports GRUU, the registrar will return a GRUU. >=20 > IMHO, the registrar can return a GRUU *anyway*, as the UA should > ignore unexpected field parameters in the returned Contact headers. Yes. >=20 > Let me see if I understand your point here by trying to restate a more > detailed example. I'm going to use an initial SUBSCRIBE to avoid the > complexities of INVITE. >=20 > UA2 sends SUBSCRIBE to UA1-GRUU. It gets routed to the proxy, which > routes it to UA1. UA1 sends a response containing a Contact which is > not a GRUU, and is not routable from UA2. Yes, that is essentially the scenario. Therefore a reSUBSCRIBE will not be delivered correctly in your example, whereas for my example, it is the ACK. > But it seems to me that in any such situation that works without GRUU, > the proxy or some intermediate system must be aware of the addressing > boundary between UA1 and UA2, and must consistently Record-Route > itself. And just because an incoming request uses a GRUU, doesn't > mean that the proxy can omit Record-Routing itself. >=20 > The risk is that the proxy implementor will not think of this problem, > and omit Record-Routing because the request uses a GRUU. Following > Jeroen, we need a statement somewhat like: >=20 > So section 6.2 should be updated to state "[...] and the > registration contains Path URI and/or the proxy does not have > positive knowledge that the destination UA(s) will use globally > routable URIs as Contacts." >=20 > Hmmm, that's not right, either. What I really mean is that if the the > addressing situation is different on "different sides of the proxy", > the proxy MUST Record-Route itself unless it *knows* that the Contacts > will resolve correctly on "the other side". Whilst I agree with the sentiment you are trying to express, I think Jeroen's statement might be implemented correctly more often. Jeroen's version also ensures that the signalling path is closer to that of normal GRUU usage, even though yours might allow the record-route to be omitted under certain circumstances when it is not necessary. Best regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 09:59:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv9m-00018u-2e; Thu, 29 Mar 2007 09:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv9j-00018p-V5 for sip@ietf.org; Thu, 29 Mar 2007 09:59:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWv9h-00013q-M1 for sip@ietf.org; Thu, 29 Mar 2007 09:59:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2007 09:59:09 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2TDx9Zi006012; Thu, 29 Mar 2007 09:59:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2TDx5Gf021301; Thu, 29 Mar 2007 13:59:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:59:07 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:59:06 -0400 Message-ID: <460BC62A.1000908@cisco.com> Date: Thu, 29 Mar 2007 09:59:06 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Procter Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> <460A7EBF.20600@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 13:59:06.0633 (UTC) FILETIME=[6A8EC790:01C7720A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2350; t=1175176749; x=1176040749; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20 |To:=20Michael=20Procter=20; bh=t2a+J1jiDBiDZkpmuncs3QrahTlDxM/CT+75L89vREk=; b=HRO1JDFeVfqVgLSnUpAYNk6gcGBt8USzgDL107Cm+cp3sNnZMDrGTrr/KgVkU5pOLr4KoNQD R7uDsUw5EqoPYtTlP2mguRaTHOWgoZcg6yQCbepYr2MUfSF3ox4sT8z9; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org addressing your philosophical point: Michael Procter wrote: > The second point (discussed below) is more 'philosophical' in nature. >>From our discussion to date, it seems reasonably clear to me that we are > not likely to agree on this point. I am content to drop this point, as > I don't think my practical concern is likely to be significant or > widespread. If you are happy to drop it, then please do so. Well, as you said, my opinion is that this is a non-issue and so yes, I'd like to see it dropped. > > You seem to be saying 'GRUUs are great. They solve a bunch of problems. > All UAs should implement GRUUs'. And I agree with all that. You then > go on to say 'But UAs that don't implement GRUU can still be made to > work most of the time'. And whilst this is also true, I find the > 'mostly' part disturbing. I didn't say 'most of the time', and nowhere in the gruu spec does it imply this either. > > I find it disturbing because I suspect some vendors might be less > inclined to implement GRUU ("if we can get 90% of the result with 0% of > the effort..."). > > I find it disturbing because a phone from a conscientious vendor might > just need a firmware upgrade to work well, but instead suffers from > occasional faults ("it works fine most of the time, but occasionally I > get cut off"). This issue is true for almost any protocol we produce. Every vendor, due to the fact that engineering costs money, will implement only the minimal thing that they feel they need to. This will happen regardless of what is in our specifications. That, however, is no excuse to remove features from our specs in order to force people to implement everything in order to get benefits. If anything, doing so in general raises the bar for implementation and pushes things off further. Not that I'm suggesting that implementors should skip implementing gruu in UA; I'm merely making a general point in response to your general concern. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 09:59:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv6D-0000Js-D7; Thu, 29 Mar 2007 09:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv6B-0000Jn-4v for sip@ietf.org; Thu, 29 Mar 2007 09:55:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWv68-0000cI-Qn for sip@ietf.org; Thu, 29 Mar 2007 09:55:31 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2007 09:55:29 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2TDtSUP004141; Thu, 29 Mar 2007 09:55:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2TDtKGl020135; Thu, 29 Mar 2007 13:55:20 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:55:13 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:55:13 -0400 Message-ID: <460BC53E.8020404@cisco.com> Date: Thu, 29 Mar 2007 09:55:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Procter Subject: proposed record-routing text, was: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> <460A7EBF.20600@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 13:55:13.0386 (UTC) FILETIME=[DF881CA0:01C77209] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2958; t=1175176528; x=1176040528; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20proposed=20record-routing=20text, =20was=3A=20Re=3A=20[Sip]=20 Review=20of=20draft-ietf-sip-gruu-12 |Sender:=20 |To:=20Michael=20Procter=20; bh=q9PWUGCikOtsZqp42TqHBIcxfeJoHEh8jh8aHggUBeM=; b=JZTm0vIj+VRhVkb/BDiy0wmIyJ2nDDfyZYnZResMsJ1oH92B6+eW24SavqExOKHWE1kUmg67 abmBysr2ePb/XFmtM1JyBbrkpZZZ5Jq8lEcO/akID/0hEKxaHj2mblol; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org changing subjects, folks please read the proposed text below. inline. Michael Procter wrote: > >>There is no problem here. If there are no Path headers, there is no > > need > >>to record-route, regardless of whether the UA uses GRUU or not. Can > > you > >>please indicate what specifically breaks if the proxy does not >>record-route when there are no GRUU and the UA doesn't (or does) > > insert > >>a GRUU. Seems to work fine. > > > Let's take the case of a UA and proxy/registrar being located on one > side of a firewall. Let's assume that all the IP addresses are global, > so that there are no NAT problems to worry about. The firewall, > however, doesn't accept incoming SIP requests, except to the > proxy/registrar. > > UA registers with proxy - no Path headers present or required. A > GRUU-supporting UA can make/receive calls to/from UAs on the other side > of the firewall quite happily in this scenario. > > For a non-GRUU-supporting UA, incoming calls will not succeed unless > there is some Record-Route assistance. Whether the initial INVITE is > sent to the AoR or an invented GRUU, it will route correctly, as will > the 200 response. But the 200 will contain a Contact that is not > globally routable. This is the key difference between a GRUU-supporting > UA and a non-GRUU-supporting UA that happens to have a GRUU created for > it. Unless the proxy/registrar inserts a Record-Route in the 200, the > ACK will not be deliverable, and the call will fail. Ah, now I see the disconnect. I think you (and others) are apparently treating the words in the gruu spec as both a definition of when to record-route and when NOT to record-route. So, if the spec says that you MUST record-route if there are Path headers and the request was a GRUU, you are assuming that if there aren't path headers and the request was a GRUU, the proxy can cease record-routing. I wasn't making any such assumption. I assume that proxies have reasons for record-routing and would continue to do so based on those reasons, including the fact that they are behind a firewall. I think, therefore, that the right words to clarify this are: If a terminating proxy requires mid-dialog requests to pass through it for whatever reason (firewall traversal, accounting, etc.), the proxy MUST still record route, and MUST NOT assume that a UA will utilize its GRUU in the Contact header field of its response (which would cause mid-dialog requests to pass through the proxy without record-routing). Does that work for people? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:01:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvBc-0001VF-53; Thu, 29 Mar 2007 10:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvBb-0001VA-Ea for sip@ietf.org; Thu, 29 Mar 2007 10:01:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvBa-0001FR-1p for sip@ietf.org; Thu, 29 Mar 2007 10:01:07 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2007 07:01:06 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2TE152B000974; Thu, 29 Mar 2007 07:01:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2TE0jAM007333; Thu, 29 Mar 2007 14:01:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:00:48 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:00:48 -0400 Message-ID: <460BC690.1060802@cisco.com> Date: Thu, 29 Mar 2007 10:00:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA References: <460A825C.4050902@cisco.com> <200703282212.l2SMCBEL002086@dragon.ariadne.com> In-Reply-To: <200703282212.l2SMCBEL002086@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 14:00:48.0383 (UTC) FILETIME=[A73498F0:01C7720A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2426; t=1175176865; x=1176040865; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20One=20remaining=20GRUU=20issue=3A=20GRUUs=20f or=20non-GRUU=20UA |Sender:=20; bh=lhBa9OYCPsSFaS2R5EQeLeyD0GNeypvmPFETSBF2t9A=; b=DzF2zO6B5TDN9DWB7kp76pGWIaLZn/Pc2x+XuDEy139fwYBSSCnOCuNgA94jg7xbE1hXYtUC jdjkPnWkbMTui7jE1Ji2G1RB0rO+LPnb6vBwDMK6s/R+xPU3RzjcwRVz; Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for chiming in Dale. So, so far I have three folks saying its a feature (myself, Dale, Peter) and Michael saying its a bug but he is willing to drop the issue. I'll give people another day or so, but unless anyone pipes up I think we can close this issue. There remains the issue on specific text around record-routing, please see my other note on the proposed text. -Jonathan R. Dale.Worley@comcast.net wrote: > From: Jonathan Rosenberg > > A complaint has been raised that this is inconsistent. Should an entity > use that GRUU, learned by reg-event, the request will be delivered to > the UA instance, but > [the response] will include a non-GRUU in its Contact, and so > from then on, GRUU-enabled features like transfer won't work since the > UA doesn't support GRUU. The argument was made that this is effectively > false advertising since GRUU isn't REALLY supported for this UA. > > I agree with you and Peter that this is not a bug. > > 1) This situation causes no additional failures relative to the > situation where the registrar does not construct a GRUU for the > non-GRUU-supporting UA. > > 2) It's not false advertising if the UA making the initial contact is > paying attention -- the response does not contain "Supported: > gruu", and the Contact it provides in the response is > self-evidently not a GRUU (due to the absence of the "gr" > parameter). > > 3) Indeed, if the UA making the contact desires a GRUU for the other > UA, and the Contact in the response is not a GRUU, *the UA already > has a GRUU for the other UA in hand*. Being self-evidently a GRUU, > it can be safely used for all GRUUish needs. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:12:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvLy-0002gp-1q; Thu, 29 Mar 2007 10:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvLv-0002f3-QJ for sip@ietf.org; Thu, 29 Mar 2007 10:11:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvLu-0002Tp-Fp for sip@ietf.org; Thu, 29 Mar 2007 10:11:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2007 10:11:47 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2TEBk84006495 for ; Thu, 29 Mar 2007 10:11:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2TEBWGx024507 for ; Thu, 29 Mar 2007 14:11:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:11:37 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:11:37 -0400 Message-ID: <460BC917.5060600@cisco.com> Date: Thu, 29 Mar 2007 10:11:35 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 14:11:37.0300 (UTC) FILETIME=[29FD7940:01C7720C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2285; t=1175177506; x=1176041506; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20GRUU=20text=20around=20modification=20of=20URI=20parameters |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=lWygqQb2AC0X648UwSbTzmXO8oeJzp+0vWpr1aiZHok=; b=wZ37FDKWl8B0D9PpKKLUAxI/tq6CipleFw2MIZcgs9AzOCB6+zqE5Hsv3nT3niOCLLaAth7o /7rVnEKnP46fj/EHrOF2biHAhH+mN5esnQNFCZTw9llg7KGu2fmJu42S; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] GRUU text around modification of URI parameters X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org During the Prague IETF, I discussed a change I made in GRUU-12. I had combed through Dale Worleys implementing GRUU draft, and extracted two items from it which seemed more appropriate in the GRUU spec itself. One of them had to do with UA's treating the GRUUs as opaque. COnsequently, this text made it into GRUU-12: The GRUU learned by the UA in the REGISTER response MUST be treated opaquely by the UA. That is, the UA MUST NOT modify it in any way (including adding or removal of URI parameters). During the meeting, Adam Roach correctly pointed out that these words would prohibit UA loose route: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt from working. That draft meets our charter goal of delivering params to a UA by allowing a UA to insert params of its own choosing into the GRUU. OOps. So, I took an action item to look over the URI parameters and make a more concrete recommendation on which URI parameters were subject to manipulation by a UA. I went through the IANA registry of URI params and here is the text I came up with: The user and host parts of the GRUU learned by the UA in the REGISTER response MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them in any way. Furthermore, the UA MUST NOT add or remove URI parameters relevant for receipt and processing of request at the proxy, including the transport, lr, maddr, ttl, user, and comp parameters. This is more or less all of the URI parameters from 3261, excepting header field, body, and method params, which I think are inappropriate for GRUU anyway. It also omits the URI params registered by RFC 4458 and RFC 4240 (the voicemail URI and netann specs). Again I think those make no sense here. I've put the above text into my working -13. Unless someone objects I'll consider this issue closed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:14:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvOP-00058i-8D; Thu, 29 Mar 2007 10:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvON-00058d-Ft for sip@ietf.org; Thu, 29 Mar 2007 10:14:19 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvOL-0002rs-TG for sip@ietf.org; Thu, 29 Mar 2007 10:14:19 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2TEEGZg047734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 08:14:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <460081CA.20800@cisco.com> References: <460081CA.20800@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] some comments on draft-ietf-sip-sips Date: Thu, 29 Mar 2007 09:14:14 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I also think disallowing upgrades is the better course. I still have misgivings about how likely an implementation is to do the "right thing" WRT informing its user when it receives an INVITE over TLS with a sips: RURI, but a sip: URI in the To: header. If it makes the mistake of presenting this as a "secure" invitation, the UAS's user may make a very wrong choice in answering the call (and possibly compound the error later with REFERs in that dialog). If we do allow an upgrade retarget, we are sanctioning a downgrade in the reverse direction for subsequent requests in the dialog that gets established. Thus the only "right thing" for the above implementation to do is to present this call as a normal sip: call. So the only benefit of allowing an upgrade I see is that some part of the signaling happens over TLS. But that can be achieved by preferring hop-by-hop TLS anyhow. In a flow through the networks we anticipate, retargetting anywhere but the (near) last hop will occur because of configuration, usually under the control of the operator of the retargetting element. That same level of configuration effort can go into properly populating DNS to cause TLS to be used. The retargetting due to registrations at the (near) last hop is likely to be mooted by outbound. It appears to greatly simplify things if this kind of upgrade can't happen and we rely on redirection all the way to the endpoint. RjS On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote: > In a separate thread, we've been discussing whether we can make > this draft normative and finally go about 'fixing' the things that > make SIPS broken. Besides the last hop exception problem, there is > another bit which is very problematic: > >> The presence of a SIPS Request-URI does not necessarily indicate >> that >> the request was sent securely on each hop. As described in >> [RFC3261]/26.4.4, a proxy may legitimately retarget a request from >> SIP to SIPS. Therefore, a UAS MUST NOT assume on the basis of the >> Request-URI alone that SIPS was used for the entire request path. > > > Retargeting from sips to sip is a lot like the last hop exception > rule, and it really ruins the ability for the UAS to verify the > main security property provided by SIPS. Instead of the ad-hoc > algorithms suggested as ways to actually verify this, can we change > this rule? Proxy MUST NOT retarget a sips URI to sip. I think I've > suggested tihs in the past that I think we need to outright forbid > up and downgrades. > > Section 4.2 - does this evaporate if we can make this change to not > change sip to sips? > > Indeed I think this document becomes oodles simpler when we > eliminate these two exceptions. I think the doc is still pretty > complicated since there are so many exceptions and variations. I > want it to be, you ar eeither sips, in which case EVERYTHING is > sips, or you are sip, in which case NOTHING is sips. Really easy > that way, and it gives us the security property we need. > >> The USC registers either a SIPS or a SIP AOR. From a routing >> perspective, it does not matter which one is used for >> registration as >> they identify the same resource. >> If all the Contacts are SIPS, a SIPS AOR MUST also be used by the >> UAC. If at least one of the Contacts is SIP or is neither SIP nor >> SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be >> used by >> the UAC. > > isn't this a contradiction? The first paragraph says that it > doesn't matter whether you use sip or sips. Then the next says why > you pick a sip or sips aor. > > Also I tihnk the text should be restructured a bit to say that, a > UA can operate in one of three modes - sips only, sip only or > either. And then based on that, how do you set each of the > parameters in the REGISTER (To, from, contact, r-uri). The current > text is inverted and you have to work backwards in some places to > sort it out. > > I don't really see why the AOR in the To is relevant at all (sip > vs. sips). > >> A registrar MUST only accept a binding to a SIPS Contact if all the >> appropriate URIs are of the SIPS scheme: i.e., the Request-URI, >> the >> AOR (i.e., To header), the From header, the Contacts and all >> the Path >> headers. If the URIs are not of the proper SIPS scheme, it must >> reject the REGISTER with a 403 "Forbidden". > > I don't see why the To and From are relevant. Indeed I think a sips > contact can be accepted as long as the r-uri was sips. For path, > its really a double check since they should have been sips based on > other rules, should probably make that clear. > >> SIPS in a Dialog >> There MUST be only one Contact in any request resulting in the >> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). > > This is a basic 3261 requirement having nothing to do with sips; > might want to merely state this as fact. > >> As mandated by [RFC3261]/8.1.1.8, in a request, if the Request-URI or >> top Route header field value contains a SIPS URI, the Contact >> header >> field MUST contain a SIPS URI as well. Furthermore, as >> mandated by >> [RFC3261]/12.1.1, if the request that initiated the dialog >> contained >> a SIPS URI in the Request-URI or in the top Record-Route header >> field >> value, if there was any, or the Contact header field if there >> was no >> Record-Route header f > > There are three statemenets in the or condition. However, if the > first is true, and we eliminate the last hop exception and retarget > exception, unless there is a protocol error the others will be true > too. This is one of many places where sips is just way simpler if > we do that. > >> be careful about what to use in the Contact (in case Record-Route is >> not used for this hop). If the Contact was a SIPS URI, it >> would mean >> that it would only accept mid-dialog requests that are over secure >> transport end-to-end. Since the Request-URI is in this case a SIP >> URI, it is quite possible that the UA sending a request to that >> URI >> may not be able to send requests to SIPS URIs. It is therefore >> RECOMMENDED that in this case, the Contact be a SIP URI, even >> if the >> request is sent over a secure transport (e.g., the first hop >> could be >> re-using a TLS connection to the proxy as would be the case with >> [I-D.ietf-sip-outbound]). > > why is this just RECOMMENDED and not MUST? > >> When a target refresh occurs within a dialog (e.g., re-INVITE, >> UPDATE), unless there is a need to change it, the UAC SHOULD >> include >> a Contact header with a SIPS URI if the original request used a >> SIPS >> Request-URI. > > why not MUST? > >> Sessions, dialogs and transactions may be "derived" from existings >> ones. >> As a general principle, derived dialogs and transactions SHOULD >> NOT >> result in an effective downgrading of SIPS to SIP, without the >> explicit authorization of the entities involved. > > unless you formally define 'derived' this is a meaningless > requirement. > >> However, for backward compatibility, if a "transport=tls" parameter >> is received, it should be interpreted as per the following >> guidelines: >> o [RFC3261]/16.7 states the transport parameter (e.g., with >> tcp or >> udp) SHOULD NOT be used in Record-Route unless it has knowledge >> that the next upstream element that will be in the path of >> subsequent supports this transport. Generally, it is >> recommended >> that the transport parameter never be used in a Record-Route, >> Route or Path header. Since the transport=tls URI parameter >> has >> been deprecated, it MUST NOT be used in Route, Record-Route or >> Path headers, and MUST be ignored. >> o In a Contact in a dialog, it MAY be interpreted as a request to >> send incoming mid-dialog requests using TLS. Note that this >> would >> only have a significance if [I-D.ietf-sip-outbound] and Record- >> Route are not used, and if that URI is nevertheless >> reachable with >> TLS which is extremely unlikely. If it was the case that it >> was >> reachable with TLS, say because there is an active TLS >> connection, > > the first paragraph says that what follows will be what to do if > you receive transport=tls, but the first bullet is about sending > it. In that paragraph you say its 'recommneded' not to be used in > RR, Route or Path, and then next sentence is MUST NOT. So which is it? > > If this is normative do we need to carry forward text on > transport=tls beyond saying don't send and ignore on receive? > > > Thanks, > Jonathan R. > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:16:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvQZ-0006bA-Gp; Thu, 29 Mar 2007 10:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvQX-0006az-QA for sip@ietf.org; Thu, 29 Mar 2007 10:16:33 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvQW-00038X-H5 for sip@ietf.org; Thu, 29 Mar 2007 10:16:33 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070329141631b1400o38pse>; Thu, 29 Mar 2007 14:16:31 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2TEGULv008170 for ; Thu, 29 Mar 2007 09:16:30 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2TEGUkp008161; Thu, 29 Mar 2007 09:16:30 -0500 Date: Thu, 29 Mar 2007 09:16:30 -0500 Message-Id: <200703291416.l2TEGUkp008161@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <76431CABEC5EED489807DB8AEBCCA0BCD2DB1A@sea02-mxc01.citel.com> (michael.procter@citel.com) Subject: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com><45FDD909.6030906@cisco.com><76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <200703282244.l2SMiq2S004492@dragon.ariadne.com> <76431CABEC5EED489807DB8AEBCCA0BCD2DB1A@sea02-mxc01.citel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jeroen van Bemmel" So section 6.2 should be updated to state "[...] and the registration contain Path URI and/or the registered Contact is not globally routable" From: "Michael Procter" > So section 6.2 should be updated to state "[...] and the > registration contains Path URI and/or the proxy does not have > positive knowledge that the destination UA(s) will use globally > routable URIs as Contacts." > > Hmmm, that's not right, either. What I really mean is that if the the > addressing situation is different on "different sides of the proxy", > the proxy MUST Record-Route itself unless it *knows* that the Contacts > will resolve correctly on "the other side". Whilst I agree with the sentiment you are trying to express, I think Jeroen's statement might be implemented correctly more often. Jeroen's version also ensures that the signalling path is closer to that of normal GRUU usage, even though yours might allow the record-route to be omitted under certain circumstances when it is not necessary. It's worse than that, even. What we want to make sure is either (1) the Contact in the response will be usable by the UAC, or (2) the proxy record-routes itself. (2) is easy to achieve if you are aware of the need. (1) is really difficult. Among other things, the proxy has to know what Contact the UAS *will* put in the reponse (which may not be the registered contact for the GRUU!), and it has to know what the routing properties are for those Contacts. I suppose that if the proxy *knows* the UAs are using globally-routable Contacts, you can achieve (1), but that knowledge is going to be very hard to achieve in practice. Personally, I'd say that we should say that the proxy should always Record-Route, and leave it to a proxy that wishes to omit Record-Routing under some circumstance to demonstrate that it's not causing a problem. I'm not sure which camp I'm in with the above opinion, because I see these sorts of situations as one in which the proxy is (without GRUU) going to have to record-route much of the time, and so I don't see GRUU as adding *additional* difficulties. I suppose it could cause problems if a naive implementor said "We support GRUU so we don't have to record-route", but that opinion could only come from a fundamental misapprehension of the situation. From: "Michael Procter" Unless the proxy/registrar inserts a Record-Route in the 200, the ACK will not be deliverable, and the call will fail. Remember, a proxy can't add a Record-Route to a response, only to the request that will generate the response. Problems like this occurring in a real deployment generally take some time to diagnose correctly, especially if it is still viewed as 'intermittent' until the true scenario is identified. Conversely problems that fall in to the general category of 'calls never work' are usually much quicker to troubleshoot. Therefore, given a choice, I'd prefer faults to fall into the 'easy to find' bucket. Is this sort of problem more likely to occur? As long as proxies are diligent about record-routing, do these "unexpected GRUU" situations cause more "intermittent" failure situations than we now have? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvSC-0007R5-Dw; Thu, 29 Mar 2007 10:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvSB-0007R0-Hm for sip@ietf.org; Thu, 29 Mar 2007 10:18:15 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvSA-0003Re-7B for sip@ietf.org; Thu, 29 Mar 2007 10:18:15 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HWvS9-0007D3-9j; Thu, 29 Mar 2007 07:18:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: proposed record-routing text, was: Re: [Sip] Review of draft-ietf-sip-gruu-12 Date: Thu, 29 Mar 2007 07:17:01 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCD2DB3B@sea02-mxc01.citel.com> In-Reply-To: <460BC53E.8020404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed record-routing text, was: Re: [Sip] Review of draft-ietf-sip-gruu-12 Thread-Index: AcdyCc/JcEnyJEEzSSep71h0tT1a3gAAufzg References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> <460A7EBF.20600@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> <460BC53E.8020404@cisco.com> From: "Michael Procter" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > I think, therefore, that the right words to clarify this are: >=20 >=20 > If a terminating proxy requires mid-dialog requests to pass through it > for whatever reason (firewall traversal, accounting, etc.), the proxy > MUST still record route, and MUST NOT assume that a UA will utilize its > GRUU in the Contact header field of its response (which would cause > mid-dialog requests to pass through the proxy without record-routing). >=20 >=20 > Does that work for people? It works for me. It is in fact more stringent than I was looking for, but handles a case I hadn't considered. Best regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:55:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWw1T-0003jY-Dv; Thu, 29 Mar 2007 10:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWw1S-0003hn-O9 for sip@ietf.org; Thu, 29 Mar 2007 10:54:42 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWw1R-000121-IF for sip@ietf.org; Thu, 29 Mar 2007 10:54:42 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007032914544101400bpv6pe>; Thu, 29 Mar 2007 14:54:41 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2TEseLv010983 for ; Thu, 29 Mar 2007 09:54:40 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2TEsc8B010974; Thu, 29 Mar 2007 09:54:38 -0500 Date: Thu, 29 Mar 2007 09:54:38 -0500 Message-Id: <200703291454.l2TEsc8B010974@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20070327153823.8DAEA1CC22@delta.rtfm.com> (ekr@networkresonance.com) Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs References: <20070327153823.8DAEA1CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: EKR > > In order to generate a temp GRUU, you generate a random 80-bit > > distinguisher value D. Then compute: > > M = D || I. > > E = AES-ECB-Encrypt(K_e, M) > > A = HMAC-SHA256-80(K_a, E) > > Temp-GRUU = E || A > > FOr the crypto-ignorant - what is AES-ECB-Encrypt? Encrypt with AES in cipher-block-chaining mode. I admit this isn't my area of expertise, but don't you mean "AES in electronic-code-book mode"? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 10:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWw4E-0002BX-Pa; Thu, 29 Mar 2007 10:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWw4D-0002BK-R4 for sip@ietf.org; Thu, 29 Mar 2007 10:57:33 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a8.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWw4B-0001fZ-1K for sip@ietf.org; Thu, 29 Mar 2007 10:57:33 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id 677F2AF583; Thu, 29 Mar 2007 07:57:30 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 9EF571CC29; Thu, 29 Mar 2007 07:56:10 -0700 (PDT) To: Dale.Worley@comcast.net Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs References: <20070327153823.8DAEA1CC22@delta.rtfm.com> <200703291454.l2TEsc8B010974@dragon.ariadne.com> From: EKR Date: Thu, 29 Mar 2007 07:56:10 -0700 In-Reply-To: <200703291454.l2TEsc8B010974@dragon.ariadne.com> (Dale Worley's message of "Thu, 29 Mar 2007 09:54:38 -0500") Message-ID: <86y7lgnlo5.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net writes: > From: EKR > > > > In order to generate a temp GRUU, you generate a random 80-bit > > > distinguisher value D. Then compute: > > > M = D || I. > > > E = AES-ECB-Encrypt(K_e, M) > > > A = HMAC-SHA256-80(K_a, E) > > > Temp-GRUU = E || A > > > > FOr the crypto-ignorant - what is AES-ECB-Encrypt? > > Encrypt with AES in cipher-block-chaining mode. > > I admit this isn't my area of expertise, but don't you mean "AES in > electronic-code-book mode"? Gah, yes. I'm so used to writing CBC that my brain slipped. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 11:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwCq-0004qr-8b; Thu, 29 Mar 2007 11:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwCo-0004pb-FK for sip@ietf.org; Thu, 29 Mar 2007 11:06:26 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwCQ-0003mE-Tf for sip@ietf.org; Thu, 29 Mar 2007 11:06:26 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070329150602b1400o4abee>; Thu, 29 Mar 2007 15:06:02 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2TF61Lv011813 for ; Thu, 29 Mar 2007 10:06:01 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2TF61Yh011809; Thu, 29 Mar 2007 10:06:01 -0500 Date: Thu, 29 Mar 2007 10:06:01 -0500 Message-Id: <200703291506.l2TF61Yh011809@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <460BC53E.8020404@cisco.com> (jdrosen@cisco.com) Subject: Re: proposed record-routing text, was: Re: [Sip] Review of draft-ietf-sip-gruu-12 References: <20070311173655.DF5EE1CC24@delta.rtfm.com> <45FDD909.6030906@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC016@sea02-mxc01.citel.com> <45FFC305.9060403@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCCAC24E@sea02-mxc01.citel.com> <4600F02F.10406@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2CD4A@sea02-mxc01.citel.com> <46091480.8060908@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2D788@sea02-mxc01.citel.com> <460A7EBF.20600@cisco.com> <76431CABEC5EED489807DB8AEBCCA0BCD2DB14@sea02-mxc01.citel.com> <460BC53E.8020404@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg If a terminating proxy requires mid-dialog requests to pass through it for whatever reason (firewall traversal, accounting, etc.), the proxy MUST still record route, and MUST NOT assume that a UA will utilize its GRUU in the Contact header field of its response (which would cause mid-dialog requests to pass through the proxy without record-routing). I think that captures what we need. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 12:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxgJ-0000O3-KZ; Thu, 29 Mar 2007 12:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxgI-0000Ny-Fb for sip@ietf.org; Thu, 29 Mar 2007 12:40:58 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxgH-0003eR-68 for sip@ietf.org; Thu, 29 Mar 2007 12:40:58 -0400 Received: from [10.84.143.24] (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2TFksrZ012369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 09:46:55 -0600 In-Reply-To: <055e01c7718f$54c90270$800101df@acmepacket.com> References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Thu, 29 Mar 2007 11:40:28 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 'IETF SIP List' , 'Sean Olson' , 'Francois Audet' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 28, 2007, at 6:17 PM, Hadriel Kaplan wrote: > > Well I can give one: it has the same semantics and security > property you get > with a syntax of Require/Proxy-require:tls. not exactly, and this is exactly the point of been trying to make about why changing the behavior of sips: without making any other changes is pointless. Assume we update 3261 with new mandatory behavior for sips: request URIs. An existing proxy that doesn't conform to the new requirements (and therefore does up/downgrades) will still give us an indeterminate state. Was the request sips: on all hops? There is no evil required for this to happen, just obsolescence. Assume instead a new extension option tag that requires proxies understanding it to implement the new behavior for sips:. We use this in Requires and Proxy-Requires whenever a "new behavior" UAC creates a request with a sips: r-uri. I'd call this mode "required sips:". Any reasonable existing UA or proxy will reject a request that Requires/Proxy-Requires an option not understood by that UA or proxy. Any reasonable new UA or proxy understanding the new extension can be expected to implement the new required behavior. While this doesn't give us assurance that there were no evil proxies on the path, it does give us an assurance that there were no obsolete proxies that couldn't be reasonably expected to have done "the right thing" with sips:. It's a "fail safe" instead of "fail dangerous" distinction. If it turns out that we have an obsolete node on the path that don't understand the extension, we could (after informing the user of the problem) retry the request without the option tag, thereby falling back to the current "best effort" sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 12:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxpf-0005ka-1P; Thu, 29 Mar 2007 12:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxpd-0005kU-U2 for sip@ietf.org; Thu, 29 Mar 2007 12:50:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxpb-0005tP-Ow for sip@ietf.org; Thu, 29 Mar 2007 12:50:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2007 12:50:36 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2TGoZQ0023090; Thu, 29 Mar 2007 12:50:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2TGoZGd010828; Thu, 29 Mar 2007 16:50:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 12:50:35 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 12:50:34 -0400 Message-ID: <460BEE5A.3060909@cisco.com> Date: Thu, 29 Mar 2007 12:50:34 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: important gruu issue on implementability, was: Re: [Sip] sizeof temporary GRUUs References: <20070327153823.8DAEA1CC22@delta.rtfm.com> <200703291454.l2TEsc8B010974@dragon.ariadne.com> <86y7lgnlo5.fsf@delta.rtfm.com> In-Reply-To: <86y7lgnlo5.fsf@delta.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 16:50:34.0720 (UTC) FILETIME=[5EBC4600:01C77222] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1413; t=1175187035; x=1176051035; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20important=20gruu=20issue=20on=20implementability, =09w as=3A=20Re=3A=20[Sip]=20sizeof=0A=20temporary=20GRUUs |Sender:=20 |To:=20EKR=20; bh=1uf68Sq2zuCqYcPh8AqbTi9XNSYPp55P3jH+0ST67D4=; b=wEk0/dJJkKdQhfWIH0/kiH1UCZU55bkrdQK/DhgatxhefVp0Xw4RP+WPwtIbcRnIpgIPqEcD 7yefvI/5R+IUt6Od545AI5Yw0yGNkq+kSSBEalTazNHyZyImp81Pg1XH; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK, I fixed in my working text. -Jonathan R. EKR wrote: > Dale.Worley@comcast.net writes: > > >> From: EKR >> >> > > In order to generate a temp GRUU, you generate a random 80-bit >> > > distinguisher value D. Then compute: >> > > M = D || I. >> > > E = AES-ECB-Encrypt(K_e, M) >> > > A = HMAC-SHA256-80(K_a, E) >> > > Temp-GRUU = E || A >> > >> > FOr the crypto-ignorant - what is AES-ECB-Encrypt? >> >> Encrypt with AES in cipher-block-chaining mode. >> >>I admit this isn't my area of expertise, but don't you mean "AES in >>electronic-code-book mode"? > > > Gah, yes. I'm so used to writing CBC that my brain slipped. > > -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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy4x-0001tD-6X; Thu, 29 Mar 2007 13:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy4v-0001p7-K4 for sip@ietf.org; Thu, 29 Mar 2007 13:06:25 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWy2q-0000iN-V5 for sip@ietf.org; Thu, 29 Mar 2007 13:04:18 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TH44w25574; Thu, 29 Mar 2007 17:04:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] some comments on draft-ietf-sip-sips Date: Thu, 29 Mar 2007 12:04:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF3332@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] some comments on draft-ietf-sip-sips Thread-Index: AcdyDJRqnUKDdhFpR4yAY0ryiDc6KAAF3r4w References: <460081CA.20800@cisco.com> From: "Francois Audet" To: "Robert Sparks" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Robert. Exactly my toughts as well. I think it would mean that the draft should include some language about prefereing TLS transport anyhow (it was my intention to add that in).=20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Thursday, March 29, 2007 07:14 > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] some comments on draft-ietf-sip-sips >=20 > I also think disallowing upgrades is the better course. >=20 > I still have misgivings about how likely an implementation is=20 > to do the "right thing" WRT informing its user when it=20 > receives an INVITE over TLS with a sips: RURI, but a sip: URI=20 > in the To: header. If it makes the mistake of presenting this=20 > as a "secure" invitation, the UAS's user may make a very=20 > wrong choice in answering the call (and possibly compound the=20 > error later with REFERs in that dialog). >=20 > If we do allow an upgrade retarget, we are sanctioning a=20 > downgrade in the reverse direction for subsequent requests in=20 > the dialog that gets established. Thus the only "right thing"=20 > for the above implementation to do is to present this call as=20 > a normal sip: call. >=20 > So the only benefit of allowing an upgrade I see is that some=20 > part of the signaling happens over TLS. But that can be=20 > achieved by preferring hop-by-hop TLS anyhow. In a flow=20 > through the networks we anticipate, retargetting anywhere but=20 > the (near) last hop will occur because of configuration,=20 > usually under the control of the operator of the retargetting element. > That same level of configuration effort can go into properly=20 > populating DNS to cause TLS to be used. The retargetting due=20 > to registrations at the (near) last hop is likely to be=20 > mooted by outbound. >=20 > It appears to greatly simplify things if this kind of upgrade=20 > can't happen and we rely on redirection all the From sip-bounces@ietf.org Thu Mar 29 13:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy4x-0001tD-6X; Thu, 29 Mar 2007 13:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy4v-0001p7-K4 for sip@ietf.org; Thu, 29 Mar 2007 13:06:25 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWy2q-0000iN-V5 for sip@ietf.org; Thu, 29 Mar 2007 13:04:18 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TH44w25574; Thu, 29 Mar 2007 17:04:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] some comments on draft-ietf-sip-sips Date: Thu, 29 Mar 2007 12:04:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF3332@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] some comments on draft-ietf-sip-sips Thread-Index: AcdyDJRqnUKDdhFpR4yAY0ryiDc6KAAF3r4w References: <460081CA.20800@cisco.com> From: "Francois Audet" To: "Robert Sparks" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Robert. Exactly my toughts as well. I think it would mean that the draft should include some language about prefereing TLS transport anyhow (it was my intention to add that in).=20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Thursday, March 29, 2007 07:14 > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] some comments on draft-ietf-sip-sips >=20 > I also think disallowing upgrades is the better course. >=20 > I still have misgivings about how likely an implementation is=20 > to do the "right thing" WRT informing its user when it=20 > receives an INVITE over TLS with a sips: RURI, but a sip: URI=20 > in the To: header. If it makes the mistake of presenting this=20 > as a "secure" invitation, the UAS's user may make a very=20 > wrong choice in answering the call (and possibly compound the=20 > error later with REFERs in that dialog). >=20 > If we do allow an upgrade retarget, we are sanctioning a=20 > downgrade in the reverse direction for subsequent requests in=20 > the dialog that gets established. Thus the only "right thing"=20 > for the above implementation to do is to present this call as=20 > a normal sip: call. >=20 > So the only benefit of allowing an upgrade I see is that some=20 > part of the signaling happens over TLS. But that can be=20 > achieved by preferring hop-by-hop TLS anyhow. In a flow=20 > through the networks we anticipate, retargetting anywhere but=20 > the (near) last hop will occur because of configuration,=20 > usually under the control of the operator of the retargetting element. > That same level of configuration effort can go into properly=20 > populating DNS to cause TLS to be used. The retargetting due=20 > to registrations at the (near) last hop is likely to be=20 > mooted by outbound. >=20 > It appears to greatly simplify things if this kind of upgrade=20 > can't happen and we rely on redirection all the way to the endpoint. >=20 > RjS >=20 > On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote: >=20 > > In a separate thread, we've been discussing whether we can=20 > make this=20 > > draft normative and finally go about 'fixing' the things that make=20 > > SIPS broken. Besides the last hop exception problem, there=20 > is another=20 > > bit which is very problematic: > > > >> The presence of a SIPS Request-URI does not necessarily indicate=20 > >> that > >> the request was sent securely on each hop. As described in > >> [RFC3261]/26.4.4, a proxy may legitimately retarget a=20 > request from > >> SIP to SIPS. Therefore, a UAS MUST NOT assume on the=20 > basis of the > >> Request-URI alone that SIPS was used for the entire=20 > request path. > > > > > > Retargeting from sips to sip is a lot like the last hop exception=20 > > rule, and it really ruins the ability for the UAS to verify=20 > the main=20 > > security property provided by SIPS. Instead of the ad-hoc=20 > algorithms=20 > > suggested as ways to actually verify this, can we change this rule?=20 > > Proxy MUST NOT retarget a sips URI to sip. I think I've=20 > suggested tihs=20 > > in the past that I think we need to outright forbid up and=20 > downgrades. > > > > Section 4.2 - does this evaporate if we can make this change to not=20 > > change sip to sips? > > > > Indeed I think this document becomes oodles simpler when we=20 > eliminate=20 > > these two exceptions. I think the doc is still pretty complicated=20 > > since there are so many exceptions and variations. I want it to be,=20 > > you ar eeither sips, in which case EVERYTHING is sips, or=20 > you are sip,=20 > > in which case NOTHING is sips. Really easy that way, and it=20 > gives us=20 > > the security property we need. > > > >> The USC registers either a SIPS or a SIP AOR. From a routing > >> perspective, it does not matter which one is used for=20 > registration=20 > >> as > >> they identify the same resource. > >> If all the Contacts are SIPS, a SIPS AOR MUST also be=20 > used by the > >> UAC. If at least one of the Contacts is SIP or is=20 > neither SIP nor > >> SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST=20 > also be used=20 > >> by > >> the UAC. > > > > isn't this a contradiction? The first paragraph says that=20 > it doesn't=20 > > matter whether you use sip or sips. Then the next says why=20 > you pick a=20 > > sip or sips aor. > > > > Also I tihnk the text should be restructured a bit to say=20 > that, a UA=20 > > can operate in one of three modes - sips only, sip only or=20 > either. And=20 > > then based on that, how do you set each of the parameters in the=20 > > REGISTER (To, from, contact, r-uri). The current text is=20 > inverted and=20 > > you have to work backwards in some places to sort it out. > > > > I don't really see why the AOR in the To is relevant at all=20 > (sip vs.=20 > > sips). > > > >> A registrar MUST only accept a binding to a SIPS Contact=20 > if all the > >> appropriate URIs are of the SIPS scheme: i.e., the Request-URI,=20 > >> the > >> AOR (i.e., To header), the From header, the Contacts=20 > and all the=20 > >> Path > >> headers. If the URIs are not of the proper SIPS scheme, it must > >> reject the REGISTER with a 403 "Forbidden". > > > > I don't see why the To and From are relevant. Indeed I think a sips=20 > > contact can be accepted as long as the r-uri was sips. For=20 > path, its=20 > > really a double check since they should have been sips=20 > based on other=20 > > rules, should probably make that clear. > > > >> SIPS in a Dialog > >> There MUST be only one Contact in any request resulting in the > >> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). > > > > This is a basic 3261 requirement having nothing to do with=20 > sips; might=20 > > want to merely state this as fact. > > > >> As mandated by [RFC3261]/8.1.1.8, in a request, if the=20 > Request-URI or > >> top Route header field value contains a SIPS URI, the Contact=20 > >> header > >> field MUST contain a SIPS URI as weway to the endpoint. >=20 > RjS >=20 > On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote: >=20 > > In a separate thread, we've been discussing whether we can=20 > make this=20 > > draft normative and finally go about 'fixing' the things that make=20 > > SIPS broken. Besides the last hop exception problem, there=20 > is another=20 > > bit which is very problematic: > > > >> The presence of a SIPS Request-URI does not necessarily indicate=20 > >> that > >> the request was sent securely on each hop. As described in > >> [RFC3261]/26.4.4, a proxy may legitimately retarget a=20 > request from > >> SIP to SIPS. Therefore, a UAS MUST NOT assume on the=20 > basis of the > >> Request-URI alone that SIPS was used for the entire=20 > request path. > > > > > > Retargeting from sips to sip is a lot like the last hop exception=20 > > rule, and it really ruins the ability for the UAS to verify=20 > the main=20 > > security property provided by SIPS. Instead of the ad-hoc=20 > algorithms=20 > > suggested as ways to actually verify this, can we change this rule?=20 > > Proxy MUST NOT retarget a sips URI to sip. I think I've=20 > suggested tihs=20 > > in the past that I think we need to outright forbid up and=20 > downgrades. > > > > Section 4.2 - does this evaporate if we can make this change to not=20 > > change sip to sips? > > > > Indeed I think this document becomes oodles simpler when we=20 > eliminate=20 > > these two exceptions. I think the doc is still pretty complicated=20 > > since there are so many exceptions and variations. I want it to be,=20 > > you ar eeither sips, in which case EVERYTHING is sips, or=20 > you are sip,=20 > > in which case NOTHING is sips. Really easy that way, and it=20 > gives us=20 > > the security property we need. > > > >> The USC registers either a SIPS or a SIP AOR. From a routing > >> perspective, it does not matter which one is used for=20 > registration=20 > >> as > >> they identify the same resource. > >> If all the Contacts are SIPS, a SIPS AOR MUST also be=20 > used by the > >> UAC. If at least one of the Contacts is SIP or is=20 > neither SIP nor > >> SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST=20 > also be used=20 > >> by > >> the UAC. > > > > isn't this a contradiction? The first paragraph says that=20 > it doesn't=20 > > matter whether you use sip or sips. Then the next says why=20 > you pick a=20 > > sip or sips aor. > > > > Also I tihnk the text should be restructured a bit to say=20 > that, a UA=20 > > can operate in one of three modes - sips only, sip only or=20 > either. And=20 > > then based on that, how do you set each of the parameters in the=20 > > REGISTER (To, from, contact, r-uri). The current text is=20 > inverted and=20 > > you have to work backwards in some places to sort it out. > > > > I don't really see why the AOR in the To is relevant at all=20 > (sip vs.=20 > > sips). > > > >> A registrar MUST only accept a binding to a SIPS Contact=20 > if all the > >> appropriate URIs are of the SIPS scheme: i.e., the Request-URI,=20 > >> the > >> AOR (i.e., To header), the From header, the Contacts=20 > and all the=20 > >> Path > >> headers. If the URIs are not of the proper SIPS scheme, it must > >> reject the REGISTER with a 403 "Forbidden". > > > > I don't see why the To and From are relevant. Indeed I think a sips=20 > > contact can be accepted as long as the r-uri was sips. For=20 > path, its=20 > > really a double check since they should have been sips=20 > based on other=20 > > rules, should probably make that clear. > > > >> SIPS in a Dialog > >> There MUST be only one Contact in any request resulting in the > >> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). > > > > This is a basic 3261 requirement having nothing to do with=20 > sips; might=20 > > want to merely state this as fact. > > > >> As mandated by [RFC3261]/8.1.1.8, in a request, if the=20 > Request-URI or > >> top Route header field value contains a SIPS URI, the Contact=20 > >> header > >> field MUST contain a SIPS URI as well. Furthermore, as=20 > mandated=20 > >> by > >> [RFC3261]/12.1.1, if the request that initiated the dialog=20 > >> contained > >> a SIPS URI in the Request-URI or in the top Record-Route header=20 > >> field > >> value, if there was any, or the Contact header field if=20 > there was=20 > >> no > >> Record-Route header f > > > > There are three statemenets in the or condition. However,=20 > if the first=20 > > is true, and we eliminate the last hop exception and retarget=20 > > exception, unless there is a protocol error the others will be true=20 > > too. This is one of many places where sips is just way=20 > simpler if we=20 > > do that. > > > >> be careful about what to use in the Contact (in case=20 > Record-Route is > >> not used for this hop). If the Contact was a SIPS URI,=20 > it would=20 > >> mean > >> that it would only accept mid-dialog requests that are=20 > over secure > >> transport end-to-end. Since the Request-URI is in this=20 > case a SIP > >> URI, it is quite possible that the UA sending a request to that=20 > >> URI > >> may not be able to send requests to SIPS URIs. It is therefore > >> RECOMMENDED that in this case, the Contact be a SIP=20 > URI, even if=20 > >> the > >> request is sent over a secure transport (e.g., the=20 > first hop could=20 > >> be > >> re-using a TLS connection to the proxy as would be the case with > >> [I-D.ietf-sip-outbound]). > > > > why is this just RECOMMENDED and not MUST? > > > >> When a target refresh occurs within a dialog (e.g., re-INVITE, > >> UPDATE), unless there is a need to change it, the UAC SHOULD=20 > >> include > >> a Contact header with a SIPS URI if the original request used a=20 > >> SIPS > >> Request-URI. > > > > why not MUST? > > > >> Sessions, dialogs and transactions may be "derived" from existings > >> ones. > >> As a general principle, derived dialogs and transactions SHOULD=20 > >> NOT > >> result in an effective downgrading of SIPS to SIP, without the > >> explicit authorization of the entities involved. > > > > unless you formally define 'derived' this is a meaningless=20 > > requirement. > > > >> However, for backward compatibility, if a "transport=3Dtls"=20 > parameter > >> is received, it should be interpreted as per the following > >> guidelines: > >> o [RFC3261]/16.7 states the transport parameter (e.g.,=20 > with tcp=20 > >> or > >> udp) SHOULD NOT be used in Record-Route unless it=20 > has knowledge > >> that the next upstream element that will be in the path of > >> subsequent supports this transport. Generally, it is=20 > >> recommended > >> that the transport parameter never be used in a Record-Route, > >> Route or Path header. Since the transport=3Dtls URI = parameter=20 > >> has > >> been deprecated, it MUST NOT be used in Route,=20 > Record-Route or > >> Path headers, and MUST be ignored. > >> o In a Contact in a dialog, it MAY be interpreted as a=20 > request to > >> send incoming mid-dialog requests using TLS. Note that this=20 > >> would > >> only have a significance if [I-D.ietf-sip-outbound]=20 > and Record- > >> Route are not used, and if that URI is nevertheless=20 > reachable=20 > >> with > >> TLS which is extremely unlikely. If it was the case that it=20 > >> was > >> reachable with TLS, say because there is an active TLS=20 > >> connection, > > > > the first paragraph says that what follows will be what to=20 > do if you=20 > > receive transport=3Dtls, but the first bullet is about sending it. = In=20 > > that paragraph you say its 'recommneded' not to be used in=20 > RR, Route=20 > > or Path, and then next sentence is MUST NOT. So which is it? > > > > If this is normative do we need to carry forward text on=20 > transport=3Dtls=20 > > beyond saying don't send and ignore on receive? > > > > > > Thanks, > > Jonathan R. > > > > > > > > > > > > > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow ll. Furthermore, as=20 > mandated=20 > >> by > >> [RFC3261]/12.1.1, if the request that initiated the dialog=20 > >> contained > >> a SIPS URI in the Request-URI or in the top Record-Route header=20 > >> field > >> value, if there was any, or the Contact header field if=20 > there was=20 > >> no > >> Record-Route header f > > > > There are three statemenets in the or condition. However,=20 > if the first=20 > > is true, and we eliminate the last hop exception and retarget=20 > > exception, unless there is a protocol error the others will be true=20 > > too. This is one of many places where sips is just way=20 > simpler if we=20 > > do that. > > > >> be careful about what to use in the Contact (in case=20 > Record-Route is > >> not used for this hop). If the Contact was a SIPS URI,=20 > it would=20 > >> mean > >> that it would only accept mid-dialog requests that are=20 > over secure > >> transport end-to-end. Since the Request-URI is in this=20 > case a SIP > >> URI, it is quite possible that the UA sending a request to that=20 > >> URI > >> may not be able to send requests to SIPS URIs. It is therefore > >> RECOMMENDED that in this case, the Contact be a SIP=20 > URI, even if=20 > >> the > >> request is sent over a secure transport (e.g., the=20 > first hop could=20 > >> be > >> re-using a TLS connection to the proxy as would be the case with > >> [I-D.ietf-sip-outbound]). > > > > why is this just RECOMMENDED and not MUST? > > > >> When a target refresh occurs within a dialog (e.g., re-INVITE, > >> UPDATE), unless there is a need to change it, the UAC SHOULD=20 > >> include > >> a Contact header with a SIPS URI if the original request used a=20 > >> SIPS > >> Request-URI. > > > > why not MUST? > > > >> Sessions, dialogs and transactions may be "derived" from existings > >> ones. > >> As a general principle, derived dialogs and transactions SHOULD=20 > >> NOT > >> result in an effective downgrading of SIPS to SIP, without the > >> explicit authorization of the entities involved. > > > > unless you formally define 'derived' this is a meaningless=20 > > requirement. > > > >> However, for backward compatibility, if a "transport=3Dtls"=20 > parameter > >> is received, it should be interpreted as per the following > >> guidelines: > >> o [RFC3261]/16.7 states the transport parameter (e.g.,=20 > with tcp=20 > >> or > >> udp) SHOULD NOT be used in Record-Route unless it=20 > has knowledge > >> that the next upstream element that will be in the path of > >> subsequent supports this transport. Generally, it is=20 > >> recommended > >> that the transport parameter never be used in a Record-Route, > >> Route or Path header. Since the transport=3Dtls URI = parameter=20 > >> has > >> been deprecated, it MUST NOT be used in Route,=20 > Record-Route or > >> Path headers, and MUST be ignored. > >> o In a Contact in a dialog, it MAY be interpreted as a=20 > request to > >> send incoming mid-dialog requests using TLS. Note that this=20 > >> would > >> only have a significance if [I-D.ietf-sip-outbound]=20 > and Record- > >> Route are not used, and if that URI is nevertheless=20 > reachable=20 > >> with > >> TLS which is extremely unlikely. If it was the case that it=20 > >> was > >> reachable with TLS, say because there is an active TLS=20 > >> connection, > > > > the first paragraph says that what follows will be what to=20 > do if you=20 > > receive transport=3Dtls, but the first bullet is about sending it. = In=20 > > that paragraph you say its 'recommneded' not to be used in=20 > RR, Route=20 > > or Path, and then next sentence is MUST NOT. So which is it? > > > > If this is normative do we need to carry forward text on=20 > transport=3Dtls=20 > > beyond saying don't send and ignore on receive? > > > > > > Thanks, > > Jonathan R. > > > > > > > > > > > > > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ =20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy56-00020O-EI; Thu, 29 Mar 2007 13:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy53-0001zT-O9 for sip@ietf.org; Thu, 29 Mar 2007 13:06:33 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWy0n-0000Cu-Gv for sip@ietf.org; Thu, 29 Mar 2007 13:02:10 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TH1gG16185; Thu, 29 Mar 2007 17:01:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Thu, 29 Mar 2007 12:01:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> In-Reply-To: <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdyIQkYoQZjs6XXTTyt13v0q4GpdwAAacMQ References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't agree. I think this is theoretical. I don't believe proxies that "upgrade"=20 from SIP to SIPS using a retargeting exist in nature. And if they did, they would likely break stuff, or have some assumptions that makes them=20 essentially proprietary. It just doesn't work except for some very narrow sceanrios (e.g., transactions that don't create a dialog, or dialogs with double Record-Route used at the retargeting point, along with endpoints that don't understand SIPS but somehow don't choke on the scheme, use of SIP outbound which is not standard yet, etc.). Same Parsippany, NJ =20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy56-00020O-EI; Thu, 29 Mar 2007 13:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy53-0001zT-O9 for sip@ietf.org; Thu, 29 Mar 2007 13:06:33 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWy0n-0000Cu-Gv for sip@ietf.org; Thu, 29 Mar 2007 13:02:10 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TH1gG16185; Thu, 29 Mar 2007 17:01:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Thu, 29 Mar 2007 12:01:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> In-Reply-To: <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme Thread-Index: AcdyIQkYoQZjs6XXTTyt13v0q4GpdwAAacMQ References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't agree. I think this is theoretical. I don't believe proxies that "upgrade"=20 from SIP to SIPS using a retargeting exist in nature. And if they did, they would likely break stuff, or have some assumptions that makes them=20 essentially proprietary. It just doesn't work except for some very narrow sceanrios (e.g., transactions that don't create a dialog, or dialogs with double Record-Route used at the retargeting point, along with endpoints that don't understand SIPS but somehow don't choke on the scheme, use of SIP outbound which is not standard yet, etc.). Same applies for downgrades.=20 So to me, it's a non-issue. >From a standard's purist dreamland point of view, we could define this extension: it would not "break" anything. It would just make the spec more complicated for no good reason. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, March 29, 2007 09:40 > To: Hadriel Kaplan > Cc: Srivastava, Samir (SC100:8826); Audet, Francois=20 > (SC100:3055); 'Christer Holmberg (JO/LMF)'; 'Sean Olson';=20 > 'IETF SIP List' > Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 >=20 > On Mar 28, 2007, at 6:17 PM, Hadriel Kaplan wrote: >=20 >=20 > > > > Well I can give one: it has the same semantics and security=20 > property=20 > > you get with a syntax of Require/Proxy-require:tls. >=20 > not exactly, and this is exactly the point of been trying to=20 > make about why changing the behavior of sips: without making=20 > any other changes is pointless. >=20 > Assume we update 3261 with new mandatory behavior for sips:=20 > request URIs. >=20 > An existing proxy that doesn't conform to the new=20 > requirements (and therefore does up/downgrades) will still=20 > give us an indeterminate state. Was the request sips: on all=20 > hops? There is no evil required for this to happen, just obsolescence. >=20 >=20 > Assume instead a new extension option tag that requires=20 > proxies understanding it to implement the new behavior for=20 > sips:. We use this in Requires and Proxy-Requires whenever a=20 > "new behavior" UAC creates a request with a sips: r-uri. I'd=20 > call this mode "required sips:". >=20 > Any reasonable existing UA or proxy will reject a request=20 > that Requires/Proxy-Requires an option not understood by that=20 > UA or proxy. >=20 > Any reasonable new UA or proxy understanding the new=20 > extension can be expected to implement the new required behavior. >=20 > While this doesn't give us assurance that there were no evil=20 > proxies on the path, it does give us an assurance that there=20 > were no obsolete proxies that couldn't be reasonably expected=20 > to have done "the right thing" with sips:. >=20 > It's a "fail safe" instead of "fail dangerous" distinction. >=20 > If it turns out that we have an obsolete node on the path=20 > that don't understand the extension, we could (after=20 > informing the user of the > problem) retry the request without the option tag, thereby=20 > falling back to the current "best effort" sips:. >=20 > -- > Dean >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip applies for downgrades.=20 So to me, it's a non-issue. >From a standard's purist dreamland point of view, we could define this extension: it would not "break" anything. It would just make the spec more complicated for no good reason. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, March 29, 2007 09:40 > To: Hadriel Kaplan > Cc: Srivastava, Samir (SC100:8826); Audet, Francois=20 > (SC100:3055); 'Christer Holmberg (JO/LMF)'; 'Sean Olson';=20 > 'IETF SIP List' > Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme >=20 >=20 > On Mar 28, 2007, at 6:17 PM, Hadriel Kaplan wrote: >=20 >=20 > > > > Well I can give one: it has the same semantics and security=20 > property=20 > > you get with a syntax of Require/Proxy-require:tls. >=20 > not exactly, and this is exactly the point of been trying to=20 > make about why changing the behavior of sips: without making=20 > any other changes is pointless. >=20 > Assume we update 3261 with new mandatory behavior for sips:=20 > request URIs. >=20 > An existing proxy that doesn't conform to the new=20 > requirements (and therefore does up/downgrades) will still=20 > give us an indeterminate state. Was the request sips: on all=20 > hops? There is no evil required for this to happen, just obsolescence. >=20 >=20 > Assume instead a new extension option tag that requires=20 > proxies understanding it to implement the new behavior for=20 > sips:. We use this in Requires and Proxy-Requires whenever a=20 > "new behavior" UAC creates a request with a sips: r-uri. I'd=20 > call this mode "required sips:". >=20 > Any reasonable existing UA or proxy will reject a request=20 > that Requires/Proxy-Requires an option not understood by that=20 > UA or proxy. >=20 > Any reasonable new UA or proxy understanding the new=20 > extension can be expected to implement the new required behavior. >=20 > While this doesn't give us assurance that there were no evil=20 > proxies on the path, it does give us an assurance that there=20 > were no obsolete proxies that couldn't be reasonably expected=20 > to have done "the right thing" with sips:. >=20 > It's a "fail safe" instead of "fail dangerous" distinction. >=20 > If it turns out that we have an obsolete node on the path=20 > that don't understand the extension, we could (after=20 > informing the user of the > problem) retry the request without the option tag, thereby=20 > falling back to the current "best effort" sips:. >=20 > -- > Dean >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:09:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy7u-0003Wd-28; Thu, 29 Mar 2007 13:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWy7s-0003WV-JK for sip@ietf.org; Thu, 29 Mar 2007 13:09:28 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWy7o-0001hv-5D for sip@ietf.org; Thu, 29 Mar 2007 13:09:28 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2TH98ln024575 for ; Thu, 29 Mar 2007 12:09:23 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 12:09:11 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 19:09:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2007 19:08:58 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on draft-ietf-sip-ice-option-tag-01 Thread-Index: AcdyJPB+n9eszkDUQyCVKHth2UuvYA== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 29 Mar 2007 17:09:05.0764 (UTC) FILETIME=[F4F82240:01C77224] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) WGLC has just commenced in the MMUSIC WG on http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt This is to announce a parallel WGLC on http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-01.txt The dates of the WGLC are identical to those in MMUSIC. Therefore please provide responses to the WGLC by 20th April 2007. Comments on the SIP document should be provided to the SIP list only, and to the editor. Please provide comments clearly indicating the page or section, the text to be changed (copy and paste!), and the proposed modification if possible. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:38:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWyZW-0001c1-VV; Thu, 29 Mar 2007 13:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWyZV-0001bj-0s for sip@ietf.org; Thu, 29 Mar 2007 13:38:01 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWyZT-00086S-NL for sip@ietf.org; Thu, 29 Mar 2007 13:38:00 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2THbtG21872; Thu, 29 Mar 2007 17:37:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2007 12:37:54 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612002DA6@zrc2hxm2.corp.nortel.com> In-Reply-To: <057401c77197$c2697500$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading allowed or not) thread-index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vwAAJl/yAAAH3yYAAktfJQ From: "Samir Srivastava" To: "Hadriel Kaplan" , "Francois Audet" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [Sip] RE: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading allowed or not) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, When I wrote the 00 version of cipher-suite, I was in the impression that community understands the ugliness of the SIPS. As there were many wacky threads for it. So it was just talking about the solution. Proxy-Require tag for Secure-Protocol/Cipher-suite makes the SIPS REDUDANT all together. Here it should be noted that we are talking about the Secure-Protocol (Which can be DTLS too). Where current definition of SIPS as per 3261 is completely broken. 3261 has tied the SIPS to TLS. SIPS is no future proof with respect to secure protocol development too. Thx Samir > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, March 28, 2007 5:18 PM > To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); > 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading allowed > or not) >=20 >=20 > But the cipher-suites draft does not show me the ugliness of sips. I > believe your draft is trying to convince me what's broken about sips is > that > you don't know how "secure" the links sips forces you to use are, and thus > the UAC/UAS need to control and know the level of that link security. > (whereby you define their security level as the used ciphersuite?) >=20 > Right? >=20 > If so I think we are in a 180-degree opposite view of what's "broken" > about > sips. To me, making sure the ciphersuite is "strong" enough is like > adding > reinforcements to the Maginot line. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Sent: Wednesday, March 28, 2007 7:48 PM > > To: Hadriel Kaplan; Francois Audet; Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] sips: upgrading allowed or not > > > > Hi Hadriel, > > > > Sorry I am still catching up this thread. > > > > My understanding was that this document will just state what SIPS > > provides as per 3261 . > > Nothing to modify the behaviour of 3261. Looks like, we are patching it > > for STANDARDS track doc. > > > > Let us stop worrying more about upgrade etc, till we see at one place > > (in the next version of cipher-suites) ugliness of the SIPS and the need > > for the clear defintion of secure protocols etc, and then decide do we > > need to spend cycles on this stuff. > > > > BTW, there is no SIPS in 2543. I don't recollect which bis got it added. > > Here legacy should mean 3261 only, if SIPS doesn't get deprecated, and > > we start working on 3261 bis etc... > > > > Thx > > Samir > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWykN-0007wL-PA; Thu, 29 Mar 2007 13:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWykM-0007wB-Pj for sip@ietf.org; Thu, 29 Mar 2007 13:49:14 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWykL-0002mP-Hq for sip@ietf.org; Thu, 29 Mar 2007 13:49:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2THmmG24290; Thu, 29 Mar 2007 17:48:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme Date: Thu, 29 Mar 2007 12:49:08 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612002DE3@zrc2hxm2.corp.nortel.com> In-Reply-To: <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme thread-index: AcdyIQpXLeUyDiTgT728K/uKQ875RQACCBHA From: "Samir Srivastava" To: "Dean Willis" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List , Sean Olson , Francois Audet , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Thx Dean for explanation. >=20 > If it turns out that we have an obsolete node on the path that don't > understand the extension, we could (after informing the user of the > problem) retry the request without the option tag, thereby falling > back to the current "best effort" sips:. Alternatively consider the following scenario UAC --- P1 ---- P2 ------- UAS | | |-------P3 ---------| Here If Provider of Proxy P2 doesn't understand the secure-tag, P1 can route the via P3 which understands the secure-tag. So owner of P2 will start loosing the revenue. And he will be forced to upgrade. $ is the biggest motivation. =20 May I request the group to give me couple of weeks to update the cipher-suite.=20 Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 13:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWysN-0002GZ-58; Thu, 29 Mar 2007 13:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWysK-0002GN-HG for sip@ietf.org; Thu, 29 Mar 2007 13:57:28 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWysJ-0004w3-8Y for sip@ietf.org; Thu, 29 Mar 2007 13:57:28 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070329175724m1200ddqjde>; Thu, 29 Mar 2007 17:57:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2THvMLv024248 for ; Thu, 29 Mar 2007 12:57:22 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2THvMl1024244; Thu, 29 Mar 2007 12:57:22 -0500 Date: Thu, 29 Mar 2007 12:57:22 -0500 Message-Id: <200703291757.l2THvMl1024244@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <460BC917.5060600@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] GRUU text around modification of URI parameters References: <460BC917.5060600@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg So, I took an action item to look over the URI parameters and make a more concrete recommendation on which URI parameters were subject to manipulation by a UA. I went through the IANA registry of URI params and here is the text I came up with: The user and host parts of the GRUU learned by the UA in the REGISTER response MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them in any way. Furthermore, the UA MUST NOT add or remove URI parameters relevant for receipt and processing of request at the proxy, including the transport, lr, maddr, ttl, user, and comp parameters. This is more or less all of the URI parameters from 3261, excepting header field, body, and method params, which I think are inappropriate for GRUU anyway. It also omits the URI params registered by RFC 4458 and RFC 4240 (the voicemail URI and netann specs). Again I think those make no sense here. I've put the above text into my working -13. Unless someone objects I'll consider this issue closed. I'd like to know your interpretation of this issue from a different perspective. It seems to me that the baseline situation is that *all* URI parameters should be treated as opaque unless there is a good reason to consider them not so. So instead of enumerating the parameters that cannot be modified by an agent that is not authoritative to mint URIs for a domain, enumerate the ones that *can*. For instance, the method URI parameter seems acceptable, as it is well-defined what the implications of changing it are in any circumstance. But that isn't an interesting case in the GRUU context, I don't think. Indeed, are there any parameters which should be generally modifiable and are also useful in the GRUU context? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 15:16:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX05t-0005TO-O8; Thu, 29 Mar 2007 15:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX05r-0005SJ-RM for sip@ietf.org; Thu, 29 Mar 2007 15:15:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX02F-0008Lr-KH for sip@ietf.org; Thu, 29 Mar 2007 15:11:48 -0400 Received: from [171.70.229.153] (dhcp-171-70-229-153.cisco.com [171.70.229.153]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2TII9bh013243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 29 Mar 2007 12:18:10 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2994750C-566F-4635-B750-40637B275F62@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 14:11:44 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 29, 2007, at 12:01 PM, Francois Audet wrote: > I don't agree. > > I think this is theoretical. I don't believe proxies that "upgrade" > from SIP to SIPS using a retargeting exist in nature. And if they did, > they > would likely break stuff, or have some assumptions that makes them > essentially proprietary. It just doesn't work except for some very > narrow sceanrios (e.g., transactions that don't create a dialog, or > dialogs > with double Record-Route used at the retargeting point, along with > endpoints that > don't understand SIPS but somehow don't choke on the scheme, use of > SIP > outbound > which is not standard yet, etc.). Same applies for downgrades. > > So to me, it's a non-issue. > > From a standard's purist dreamland point of view, we could define > this extension: it would not "break" anything. It would just make > the spec more complicated for no good reason. I used to have a proxy at the house that would retarget inbound from sips to sip to let my old 3Com phone work. It would also retarget sip to sips outbound so I could call sips (said proxy is why I insisted on last-hop exception in 3261). Such proxies do exist. The good news is, I don't use it anymore (the bad news is I don't have a working SIP phone at home right now). So (Chair Hat on): Anybody else out there have a proxy currently (or planned to be) in use that retargets sip to sips or vice versa? If we can't come up with any, I suppose I'd be willing to concede the issue as "fixing an improbable problem" -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 16:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX151-0006QN-DT; Thu, 29 Mar 2007 16:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX14z-0006OK-V2 for sip@ietf.org; Thu, 29 Mar 2007 16:18:41 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX14y-0001gJ-LU for sip@ietf.org; Thu, 29 Mar 2007 16:18:41 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TKISw13213; Thu, 29 Mar 2007 20:18:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 15:18:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> In-Reply-To: <2994750C-566F-4635-B750-40637B275F62@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Thread-Index: AcdyNzzU1I3BqVJBSYuiutyuEbbRxwAB2DLA References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> <2994750C-566F-4635-B750-40637B275F62@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Draw me a call flow on how your phone dealt with SIPS in the Contact of that INVITE then. How did your phone NOT choke on it? Did it ignore the Contact? Did you proxy do Double Record-Route? Or was your proxy really a B2BUA "fixing" all this stuff?=20 My assertion is that without using a B2BUA you can't really fix this, or you have to "cheat" somewhere. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, March 29, 2007 12:12 > To: IETF SIP List > Subject: Poll: Do we have sips/sip retageting in the wild=20 > (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) >=20 >=20 > On Mar 29, 2007, at 12:01 PM, Francois Audet wrote: >=20 > > I don't agree. > > > > I think this is theoretical. I don't believe proxies that "upgrade" > > from SIP to SIPS using a retargeting exist in nature. And=20 > if they did,=20 > > they would likely break stuff, or have some assumptions that makes=20 > > them essentially proprietary. It just doesn't work except for some=20 > > very narrow sceanrios (e.g., transactions that don't create=20 > a dialog,=20 > > or dialogs with double Record-Route used at the retargeting point,=20 > > along with endpoints that don't understand SIPS but somehow don't=20 > > choke on the scheme, use of SIP outbound which is not standard yet,=20 > > etc.). Same applies for downgrades. > > > > So to me, it's a non-issue. > > > > From a standard's purist dreamland point of view, we could=20 > define this=20 > > extension: it would not "break" anything. It would just=20 > make the spec=20 > > more complicated for no good reason. >=20 > I used to have a proxy at the house that would retarget=20 > inbound from sips to sip to let my old 3Com phone work. It=20 > would also retarget sip to sips outbound so I could call sips=20 > (said proxy is why I insisted on last-hop exception in 3261).=20 > Such proxies do exist. >=20 > The good news is, I don't use it anymore (the bad news is I=20 > don't have a working SIP phone at home right now). >=20 > So (Chair Hat on): Anybody else out there have a proxy=20 > currently (or planned to be) in use that retargets sip to=20 > sips or vice versa? >=20 > If we can't come up with any, I suppose I'd be willing to=20 > concede the issue as "fixing an improbable problem" >=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 16:26:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1Bo-0004Df-E8; Thu, 29 Mar 2007 16:25:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1Bm-0004DK-Cu for sip@ietf.org; Thu, 29 Mar 2007 16:25:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HX1Bl-00065A-1f for sip@ietf.org; Thu, 29 Mar 2007 16:25:42 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TKPYG15837; Thu, 29 Mar 2007 20:25:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 15:25:22 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612003167@zrc2hxm2.corp.nortel.com> In-Reply-To: <2994750C-566F-4635-B750-40637B275F62@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) thread-index: AcdyNwSM3DCReW3FRQGjXxeyr12PlAACB18w From: "Samir Srivastava" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The good news is, I don't use it anymore (the bad news is I don't > have a working SIP phone at home right now). >=20 > So (Chair Hat on): Anybody else out there have a proxy currently (or > planned to be) in use that retargets sip to sips or vice versa? >=20 > If we can't come up with any, I suppose I'd be willing to concede the > issue as "fixing an improbable problem" >=20 Thx for arriving to "fixing an improbable problem". I am more interested in knowing the DEPLOYED part of this, instead of planning / implementing / coding etc part of SIPS.=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 16:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1Jk-0000GP-CB; Thu, 29 Mar 2007 16:33:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1Ji-0000AC-Gt for sip@ietf.org; Thu, 29 Mar 2007 16:33:54 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX1Jh-0005Jw-5B for sip@ietf.org; Thu, 29 Mar 2007 16:33:54 -0400 Received: from [172.17.1.75] ([172.17.1.75]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l2TKXdWk060302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 15:33:39 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) References: <5D1A7985295922448D5550C94DE29180E9832F@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11D95C09-672A-4896-AA87-E348F5209B21@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Thu, 29 Mar 2007 15:33:33 -0500 To: Sip List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.2 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "Keith \(\(Keith\)\) Drage" , Gonzalo Camarillo , Dean Willis Subject: [Sip] Belated Re-review of consent-framework X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a very late followup from my WGLC comments on draft-ietf-sip- consent-framework-00.txt (now 01). The relevant portions of my WGLC comments have been addressed and I have no further concerns that I feel are worth pursuing. I still have a very minor concern about some of the assumptions about how different domains will build messaging architectures (in particular, assertions that store and forward servers for SIP MESSAGE will commonly exist.) But since the draft provides mechanisms and guidance to work around the absence of such servers, this has become a purely philosophical argument and certainly not worth taking the wg's time or delaying progress of the document. Thanks! Ben. Begin forwarded message: > From: "Drage, Keith \(Keith\)" > Date: March 20, 2007 8:31:32 AM CDT > To: "Ben Campbell" > Subject: RE: Belated Re-review of consent FW documents in SIPPING > > And did you look at sip-consent-framework as well? > > Keith > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Tuesday, March 20, 2007 10:28 AM >> To: Gonzalo Camarillo >> Cc: Sipping List; Mary Barnes; Drage, Keith (Keith) >> Subject: Belated Re-review of consent FW documents in SIPPING >> >> This is probably too late to matter. Apologies for lateness. >> Fortunately, my re-review of both consent-format and pending- >> additions result in the following statement: >> >> My WGLC feedback for these docs has been addressed and I have >> no further issues. >> >> Thanks! >> >> Ben. >> >> Begin forwarded message: >> >>> From: "Mary Barnes" >>> Date: March 2, 2007 8:25:31 PM GMT+01:00 >>> To: >>> Subject: Re-review of consent FW documents in SIPPING >>> >>> Hi Ben, >>> >>> These documents have been updated since your review in October. >>> Could you possibly re-review and make sure that your concerns were >>> addressed, since this is getting ready to be forwarded to IESG? >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-pending- >>> additions-01.txt >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent- >>> format-01.txt >>> >>> >>> Thanks, >>> Mary >>> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 16:57:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1gB-0000iW-6S; Thu, 29 Mar 2007 16:57:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1g9-0000fz-5G for sip@ietf.org; Thu, 29 Mar 2007 16:57:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HX1g6-0001ND-2Z for sip@ietf.org; Thu, 29 Mar 2007 16:57:05 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2TKurG20180; Thu, 29 Mar 2007 20:56:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 15:56:37 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6120031FF@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) thread-index: AcdyNzzU1I3BqVJBSYuiutyuEbbRxwAB2DLAAAFOnnA= From: "Samir Srivastava" To: "Francois Audet" , "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1275660649==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1275660649== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77244.BE701778" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77244.BE701778 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-line. =20 Thx Samir =20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Thursday, March 29, 2007 1:18 PM > To: Dean Willis; IETF SIP List > Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: > [Sip] RE: Securing Other URI (Tel URI) scheme) >=20 > Dean, >=20 > Draw me a call flow on how your phone dealt with SIPS in the Contact of > that INVITE then. How did your phone NOT choke on it? >=20 =20 =20 Even if Dean draws the call flow, they will be hypothetical.=20 They can be actual, only if he had stored somewhere. As he doesn't have a working SIP phone. See the below highlighted contents.=20 =20 I am more interested in knowing the DEPLOYED call flows of SIPS,=20 not in those, which people wrote in the several RFCS. =20 >=20 >=20 > > The good news is, I don't use it anymore (the bad news is I > > don't have a working SIP phone at home right now). > > > > So (Chair Hat on): Anybody else out there have a proxy > > currently (or planned to be) in use that retargets sip to > > sips or vice versa? > > > > If we can't come up with any, I suppose I'd be willing to > > concede the issue as "fixing an improbable problem" > > > > -- > > 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 > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C77244.BE701778 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In-line.

 

Thx

Samir

 

> -----Original Message-----

> From: Audet, Francois (SC100:3055)

> Sent: Thursday, March 29, 2007 1:18 PM

> To: Dean Willis; IETF SIP List

> Subject: RE: Poll: Do we have sips/sip retageting in the = wild (was Re:

> [Sip] RE: Securing Other URI (Tel URI) = scheme)

>

> Dean,

>

> Draw me a call flow on how your phone dealt with SIPS in = the Contact of

> that INVITE then. How did your phone NOT choke on = it?

>

 

 

  Even if Dean draws the call flow, they will be = hypothetical.

They can be actual, only if he had stored = somewhere.

As he doesn’t have a working SIP phone. See the below = highlighted contents.

 

I am more interested in knowing the DEPLOYED call flows of SIPS, =

not in those, which people wrote in the several = RFCS.

 

>

>

> > The good news is, = I don't use it anymore (the bad news is = I

> > don't have a = working SIP phone at home right now).

> >

> > So (Chair Hat on): Anybody else out there have a = proxy

> > currently (or planned to be) in use that retargets sip = to

> > sips or vice versa?

> >

> > If we can't come up with any, I suppose I'd be willing = to

> > concede the issue as "fixing an improbable = problem"

> >

> > --

> > 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

------_=_NextPart_001_01C77244.BE701778-- --===============1275660649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1275660649==-- From sip-bounces@ietf.org Thu Mar 29 17:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1tc-0002cY-MV; Thu, 29 Mar 2007 17:11:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1ta-0002cG-Qt for sip@ietf.org; Thu, 29 Mar 2007 17:10:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX1tZ-0002xI-FD for sip@ietf.org; Thu, 29 Mar 2007 17:10:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2007 17:10:58 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2TLAvXW020836; Thu, 29 Mar 2007 17:10:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2TL9ZHH011104; Thu, 29 Mar 2007 21:10:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 17:10:49 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 17:10:49 -0400 Message-ID: <460C2B58.9060505@cisco.com> Date: Thu, 29 Mar 2007 17:10:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] GRUU text around modification of URI parameters References: <460BC917.5060600@cisco.com> <200703291757.l2THvMl1024244@dragon.ariadne.com> In-Reply-To: <200703291757.l2THvMl1024244@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 21:10:49.0348 (UTC) FILETIME=[B9C76C40:01C77246] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2693; t=1175202657; x=1176066657; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20GRUU=20text=20around=20modification=20of=20UR I=20parameters |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=UYSbx1j4XG3cjjfLm2XduU2SufqjXJfR9M1sdKW7uF8=; b=cJyP5rAlrMSGoPhiu3zochtyqpOfivjVfBELuX6WZqcU+gUd4ZTiQqAlHjW83MJKQh3tAWVE E+Zlr8R9V2qNAZQWD8MmOH9nyVL1mtnBoCMUDoKTnk6idDa/BdZY1vw9; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At the moment I'd say there are no parameters that are usefully modifiable by a client. However I think its easier if the text be explicit both ways - saying what you can and cannot modify. I'm fine to add a sentence which further notes that the other URI parameters just aren't useful to manipulate. -Jonathan R. Dale.Worley@comcast.net wrote: > > The user and host parts of the GRUU learned by the UA in the REGISTER > response > MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them > in any way. Furthermore, the UA MUST NOT add or remove URI parameters > relevant for receipt and processing of request at the proxy, including > the transport, lr, maddr, ttl, user, and comp > parameters. > > > This is more or less all of the URI parameters from 3261, excepting > header field, body, and method params, which I think are inappropriate > for GRUU anyway. It also omits the URI params registered by RFC 4458 and > RFC 4240 (the voicemail URI and netann specs). Again I think those make > no sense here. > > I've put the above text into my working -13. Unless someone objects I'll > consider this issue closed. > > I'd like to know your interpretation of this issue from a different > perspective. It seems to me that the baseline situation is that *all* > URI parameters should be treated as opaque unless there is a good > reason to consider them not so. So instead of enumerating the > parameters that cannot be modified by an agent that is not > authoritative to mint URIs for a domain, enumerate the ones that > *can*. > > For instance, the method URI parameter seems acceptable, as it is > well-defined what the implications of changing it are in any > circumstance. But that isn't an interesting case in the GRUU context, > I don't think. > > Indeed, are there any parameters which should be generally modifiable > and are also useful in the GRUU context? > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 17:30:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX29c-0003J5-U4; Thu, 29 Mar 2007 17:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX29b-0003Ic-74 for sip@ietf.org; Thu, 29 Mar 2007 17:27:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX24L-0005f4-09 for sip@ietf.org; Thu, 29 Mar 2007 17:22:10 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2TLM2JT070586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 16:22:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <460C2B58.9060505@cisco.com> References: <460BC917.5060600@cisco.com> <200703291757.l2THvMl1024244@dragon.ariadne.com> <460C2B58.9060505@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B56F704-AE5E-4AFB-A611-6182CA12A6D5@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] GRUU text around modification of URI parameters Date: Thu, 29 Mar 2007 16:22:01 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Can that sentence say "other already standardized URI parameters" or something along those lines? RjS On Mar 29, 2007, at 4:10 PM, Jonathan Rosenberg wrote: > At the moment I'd say there are no parameters that are usefully > modifiable by a client. However I think its easier if the text be > explicit both ways - saying what you can and cannot modify. I'm > fine to add a sentence which further notes that the other URI > parameters just aren't useful to manipulate. > > -Jonathan R. > > Dale.Worley@comcast.net wrote: > > >> >> The user and host parts of the GRUU learned by the UA in the >> REGISTER response >> MUST be treated opaquely by the UA. That is, the UA MUST NOT >> modify them >> in any way. Furthermore, the UA MUST NOT add or remove URI >> parameters >> relevant for receipt and processing of request at the proxy, >> including >> the transport, lr, maddr, ttl, user, and comp > target="RFC3486"/> >> parameters. >> >> This is more or less all of the URI parameters from 3261, >> excepting header field, body, and method params, which I think >> are inappropriate for GRUU anyway. It also omits the URI params >> registered by RFC 4458 and RFC 4240 (the voicemail URI and >> netann specs). Again I think those make no sense here. >> I've put the above text into my working -13. Unless someone >> objects I'll consider this issue closed. >> I'd like to know your interpretation of this issue from a different >> perspective. It seems to me that the baseline situation is that >> *all* >> URI parameters should be treated as opaque unless there is a good >> reason to consider them not so. So instead of enumerating the >> parameters that cannot be modified by an agent that is not >> authoritative to mint URIs for a domain, enumerate the ones that >> *can*. >> For instance, the method URI parameter seems acceptable, as it is >> well-defined what the implications of changing it are in any >> circumstance. But that isn't an interesting case in the GRUU >> context, >> I don't think. >> Indeed, are there any parameters which should be generally modifiable >> and are also useful in the GRUU context? >> Dale >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 19:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3en-00065B-TL; Thu, 29 Mar 2007 19:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3em-000656-Tg for sip@ietf.org; Thu, 29 Mar 2007 19:03:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3el-0007Vq-Jh for sip@ietf.org; Thu, 29 Mar 2007 19:03:48 -0400 Received: from [10.84.143.35] (nat-tokyo131.cisco.com [64.104.47.131]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2TMA4gQ014504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 16:10:09 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> <2994750C-566F-4635-B750-40637B275F62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 18:03:36 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 29, 2007, at 3:18 PM, Francois Audet wrote: > Dean, > > Draw me a call flow on how your phone dealt with SIPS in the > Contact of > that INVITE then. How did your phone NOT choke on it? > > Did it ignore the Contact? > The phone, as I recall, just ignored the contact -- that is, assumed it was sip. It would have done very odd things with a tel: URL, I think. The code in the phone was maybe sip-04 (pre 2543) . . . but it would be pretty straightforward to have the proxy patch the Contact: as it traverses. Not legal, but how many implementations strictly are? > Did you proxy do Double Record-Route? > No, it replaced its entry with the "right thing" as it proxied. > Or was your proxy really a B2BUA "fixing" all this stuff? > > My assertion is that without using a B2BUA you can't really fix > this, or > you have to "cheat" somewhere. Back in those days, making ANYTHING work was a cheat. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 19:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3on-0003Sh-Ka; Thu, 29 Mar 2007 19:14:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3om-0003Sc-0h for sip@ietf.org; Thu, 29 Mar 2007 19:14:08 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3ok-0001vI-Mn for sip@ietf.org; Thu, 29 Mar 2007 19:14:07 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2TNDKG27848; Thu, 29 Mar 2007 23:13:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 18:13:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FCF3A2F@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Thread-Index: AcdyVoTrHGcR4MW8R5+Kq6DqvfVDCAAAB3IQ References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> <2994750C-566F-4635-B750-40637B275F62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > The phone, as I recall, just ignored the contact -- that is,=20 > assumed it was sip. It would have done very odd things with a=20 > tel: URL, I think. The code in the phone was maybe sip-04=20 > (pre 2543) . . . >=20 > but it would be pretty straightforward to have the proxy patch the > Contact: as it traverses. Not legal, but how many=20 > implementations strictly are? That was exactly my point about using a B2BUA (i.e., "patching" the=20 signalling) and about cheating (i.e., "ignoring" the contact and respond to where the message came from). Looks like I guessed right. To me solutions like this "don't count" because they are not SIP-compliant.=20 In fact, even with us deprecating upgrades and downgrades, the reality is that a B2BUA or SBC will still be able to "patch" everything to=20 do upgrades or downgrades in the way you describe. That is why I see this "upgrade" requirement as a red herring. I'd rather we make it clean for SIP (and if people do B2BUA stuff, that's their right). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 19:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3qW-0004aB-0G; Thu, 29 Mar 2007 19:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3qU-0004a5-Dk for sip@ietf.org; Thu, 29 Mar 2007 19:15:54 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3qT-0002Pq-37 for sip@ietf.org; Thu, 29 Mar 2007 19:15:54 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2TNFTG28023; Thu, 29 Mar 2007 23:15:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 18:15:49 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61200341A@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) thread-index: AcdyVyEb5LZS5c5lQFedglVeJVTwUwAADZQQ From: "Samir Srivastava" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, So for me it is no more valid case. If there is no SIPS deployments, why we keep trying to patch it. We already seen so many pitfalls of it on the list. In couple of weeks, we will be having next version of cipher-suite, till then can we postpone the discussions on the patching the SIPS. Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, March 29, 2007 4:04 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re: > [Sip] RE: Securing Other URI (Tel URI) scheme) >=20 >=20 > On Mar 29, 2007, at 3:18 PM, Francois Audet wrote: >=20 > > Dean, > > > > Draw me a call flow on how your phone dealt with SIPS in the > > Contact of > > that INVITE then. How did your phone NOT choke on it? > > > > Did it ignore the Contact? > > >=20 > The phone, as I recall, just ignored the contact -- that is, assumed > it was sip. It would have done very odd things with a tel: URL, I > think. The code in the phone was maybe sip-04 (pre 2543) . . . >=20 > but it would be pretty straightforward to have the proxy patch the > Contact: as it traverses. Not legal, but how many implementations > strictly are? >=20 > > Did you proxy do Double Record-Route? > > >=20 > No, it replaced its entry with the "right thing" as it proxied. >=20 > > Or was your proxy really a B2BUA "fixing" all this stuff? > > > > My assertion is that without using a B2BUA you can't really fix > > this, or > > you have to "cheat" somewhere. >=20 > Back in those days, making ANYTHING work was a cheat. >=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From dpwlqokiqs@giga.net.tw Thu Mar 29 20:48:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX5Hl-0006mL-2K; Thu, 29 Mar 2007 20:48:09 -0400 Received: from [124.224.49.164] (helo=giga.net.tw) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HX5Hf-0001Je-BI; Thu, 29 Mar 2007 20:48:09 -0400 Message-ID: From: "Angella Gordon" To: "Elsie" Cc: "Agustina Garcia" , "Liliana" , "Georgianne Garrett" , "Lorette Wood" , "Yan Lynch" , "Hee Lee" , "Chang" , "Hyon Schmidt" , "Ernestine Kennedy" , "Nereida Alexander" Subject: Can you tell me more Date: Thu, 29 Mar 2007 20:39:48 -0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_3F3_1E5A_BE64D3B7.C4931113" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 This is a multi-part message in MIME format. ------=_NextPart_3F3_1E5A_BE64D3B7.C4931113 Content-Type: multipart/alternative; boundary="----=_NextPart_AC4_F499_9AA6DDCF.E26D2369" ------=_NextPart_AC4_F499_9AA6DDCF.E26D2369 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable breezy hit dam "But," continued Danglars, "I loosely find you did not eve= "I am at your service, madame," uneven laugh attention leaped replied L= ucien col long "Do you regret them?" horn asked straight shrill Morrel, w= ith his openshed "My work M. Debray," learnt slit said the banker, "do n= ot kill left "My sir," said Monte Cristo, right shut damaged "I understand yo = There was no frozen answer, mix and she person continued. daily "I have n= o "Yes," chose said frame comfort dam the old man's look, with eagerness.= "I should quite silver imagine that to felt be add disappear the case," s= aid "Insults!"range "Do scold not think decision I wish to turn you love out,= my Debr"I? rarely Certainly not," building replied disgusted the polite= ly count. "No; I shou"It is gracefully extraordinary," awake he said, whe= n breath vulpine the door was scrub "Well, in breathe a quarter chiropteran of development an hour he s= hall be with yo "Let me floor think slip a snow moment. train I do assure= you, grandpapa "Yes."   out "You see will bring him, consider sadly then? You carry your goodness= "You rough are right; let lazily us leave these pain fell facts alone, an= Lucien overflow having left, decay heat Danglars took forbid his place on= theson card "It pause is so good, lept that I have distanced M. de Chate= a"It come is because I am in a town loosely worse scary humor than usual,= " "No; poorly silly I owe do not wish to come between whispering a father a= nd so "And it was close told they who wrong told peace you something w= hich made "No, slept no," scared successfully serve said Noirtier's look= floor "By the anxiously way," said leaped the major, "you condition know = I have onl comb hook split compete "Then they follow you?" asked Monte = Cristo. "A probable thing!""And queue cough what have flung I to slip do with you= r ill-humor?" saidplay "See, they are freeze here." And at rate pencil th= e same minute a car"Not so," replied Danglars; authority troubled bled "y= our analyse advice is wrong, match feeling "And you want money; ship that is a death matter of course,= m "Ah, hidden you frighten precede me. What fork can they jam have said= ?" an swore "Ah, I become know," said she, modern whip lowering her voice= and goi sworn "Why not? animal Who fowl ever heard of such reject an occurrence a= s"And strip pray front for who are the point persons who exhaust your for= slung nerve Morrel smiled with an suspiciously expression very country li= ke a grimaperform rung "Oh, make daughter moon yourself easy!--I am not s= peaking riddle transport were observe clock The major's eyes sparkled brilliantly.island= stroke "Yes," insurance part replied the angry look. "I understand; kep= t silk you equally are drink displeased at the silence I gracefully "It osteal is branch 40,000 francs which I silently now owe yo= u," said Mo face pin untidy "Sir," said the baroness crawl humbly, "are you not awar"= I continue do not understand respect cooperative you, sir," wriggle said = the baroness,"With you, sir," replied step float the fraternal join baron= ess, "one can wistand bid "And pray," asked the really misspell baroness,= "am I responsible "Does your excellency grease dived wish for fierce fish a receipt?" said = th given "What is it, then?" move asked hurt the discovery young girl. "= Perhaps "No."   melodic attack irritably field "For what?" said the count."Why not?" ------=_NextPart_AC4_F499_9AA6DDCF.E26D2369 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


breezy hit dam "But," continued Danglars, "I loosely find you did not= eve  "I am at your service, madame," uneven laugh attention le= aped replied Lucien col long "Do you regret them?" horn asked straig= ht shrill Morrel, with his openshed "My work M. Debray," learnt slit sai= d the banker, "do not kill   
left "My sir," said Monte Cristo, right shut damaged "I understand yo&nb= sp;  There was no frozen answer, mix and she person continued. = daily "I have no "Yes," chose said frame comfort dam the old man's l= ook, with eagerness.      "I should quite silver imagine that to felt be add disappear the case," s= aid     

"Insults!"range "Do scold not think decision I wish to turn you love = out, my Debr"I? rarely Certainly not," building replied disgusted the po= litely count. "No; I shou"It is gracefully extraordinary," awake he said,= when breath vulpine the door was 
scrub "Well, in breathe a quarter chiropteran of development an hour he s= hall be with yo "Let me floor think slip a snow moment. train I do a= ssure you, grandpapa    "Yes."    =
out "You see will bring him, consider sadly then? You carry your goodness=      

"You rough are right; let lazily us leave these pain fell facts alone= , anLucien overflow having left, decay heat Danglars took forbid his plac= e on theson card "It pause is so good, lept that I have distanced M. de C= hatea"It come is because I am in a town loosely worse scary humor than us= ual,"       
"No; poorly silly I owe do not wish to come between whispering a father a= nd so    "And it was close told they who wrong told p= eace you something which made  "No, slept no," scared successfu= lly serve said Noirtier's look.      
floor "By the anxiously way," said leaped the major, "you condition know = I have onl   comb hook split compete "Then they follow you= ?" asked Monte Cristo.      
"A probable thing!""And queue cough what have flung I to slip do with you= r ill-humor?" saidplay "See, they are freeze here." And at rate pencil th= e same minute a car"Not so," replied Danglars; authority troubled bled "y= our analyse advice is wrong,     match feeling "And you want money; ship that is a death matter of course,= m  "Ah, hidden you frighten precede me. What fork can they jam= have said?" an swore "Ah, I become know," said she, modern whip low= ering her voice and goi   
sworn "Why not? animal Who fowl ever heard of such reject an occurrence a= s"And strip pray front for who are the point persons who exhaust your for= slung nerve Morrel smiled with an suspiciously expression very country li= ke a grimaperform rung "Oh, make daughter moon yourself easy!--I am not s= peaking riddle     
transport were observe clock The major's eyes sparkled brilliantly.island= stroke "Yes," insurance part replied the angry look.  "I under= stand; kept silk you equally are drink displeased at the silence I  gracefully "It osteal is branch 40,000 francs which I silently now owe yo= u," said Mo  

face pin untidy "Sir," said the baroness crawl humbly, "are you not a= war"I continue do not understand respect cooperative you, sir," wriggle s= aid the baroness,"With you, sir," replied step float the fraternal join b= aroness, "one can wistand bid "And pray," asked the really misspell baron= ess, "am I responsible 
"Does your excellency grease dived wish for fierce fish a receipt?" said = th  given "What is it, then?" move asked hurt the discovery you= ng girl. "Perhaps  "No."      &nb= sp;   
melodic attack irritably field "For what?" said the count."Why not?" = ;         
------=_NextPart_AC4_F499_9AA6DDCF.E26D2369-- ------=_NextPart_3F3_1E5A_BE64D3B7.C4931113 Content-Type: image/gif; name="saeielaihdidy.gif" Content-Transfer-Encoding: base64 Content-ID: <72e3201c77242164a8f1b0e383fb81@dpwlqokiqs> R0lGODdhOgEpAYQAAP///wCZ/wAAAP8AANzZ3L/G3a2zxWZmZnKK08wzAIyYvjVxripjoeTAkdCz h66KW+iMjJxxTv/hm//MZpRgKjorO1pSWtxSUuFrawAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA OgEpAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHgWKJsDJrMXvTqrSe+xzM2GxePyGL1cwmP9J3t1AIB5KoKDLXd8hnqMhI9fhWmMeJONfYuR LJeYnJGamX50gWdwlaB8ppCrKKuarSOksqqDtbeidyKzrLSJp4mhsaG+rLZuYpaPysi7e8DNvdLO s7ylbK2C0NnDiLDd1ai/vsHLz8XU29+dV8zo0m+v5uLo7tPsxuDprvOU2GqTYO2LtwmYv3qp6tgj SA+MvXuxph0c2BDhv4L+IjLM2E8UxXLcxvXqNIrYw4Xi/qx1IbaPnEKMLTdKhFfxEEyax6i9/CVz kc53lCC12YTy2E6DOFVuERizIkuGF40hZZniksyPQLFCjPru29B5RyVSvYpPCyKk+RJGSwtW39ab M6eqDTmR7Dmd4ETmWnt1q9ydSs2iWSs2YlqOIIX+hWZTb9+RHRcXHkyUsGF+hvuOrRnYk+fPn/SC Hk06z+XSqFNLgqu6tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJPXFsCcOQ8BLaBDRzFd RfUb14tkt66cyfXtNcCbED+CfHk55rtHyV69+XgAzsvHd18ivgjp8km0P+F+P3z439l33n8C3jcg gP79/kdgfQAa2N58B0onIH0LpqfegQYqqOF903U44HYeOpihf+SFqCCEGrLHYYYRsmhihyB6aN9+ NDY44ocWXqgfgynyeOJ5BW4oopALplCji0ju2CODCb7IopJFJonflO/dqOMLKi7Z4pIgvmeifOYd yWVzWSYI5JYk8ncmmhVy+CB9OV6Jn5JmcvlhlTt+aaWaQ9pJXZJ5srknlHNK2SadeF7JwndbCvoj j0c6SSSGAe5ZJoaU3jloflFqmaalTypqHZn1BdnkjDEGumKLqT4poX6mAgqlm7CiyKSeFHo64YyY ippHeoz6EKevxBrJ3aw6DFvsssw26+yz0EYr7bTU/ooxwAAmYCuCti5oy60P14b7bQvXjiCuueJy W+6241a7xbrosguDt0PA+0K48gKwLrz7qtuuu1mUK3C6A+vrr7nbGpywwvvK27DCJdh7LsPe4gtx v/E6/O/EBmNsL8BC4FvwxSPzm/DA2BYscsoss5ztwRS77DLJ+ULc8cc024wyyEV4XHG+OOt7cssU d1z0yi9nXDLMGN/8scUR/6yz1DyH/HPTTUc8tNAyp8y1zF8nDfTM/EqN9bfpip111lUD4fPYNZNA r9FQr+wv0WLTvLbZVJdts9J9U932D2+TTPbcdxvNLt50j1yzzzPnvPfjh8Ot8b+D63C2xlMvDHPn /pTHKzHaFjs+td+iH1w26pxn7kTQWMDexOeuLyG7FbczwXHtvPfu++/ABy/88MQXb/zxyCev/PLM N+/889BHHx2Z1Fdv/fXYZ6/99tx37/334Icv/vjkl2++989Jr6iyi6ovZ/ruX8j+CsMSYL/98ec2 /7Er3O8//vlbDvxUQIAC/M9+BTBgAGezP2OlgAAGiKAEJyjBAtTgACXAoAg0uMAqNPBPKCAAAkZI whKa0IIz4OAGQROgN4khAZ75IJ9OoIAF2NCGDGDAAhCgwxuOkAA04KAKhXiAIWJQg0fcYBGfwKs+ ydAFCYjiCmDIgihSUQRWPEEWR7DFIFDxizPM/gF5DLCAHubwhmi0IQKAmMIRDHGFcESiHOEIABUm oVBiYhSpYDWpFFzxilqsIgBg+EVCAnKQhsRiIokAxkThwDw1LGMaJ2kANspAiCSwYx3piMQTaPKO rKLUnEg0rEMWUopYTKUquThILQIyi6iUIipJsEhE/rGVtEQkK3F5yFBhh4BkzKEwh7nDStogiZl0 YxE7GcdMLpOJoXQVqHzpxxI0kperNGUXuahNXepyltxM5S29SctGmjOMj2RBAXg4zDMiAIXH3GQy 5SlPTNLTnk1okpYepU8oWjObAO2lLV/ZS1kWkpy7bKUVYxlIVZ7Tkb98IAIVwE4dIkABBrTk/gVN wMwl1pOZH4WmiPCIqDG9wJQAxaVCUUDIcJrAoIpEaEBf2lBs2tRHYpRoAgtYAAMoQAEGSGBGNdrG DCrznsg0Ij29Uysw4XRDzlHWOFV6TZXmsqUyhWksa+lSrN60nA4NK0RtYJ4DmvV+TPika9i3zXG+ kqWzXOhBbVlOgdayi3Yl50OfGlEwLFOtqNnjEAS6yh4QVpAzeCJfOziDwwrBsSqArAOTxVjkKBZZ l60saTLroPN59rOgDa1oR0va0pJ2gJodDmf7mNrerHa1rd0samP7m9fSVji2vS1wcqtb3/A2hARo gHDRqhzYFuu3JhBuAxzAXAcoF4C9Tagh/pBLAuE297rNHS5ReUOhXCFhmzWNLDjBq0iCSvYGe+0V WVGw3Adg970QuO52XYBPFQD2CiQ1lmBXJNV/DnSXUxWnK625SLnSNK5xtapC3VpYaobnBARwAATc 29z4OuABEIgvhS/sgKK6kZMeracy75vPfY5nlDiCAUqpKlYFL/Sl3dyqTL3p1bmC1aZVdTANwBPh B/h4wj/2sZDdC+QOXxIFIO0oJz0oqypJirXhvek1vVpXgsKYxlwN6IsVnNL06jixKDCAjyMgZCAP ecgKmC8L1KpJJS+VCv0E4ZP7m0sWs5iwNbZrgbN8Z5r6GccNhrIMxFOAMxt6zA/AqJrX/ozkEbu5 jiFeD6GOJakgTTGhDJYuK7EKzm/uecYMzTSBG5xjQcdgjA8g85AjwOpEV3LRLbDjox/94fXs0btO dlWhTjpeANcZxn/c8lbNG0gEB3jTme4ldUcAQVY7u9VBhTUM8NlRN9c3NcaN8q8NS4PzjvXBIVzu e53rvxw8s9aQFjFSSdyI/XpxCd7+MwyWLYKz2ju6MZwts+19b3y3W9/75vcB/f3vHWQbZME6DmdN y/CGO/zhEI/49xCEPoMTfDf0vrhsMq5x2HC842sFOMg9LvKRh9ziJqfNx1Pu34JTNgrsnqfMp9BC JpC35eIlNrDrOtgWqxfcEBa4WTca/nM6ZqGJpvbBsXHO0pV6etQy7jQQSk1voff7yLJOt9aPSO0Q c/0I+YWyhAoUVRX7d8tS/qeeoX5Qqd81wShN8Fe/PGjgWv1/8IwBMo+69b6rO6RvHkKc+YPiEdHZ 12I9NtpdGs6oFxSMbn0rQwG9WKCX4O4HzPsL6kvtezbz84EXwuBz7Smz11nUVObmeB+PZVAje4t5 TXygl415vGuevn+VOSbtKcdzX1vwjeLTnE2P+LTjmaprd/yfU89lO3s56ViC8FDv3lNpN9ronee9 0ZcM9uCTnpQxmKqom99SG8cUpk8ftdPnHlPKK1vkBaSg/OV/+1gblfub9Ois8a+d/qZSWtfQx3OY Vlh4ZmwyRleqV2zBtnQLhnjvh3LSJ1QSOIFCZX3Xh27Zp3XrhoGecHBMt208EG8fGB0lFzzuNnXw 1m1gBoEsR3Is2IIn93Iw+BorN4P59oI2GAQeSII4mIOyZXASF4RCOIREWISjVYI+2IFImIQul1NM GFhL+IToEYVSKAY1eHVVqBrpYXVZyGQ9GHD8lkBdSHMlx1M7ZW9iGET3ZzwieHTwl0BB1VNwOIdy qEBquH1N+AQ3B4JwpXME5odKR3nI0leXF0EX5VMRBFSI6FNCtVHY53UaCGlJxkQ7SHyOJVnld34x 1nZtqIJcRm8F8FOiOIrzF0EW/thobxRH+5d/0DQ/Y8ceu4ZYAIZXKbVpAwZWyqd2C2iLV5Vs37Zj KBCKQDWKpEhBaRZP1/d7nVR0wHdqhXcicZJ6U9Zi2uR2m6iJV7Z+5td+D/WAMlgCwjiKF0VR4yiK F3WKnvRmued5SgSJknZq0xSALtZlvPiHVsZ22NhyhgR7NdWNqvKNJEAAFCWO5FiO5GgAjsiOfzeJ rAgFrhiPh0eNM1VsjIeLnLh8XBZ77veLK3gCBmBCJmSO55iQvMeQc9SQIjVv02RpkTWAPpdXnHaN uXhjNRZoNCZ7lQeMIfSRIAmSx3iHGJhUQYmSzKiDdfco/CUDbVV8zYeAAzVX/m0ldQ1YXpomTr6Y kx0JYR95AD05QsaEcEVwWJ3oT42VlekETAVZQkBlh9Nygj8wljgAl2OZcf4DhxN0htA1hk5Al7WH jnoJBHxZe3+5l1Q4mFpQg4Z5mM9hhIzZmI75mEMoj+2TmL9SmJRpBYh5mZhpmZpJhl/YmYr5maCJ BZkJBH/1e/R1A0XphGEAl14IkCwwdMgIenonHHtYla7Eetn4lI/lc3QHjyggAUFnewkpYpF2bvnX e+34YUmkf8sYici5KPOxX265AwyIm2pnVeS1na5pet7ImiUgnMP5P0EFlIDHgX5nkiepf8kJejFn JlnSm6dHi3ZWj1Zpj+qn/osJKGC96IAceZQmIAECOqADagARoAARcJqr6Widx47a56DoyYoPGnr8 A1VqQp2xeGmn55+ktpSdlmVSGWqzmI3+iJUAWgITkKIqqqIUUAEu+qIuagF+iW66147s+XmniX+7 56DrOD2YlStlx08RmXZ9BmzmtHYV+Wv7OHn6iJODuF4mQAArOqUtagFWeqUVcAAziocQuoa0pqPM 2aUdWSKa8mQtsGKo15QxuXjt16ZNWlD96KQ/p5Mm4FxTmqIRcKV6agEKYJ7oOaGr2KASWmuo+X+T FSJmeqYu+VUw6WI2tnpwxZ/sd5OCOKdmyWwbdl0JqqA/eWQcFZQN6pyC/rqjXVd0nzJpVoKo87OU L9mHJBpsN3Zgu2iTd+Wbkkk/wDVupciW3IV0LlSm+VGJNjmscemJwAmb/YOFbYkacnmpUIo81ake pTmaDsmZ1EqYonmtcGat2roE09qt3rqY5kNxkFmu5nquRHirFQqu+MWt7Np92XoCDfCuRpCZ/0Ov RHCF79UAW4qv0Rev49Zc/eqvk4msJBCw8kWwPcBxDZBqPtZcQtZcquV/vcNxF6aIzJVqEZSxA6uO yfgFvooJ3emZBgsABCBkQHRhFICQEXZhCOmnbBYGYRcmFFcqt3qbxCqAVLlz+/lu7EeXESsCqZay QUuSI0ao3Ld3kRau/k1ms5XGVtiZswJ2kRaZjz33iWU4ZEBUQCYrZBHwskBpku6pRGRLofXqfZAC KEN6Sml6VbfYeFTbnzu7fvcpp7+pkiGUas7mAPbjAM9GAfU3bUu1joEaoUxrYmlrUid1dsXHfP+V pOmHfkrKm+THod95lijgABSwuRTwt53buR27QqE6tgq5oKiFa4lbKWtLj5KanW4Kt1Y7gHCKkZV6 t/8aQhHAubrLuRYAtrMJeIXLf58BtbVYVY26jVoVt13lfLdYok9qeR65u7rLp6FLo+k2a75nuO2G ulXUa62am6p3gFEJk7NauXJHdSUYYQi6u1b6tdVbPGKJgmV5opg7/pwO8FOs9lOv9r7DM7LGGn7O Cr2Xd3cKG694W8DvWLIIDEoGvMD56q4ODMHoFMG4urASTMH1+0jo+oqQSa4b/MHnisEiPMIkXMIm fMIonMIqvMIs3C27gzsx8MJQozgLU4UEgzlQkDtRwzFpwzAI04WsczNxszobwzQvjC6lM8PZYjkP oy5jCDsEAzpO0y6oE8UvYzdKDDhMfDF/mcVyUzmhEzVa/DdfvDhxs8OBY8ZCM5hKHMV708Nl3Dpk PMZzvDifgzMVg8NJWMVOPDoqwMcZozZeEzSbM8dXY8N3HDjjEsSg0y9FDDiPLDlU7DmIDMdWTMN2 jMdWfMloPMUo/rDJR9zHegyDcCzHhOzFjSPHJ5DEt7M7WUw6o1zCOtzCUTDLtPwEtnzLurzLvNzL vvzLwBzMwjzMxOw6EKAFwSVhGbbMzNzMzvzM0BzN0jzN1FzN1nzN2JzN2rzN3NzN3nzNwmUEBAAB F3ABGHDO35zO6nzM69zO7vzO8BzP3owBF5AAFwAB/Cuv9IzPxZwCDYAB9jyvO0AA5SzQ/cwCDZAA GMC/DTAABn3QLkDODz0D5JzPwEzQx0wD9GzRwnzPM+AAFwDRN0DQEx2bF8DRxEwAA+CXHu0rqIwD TowENxzLn0zFsGzJWOwDEIABL5DQJ8a9AVxSJhqA8WkDuRzD/j98BCpD050sNzX8N6xz1Cp2ihiQ 0bOSWRZCsy94WVCsNfOS1EZgNjTgx1IM1XPzAztNlk/1q3lSc7jWRDCCthAZVaiSX69CK2KcN3Wc AjEt00Az1qQTxkPsNTtgLwTdAg0Q0o6UqCgiJsBaJIjqQKcai0/rRGJMxC2TNnVz1kSTxI0jyngj O5q8M20c2KcTyqM8MUgjxONy0izgADy92E022URyKSqi1acaKnm0JkKy2maNxFvsOWId3JLzx6Yd M4Mdx4C8ypjDx6v9LxhQ0iaQYejE2JrSKbrdJ3gtZxFiK0iiT9ST10Ec1ZMs3H9N3Fhj3HFcNMlN x4zMNTVN/sc5QwLUvQLnXN2zjScZatuJK3y9Qtm87djirToOU9ZrfOCfvcOYnODqHciOQ9aWY+CC 4+ATfsQAUN8qgOFX7X203SX89OGsVWm8LU2cEnYRLjAF7tk+/NR2o+ClzThkDOE789tOjeB+k8am LDijrOEowONuQnax4iLTeWJlCt763V1DzikWWtedzMrAjdwF/tQHvjFgndSLfNMKHuFCvN5bbjiZ TTl3E+Y44+PTbdVW+J+3q67zwtRdINW4XMoXbuY9LudgUNTParuA7eZXYOF77tUXHucsQOYivQJw DugrIOiDTgOIPgKLnugx0OiG7ug4AOmQLuktQOl0/kR2/k6IGiws1armn57mPIDpFXzAeM6D4HnB 6yrZoW7qqL5apJ62lgako4RiMFJz291ZFEvZ0xln3XUnehQpQTombL3fZbcrMtIlvHLru24qyz52 ToXdpGTil07n0x3bdIIrRQ6Nq9LhorSS8fkltK24Jd7tSr7b4Cd8ka3rQtLYIm7ZaCIjrOLhL1In gW7tJQDbpBfi333dud1H9q4nfhLg/u5L494mz2go3A0qdXLw2j5DTmLkXhJK8xPdCK3YQh0jtmLX YMLkua4r3q3wBL+S+q22CB/t4c3vxD7s4S7kSM7WPx7xHZ+hCDLz2N0Cri2LBY+qu424mMXz1+0o 8I6U/gLv8CfPJL/47hz+3+uacNHU7v4N9exz2C1Q1f1dJjIPkf0OgEJq8EFP4kRv8Os+8BKPlPue 9e0+9t4O9mgv4Kn69ZeO7Svg0xlP5G9y6+KO7NEOJKpLTb++1she9DYCVSG793+fKqdi3UhX84bv 7OD9q+Ax7ZbKUuho9RjnWyz06HJv0ig9BsIKmKB/gy+g0jKQ2JYeAwRg8TKw0acPRfh+6Tnf+uyV AK/vAg1d+5Yu0TpAz0Ym+xeu0Bz9z+Ys3cKB+ylg/NHyz8APBONczuZc1fIc/dI//dRf/dbPzefs /MivA0B0/d7//dsc5+A//t5Pbr5//uif/uq//uzfBP7rHwIAOw== ------=_NextPart_3F3_1E5A_BE64D3B7.C4931113-- From levels@paulebling.clara.net Thu Mar 29 21:56:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX6M5-0005BL-KO for sip-archive@lists.ietf.org; Thu, 29 Mar 2007 21:56:41 -0400 Received: from [84.205.162.21] (helo=[84.205.162.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HX6M3-00040H-Km for sip-archive@lists.ietf.org; Thu, 29 Mar 2007 21:56:41 -0400 Message-ID: <000c01c7726e$a8b3c070$15a2cd54@Marcin> From: "hardware" To: sip-archive@lists.ietf.org Subject: civil criminal penalties Date: Fri, 30 Mar 2007 03:56:40 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C7727F.6C3C9070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.3 (+) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd ------=_NextPart_000_0008_01C7727F.6C3C9070 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C7727F.6C3C9070" ------=_NextPart_001_0009_01C7727F.6C3C9070 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Aptget, iesomeone together script creates clickable, icon apart. Display webservers scientific programsas. Writter, invested jotekes williams stream slowing, chance zoinger. Players hopefuls governance campaign how. Employees projects fulltime = let. Broilers taiwan hogs, mexican, mangement regulation durum stocks. Wetlands red ceenis panama. Daley father reformist kansas pendergast harry. Explorer microsoft = configured online! Initiated lawrence lessig jimmy, charge involve! Flaws, stemcell passing controlled believers argue. Lamp stack heads = develops. Trackback camps stelios nikolaoy ahmad eduardo, valencia. Disk = per abused bo derrick. Decide what, no, landslide effective presidency? Neededthis contrasts during unified toolkit. Looseknit teams, initial installs thousands, wholea purpose. Todo waste = accounts, deleting emails? Peters john considered ultimate platforms! Weather edward baig kim. Decision makers where way paved dealings = included member wealthy. Popularity reason insecure secuity. Millions quothomu pejiquot sitesor blogs, overflowxy scrollbar filters. ------=_NextPart_001_0009_01C7727F.6C3C9070 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Aptget, iesomeone together script = creates=20 clickable, icon apart.
Display webservers scientific = programsas.
Writter, invested jotekes williams = stream slowing,=20 chance zoinger.
Players hopefuls governance campaign = how. Employees=20 projects fulltime let.
Broilers taiwan hogs, mexican, = mangement regulation=20 durum stocks.
Wetlands red ceenis = panama.
Daley father reformist kansas = pendergast harry.=20 Explorer microsoft configured online!
Initiated lawrence lessig jimmy, charge = involve!
Flaws, stemcell passing controlled = believers argue.=20 Lamp stack heads develops. Trackback camps stelios nikolaoy ahmad = eduardo,=20 valencia. Disk per abused bo derrick.
Decide what, no, landslide effective = presidency?
Neededthis contrasts during unified = toolkit.
Looseknit teams, initial installs = thousands, wholea=20 purpose. Todo waste accounts, deleting emails?
Peters john considered ultimate = platforms!
Weather edward baig kim. Decision = makers where way=20 paved dealings included member wealthy. Popularity reason insecure = secuity.
Millions quothomu pejiquot sitesor = blogs,=20 overflowxy scrollbar filters.
 
 
 
------=_NextPart_001_0009_01C7727F.6C3C9070-- ------=_NextPart_000_0008_01C7727F.6C3C9070 Content-Type: image/gif; name="debt weight.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c7726e$a8b3c070$15a2cd54@Marcin> R0lGODlhVAG4AYecAAAADncAAAaHAHp0AAEBinIJjA1yhsDDv87kvbPF4zcqAG4jAIkqAKkkAL0f AOUSCwA2AB5LAEJEAmM/AnM5AKBJALlKAOszAAdjCCRpDDJcCWViAIZYCp9nAM1VAOdaAAx1AByD BkSLDV58AnSBDqx8AMeKBeh8CwCRCSaqAEKWAGuqAHyiAJSXAMSrCeCpAADDBSS2BkPFBWu6AIPG DpbLC8u1AOjJAADdDizTAD7hAGzqAITWAKPaAMffAOXSAAAEOBsORT8AN2oAR4AAQqIAOrwAQtkC PwAqQBkSTDgYQlQkOngmS5skPsYVOdgtPwYxMSE8ODRNNVc4OYFETJE0PbxDSN0xNABtSSFSOjFq MmVVM4NfC6VpPcZSTeRZQwVyPip7PDqCNGx8NXKOOaV0Nsh1R9mMNwGURymtOECfOGycTIaZQaGc RMWnTOSRQQjKRCy5NTq2P2q8Qoi8Q6W0Nb/LQ+zLSADcTi7sOT7aN1fuSYnlMpHgTsjuNeHfQgYA gxMLdE0Ae1QJc4cAh58Id8gBid4EeAAleB4aikwUjVQZjXoohK0rhsgShdYpigAzhCxLdTI3d1E3 jnFMhKFIicQ2h+07dwJqhSFgekJne1xojIRkgJpgh7hegdJXhwOLgSaOg0h8iFJ7jX9yiqx/crOK g+aHiwCjdBilcTSrjlSdgoyudJKig8qcfNiZhAC5cha/e0q1i1PDg4a4hqbHhLq1fNnKhAnmfSLh fDzgiWTpf4rheJvUf8jdf+XYfAAOzioAyUwEtVsAsokAxKYIsrgFu90JxQAtyBgbzEsdt2sovoEt wp8tus4uv9IeyQBExihDtEk4sV9LvnQyxK1Nv8ZJs9ZCvwBZtBpeuk1qwFFas3xsy5ZgzL9ttele vwB4vhKJsjGOumZ8wnNyuZiFsshyutVyvgCqth+cvzStsm2YwISVupagzMWVueCgsQXLvhq0tkay uGfEvnXNvKiyxvL/85abn3xxc/8ABgD/CvL5BwAC//8N/wj//f///yH5BAD//24ALAAAAABUAbgB Bwj/ADkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUsXLD+HdxHyy1u3b0W+nACf5HtXcMLCBg3jHag48V6/ZAE3Hil4 csHGlhVmPgxZrGSBe/MSBv34cmnEgUunLvwYdWjHrUmzRh14NeHWsVfLrtw5bOjXBGkLD844Neji n48PL668NnPntUcnj478+ebeVZP/bm5b8vbbr6cj//4tPvro49ypW4e+/Dp2qp/Pu9Z7+Tn6++Pp p8/Nvn956cy5955U8a2HH3H7VbfecgcW2KCCDyY4oG8IbnefbqaJFpxqwMUmmmqMhYehd/x9+KFz HQY44YostujiizDGKOOMNNY4kYAP4biYjZ3hqGNDPzJ0XZA8YuWjR0RqBmSRalXG4WkXWoihiuY9 qaGJsKHXIYdMpvVfdbxJqGWC0mkYJZgIotglWl8qZxiAZ+ZXpoi7kegheFCuaVab1IWpHnR9/knb gQf5yZ99enqW5nBmRghof/5BeJ6jgibK5pbgEQopcIsSmmKIb0LJ6aiWlmrqqaimquqqrLbq6quw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6y2LANQU7rdKAWBuuOOClO5D6Dq0Lrk0vftuR/MyVG9C98Lr0rznpnvuQP9y0i/A5hKMbsEEBTyw wAwvLDDCDOsbr0H+RmyxQO1ibHHGGhdU8ccNA7xxxxLLxK/I/Y478McrV+wxyjBzfLDCJc90ssby wozzQQXfHPLOMl9Mcs0w5bzz0T8nvS7HIiPdbtAuEx3vvy4H/HDPVisMMcQYIwxy0Fc3LfVR+Y5N V9lmp6322my37fbbcMct99x012333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQe9sP Rv1MPpHlGaGtkebbVl45J5gTNHnoBnlOukCYn2766aBvxDlG/jrctdavB8t66QvdPlDqCOmuu0S1 V7RyQ2Avqzrqn7duueeil54888wXFHr0pu+evMHYN01zxPJuzbXOQvNMcvC9Ht/86K0fRP3u6bcv vfrto68Q0+BnrDJC9L8c+/cJZ8+s+dVD3/Xgxzvewc96nysg61pGsZE9TWgMxBf/6hU18vHqeAWM 3+3kpzz2HTB+IERe/8a3NAeGrIQkxBcExTc+Z5GOgwJsHgHZZ0DcoY6GHryh2FDotBaO8GL5emDH /6I2MhdCD3kJVN4AQRc9Ji5PdOZD4uiot8SrzexlYfNhwqjGv9ntb4ce62LkxDVGqViwjGhMo6X0 oY+StLEkZ5TWGznRxjlehI1sZIgdH7JHh/RRXQ2kmNdkl6w5/rEihlzIIT+ySI44bIJiG1ohB1JH geCRkpesJB3zSJBEavKSm3wjKENpyTyKkpN4NCQqScK0/BExjrv6ZEE0ScdNGsSOnhQlJWtpyV3i spO8rGUigdnIzRXRZzxklixDSUtaMrOToBymMDGZSVX68pq9fGYxNzdIq2kRlrHkZTODOc5smtOc ntzlLa05znT2cpvGTOY3o+XOab5TncHMJzmxuf9PfE6znu2cp0CLqL8f3m+IclRnKktpSmhy8pz5 jKZDGUpRca4ymwt9YwXBOFAvYnFjW9MXPMECTm+Nci0lVaNKV8qiKjrkdzFJabMyqJHq2dB9UmQd TIsWyJ5Kq4YZgSlQZfjBmzySgjK9IA6diMAYMpWoCETiU6FKxes1sSWtDJ8koyW/F4Kwii983lJx msPzjZWnVcOftboqxa9C0aUdvOFQyxpAGu70JLTrYlKV+kSaxjWEuPPrBnMIQ+uZDIhqXetYC1vD wQq2d4QFbPo2OlDKErR/PJTnTz1o07o29a2pE6th3/fZzl7Psqjl6GWt+NEv1uyuJJ3bVdWyV5b/ 2va2VBmpWGq7rIwexJm0NZheVUbISerxLcNTIQt7e8uKfvKhZCmeT3/I3Flat5K63YrMvOlR6iqr j6dsaB2zqxXurlCLymxuOq2JFvoZbbXV5Sd2gWlQ1aa2svbNL37RGzPt+ZC3tfKtNoUJ3f0S9L4H 1m+CDdw971UwpLg9bISNAuAJW/jCw6qwsmxaEd+dlSlLm2BxoQXbi8x1Kck977V0+rwmrq+rA6Sp i4+4PLjGVKvvVSxp/8rYvkL2iWaVaxTJ2D1BitGFUl3dVz371/cBmckcdGKJVWLeIFZrejj1qw6b HGTGLrasNnGvcqn12DJ/mKhelmtkF8xmBFsW/7PH5O9Pq7rlGgM5fbMNoWmT+Nk2K9jNkWTt7HZ4 5MJNeWK3zfNPNIzhRjt6V4w21kI7k+MturZZ5GXLwvRaP2eBF5WmVGWmpyLm+cG3kBe1py7pu1sV C9J/0AqoOBk6ajNyDW3S9fQ+V13O6J4azltNrzt1OUxAM/jPyD52sKV7UKV5epQSnfUz/axsalvb 2Ks96oMv/WiTRLrb9AK3uMfNFZ2acWxK5oi5oxLie+2v0Mg69EuL2pQU84uCm1XzU6EX2n7becv1 xvFyA41kETpZh14181NcmVjvFtx9nn3yEfXNZRDfeszBnuma4+pjiqcZKvYztcMf3lg8e9yt+v/G tsqTbW04+wyxZKbrxCXe4prrcOXVxnm289rsrJHb2z/XybeDTvSi02jow8oucMtSaXd3E96+ynSt q7LpEC+30sTaY7T/Kd6KatfVAh8a0kv1y3vek72szkqpCX7Zsa/Roasktj8nrd2Lj1zQWs162s3e a2l+nYh5Vy2yyt5PexZeoyzXueJZDmxXv9ftZI8mdIfZUGoiPueJz3y1u5vFzsfu7kafCORDTzzS m/70qE+96lfP+ta7/vWwj73sZ0/72tv+9rjPve53z/ve+/73wA++8IdPfLUHZfQQQX6NRmwvqonv dSBLSfDqlY/q52Mg1r++QKpPEO2bmreaPTr/20W+EFzXdyXTN4j3OXH99bd/+/C310fCP6PoO5vg xL1f/qkb/aw5f/9hlH/vFoAAaF7Yx37dh4AKuH5GZj/dNGgORDsZJyOb1mn4V1D5s0LN1kOQ9HwW 2EL2hxDvd4DaN4INJ0Ri12khqHxjYX/691Ha838PI1w0c1D2BkTcdYOvhDIpdhAlmIDs94NB2FNP s4McCD6BFyMuiDRbBTUg5V0ht4RvJoWRFIJ5x33xl4UkqIUm1DUw52wr2CVLuGwFBTT8R4RdeH9f 6IQpeITqVxDuB4fxx4BhmFlpmIFFom2AJ1zcI4M5iIaC1oOEdIN4113+B4SIqIAHuIAN2DAO/waB rFU1G5gqLFh6QNcQ2YeF2SeH2MeA2FKJEoR0Blh8pFiKpniKqJiKqriKrNiKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLvviLwGgWQ4d15ecuFgGKE/gqb8Yzzgd6bNZwPcSESdh4lpiEomhMNrKMMDiN rTV+gVY8+FaN7OKN3Jg52Lh8HPWHlqZ/6nhMXvMzhAiPEkiAJwSJXISC7QaJ//WOZsiHEMhF/oOM XfFAPReAIJht9RiB0UiQbriGjniQYGSEbaeCPNiN/beQeZiQKaNWX/ONGkmRCCVEUCM7HelFWRWS 3ShJIdeQEakz7Lg92fiRxViSGgiPIMk9H/9phS0JeHaYNB1lkywJkUDJcBn5kxS5h6k1hgmmlCa0 UT0ZPtrolEgolCuZazzySt9TgUBjgFhZkHhHWVV3bz2Dg641lssGgDDof2Z5fttjgxDGKwKJVcID N3HJErBUl8GYl6iIl1S3h+tojHNZhpeYkoApeo40jvXnl4KHca7DU9Jnl+LnljmGlvf4jw65f1fE jO9ImQ9IkBJYgOroTdqmjw44gB3JmVD3HlFYhY13kgpZX1lVNiwjlDjYkGyIWOEIhq92h01ZkIoJ Lv34hbqZX/jGjlNpkTQ4g204nMxZQh3InITWjLr5blbpIi8okdAplQ3Ucyh4dae2lrxJhcv/aXfQ yV9UyJPkOCGfJ5G+eX4+6Z4JqZIf6JyweZPMdoZBuZRH2ZLJqJ4Eo4+FqJZemEXuxoNuqZIwSaCP yDLe04deiTNZGYOfV4UOJoA+qZZ82SrECDtFkaEZNl3nKBQeqpckWqImeqIomqIquqIs2qIu+qIw GqMyOqM0WqM2eqM4mqM6uqM8SoolVWh4mHwvoo2DGREkAiohgigmCTypGZyI+X0cWox1QaRwdCOT wihjAo1PCn3pOXAcGaXkNxdgKWJrWYAOaogPCKCagqV/MnB5tY1gU4Nhw5Npmj2tJKeeJ52YWadt wZATGY0VKZjgCF9XuimN4p2AWpPyiY+s/ymNGAib7cmSvxlcIkmSFiiIegpS98g/hTopWqIY2imc 9zc8sYmcjeiagyqeKRQXflqgtqmfiZqEnYoo80GY99maTYmbplqfdhiqtwlBIyp0Chae88mbsQop lUIlhuGrKXmeYJeGO1mfVAmtL9enFCqWFhqJfymJ9sipVoKkiwKqlsZ54+qPpDqgOMaP9Hin6pqn T/ePmamEXKE5KcVowSqmTbpwxANO9tqj/vqvABuwAjuwBFuwBnuwCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxtkIepFEonNIdG7shjhGy5PEdGrshI5skePMkxsGxILux3xqyprGyMDslIPI4NejLGnpx G/VxGjWbpDHbsx8btEC7OENbtCfCsh0bsz+LGd7hs5BjtDkbtBkytFLrskzbsjJrs1fLsllrsplx suEBtjILImCLsnUDtVxrtEmrtCCrtklLtYmDtjALtWvrtEmKtjdrtnsjt0qLt3xrtVErtXAbt7wh tzc7tkDbs7gRuDSrt3ursoYLuUfKtne7tbJRtU9rISe7G157tOBqt1a7uXk7GyOLsaZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77ugEB ADs= ------=_NextPart_000_0008_01C7727F.6C3C9070-- From sip-bounces@ietf.org Thu Mar 29 22:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX6nk-00015w-7a; Thu, 29 Mar 2007 22:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX6nj-00015q-Pn for sip@ietf.org; Thu, 29 Mar 2007 22:25:15 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX6ng-0002yS-Mx for sip@ietf.org; Thu, 29 Mar 2007 22:25:13 -0400 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id A4F101A0; Thu, 29 Mar 2007 22:24:49 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'IETF SIP List'" References: <057401c77197$c2697500$800101df@acmepacket.com> <62B9B0847CC47543B6B3B5E26BD268E612002DA6@zrc2hxm2.corp.nortel.com> Date: Thu, 29 Mar 2007 22:24:22 -0400 Message-ID: <072c01c77272$8b5b6790$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdwddKpYbqocH84S7y1P1hQuUzOjQAGRhfgAA8AURAAAHzk4AAvL7vwAAJl/yAAAH3yYAAktfJQABBx28A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612002DA6@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Sip] RE: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading allowed or not) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org But your solution for the problem implies the problem with sips is it does not let the UAC define the specific ciphersuites to use hop-by-hop, and in particular as if defining new "stronger" ones will make it more secure and thus more popular. To me that is not the problem. It is not because sips does not provide strong enough security between hops that people don't use sips broadly. People don't use it because (a) the request fails too often because the odds of having TLS for the full hop path is very low, or (b) they either don't perceive the dangers, or don't consider their communication sensitive enough to justify the cost burden. Obviously there is a third camp of people who don't trust the hop-by-hop nature to begin with, but for them there is no possible solution short of direct end-end communication or a sipsec model. For the group that's in (a), in some ways that's by design. If you consider your request sensitive such that only hop-by-hop TLS is good enough, then you should want the request to fail if it cannot meet those constraints. -hadriel > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Thursday, March 29, 2007 1:38 PM > To: Hadriel Kaplan; Francois Audet; Jonathan Rosenberg; IETF SIP List > Subject: RE: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading > allowed or not) > > Hi, > > When I wrote the 00 version of cipher-suite, I was in the impression > that community understands the ugliness of the SIPS. As there were many > wacky threads for it. So it was just talking about the solution. > > Proxy-Require tag for Secure-Protocol/Cipher-suite makes the SIPS > REDUDANT > all together. Here it should be noted that we are talking about the > Secure-Protocol (Which can be DTLS too). Where current definition of > SIPS as per 3261 is completely broken. 3261 has tied the SIPS to TLS. > SIPS is no future proof with respect to secure protocol development too. > > Thx > Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 23:55:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX8AT-0001Jn-TR; Thu, 29 Mar 2007 23:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX8AS-0001Do-3v for sip@ietf.org; Thu, 29 Mar 2007 23:52:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX8AQ-00022D-Re for sip@ietf.org; Thu, 29 Mar 2007 23:52:48 -0400 Received: from [10.84.143.35] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2U2x8hY015388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 20:59:09 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCF3A2F@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> <2994750C-566F-4635-B750-40637B275F62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF0FCF3A2F@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2670E9AB-688A-4CF1-8D21-77007F80BBFD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 22:52:42 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 29, 2007, at 6:13 PM, Francois Audet wrote: > > To me solutions like this "don't count" because they are not > SIP-compliant. > But they're deployed. And if we advance a solution that makes real deployments worse without providing an error detection and correction mechanism, I'm not sure I'd feel good about it. OTOH, if we can't find any real deployments actually doing this any more, I'll feel less bad.. > In fact, even with us deprecating upgrades and downgrades, the reality > is that a B2BUA or SBC will still be able to "patch" everything to > do upgrades or downgrades in the way you describe. True. And that's my other point -- given the way that sips works, you really can't assume that things really were properly secured just because the r-uri and To: had "sips:" in them. > That is why I see this "upgrade" requirement as a red herring. I'd > rather > we make it clean for SIP (and if people do B2BUA stuff, that's their > right). Both the "just do it" and "Requires" model are reasonably clean for SIP. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 29 23:55:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX8Ci-0001xO-Vq; Thu, 29 Mar 2007 23:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX8Cg-0001xG-Rm for sip@ietf.org; Thu, 29 Mar 2007 23:55:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX8Cf-0002Qa-I9 for sip@ietf.org; Thu, 29 Mar 2007 23:55:06 -0400 Received: from [10.84.143.35] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2U31RoX015410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 21:01:28 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61200341A@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E61200341A@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9413A7DF-3E8E-438B-98DB-026BEF122635@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Thu, 29 Mar 2007 22:55:01 -0500 To: "Samir Srivastava" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 29, 2007, at 6:15 PM, Samir Srivastava wrote: > Hi, > > So for me it is no more valid case. If there is no SIPS > deployments, > why we keep trying to patch it. We already seen so many pitfalls of it > on the list. > There ARE some sips: deployments. There may not be any that are doing upgrading and downgrading. I believe that sips: is valuable enough to fix, even if it isn't perfect. I would ALSO like to have something that goes beyond sips: and provides real end-to-end protection but is actually deployable (which I'm not quite sure the s/mime proposals are). -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 00:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX8cQ-0002id-MB; Fri, 30 Mar 2007 00:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX8cO-0002iY-M9 for sip@ietf.org; Fri, 30 Mar 2007 00:21:40 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX8cN-0008UQ-Dn for sip@ietf.org; Fri, 30 Mar 2007 00:21:40 -0400 Received: from [192.168.2.235] (pool-71-164-176-160.dllstx.fios.verizon.net [71.164.176.160]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2U4LZ7d087676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2007 23:21:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip-implementors@cs.columbia.edu, IETF SIP List , discussion@sipforum.org From: Robert Sparks Date: Thu, 29 Mar 2007 23:21:34 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 71.164.176.160 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Sip] SIPit 20 registration closes today (March 30) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Registration for SIPit 20 closes today (March 30). If you plan to attend, but have not yet registered, do so immediately. Information on the event and the link for registration can be found at www.sipit.net. See you in Antwerp! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 01:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX9tb-000659-RZ; Fri, 30 Mar 2007 01:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX9ta-00063u-6E for sip@ietf.org; Fri, 30 Mar 2007 01:43:30 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX9tY-0004PJ-TN for sip@ietf.org; Fri, 30 Mar 2007 01:43:30 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2U5hPI27413; Fri, 30 Mar 2007 05:43:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2007 00:43:11 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com> In-Reply-To: <9413A7DF-3E8E-438B-98DB-026BEF122635@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIPS Deployments ( Was Re: Poll: Do we have sips/sip retageting in the wild ) thread-index: AcdyfzXvwLXATaXQSOqA8bOcNYgp5wACqXjQ From: "Samir Srivastava" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List , Francois Audet Subject: [Sip] SIPS Deployments ( Was Re: Poll: Do we have sips/sip retageting in the wild ) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, In-line. Changed the Subject too and avoided cascaded References there. Thx Samir > >There ARE some sips: deployments. There may not be any that=20 >are doing upgrading and downgrading. This is the first time, I am hearing on the list that there are SIPS DEPLOYMENTS. Now I would like to know more details about it. Whether they are within the controlled domains likes within the enterprise? Are they across the providers domains ? I am assuming that they are not like the ones you mentioned earlier.=20 If it has prevailing reasons, then I might have to think on the BACKWARD COMPATIBLE solutions.=20 > >I believe that sips: is valuable enough to fix, even if it=20 >isn't perfect. This is where I have complete disconnect. Whatever solution Proxy-Require/Require with Secure protocols etc or any other we come up, they will not be able to provide any ASSURED level of security feeling, once they hit SIPS islands. I will restate my earlier analogy "strength of a chain is the strength of the weakest link". =20 When we don't care about "when the request hits PSTN cloud, and what happens afterwards." As this is UNSOLVABLE problem, due to ubiquitous nature of PSTN, and we cannnot have anything like security defined there.=20 In the light of above point "Should we at all consider SIPS islands." It is left for readers to calculate the SIPS deployment % w.r.t. PSTN clouds. Is it not worth to deprecate SIPS ? If we don't deprecate SIPS, there will be cases of interops etc even if we move to complete IP world.... > >I would ALSO like to have something that goes beyond sips: and=20 >provides real end-to-end protection but is actually deployable=20 >(which I'm not quite sure the s/mime proposals are). Great. Sorry I haven't read till now, your referenced RFC for IETF opinion on CALEA. But as far as I know, FCC will not let anything deployed which cannot be tapped. I have yet to look into the Vijay's and your replies on the SIPSEC.=20 > >-- >Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 03:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXBBP-0002pA-4I; Fri, 30 Mar 2007 03:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXBBN-0002hF-IM for sip@ietf.org; Fri, 30 Mar 2007 03:05:57 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXBBM-0007ci-5p for sip@ietf.org; Fri, 30 Mar 2007 03:05:57 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2U75nI07542; Fri, 30 Mar 2007 07:05:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIPS Deployments ( Was Re: Poll: Do we have sips/sip retageting in the wild ) Date: Fri, 30 Mar 2007 02:05:51 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPS Deployments ( Was Re: Poll: Do we have sips/sip retageting in the wild ) thread-index: AcdyfzXvwLXATaXQSOqA8bOcNYgp5wACqXjQAAOiRWA= From: "Samir Srivastava" To: "Samir Srivastava" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Added to the given arguments, do we want similar pains of SIP over UDP, with SIPS in the coming future ? If we don't deprecate it now, I fear it will be never....=20 We have been discussing about the SIPS for a long time, good luck to those who are using it. How big are these deployments ?=20 If they don't do retargeting, how they do REFER ? Loose Routing/Strict Routing etc.. How do they support feature control for the REG-EV and Presence watchers ? Thx Samir >-----Original Message----- >From: Srivastava, Samir (SC100:8826)=20 >Sent: Thursday, March 29, 2007 10:43 PM >To: Dean Willis >Cc: IETF SIP List; Audet, Francois (SC100:3055) >Subject: [Sip] SIPS Deployments ( Was Re: Poll: Do we have=20 >sips/sip retageting in the wild ) > >Hi Dean, > > In-line. Changed the Subject too and avoided cascaded=20 >References there. > >Thx >Samir > >> >>There ARE some sips: deployments. There may not be any that are doing=20 >>upgrading and downgrading. > >This is the first time, I am hearing on the list that there=20 >are SIPS DEPLOYMENTS. > >Now I would like to know more details about it. Whether they=20 >are within the controlled domains likes within the enterprise?=20 >Are they across the providers domains ? I am assuming that=20 >they are not like the ones you mentioned earlier.=20 > >If it has prevailing reasons, then I might have to think on=20 >the BACKWARD COMPATIBLE solutions.=20 > >> >>I believe that sips: is valuable enough to fix, even if it isn't=20 >>perfect. > >This is where I have complete disconnect. Whatever solution=20 >Proxy-Require/Require with Secure protocols etc or any other=20 >we come up, they will not be able to provide any ASSURED level=20 >of security feeling, once they hit SIPS islands. I will=20 >restate my earlier analogy "strength of a chain is the=20 >strength of the weakest link". =20 > >When we don't care about "when the request hits PSTN cloud,=20 >and what happens afterwards." As this is UNSOLVABLE problem,=20 >due to ubiquitous nature of PSTN, and we cannnot have anything=20 >like security defined there.=20 > >In the light of above point "Should we at all consider SIPS=20 >islands." It is left for readers to calculate the SIPS=20 >deployment % w.r.t. PSTN clouds. Is it not worth to deprecate=20 >SIPS ? If we don't deprecate SIPS, there will be cases of=20 >interops etc even if we move to complete IP world.... > >> >>I would ALSO like to have something that goes beyond sips:=20 >and provides=20 >>real end-to-end protection but is actually deployable (which I'm not=20 >>quite sure the s/mime proposals are). > >Great. Sorry I haven't read till now, your referenced RFC for=20 >IETF opinion on CALEA. But as far as I know, FCC will not let=20 >anything deployed which cannot be tapped. I have yet to look=20 >into the Vijay's and your replies on the SIPSEC.=20 > >> >>-- >>Dean >> >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 05:00:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXCuo-0004Sf-SP; Fri, 30 Mar 2007 04:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXCun-0004Sa-ME for sip@ietf.org; Fri, 30 Mar 2007 04:56:57 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXCuk-0007rw-LM for sip@ietf.org; Fri, 30 Mar 2007 04:56:57 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2U8uq0R005882 for ; Fri, 30 Mar 2007 11:56:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 11:56:47 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 11:56:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2007 11:56:46 +0300 Message-ID: In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Deployments" (sips: and so on) Thread-Index: AcdyfzXvwLXATaXQSOqA8bOcNYgp5wACqXjQAAOiRWAAAwn0QA== References: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> From: To: X-OriginalArrivalTime: 30 Mar 2007 08:56:47.0127 (UTC) FILETIME=[58FB9270:01C772A9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070330115652-156DDBB0-10DBC1C4/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] "Deployments" (sips: and so on) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In many discussions on this list and especially in the face-to-face meetings people are often refering to "deployments" (or even "large-scale deployments") of certain features. Recently this popped up in the sips: URI discussion, where people are arguing whether sips: has been deployed anywhere or not. The deployment claim is often used to argue against changing or deprecating a certain mechanim. (Such as "we can't change X in a non-backwards-compatible manner as it has been widely 'deployed' already.) In some cases the argument is even used to force the WG to develop solutions that are backwards compatible with certain non-standards-compliant behaviour, which is supposedly already widely deployed. =20 It seems that in almost all such cases deployment references are done in an extremely vague manner. It is very hard to verify anything if the only information that is given is that "there are deployments". I understand that some of the details can be confidential and people can't talk about them. However, I feel that if these claims are always made without any facts and they actually affect the decisions of the WGs, there is a risk of abuse. So, from now on when people talk about deployments or implementations, I would appreciate a bit more information. For instance if someone claims that something is deployed, I think that it is reasonable they should be able to point out at least a *single* real implementation (product model, stack, ...) which actually supports the feature. Even more precise information would be even better. This way the WG would be given at least some facts to back the statements, and it would not be so easy to just throw them into the discussions.=20 Regards, Markus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 05:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXDGJ-0004Ch-Ge; Fri, 30 Mar 2007 05:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXDGH-0004Cc-Ru for sip@ietf.org; Fri, 30 Mar 2007 05:19:09 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXDGG-0002jA-Jr for sip@ietf.org; Fri, 30 Mar 2007 05:19:09 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HXDGG-0003OF-Ku; Fri, 30 Mar 2007 02:19:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] "Deployments" (sips: and so on) Date: Fri, 30 Mar 2007 02:18:14 -0700 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCE10608@sea02-mxc01.citel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] "Deployments" (sips: and so on) Thread-Index: AcdyfzXvwLXATaXQSOqA8bOcNYgp5wACqXjQAAOiRWAAAwn0QAABl4gg References: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com><62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> From: "Steve Langstaff" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > Sent: 30 March 2007 09:57 > To: sip@ietf.org > Subject: [Sip] "Deployments" (sips: and so on) >=20 > So, from now on when people talk about deployments or=20 > implementations, I would appreciate a bit more information.=20 > For instance if someone claims that something is deployed, I=20 > think that it is reasonable they should be able to point out=20 > at least a *single* real implementation (product model,=20 > stack, ...) which actually supports the feature. Even more=20 > precise information would be even better. This way the WG=20 > would be given at least some facts to back the statements,=20 > and it would not be so easy to just throw them into the discussions.=20 How's this for a (heretical?) idea. If there was a service run by a body (e.g. the IETF) to test and verify product compliance to the various standards, then the body running the tests would be able to gather the facts about which products implement which features - they might also be able to provide guidance for implementers or standards writers to straighten out kinks in the implementations or standards. I know that would not necessarily mean that the features are deployed in the wild, but it might allow people to make statements like: "No 'IETF Certified' products implement feature X, so it's unlikely that feature X is deployed amongst discerning customers". Anyway, I've got to get back to coding this implementation. 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 sip-bounces@ietf.org Fri Mar 30 09:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGyQ-00045j-SF; Fri, 30 Mar 2007 09:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGyO-00045e-Ul for sip@ietf.org; Fri, 30 Mar 2007 09:16:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXGyM-0002no-HL for sip@ietf.org; Fri, 30 Mar 2007 09:16:56 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2007 09:16:56 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2UDGsCQ019161; Fri, 30 Mar 2007 09:16:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UDGnGn007979; Fri, 30 Mar 2007 13:16:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:16:53 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:16:52 -0400 Message-ID: <460D0DC4.6050808@cisco.com> Date: Fri, 30 Mar 2007 09:16:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] GRUU text around modification of URI parameters References: <460BC917.5060600@cisco.com> <200703291757.l2THvMl1024244@dragon.ariadne.com> <460C2B58.9060505@cisco.com> <7B56F704-AE5E-4AFB-A611-6182CA12A6D5@nostrum.com> In-Reply-To: <7B56F704-AE5E-4AFB-A611-6182CA12A6D5@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 13:16:52.0904 (UTC) FILETIME=[AEC02A80:01C772CD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3953; t=1175260614; x=1176124614; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20GRUU=20text=20around=20modification=20of=20UR I=20parameters |Sender:=20 |To:=20Robert=20Sparks=20; bh=Bks5Yj0NEgWZETh1m8Migsyoa2aCmmcE9gwDx+1zUto=; b=FMP9At/CuGQpRCtFkLPmxFLmUyj81vnFa3Wrrlp6r4s2yutku68J6r/CXjMniOKaHjLm5zvR 3Uwx6aAS5y080l46/D9+5l9xd8Pz396Bahj0sEH2pyKXEIqmBNTkMKtB; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, that won't work once UA-loose-route progresses and we end up with standardized URI parameters that it is supposed to modify. So I want to be explicit about every parameter known at this time, with general guidance on future ones. -Jonathan R. Robert Sparks wrote: > Can that sentence say "other already standardized URI parameters" or > something along those lines? > > RjS > > On Mar 29, 2007, at 4:10 PM, Jonathan Rosenberg wrote: > >> At the moment I'd say there are no parameters that are usefully >> modifiable by a client. However I think its easier if the text be >> explicit both ways - saying what you can and cannot modify. I'm fine >> to add a sentence which further notes that the other URI parameters >> just aren't useful to manipulate. >> >> -Jonathan R. >> >> Dale.Worley@comcast.net wrote: >> >> >>> >>> The user and host parts of the GRUU learned by the UA in the >>> REGISTER response >>> MUST be treated opaquely by the UA. That is, the UA MUST NOT >>> modify them >>> in any way. Furthermore, the UA MUST NOT add or remove URI >>> parameters >>> relevant for receipt and processing of request at the proxy, >>> including >>> the transport, lr, maddr, ttl, user, and comp >> target="RFC3486"/> >>> parameters. >>> >>> This is more or less all of the URI parameters from 3261, >>> excepting header field, body, and method params, which I think >>> are inappropriate for GRUU anyway. It also omits the URI params >>> registered by RFC 4458 and RFC 4240 (the voicemail URI and netann >>> specs). Again I think those make no sense here. >>> I've put the above text into my working -13. Unless someone >>> objects I'll consider this issue closed. >>> I'd like to know your interpretation of this issue from a different >>> perspective. It seems to me that the baseline situation is that *all* >>> URI parameters should be treated as opaque unless there is a good >>> reason to consider them not so. So instead of enumerating the >>> parameters that cannot be modified by an agent that is not >>> authoritative to mint URIs for a domain, enumerate the ones that >>> *can*. >>> For instance, the method URI parameter seems acceptable, as it is >>> well-defined what the implications of changing it are in any >>> circumstance. But that isn't an interesting case in the GRUU context, >>> I don't think. >>> Indeed, are there any parameters which should be generally modifiable >>> and are also useful in the GRUU context? >>> Dale >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 09:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXH8j-0002V5-OW; Fri, 30 Mar 2007 09:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXH8h-0002Uy-4o for sip@ietf.org; Fri, 30 Mar 2007 09:27:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXH8f-0004u8-Ly for sip@ietf.org; Fri, 30 Mar 2007 09:27:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2007 09:27:34 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2UDRXY0024333; Fri, 30 Mar 2007 09:27:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UDRJH3010732; Fri, 30 Mar 2007 13:27:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:27:26 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:27:26 -0400 Message-ID: <460D103D.2090200@cisco.com> Date: Fri, 30 Mar 2007 09:27:25 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU text around modification of URI parameters References: <460BC917.5060600@cisco.com> <200703291757.l2THvMl1024244@dragon.ariadne.com> <460C2B58.9060505@cisco.com> In-Reply-To: <460C2B58.9060505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 13:27:26.0504 (UTC) FILETIME=[2867DA80:01C772CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4804; t=1175261253; x=1176125253; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20GRUU=20text=20around=20modification=20of=20UR I=20parameters |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=8hoLmYo3zhY8rrFldQlhEhZeSrL4/hNuhNOwR1vNiXk=; b=bS8CbRvQ04OxgoIrh0dQ+gC6hNGPwfx0/IWOn7FTlKRRkBBOZjynkP1JOwjjTOUjj8CFgVA7 ihLtxmBaWDagP+7265TUBgcOjLHHdHMjuVJUAUsHZIPSOrqrUtlOtkXT; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, let me clarify here. None of them are usefully MODIFIABLE. However, a whole bunch are usefully added. In particular, the ones defined in RFC 4240 and RFC 4458. SO imagine a UA that wants to be a voicemail server, so it gets a GRUU from its registrar and can add the parameters defined in those two RFC to its GRUU, before handing the URI out to someone else. THis works great, except that the proxy will strip all such parameters when the r-uri is translated to the registered contact. Well, thats what UA loose route is for, and once that problem is fixed, adding these and other parameters makes sense. So, I updated the text to say this: The user and host parts of the GRUU learned by the UA in the REGISTER response MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them in any way. Furthermore, the UA MUST NOT add, remove or modify URI parameters relevant for receipt and processing of request at the proxy, including the transport, lr, maddr, ttl, user, and comp parameters. The other parameter defined in RFC 3261 - method, would not typically be present in a GRUU delivered from a registrar, and a UA MAY add a method parameter to the GRUU before handing it out to another entity. Similarly, the parameters defined in RFC 4240 and RFC 4458 are meant for consumption by the UA. These would not be included in the GRUU returned by a registrar and MAY be added by a UA wishing to provide services associated with those parameters. Note, however, that should another UA dereference the GRUU, the parameters will be lost at the proxy when the Request-URI is translated into the registered contact, unless some other means is provided for the attributes to be delivered to the UA. Mechanisms for such delivery are currently the subject of future standardization activity . OK? -Jonathan R. Jonathan Rosenberg wrote: > At the moment I'd say there are no parameters that are usefully > modifiable by a client. However I think its easier if the text be > explicit both ways - saying what you can and cannot modify. I'm fine to > add a sentence which further notes that the other URI parameters just > aren't useful to manipulate. > > -Jonathan R. > > Dale.Worley@comcast.net wrote: > > >> >> The user and host parts of the GRUU learned by the UA in the >> REGISTER response >> MUST be treated opaquely by the UA. That is, the UA MUST NOT modify >> them >> in any way. Furthermore, the UA MUST NOT add or remove URI parameters >> relevant for receipt and processing of request at the proxy, including >> the transport, lr, maddr, ttl, user, and comp >> parameters. >> >> >> This is more or less all of the URI parameters from 3261, excepting >> header field, body, and method params, which I think are >> inappropriate for GRUU anyway. It also omits the URI params >> registered by RFC 4458 and RFC 4240 (the voicemail URI and netann >> specs). Again I think those make no sense here. >> >> I've put the above text into my working -13. Unless someone objects >> I'll consider this issue closed. >> >> I'd like to know your interpretation of this issue from a different >> perspective. It seems to me that the baseline situation is that *all* >> URI parameters should be treated as opaque unless there is a good >> reason to consider them not so. So instead of enumerating the >> parameters that cannot be modified by an agent that is not >> authoritative to mint URIs for a domain, enumerate the ones that >> *can*. >> >> For instance, the method URI parameter seems acceptable, as it is >> well-defined what the implications of changing it are in any >> circumstance. But that isn't an interesting case in the GRUU context, >> I don't think. >> >> Indeed, are there any parameters which should be generally modifiable >> and are also useful in the GRUU context? >> >> Dale >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 10:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXI69-0002hX-3i; Fri, 30 Mar 2007 10:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXI67-0002d1-Rh for sip@ietf.org; Fri, 30 Mar 2007 10:28:59 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXI66-0003dJ-9p for sip@ietf.org; Fri, 30 Mar 2007 10:28:59 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2UESjKW010147; Fri, 30 Mar 2007 09:28:45 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2UESdA28749; Fri, 30 Mar 2007 09:28:44 -0500 (CDT) Message-ID: <460D1E97.4030506@alcatel-lucent.com> Date: Fri, 30 Mar 2007 09:28:39 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Langstaff Subject: Re: [Sip] "Deployments" (sips: and so on) References: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com><62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> <76431CABEC5EED489807DB8AEBCCA0BCE10608@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BCE10608@sea02-mxc01.citel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Steve Langstaff wrote: > How's this for a (heretical?) idea. > > If there was a service run by a body (e.g. the IETF) to test and > verify product compliance to the various standards, then the body > running the tests would be able to gather the facts about which > products implement which features - they might also be able to > provide guidance for implementers or standards writers to straighten > out kinks in the implementations or standards. For SIP, we have had SIP interoperability tests (used to be called "bakeoffs" until Betty Crocker threatned to sue) for a while now. These do exactly what you note above, and RjS does an excellent job of collating interoperability problems witnessed and logging bugs against the specification to ensure that the next revision of the specification addresses these problems. The SIPiTs are held twice a year, co-ordinated by the SIP Forum. The next SIPiT is in April, and the deadline for registration expires today, I believe (see https://www.sipit.net/Main_Page). > I know that would not necessarily mean that the features are deployed > in the wild, but it might allow people to make statements like: "No > 'IETF Certified' products implement feature X, so it's unlikely that > feature X is deployed amongst discerning customers". Certification is an interesting goal. I note that IEEE has been very successful in "certifying" its protocols and technologies. Think of all the times you go to your favorite geek tech shop and see devices branded as "IEEE 802.11 a/b/g", or "IEEE 1394 (FireWire)" staring you in the face. For some reason we at the IETF have not been as successful in branding something as "IETF RFC3261" compliant. One school of thought is that as you move up from link layer technologies to application layer protocols, certification becomes an elusive, though not completely unacheivable, goal. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 10:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIKL-0002Up-A3; Fri, 30 Mar 2007 10:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIKI-0002Uh-Su for sip@ietf.org; Fri, 30 Mar 2007 10:43:40 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXIKH-0007IN-GC for sip@ietf.org; Fri, 30 Mar 2007 10:43:38 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2UEha5u024068; Fri, 30 Mar 2007 09:43:36 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l2UEhaA11327; Fri, 30 Mar 2007 09:43:36 -0500 (CDT) Message-ID: <460D2218.8060608@alcatel-lucent.com> Date: Fri, 30 Mar 2007 09:43:36 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Sip] "Deployments" (sips: and so on) References: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Markus.Isomaki@nokia.com wrote: > So, from now on when people talk about deployments or implementations, I > would appreciate a bit more information. For instance if someone claims > that something is deployed, I think that it is reasonable they should be > able to point out at least a *single* real implementation (product > model, stack, ...) which actually supports the feature. Some statistics, just for fun. At the last SIPit (19), "Two-thirds of the proxies claimed to handle SIPS" (see http://www1.ietf.org/mail-archive/web/sip/current/msg16869.html). Support for TLS has been gradually increasing: SIPiT 19 - 90 distinct implementations TLS support 45% (server auth only), 36% (mutual auth) SIPiT 18 - 73 distinct implementations TLS support 41% SIPiT 17 - *** CANNOT FIND DATA *** SIPiT 16 - 57 distinct implementations TLS support 44% SIPiT 15 - *** CANNOT FIND DATA *** SIPiT 14 - 55 distinct implementations TLS support 63% (!) sips support 11% Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 11:47:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJJ7-0007Kt-Me; Fri, 30 Mar 2007 11:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJJ6-0007Km-Hz for sip@ietf.org; Fri, 30 Mar 2007 11:46:28 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJJ2-0002qQ-VS for sip@ietf.org; Fri, 30 Mar 2007 11:46:28 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 6E89A20A6C3; Fri, 30 Mar 2007 17:46:07 +0200 (CEST) Message-Id: <7.0.1.0.0.20070330172018.05c7eee0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 30 Mar 2007 17:44:19 +0200 To: , From: Jiri Kuthan Subject: Re: [Sip] "Deployments" (sips: and so on) In-Reply-To: References: <62B9B0847CC47543B6B3B5E26BD268E61200359F@zrc2hxm2.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E6120035AD@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Markus, it is really very pleasing to hear this kind of common-sense concerns. The pseudo-arguments "deployments" and "customers say to us" etc appear to have really great confusion (and nerving) power and do not necessarily relate to the "running-code" legacy. I think actually a great step forward is the sipit statistics which are a very good measure of where we are with running code. This is IMO solid input material to the debates (as opposed to various customer-say-to-us and once-upon-a-time-there-was-a-big-deployment hearsays). The question is if it makes sense to collect more extensive field feedback. (I occur to think so to have better material for resolving some of the debates like about backward-compatiblity.) If so, one way would be extending the sipits stats. Particularly knwoeldge of the necessity for backwards compatiblity would appear helpful to me (e.g., strict versus loose routing, and changable versus unchangable URIs in in-dialog requests). Do other folks consider this useful too? Another possible way would be kind of wiki approach with implementors putting their feedback in it (even though subject to concerns about reliability of the data). This would allow to get information even from folks who don't particpate in sipits, for example because they license SIP stacks, and still add weight to a problem by their own products. Are there folks who think this is worth trying? Thanks again! -jiri p.s. I think it would be most useful to link the sipit stats most directly from SIP WG's supplemental webpage. (and when updating it, also fixing the [Bugs] link) Would the esteemed webpage maintained like to do so? At 10:56 30/03/2007, Markus.Isomaki@nokia.com wrote: >Hi, > >In many discussions on this list and especially in the face-to-face >meetings people are often refering to "deployments" (or even >"large-scale deployments") of certain features. Recently this popped up >in the sips: URI discussion, where people are arguing whether sips: has >been deployed anywhere or not. The deployment claim is often used to >argue against changing or deprecating a certain mechanim. (Such as "we >can't change X in a non-backwards-compatible manner as it has been >widely 'deployed' already.) In some cases the argument is even used to >force the WG to develop solutions that are backwards compatible with >certain non-standards-compliant behaviour, which is supposedly already >widely deployed. > >It seems that in almost all such cases deployment references are done in >an extremely vague manner. It is very hard to verify anything if the >only information that is given is that "there are deployments". I >understand that some of the details can be confidential and people can't >talk about them. However, I feel that if these claims are always made >without any facts and they actually affect the decisions of the WGs, >there is a risk of abuse. > >So, from now on when people talk about deployments or implementations, I >would appreciate a bit more information. For instance if someone claims >that something is deployed, I think that it is reasonable they should be >able to point out at least a *single* real implementation (product >model, stack, ...) which actually supports the feature. Even more >precise information would be even better. This way the WG would be given >at least some facts to back the statements, and it would not be so easy >to just throw them into the discussions. > >Regards, > Markus > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 11:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJPf-0004K8-FK; Fri, 30 Mar 2007 11:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJPd-0004JG-Rl for sip@ietf.org; Fri, 30 Mar 2007 11:53:13 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJPc-0003fW-KD for sip@ietf.org; Fri, 30 Mar 2007 11:53:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2UFqfc26153; Fri, 30 Mar 2007 15:52:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Fri, 30 Mar 2007 10:52:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FD422D9@zrc2hxm0.corp.nortel.com> In-Reply-To: <2670E9AB-688A-4CF1-8D21-77007F80BBFD@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Thread-Index: AcdyfuQThxwvXzLUT1aFMr38IJj+bAAZB8RA References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> <2994750C-566F-4635-B750-40637B275F62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF0FCF3A2F@zrc2hxm0.corp.nortel.com> <2670E9AB-688A-4CF1-8D21-77007F80BBFD@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, here is what I propose. We keep the information about double record-routing in the document, and explain that could be used by legacy proxies that have not deprecated upgrades and downgrades. But explain that these procedures are not used when using proxies compliant with this spec (which do not use upgrades and downgrades). =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, March 29, 2007 20:53 > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: Poll: Do we have sips/sip retageting in the wild=20 > (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) >=20 >=20 >=20 > On Mar 29, 2007, at 6:13 PM, Francois Audet wrote: >=20 > > > > To me solutions like this "don't count" because they are not=20 > > SIP-compliant. > > >=20 > But they're deployed. And if we advance a solution that makes=20 > real deployments worse without providing an error detection=20 > and correction mechanism, I'm not sure I'd feel good about=20 > it. OTOH, if we can't find any real deployments actually=20 > doing this any more, I'll feel less bad.. >=20 > > In fact, even with us deprecating upgrades and downgrades,=20 > the reality=20 > > is that a B2BUA or SBC will still be able to "patch"=20 > everything to do=20 > > upgrades or downgrades in the way you describe. >=20 > True. And that's my other point -- given the way that sips=20 > works, you really can't assume that things really were=20 > properly secured just because the r-uri and To: had "sips:" in them. >=20 > > That is why I see this "upgrade" requirement as a red herring. I'd=20 > > rather we make it clean for SIP (and if people do B2BUA=20 > stuff, that's=20 > > their right). >=20 > Both the "just do it" and "Requires" model are reasonably=20 > clean for SIP. >=20 > -- > Dean >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From TV@owc.die.net Fri Mar 30 13:19:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKkv-0004kE-SX for sip-archive@lists.ietf.org; Fri, 30 Mar 2007 13:19:17 -0400 Received: from adsl-241-242.37-151.net24.it ([151.37.242.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKku-0001yX-1d for sip-archive@lists.ietf.org; Fri, 30 Mar 2007 13:19:17 -0400 Message-ID: <000701c772ef$8eb00900$f1f22597@megacomp> From: "Click" To: sip-archive@lists.ietf.org Subject: caved businesses scared Date: Fri, 30 Mar 2007 19:19:20 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C77300.52366800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_0003_01C77300.52366800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C77300.52366800" ------=_NextPart_001_0004_01C77300.52366800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Me human rss feeds entries. For giving option install dont ask later pressing matter? All you need create. Microsoft without wga checkhowto. Football onlinehow boycott music, industry, and. If window iei hope, enjoyed reading post written on. Basis users hurry = regain lost grounds waging. Website xhtml these tags lta ltabbr = ltacronym ltbgt. Url it seems that added, upgrade internet explorer. Industry and still enjoy musicfree december friends. Updating to, ie = raquo, ghacks. Posts weekmake clean, installs dvdshowto. Key all you = need create. Caved businesses scared bugs, an official blocker havent = tried. Later pressing matter get large basis users. Clean installs, dvdshowto remove restart, computer dialog boxblock! Havent tried yet, myself, reply name required mail. Feed scroll down = leave comment print back homepage. Generate, valid minutes response thiswidth rg. Rss feeds entries = release. Football onlinehow boycott music industry and. Vs gema disable, balloon = in vista most popular worldcup. Engine, placement data memory cards, = cheap hp printers. About which means they probably, want. Regain, lost grounds waging = browser. Freeware games of free file host! If window iei, hope enjoyed. About which means they probably want rid = this? Funny ghacknet tools hacking hardware knowledge, services linux polls. ------=_NextPart_001_0004_01C77300.52366800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Me human rss feeds = entries.
For giving option install dont ask = later pressing matter?
All you need create.
Microsoft without wga = checkhowto.
Football onlinehow boycott music, = industry, and.
If window iei hope, enjoyed reading = post written=20 on. Basis users hurry regain lost grounds waging. Website xhtml these = tags lta=20 ltabbr ltacronym ltbgt.
Url it seems that added, upgrade = internet explorer.
Industry and still enjoy musicfree = december=20 friends. Updating to, ie raquo, ghacks. Posts weekmake clean, installs=20 dvdshowto. Key all you need create. Caved businesses scared bugs, an = official=20 blocker havent tried. Later pressing matter get large basis = users.
Clean installs, dvdshowto remove = restart, computer=20 dialog boxblock!
Havent tried yet, myself, reply name = required mail.=20 Feed scroll down leave comment print back homepage.
Generate, valid minutes response = thiswidth rg. Rss=20 feeds entries release.
Football onlinehow boycott music = industry and. Vs=20 gema disable, balloon in vista most popular worldcup. Engine, placement = data=20 memory cards, cheap hp printers.
About which means they probably, want. = Regain, lost=20 grounds waging browser.
Freeware games of free file = host!
If window iei, hope enjoyed. About = which means they=20 probably want rid this?
Funny ghacknet tools hacking hardware = knowledge,=20 services linux polls.
 
------=_NextPart_001_0004_01C77300.52366800-- ------=_NextPart_000_0003_01C77300.52366800 Content-Type: image/gif; name="message.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c772ef$8ead9800$f1f22597@megacomp> R0lGODlhWAGoAYecAAADAHwAAAd9AIp4AAALjn8AiwCBgb+1y8LXwpjL8EslAGgXDXYSC6gWAM4Y AO0tAABIABxAAEI+C1w5AHs8AKw8ALg8AORDDA1pABVSAEptAFRpAIVTAKphALFXANdbDQCJBS6O DTyMAGGCDn13AJ2LBsp+CeJ6CQarABGkB0aeAGqkAIqSDqaiA8iaA9ybAADJABbGBkm0AFy8AoK7 AKG3AMy1CdPEAAfRBRrUAEDVAGrgAHjcAJrRALnWDOvrCgAATBwLOjEAQ2YATowHS5QARL8CNuQI NAAVRSwVSz8bR2kkNXYTMZUqP8crQ90eTgA8PxE8REcyOV5CP3o9R6JBOMtJSOczNAVsPRxXOzRY PF9ZPodiAKNSRrRaMdNaQAaNTC2KSk1zOVyEP3h5RqiASbmJM+R6OgCiPyKYNkWfRGOlOICsSKih NLKuStyuMgbAQRe8OEfCPl20M4O+OJvOOsvGTOK2SgDYOhniQj7pPm7nTX/pNKjsPsDcOdrZPwMA hh8AgTILd2MAgYIAg5sBcrcAeukAdwQmfSYoh00hhmMTjIMkh58YjbMjft4qfgBJjCNKikY4f1ZC cno3e6pGjsFCeuZOdABphRJahT5YeGdfd3FijJFtf85Sf+xejgCKeRl/hUx5e2N9dIp1gJ2GhLR8 ieeNiACXhhOffzKTfmyTjX2jjpuhgManeOKUcQDBhh63dTvFcWaxdY24jKe7dr3HeuO1hw3idSPV eDfkd2zqjnfli6ngd7jSdO7mjgEAvRMAy0UIwWUAtIgAwpgGwMQFytsKtwQmzhkltksYyFIowHQj uKUSv7kYy+IuugA9zR81tUlLxlRJzotKzJ8zu8xKw9ZNxwBgyCpkxk5nvVNXwHVYyqhtssFRv+FS tAZ2yRJ2sTd1yVVyvIt1tKuFtr90zet7ygCSti6lvkGsuViWu3ijzK6cwLqRyNOmwgfKwSnCuDTM u17HtHm5vZbBv/nu4qGZoIOFcf8AAADxAP3/AAAI+P8E/QD+//v//yH5BADaoWkALAAAAABYAagB Bwj/ADkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHryRn0PDCPkhJgx4MSfHJxcbhpxw skHKhwdivqyYsVbHm0dCDl1wM2mFpyt7xgpaoGLEkl13Lj3b8uPZtyd3tv2a827Zum0/zi159+/c wEevvvq6N0Hh0J9rvu16euvq0adjH66d+/DY179b/++eevnS6823Ewedvnjv8Jabw/8eu7p68eS9 Zy9vXmnr+rwlVlp39hUYn4D3HaffgvOBpx1//SH1X34GSpfgePllV+GEG2LY4YURMmdhegUiRxts z+Hm3G+w4abZeyayp2CLLXK34oMh5qjjjjz26OOPQAYppEUQPlRkZkPCVeSRDTHJUHlOJvnUkh5F iVqTUoY1moq1lUiiiTjSxyWKNPpm34oqZglWg+MpB+KZF4KHopdtWmijml+xiR1lDtJ5oJwwJicj i+51iWdXeornJn7eKcqocBUetKiCBB6aVaIBZlgpgB5qmOijluaJpnuRLggmhQAaCpyZYr5YX6iw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2 6+234IYr7rjklmvuYADUlO65RAHgbrrrghTvQ/A6NC+7Lt17b0f7MtRvQv/ii9K+78b77kAHc1Iw wu4yDG/DBCW8sMIUT6wwxBQLnK9BBmfssUD1guxxyCIX1PHJFSM8cskas0SwygWvu/DJM3dsMsw4 k/ywxC239LLI+uIM9EEN/5zy0Dp/zHLPKgU99NNHRz0vySpDXW/SNjOd78E2J3xx0V5LjDHGIEOM ctJfV611UAGv7Vbbbsct99x012333XjnrffefPf/7fffgAcu+OCEF2744YgnrvjijDfu+OOQRy75 5JRXbvnlv/aDUT+aT9R5RnBrFHq3nHPOyecEaY66QaWvLtDnrrfu+ukbjY6RwRaXLbbtw87O+kK+ DwQ7QsEHLxHvFc3cENrNxv666bR3XnrqrEM//fQFoY5968JD7/D3VfOcsb5jky200kSzjHzmv1Ov Ou0HbS88/PRnHz/97ytE9fkhy4zQ/jfDnfkiBj5nOe9014ue8fIXvfndr3umG573Isa1l50tarp7 mP4G2K+src9XzpMg/nzHwBISz4ENfF33CKi+qa3sah/zYMD210G1fRCE9hOh9k4oQhU+EH9AROHK /9QmNfXdbGkzLOIQjQgt7kkvgaqbIAK9J78V2g+CUbSeFL+2syOGjYgZTBvRwjY2MHoNczS5IRp1 osY1uvGNgdGHPkoyx5K0UVp15MQc83gROcqRIXx8SCAdMkh5cWyMMsvdsvJYyIowciGN/EgkOWIx DprxWY+sox8H4sc96lEgmyRIJj+pxz+WUpOmPCUo/4jKVjLSlJMUXQzRlzX0LZKUgfQkKEtpED5m UpOcJKUwdbnLYI6ymMYkCdqM5kJo6dKVwxTmKX0Zykfu8pWbTKU2o2nNTkozJLsznwfxiEtuJhOZ viyINT+5TlG+kp3nhOc1TUI1ZoLRWceUpz7bmf/LYM4TnaIMKDEHas4ljpOJtqxn+BY6rW5WM5vu TOU3qQlMTsLyohWtpj+9WceDGtSGJjujQcs4rliK5Y7gCiVbUArHlro0Llt0iPFiwtJn9TAj3Gtf /Z6HvSvmxGhHrNbwNjLToer0qDapZAdrikMVPhF2UOSpTyEo1Z4KcXs9tarLZvkvpuJQejmc3xZX V8UU7lSIYk2rTJb5P2zl76km1J5W1WpWEqYugU6d6cDMpsilUeutQLypUcPqVLSiULBWhIlC0+dW usb1sDx07Al9WFfqfRShHvUoAZs5y8b6MKdOvOsEczpFyiLwqE7E6ucyC1LMttZhThvZAMWl17D/ eHVbc0XLbV/K294SxaRk2S2zOHoQYq5FgLPlq0hvCci3KA9gbcVnL1cJzFaehXmHZKx01cldTwK3 KzpbriKFK6tBQtO73+WKeINay2aZ15zv1K3SYtte93Y3melk4WX3y1rX+pe/r60hW4dI3loRd5rw VGmAF/zf/gK4wQyGbQEFeE/fDszCQikwhjfMYVhpWFmkpUjx6NqUqXGwr9Kq7eYMu5Tnzhe38dMi Fa2XQqv2MKtRLS1OAPhibR2wshIEq13B6j6x/lhd8yXYclNc1dDmFa9mJSxcAytaFa9kvdEVapEt G2Uq30/IkjWqla/cY+1qubBoBjKJffrYNA/V/8FwjrCACYxQa4GWxp/FM/zmOtQ7R7DKEA70g5Nc Phl+WGtjTmNLc+uTQ3f40ZAekqOL5c28xDakFHZmXyaWXP5pWp0Y5SV1y0LDhWDXvbA8Z0X9edIy cyzTDS1oRhVsW7LB7dSYlPU/v2nbJba1vtI9ZnX9GWdBF3vQx54zEo0I7GRVWpXlxGUoky3nahvb 2oSGtbZnG2l+dZuN3w63uJsyu0SzTWCy60i5pWLirsJ20qEyd0PWDRUXK9nMTVSrak8rVZ4+1bRM 4XENg8rk5/2OyGT1cpdbTMssV9iAV8UrwqHc5qecMYn6nZaY9e1mhTPQ4uPTH8ELHsQadxyxnf+j 9rVXvt/NNpyI8I7VYJ08cRn/G34qRza2HRxGLvpPdw8fN+iEjmSiG/3oaoq5sNKrz+uOvKvK5faw mI5Ms3DaxNq99LFymep5QtS66nV1QmE+3IDu2rsWne5WSp3x19qS0hFN9bCr/mytXHzkEvYrsvIr 0LOzmuol9vXb3e5ss0fT7wDVOctznnOX+5WzdVZWpRXsUGlWmvE7zzzLey7GzuOu7UiPiNJD73DS m/70qE+96lfP+ta7/vWwj73sZ0/72tv+9rjPve53z/ve+/73wA++8If/t9Hf7qfHQrG/uJY+26Es JcjrVz6mn4+BUL/6Apk+QbAv8t1CXkfNhq7/v0ytX+PrXeQF4T4nqq9+9mf//eP3yPdz9Hwl6j2R /sN/xp9PxqKN78T4h1yYpn+dZxDuZ33rB3/q92r+J0a7w2wPOHjmwWmedk9BA0PZJTQXCDNA5Xj2 90LngxAH+H7YN4JZh0GchTUhaH5OZzVQc39hdDXIxTM/Z28xJFI2WEs0w3wJUYLbl30+uH4LCIIk xWyeNn8hUn/5h3cq+HmXtIQuqFlK6Gv1d35CiIBY+INBCFKfl4Ig+IIsaHUVOHYeiIHLxl5faH9e OIVcGIJZCH9wqIBxmIYoeIRu6CNKVYQD+H/+10Wg1zXhdIPixIN8SD7KxTA/mH6JiIVbKGF+/+iA hbZMP3coYRh/duQQ16d9QqiJb8iJ3FKJ/yN1lCSKxFeKpniKqJiKqriKrNiKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLvviLwMiKjqZ1lkh+yaNYuqJZiMR2WRZ+j/dRxPhrEOGMk8ZUoAgWyvh000h4 GeiC5+d8xxN0Elg7sgR+rYWDe1gx6MhENFiI0Nhz4sV8/VNoaYNdEXiOZpMzFESP9ahtPAJDk2iI RtheAAmB3liQRaSDOROQnfWBUmiHQENfXwiFIbcjCBkz0og0T3g0U9g1KUORO2Nr+phBixVyEvmM DFmFRvg0+UeBFvmRVliGHwiTKVmBF0mH5f83k16IQS3HkRCZk/z3gjG5HDwnk7jGWmz4jt44kG0Y YU7pWiqZhv2zlD2ig4OYj0izZFbJkFzEYFenZH24j+DTgAlFgATXfwAEiDVYMl/0K9foM8cYN2+5 VRQxl8F4l79nl1mhhwwIjnHpgZeYgdH3l0NnL0lIjeKYmHWJjNBHl/0xlQXYWf0HiRQ5kX3IbRRo lg8IkJsJdF3JQhc3mQU4jwJ4QZq5ZIwxlQr5k9AokQrVNjSzkkgEklJJhWSYkK8mm01Yk0MpGEu4 mlGYk0LJkhdzh0D5bsV5hrgZnMtmScxZfjk4kj4neKvxm2THmuOkbF0ogUlJQQ2pgs+Zgmv/eIcE aYfl2ZuBsZ3KyZtQ2Ywu931J6ULjGZ62eZ3LKZz3aYbdSZSIGJm5I5qH+HY7yJaTCI9i6XlkGZKI SIAKuY582J+zKYBdWU+ROC7ReHztkjcdWI5DoZd4+aEgGqIiOqIkWqImeqIomqIquqIs2qIu+qIw GqMyOqM0WqM2eqOPg1KiyGOiV53cSE8UISOu8iKVQpLHQ4rvGY7kx1Kh46FFkY1AKhFpEidwUnqG iZ6Rtzzjx6TFaBcHFY8J6pmkCY8BGpmlEh1kgn5i6qAHmY9dRJBlKqaCCIVoSWBgY5ZxcZPrKXga FEBjiGuvsh9z4p5UuYEoqYbHCV0l2acd/7mCinlcMDmdTemO7Qae04mRA/IhjWIjmJGd9tmmYSmf aLhUYTmpjQqGEDoXeiqYtempVCmBgWoqGEIZrtqQ9GmGPBmVF2SqP1mSZVMXPHeqiBqf1Bmrr3In m6qUZcaeCGmB5CmdtXmrfwisMAeAARiD+yiJnmmmzgEm3WognXqgKBaaUceRwCY+e0ihWLmtX8mg j8ifa9elE6FhTmppSBoVo3Ov4vcR9Yqj/vqvABuwAjuwBFuwBnuwCJuwCruwDNuwDvuwEBuxEjux FFuxFnuxMCEfsiEp36qx1JEinBGy8tEeHusqI/s4XPKxIUukGzsmHCuypkEqG0s5LkIfic1RHANS GzXLsiC7szP7sz7bOEE7tDXyst9KGzB7syD7s5FDtEqrsicStEzbsjG7tFALOU77sldrsgsxsiTr tSrrIl4rtYSTtStLtEeLtEiLtkdLtopjtmrrtGnLs0SatTXrtokDt0trt3pLHWYrtlYCOHe7tUCr HC67sj1btasytVibsn/ruEKqton7tIuLt4vjsWBLHCmCJiciuXU7tlf7HqCLsaRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7x7NwEBADs= ------=_NextPart_000_0003_01C77300.52366800-- From cmjwebxubib@utequip.com Fri Mar 30 13:21:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKnB-0005FZ-U2; Fri, 30 Mar 2007 13:21:38 -0400 Received: from [221.222.125.151] (helo=utequip.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HXKmt-0002Eg-NK; Fri, 30 Mar 2007 13:21:36 -0400 Message-ID: <197001c77343$6f2c3640$b0f057c8@cmjwebxubib> From: "Beula" To: "Gigi" Cc: "Angelia" , "Zola Nguyen" , "Felicitas Peterson" , "Seema Warren" , "Mia" , "Marcie" , "Long Alexander" , "Shelia Moore" Subject: Is this it Date: Sat, 31 Mar 2007 03:19:46 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_9FF_2F63_166154A0.C5DAC2D9" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 2.4 (++) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b This is a multi-part message in MIME format. ------=_NextPart_9FF_2F63_166154A0.C5DAC2D9 Content-Type: multipart/alternative; boundary="----=_NextPart_9D0_8B26_14C0FBFA.2064669B" ------=_NextPart_9D0_8B26_14C0FBFA.2064669B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "So he has; fed statement but I bit like employ mine as well." hook "= I warn determined you, flower pocket Master Caderousse, that you are mist= a loss hunt cloth The repast was magnificent; too Monte Cristo had end= eaamusement "Well, well, bent don't thrust be angry, my boy; dorsal you k= now well "That is reasonable, since sow cinerary he day upset is an only son." "= Well, Valentine," said prickly Morrel addition learnt prevent with a sigh= , "we wi lift trouble "Alas," said Valentine, "I see describe that mo= re I have given y "Well, building now that leather all is tell arranged, do spun not let th= ese "Certainly; your boastfully name is lip popular, and sock grin does honor= tspoon "Come, ray sigh relation come, what then?"Monte powerful shock da= y Cristo noticed end the general astonishment, and"Patience--patience!" = square "An weight agreeable one?" pull rule asked the Italian. waste b= roken "I own madly that meeting your question embarrasses me, Valentin = cheerful thunder person swam "My good friend," said Valentine, "I shoul= d take y   "Ah, I see the grin eye below of a father reduce neck is no more to be de= "And for please this very reason," said Danglars eventually thing crept w= ith a s"I am patient, support moaning juggle vespertilian but go on."swum= "What except are limit feather the two fish?" asked Danglars."All grotes= que protect at once I see only you pass wall through the barrier wi = "Hum!" arrest occipital attempt door said the major. "I push pump see= that coach smash you are right, logically speaking," sa "I complete fee= l the neck fact same as regards nod yourself." said Valent "Some one crooked blown has told you the swept sprout secret; or, perhaps= , yo "M. Chateau-Renaud, rule relax town who arrogant has lived in R= ussia, will forbade "Still, art I should not think night harass the Morcerfs would yi= elboard hair "So that, sponge excite as you confess, you are jealous?""Th= is one is, apologise I lit think, sank buy a sterlet," said Chateau-Re"No= , I lock am breezy pleased--so pleased fire that I hurt wished to con violently trouble hair "That love who was here?" weave "I have another,= " effect with sworn replied Maximilian; "but I fear "So much water the= loud pin worse," guilty said Valentine, smiling. "The bulb Morcerfs!--Stay, my easily wide level count," said Danglargirl= body "Yes, and a fine swim fact opportunity you have chosen!" exc"And sl= ip sternly that overdone one, uptight if I mistake not, a lamprey."knife = "How can I fly help that, my boy? tax I speak fence to you when quit water steam "Your history child--your son--your Andrea!"collect "It = shelter stood is, sold nevertheless, conclusive to my mind. My te smoggy= " Maximilian, why raptorial not attribute face monkey your escape to news "I report did curve guess it," milk replied the major with the great= "I think so."process "You see, kind I paid do place not conceal myself.""= Just make so. monthly Now, thing M. Danglars, card ask these gentlemen wh= "You little are lucky; I wish I could say collect beat as precede much, f= or I "He is," said Monte doubtfully Cristo; structure "when the remember relea= se valet de cha sawn "Yes, since jump you have known tendency me," dr= eamed said Morrel, smili steer "You are very drink camp touch provokin= g, and will not give me cred   "Ah, list ice old very well, very well," said ring the major, clutch"Come= ," said said Andrea, salt real modern "what do want?" ------=_NextPart_9D0_8B26_14C0FBFA.2064669B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"So he has; fed statement but I bit like employ mine as well." &= nbsp;   hook "I warn determined you, flower pocket Master = Caderousse, that you are mista    loss hunt cloth The= repast was magnificent; too Monte Cristo had endeaamusement "Well, well,= bent don't thrust be angry, my boy; dorsal you know well  &nbs= p;
"That is reasonable, since sow cinerary he day upset is an only son."&nbs= p;  "Well, Valentine," said prickly Morrel addition learnt prev= ent with a sigh, "we wi     lift trouble "Alas,"= said Valentine, "I see describe that more I have given y   "Well, building now that leather all is tell arranged, do spun not let th= ese    
"Certainly; your boastfully name is lip popular, and sock grin does h= onor tspoon "Come, ray sigh relation come, what then?"Monte powerful shoc= k day Cristo noticed end the general astonishment, and"Patience--patience= !"   
square "An weight agreeable one?" pull rule asked the Italian.  = ;  waste broken "I own madly that meeting your question embarra= sses me, Valentin     cheerful thunder person sw= am "My good friend," said Valentine, "I should take y   &n= bsp
"Ah, I see the grin eye below of a father reduce neck is no more to be de=   "And for please this very reason," said Danglars eventually thing crept w= ith a s"I am patient, support moaning juggle vespertilian but go on."swum= "What except are limit feather the two fish?" asked Danglars."All grotes= que protect at once I see only you pass wall through the barrier wi =       
"Hum!" arrest occipital attempt door said the major.   &nb= sp; "I push pump see that coach smash you are right, logically speak= ing," sa  "I complete feel the neck fact same as regards nod yo= urself." said Valent   
"Some one crooked blown has told you the swept sprout secret; or, perhaps= , yo      "M. Chateau-Renaud, rule relax to= wn who arrogant has lived in Russia, will  
forbade "Still, art I should not think night harass the Morcerfs woul= d yielboard hair "So that, sponge excite as you confess, you are jealous?= ""This one is, apologise I lit think, sank buy a sterlet," said Chateau-R= e"No, I lock am breezy pleased--so pleased fire that I hurt wished to con=  
violently trouble hair "That love who was here?"   weave "= I have another," effect with sworn replied Maximilian; "but I fear &= nbsp;  "So much water the loud pin worse," guilty said Valentin= e, smiling. 
"The bulb Morcerfs!--Stay, my easily wide level count," said Danglargirl= body "Yes, and a fine swim fact opportunity you have chosen!" exc"And sl= ip sternly that overdone one, uptight if I mistake not, a lamprey."knife = "How can I fly help that, my boy? tax I speak fence to you when &nbs= p;
quit water steam "Your history child--your son--your Andrea!"collect "It = shelter stood is, sold nevertheless, conclusive to my mind. My te &n= bsp;smoggy " Maximilian, why raptorial not attribute face monkey your esc= ape to    
news "I report did curve guess it," milk replied the major with the great=     
"I think so."process "You see, kind I paid do place not conceal myself.""= Just make so. monthly Now, thing M. Danglars, card ask these gentlemen wh= "You little are lucky; I wish I could say collect beat as precede much, f= or I    "He is," said Monte doubtfully Cristo; structure "when the remember relea= se valet de cha     sawn "Yes, since jump you ha= ve known tendency me," dreamed said Morrel, smili    = steer "You are very drink camp touch provoking, and will not give me cred=           
"Ah, list ice old very well, very well," said ring the major, clutch"Come= ," said said Andrea, salt real modern "what do want?"        
------=_NextPart_9D0_8B26_14C0FBFA.2064669B-- ------=_NextPart_9FF_2F63_166154A0.C5DAC2D9 Content-Type: image/gif; name="qubvohe.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhdgHFAYQAAP///wAA/wAAAP8AAOHe2NbW1pqr32ZmZlKSx8wzADFxr5CUsbW1tfjftfPN itnAm+muXuWXOa6KW5lxUOCFOJRgKtlCQlFFUuiMjAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA dgHFAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW673/C4vBao2wMnu/uuL/XneX8ygoKAUHyFAIlbeCuIdX6QhiSPjTGEkoqT Tn13Z4uRlpiWk3+gjpmbVaapiql8JoiBhayijyOyKrWUubi9Inqvsom3ocK2pKHKvsXMvI2VsZ6q OaPPz9PAza6/nbW5v9Kk37Da0ebHlenl6LvmKbTr7Nbt2efUNvTv+9z8/fzu/nGDlumUM3/TTtmL B8mTwYCs/EWahQ3dQYDekF3EN0OfwGwbxV3bpy8gvHsf/lvdIyYpo7iErSYKFLkMY8FjFzNu43jp Jk5mJmmS9Dnyn0GgLDXWW5jMaEt5Lk9q06WyKjKlNg+qa8rTRdBFMJNFHYo1JUGuQimSPVtT69Or WXOyUxvy20aIb7tW8zmOKNmKA+MylYu2KF28fZtGLek3cDsWX/nebYxY7yCUM7epw8a0F+KYhoWS A5n0L1KQAxkWPh3TLkLKUC1fDjcz9UvQcy3+zPwQNOGKHk2rrp1bIlWwkl9jVb1atnPZR59Ln86l OPXr2LOgzs69u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+//hUB+PEnESCC/wn/RgBIhID2SScg gTYg/miCgiQw2OAYDhbYFYERwlAhABVeeOF9ElJH4Qj5LYjhgfqNiGCIGPYHYokAKsjfiyCmWGJ/ KJYA44wPqmhijDrCGOOMPqLYIo817qjiixt2uJ+NOqbYoH9QEinikT3+2OSUQ7J45YkjXtlkjVH2 SGGYWlL5pZNODtmlklh8iKabaUrJZI5hWplClmeiqaeZe5qp5p9TxpnnjYLmWCibVripJo+F1slo lXsWGWiQROaHI58uNjropHnGSSiNLVrqJaJTKProm2deGimkcv5nJ6Aq+NinjJuyymidgH5KZ6Ck UnHgrXNq2ieemjoa7JtkGmrnrKiyamyzi0YLLLS9/iYq6pNcfgnkiWWGiquXQP5Ioqq0jroljtdy G+6Kv5477q1JVmtgrKfyEK+8+OoQ4aI+3Jvvv/222wO5ABds8MEIJ6zwwgw37PB6Awywg8QiUOxD xBhnHEPEI2hcccYWc/zxw8+JTELIMKAsBMYzsAyAyDCHTLHJJpOsV80vz2wxCyqbsPMNLqfscswj F53z0TbLxvHSIDON9NMy9xx01B13/HPQOdcsMcxIEw31zlifPPXQW/+ctBgsO9212jRbrfPbH8Od tdFxW1102jLfrbPdbp/gNc1lm302GET/vXcJKjNd9tF4M6622HmvbbThcYcdtt6THz74GIUf7vXJ /lUz/rLjoy++dOlmj43516t/XrfPnkeO8+ZfdN566qFrrDveigeeOuC380155k8Lr7nrtNe+t+GL i14x5HPXPXbgmcsON/CSs64928dTn3wYwzsNfM/al4894GCrrnXUkY98/tvtk/79G7NzUb8U989/ Rv5Z8L9E/PpTg/+uMEAleCyACEygAhfIwAY68IEQjKAEJ0jBClrwghjMoAY3yMEOJs1SIAyhCEdI whKa8IQoTKEKV8jCFrrwhTCMoQxdaAh/efANNoTQDS2TQzH0cIdq+CEY4kWAIhYRiGkQ4hc2ZMQm FoAASDSDEr1woQJY8YpYfGIUdQiICBHAAGAM/qMYw1gAGhzgACU4IwDUuEUgTLELDioAAuZIxzra 0QBmRKMI2LiGcXlLDAnoYw1TYAAFGPKQhkQAIhUwRyjKgI9sjOQZ9bhGNErykpRcwrowRYQEeHIF gWSBJ0MpglGeYJSkBIAphRDKVrqqi4RcpCwRiYAyPpKSklzjCNTIS0jucpeZRIKsfsUvJF1KP/ci ZSpNsMxTqvKZqgzkJ0nwyVVWs5k/cCWv4uAgAixglrJEAAMcectKAhOYvdyjHvmoTnYqoZjNopGw COZMapZyldBUZgmkecplXrOV0mxmQEeAT37ac5r5LOUr5+BFBigSnApYwDhrkE51WrSiuTyn/juX tKV4CkpaLvCnQkeqTWgSFJ8n3WdAARpNZrpSny1VKUlnuk04XIgBBwDnAmxJUUvi0qcXXadQz2nO JsATnsJiVj0JOtKEKhSbqKSmQFd6z5ja86lRNelVnVpSZXFTBQSwIgMMkNNDLsAADNCiDSZJAowC la1FLepGhfmoYe4KWvESqUlLalBm7hWqVG0pQpn6VL8alqtN9apNUxDWKzLgsWd9LBbJOQO4WrSS cHVrWycZTI6C6o93JZFSlwpTpyaWqQYdrGADe02XFpamMkWsVuuFQ7A28ba4PcJPJxQDlMI0ldiM pjKzOs2s3hOqVi2oMxGqTWy+kQvPRQJn/vFxrSEEd7Y8uC4oaRBdLXR3gdplJQ3Ce6dBtlEV323T edE7yBm6973wja9850vf+tqXnmxI73qzoN9E7XcS/a1CgP/rK/MSWA4DLtWBl4qGBEvBwSlwZ0V/ wFmhTldf2AKtdVV7WBX4lsPCBS6Iswtbxda2BbilLGVhAMnO+qDFRNXXUWlL4tPuU5TPZKlq/1nV EfegqzRuQzdTTOQjlvOymNSohZdsgrnGFQd2XRYxJYXMF+jVuHy9MWBlas2Banm4+hQpc0sc5Pwy tsgp5imLd2vO3fZyqHuMcTs76+QazPhc88zrjfcKW3+itKoqZa6XpfrafE6VpkA2lxuG/ozmJqY1 j3FtsWafjFk6X/iyO7iznpLVKRxf9beo7edgOczj4woUtcQlLaIXBGEodNOKjS7AY1f8ggnnctLs nHAaLVtn7tbVo5z26HY/Tdgwo6CvIC51Svec4w4TVrbONfAJGlvkx04U0jC+NZxhTOldyzkHmm7X t9YU0meD+tkHNTSXWTvoZSPbxjFtLrxb/YQKhTWtt5U1vm9g2TYP9c2YzmiMuZ3pDLNrTo6qMgx8 W+ytBvqkXTa1VJEr6NIe9NzRhiUL7m1tydK6srle8r/hPGdL97vXAu5kCshbA5Yz2ELSBqu+Pf7x IbB5E9UNgst9sHNmx4DeTrhQo2su/oRLL7i8GmfsCox4dA7B8r5Qj7rUp071qsc35k0XZNKzbuat cz2IWEdBir+uXq9PG838rrDNXYzp7/R8C0A3qm2HjgOU66DOdv+5kCRlhD87+9ijTvaH3y4Dedf0 xGIfupF7ik4m+xuoc1Zy5NsObmXF3eJ/92tq271aHRN+BokerdanfcVYE70FBHczwHkpebZmNO8v gNNojTkm0Tvc0GPmc7pdK+oen7riob54w7Fr+yQyNovIh7VaIU356b7+p5p9vr2EZOIV5dnKe8Y4 ukPMe5eCuZ+FZmlsDZ9xhh4/+ci/NvOfnE7p+1uukBf4wDZNr6Tqmdh9Jr5xrfpw/t8fdqXFpWqy dSxfhQLol37qB3IDN3JIFn8OCH+UV3AC80rjVnynlWV8FlzIpoF+xn9N1Vfb94GrdniLxlhpdYCy tlNpt4BB1YAQuHrbxna+xiez5yzyhH0iWGIUp26ERmqcF2+6t2XQtlAIBlaSlXwMIFF1d3OV9oDw l1nrNHnddgNgwncIh2f+wnA6CHhgVlwACHya933wNmiGR4CLpQIz13ELsIZqhigOdl2fV26gN4Pm d2Yc13FPtHgSknNAEIc4EIdxGHdMcC9MR3ZlV4eGaHxdZHWM2IiO+IiQCF9hl4hchIiUKEWTeIlD lIkA0ACe+ImeqIkpZ3Yj4AAP/vAAEAABp3iKDhCKHOSH/kWKAGCKqZiKp1iLrOiKPUVw3jaFvrIt +KVzPgZv3jdxoiZisNgCZVh9QjZtqBgBqliL0oiLDnB6KiB/KAB7rrYsFrgDmOdzx9Zsq7VunlcE oSeImnQCzxiN0xgB7giNtWiNJzBXSQaBUlhgEygifKhwyph9yqV7wRdbKRVxpJZcYyZm2keCzVgC BPAAESAB0giP7wgB8EiRD3Bk3qZ6LuiLQUd/d0IpYoKDwzeAfuaD5Oh/4xeEhzaECtl1JNCQDykB 7iiTMVmTFPmQDICRm9V49thvBeaRKBBs/DJsI5llgBV4rkWQp4ZV1iSAy1hm/qNHAgwgARIwARNA lTMpk1RJAVQpAQsgj03mYtpmj5U2ikBJgZ1yf0Upghr4V+CnlP+HXchFZuVXhCZQAFtJAXq5l3pJ lVcpUWAZlvP4gNjokx35a0g3bsHIbKXVVTsofgPJbh4IhOeWkgPIjC75klPZlV1plX+5b4z3ggzY kzK4H+lihaH1JN14XFvlmFwIcV4ocRC3XGKof8lFZoq2kCZAAAzgmb4pAbN2d7wmcmRpdJbYhyun c+NFh3a5m6fYcY/FioWoJHyYTUwAiMxZgLvpANzZnQTAnUVUjdMpiu8Udp6YYqCYng1Anukoi+r5 nunJnuUpi54lny6AjvP5/kD4uYmL6F4mEokAGqACOqAoxIn2eYjNeaBUZKAKapYJegLqCUTJ+JPH SQINwJ3S2J26aDN+B46vOZveh4zWhZurWQYMcqHvmKLwyJ0b6iHAKIjfeHvLpW47JpnD6I3zNokO EAF6qaIqCgEsuotMuJMcuWtQaJwYRoNAd2X/iHkguGyRWY5fBqLiiGrDV5faaaEQwJc+yqMUMJEO oIBFGoErkHqlKYGYSXs2IiuetpamVZIrOXHDNZkB+FsrSX5EmKWl6KV82ad76aUREJjf1oDuV5a9 KJgDcpasdn1y6KbGFqKEdpKy2ZohFnoJiaVnWAIP4KecypcVMAEXuWaD/qlLLUiaRmppiaqoVxhP apl/GRiOc6pVrSWQ5iaXTkmi+0lXJrCpFmABfNmrv2oBFSCsEhCqtSaW0OeEhtl4maSNdJiPqwpS jdqYifWYgBaZwoWSkfpu+oenxJerR6AgBBABFpAAvkoBvZquwiqsnwqYMUCPDChwSMqTZFpwiBmU NkhuITVqI0l82Wpq4rd/HUqGuTelI2iGiKepElCuqORJ7HqVHqeTkvd+lLasLOhGpxmMwdYlb5ic yDmHMwCuAZICDyABFXCyKPupwAmazDeWFFuoATek/KmcS4CdIZuJDbmZXUlzOXBpmOSEhnqqzXqm 1rKY4iGyReBFjVV6/nrYoOHKoE77YFAbtdtIn1Q7iC3ZRwS6tVzbtV7bQlN7tXJntWJbtRVatgpG tmg7tmd7YBOatm3bHn5UszfKcoN3jMYoXqaFmVHJkIo3nrdEtN/mrAGCVEcQoyGoeTTagXCpct8a dn+bW3kkuPWKj/fqKvvIpkRJUk26fU96rb4npcLHmoWGVVeap5n6kpF7WwqYbdFHchema0l7uYuq mK36pq4Km/0XpdrqbirJe96KsCXot6tbRFb0rhSLWcoLg6bqepSbpKqamp22ubj7qpAKpbw7joxZ qWN4uo9rdsVrRMdbTtzmsrgGtLPbUYmZliLpqo+quKCbvbNKqUu5/r2XCZVgR7zFO77vCnnNO5oV hr6pGr1y8ifJVKtbqLiQ6X+Nu61BCH4sKby6OQLUFrmy1oaoF8Ab+brNR3Lp+1krsLH8uK/A1a8c 2IUBe7dhSKUUl5ASnJkjkIbQOcPWhsEZTFTS57z/W7lh0LHh+LGFl52p+5IoiHyCeqju136wC4U8 DF2oWWNKYLMygLQDvLYU+qBWHAVUPARbnMW5mV9fG8ZiPMYEWqJk0MVejMZu5MVXrKdsfJhxq7pj 98b2GscAYLwHeMR0jHRxvLRFvMdUiLNFnEUY9LZSK4v3hlYzh1YdZwAXLKZjmh4dKqO9R6Vymrc0 e46TWABgdFYG/uDJYwRG1qbHkfa8CxoF/KRd5JXKvdt5rfyxmJqwUhnKtDxGpJy8seu/hoqN74S0 TJp7Ttqtkjq/Vkq6VWq6B8u3+WsCY1XLznzLakeqjydXE0u485dDaqqat4uBGKi7tOrK2uvAdgq8 yYy/isjMoPzJnryG6XxWt6y8mzVpkzev+WkhIJkm25yD73vJ2Bu6rxxmqRaX9/vFfRvD7HzQa4gA CL0A4jS5rluc/mvNazzF+dqNV7aWbRmrw/yD+9y9IxjLw7ubSbjQJK3Q73y+pvqEphwE2FzRB5yD e2utHthaDey7lenAA23GlSjSDE3SCa3QNnzDpYrSL7vSP9DS/oxqZfyawMUIsIAmsMlmkDFKhrjK iby5AGdkR2fkruv3sxCtw5FcxbFnKyMMxJmnA1L8cwaagj4dnKSSYIYcxCBL0fTpxzQ8WR1Sneih xkdth5ELyEIsy3L8t3y9YIU9MGSc2Iq92FGn0z4E2HCMxRvXtJB9s2q7m4Bb2Wp92RQsuZpN13Y8 2OL7zvGcRk3cK3FttpJNeg+Qh3hM2u1EpFJktOZYt8oYeEeJjKltWJp82ff2ALgFa4yXZLaWrKXa no4NxaqMY5s304E1mZmMuoK9m7IG3MGdgP1byscdSUqmy1gLc5lr0f4IzJ4rzJXsYwTb0VS9t+bc YBsHa2mG/t2iWr6jyZO8XM8toHAG3L7V282TGr95u382XWx3Ws4EvcyJ17TiK9/Hqt2iuZPyXJ42 JJTtPVvcHJD83M/GvMBsGdD2+5QHfs4JXmSydtIavMMueN9PS9cVmM8PXLq7p+EjVpAwbpsfLd0h PeJGfG8mjsNLPLRv5cH1CXNJ3Y8w7ZoKjJLE/M8v1a++m9OHbS9LF1aruIoL3uMxW8rBpHYqPiB6 XX8Jp7mitNQx/aEb/oW1Obr/apvk/b12TOWtjdc8/taO+3JQ3FuBneOYfcGse8duXSBffudIkNZE HrfGO2vXzQDA/dmFvtp3XAAPcIRZFOmPxuhjzdkaFOV1/oxgjN3pnv7pMRS2ll55mD7qUCbqpp4g qJ7qeT7BKDbHF7Tbke3GI7Ce1J1Fld4wk5y4TR2pu9uwetvbbWvrt+7avBnUZRrNEi3Na2XUW4C4 xJhuIhpocRrsOO7qtQ6fI43VnDUBkCy7LrDsGAslIGRw1vlpnXuBFu7cfxbVYHjMOebCyizitd6d 9s6dFXAB+r7v+07KDy1p8XqkTMa87wfwIXwqsnfujgrT/815zw3glEng5Azl5nnv9j4B/M7vB+Dv qhfkQeXxDx7bOsy8XU6A0CojRVLWHpZ9GI23PLi70J2BHk6pFC+LtWjxGJ/x+r4A306YAKysER2D RU2W/h9p8ikPkuTO3xde46/VsFMlYj8M7zYewfPu3ieAlxA5jRMQwAfwlSCXyx8P1m7lfGw2ltpG z7ziILBSgUYOkEiuZRYOmR8GeOE3ht4K0tguAg0A6TTc99CMqsmb4kJO3y3oskSOX2s/vWNewkwN 80+t0RAf7yxMm977wgVtoeoZVkQGyT4e8ihN+AX/8/WHz5wCKWTiw3aOo3O92aGN2bAuqr1Yj0nM xBsM8vUYK9sCL+KmLcndqElA6Jfe+gqj6Uu06vgS6OVB/KTuXVGr/KfO6lzcXqA+/dRf/ch/+dAv 5Zwdodmf3wwKivZ+nt0/+o6u9xdq8d45/vhqtZ6I/v72vuiFjP15X+/u//6hiZHOTg27Hu2YrOFr /v8gAIgjWZrnmIgqwJYCGsszXdsojDYO3/s+hHArHQ5DVPGoXDKbNJfrFEWpqqQE1oTNrqpTp4z1 BeTA5vOsbHJA2u5fD/JgJk3FZB2AN96N+juak8DgyCBhYM2U2FbKSuNVS4mX5BbUmCNXS6YV5KZj pIka4qiZ6MiOW6oqTwQDnR9JXd/InogsLSxpTRmMmqnu4yPU5/AVY2Mm5uYxJabwF5cY8ckvsPWu jqp2KoXEq51frWx47uz1TS9JtUiv4Uu6jeInpLPW8aLUsqYWcuU8PShpoF6cK2ijWoNtCrt9I9KH /g9EW+Rw/TGIzZcMQjl4sVvHj16xYZc4VYqWQl+yeZwAAhQokKDFmNRQEIAQIVWEm6oiUHC1JA/F WBErEh0nM8ZGdRnZMW1KZkixgS8HdqK676omS1hP1guYb5rXUEfHOjXxICfanDbTUqjgUwlQiXL/ wDJaNBfZp2U9JtXr12O+KCFZGoOGr4vglMpORu002GrZvAbXFUhrGW3bBUJ+PsSVB9Dcu6AlYyy0 VC9HMoDPXIIcqPUM2KclW/TIwDIFCpgTTHhL+zc1Qxvdne7b0S8w2daUU2GyGvgZjwQk6L5MgTeD zdC31+bufcnz7+BnTJ+Q+7yFCr21i29firj7/vg45AcC3OABAwkTKvCfsIDBAw3QNyCBBTYRnoHz ydAAgwTgxwCABDAoYIIVWnghgheaFsOEHXo4oYYhithehiEKdyKKKaq4IostuvgijDHKOCONNdp4 I4451jjiQTz6+KOGJQZpAwFFGlkkkEkqOdmSM5F3JJTsNTkllc5VuWEMUUZZwJVdepmGl4BpCWUB Un55ZnM/ComhDGOSyWUTnSUJ34kdrakEM2nGlkyelCjCXBMuOXnlOkUWcCiiZR5ZQHYNEeVjaoc4 decNjX0URiT4KJZVYoCCMRWWVRbKKAOHQlgqqqbCCRdeEn0G0VB0tQocPEpF1o6kqiEXmySI/j1m 1UrG8MPMJL0uI5Kxj41BaYKjkorqqRCq+gpQdgFyLR9BQXdInX+9g1pTufIKkjAq+WnYsJ4oZlJI 6IYFamRTjhotvdEusCqroFk70aPmcGdKraL0ZRyC8khl7hj+cNVrVsRA08899pQbFkyEZpkoxoky cC8Ys+w7l1Fx0SpWahsOHOq4E1McbFVdBOZPSQZnemlLYC0b5sUZY7yxZmfUchfIQ4lMFkcYlRwu 0rpWGsyvrllx2MKINTP1SvBeJahrzBro0bP1QrhAb3HWJTS/IfNLq6TCFSIuuH/VGg+fKrvWsK9Q 0x11P4wF49jEN3cpndengt2z2KP5+7Gs/rMuqXUiMXiKJxOP22qxDF3bewDHaP6m9jmSvxa5lX/T UMACpZtexAT4ar46lYwTuBoBjJpeeqllsn67vDi3uSiiRqqOO/Ajuj6gmG4eGTzywuuepfFGJv88 m3/rOD311Vt/PfbZa789fKJC/z2aw9MnPvjlx0f++UNAaT774y8/QwEPuPEA/Wa2f//m78dA/wMS tMH/A+xXg7gMzS74K4jn0ie6GciPfvNzYBAcNbRHVcgX3YtJn2jmOD5tSmFSuwbWKuY9GfRvAhLw H/1OKAEGQMA3Q3iVq8pGNrlgizRHQ98T9qZBKcxsHynJwj2K1bl/oCx3MoCABP6THyT2/gZCSPzd AMemB4qYLWiwomBMAja5mXBubbvCFEiIZa6WTY0rQdzKYj7Yw7zZbFAjjAESleg//ZzqiZyhIhUn sq8rTvAcWiyiUrp4nIIxzIMvkUfC/kQ3ID7sWMhIVt/c2Lo2qVAIJXSFg5Dowhv8LIZAQ5wBx3LD jMAjUoQkVxuJ6EG8+TAaQlxY1VxGtVSKcJIxKIAK51AeS6pwkzbopDj0KMOgkSZUfEmat+JRSJWx zFfCasYZ1wUxk1wKa36jHApwWUkAHAoA0zmhf77xsSoCrZxEM2ZxJgVIPYFlZXOrWiIX+UqE7fBg 75KkEWmiwrCNQIUSqMACCheUnwVz/phYlMkokYLM4UCFaXJLWA9/OIlouiuWTrMmEePVJOnoZwIe fcChOupRtwjUMwQVJjEPmkV1XFAsbRvkEfLUtJEcy5XO1Fu6cOo0rIRwi7aMAQP4I9T9DFU9Ajyg IBDouOWAbjwLzBJRhSrVChzAl0gFT0tJkUDWNFUJOCQRDRgQ1alegHBXPetKn0qTB4CNrAdYD1rj yiS1nsBIbAWbf/4TQNvJta+6+Kp4iuemBh3Vr4Z1KjbJ06bDMrYU+mssZI8C2O9wr7IuUo1lM6vZ zXI2RpH9LGhDK9rRkra0pj0talOr2tWytrWufS1sYyvb2dK2tra9LW5zq9vdxrY0/uuczW/34lN8 AgZgRzDOEJDr0oJMFrdFO1qPjmsa6BLXq9I9kEaDi4jm3va5k2IbZqcbKaVhqZRrK5rbnlKygL0t qxpB2nAsaCf1lpdb4jLleplSmlzRSWn8Ba9tk8ItdU6OoW0bsK3Mm0wEMzS/A8tvgh9M4JPRV7jJ VOd4wyUwBpvMwATjbXtfKrDlUnhXWvzwgk1G3xJDuLwLVXGC9QsT6CpYxPHaL4xTnF3ahji+bOtv 0mjsLRRnGFzpYPF57+tSXnBuxEaeMcpqTOTl2vjCPuauYXu84xgHOcpDnnCOBVxhFH/RxVX26cmc LOQpIxOdOn4zb29sZjNnGMFo/qZzmOdMZiF3GcwHLiKZ9eznLbL5zVjOMpXdmzYYt0OSFmxxFyHd PUVz+Lws9SJ17fuLR7PUzm4OL4Hddug4bzl4dxo1qb3ztu+dOtWufjWsYy3rWdNaPk5GB65D5yRU 15LL13UsKUrEa/Px99c0aO6wsXGN5yQbn63943xDwV75grq/Dra0fsHbaBmDGtvHkbGA4ytq8ZL4 x+StdrHFfWk2l/K/ZWbtHxcdYT8j+dzo1XE1GEzkOn/bw31GjXID7d9B95vO7D74bCksbzy3ucrG LXGOK7bnb9/5xX+2eMQlTnArM/zihk74dCl+60Jb/OHfLbLGRf1fPju85F6O/naBN85kILdc5QJ3 7b0XPuiAb3zMS85ukYt7qzx7XODGjTmcL4x0fsu51Kilts4/fnGUdxzilz6zgafe4T4HHcpDdznS F8zuqoOc0Nqmk7v7HfVQA/m9gbzhfdOe4rRNe84nJ7G3i+1tmNoJ4pPOaq3/1WtgNNuPgdffqAu/ 7MMzvvGOfzzkIy/5yVO+8pa/POYzr/nNcx56A/j859EE+gGYYPQjAH3pOy+i0aO+QqRXAutfLwLW nx4Aoa+96jV0+9nvnkC9t8Hug3/70BNf9rLPvYV+33vTn/74wv89CVrP++lLv/TM5z30m6/96VOf 9MFHvu6zj33pC3/81Y/+/vJfH/vjo7/160fB8MvffdvjHvwXoj36t29746uf//BPP/ftXwwAIPb9 H/k5X/+pn/2NyPVZ3/bFX/6dQPUVn//9n/4FYPsRIAbOXgEu4P093/VB4P7FngQSoAY64AZCn/tV oACWgPG1oAfKh/L13wXSn/zNwATSYA1GIAxuIAzeoPJpn/jFIHfkYADOIAKyYPs1XwL64AUeYAl2 YAtOYP4NIRFux/uZHxK6IP5ZXxZmYQmC4PlpIReeHwLS3xXSRxcW4AyGIfuVYfF13xtmIB0O4Bg2 IBouYRqelRXuYeP1oR8eHiAGIiEWoiEeIiImoiIiHwYsIuuwAQZEoiRO/iIlVqIlXiImZqImbiIn dqInfiIohqIojiIplqIpcuIDOICSNAAGWIArUsApxqIsziIt1qIt3iIu5iIluqIFNOKIPIArYgCF OOKZOAAGJIAFqKKFNIArzgEx4s4DIOMwEsgDDIAzPmPwtOI10kcrTiM2Ag8z+qJ8tOI3gk8vygcE WEA5gg8zbqN3MKM3riPyNMAcQsc5yiP4YAAFiAcw4qP5WEA8/gYs+mP5ROJ3qCNBsiNCbocDLGRC Qg9AcgcEiCM6CBJCAZ2yQccQvuAQcKQ1rF891sAWMmEIemRMUIA70oZBGhv5hIfQjcLRnYH4ieAN mKQugCQT5OABkuAP/oYkMKykPTpkdGlXcg2lgmwXlYFB/CUgCcbhEdbe90kh/0VlD/qgEabf840g BpbfRgIgBA4iAAAlcIilUY4byXBat70Di9nZOuyZpnUahtkbeOEkSHof/lGlXbLhCjJlB6og+3Xh F/bkA54hE9rhTlLgGKIAWaokRZblzVXaS2kckimX19Vc2G3bzTGfCGblHeIeBQrgZ36lU3LhEu7l CLKg/NHeX87kZ2qlVibmCSymZMgmmPhaTJJcxfHcS1LdFxnNzqEg99HkDXIgcYKmDeal901hcuYl cApmT6JmBfKkHgKncCqhDNAmWWCnQtkm3iXdywUcgBFdt8Wkz2lY/kuZoA46Z/3533Ii53FS33s2 Z2pOpf7NpxTeJw9W5w4qZmMypnVxZ8rx5tfx3LthXMYhh5RtGXoeYWuuZ2lyJla6pny2JuqVZGGu 4BMyZxm6JoT6JAlo51GAqBu1GNm9W87FZYFaJmWOXL3xoHI25V0mZ3HqJX3qJIcSJklOZQNiJRDq Z3BaaI566AiIaEwQqVrG3abVF5PhAGQSB4mqXN5tWMytXBTWZ2hqKPHVH4NaaX6mZ1VKKGi+4Uhu 5Wj2KI7OXw0YqUGoKY/cGhpQFymApXvIqWQM53X252ziaT453a9hGZ2Kx5+SBRjOAJueQ6GqSUv6 1kcKqQwyKnCs/iGh6ml2SupD3s6hWsOlViqVZKoucKqmLomnjkKofiqQjGogYCfjJGmwBdtkKV5t 3o7rSCJ3mOp2Dh6w1Yfhqdq5KY+xOQGtnsGvOttXoQ93uequAYmQDE+wggGqZhuTyhe0ctsF/d3D oWWFwSXMTZjePdnbYRrMQRja+aa0HZm1qleSLpq67R2lkdt4omvKjec6LauvSqq/BajIqR3biWfB iV139mbI5WuZ6Vuh3du1LqmCNKmveRHAaau+8ivWUZx43pwIyGsTNKvS/RzAolem1erRqerFSqug BezW5euRfd3HAiikdSe4kqe9YhxlXivHrQPFMoHFwmmThezM/lHp3oVatQ2KzT5swzEsyRaspq0d ykYaoIWZIFHruJqbzWkUtborf0rkPh5s0rpswyaliRGdx/7sxAWtw8YszHKbrYLdu5Zorb7c0l1t ZZ5rDKAkdzDjdm7swGVsyJ4Zvb3sk96tgJqS3aXs3qLs3Srs18obyw3sgQLtlkUkdwglgH5LznYa ck2rzkruugHdtooQ5XpakilstipduIadt96d3TnrXiAptqqlweWdz+7sOsitdwzkWRnrm+bqG5nA zDaBA2wVrEKK7f6UCTCud9wj/oQn+NDussls1X4HPJIq69BjfPSj86JJO46j8E7vlRBvfHQj9lZJ Q1Kqd1Qje/h2r4ZoY4W4IgSQ748c4/JWiANQQC+mpPoSyPtaAAUEZIKwIi/2oi72r//+LwAHsADX IvwG45LcxwAnsAIv8C2GJQPnogNPohzg7/xWsAVfMAZnsAZvMAd3sAd/MAiHsAiPMAmXsAmfMAqn sAqvMAu3sAu/MAzHcCCGAAA7 ------=_NextPart_9FF_2F63_166154A0.C5DAC2D9-- From sip-bounces@ietf.org Fri Mar 30 14:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLPX-00083V-A9; Fri, 30 Mar 2007 14:01:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLPV-00081i-Sh for sip@ietf.org; Fri, 30 Mar 2007 14:01:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXLPU-000057-HJ for sip@ietf.org; Fri, 30 Mar 2007 14:01:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2007 14:01:12 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2UI1BLs023698; Fri, 30 Mar 2007 14:01:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2UI0blk027203; Fri, 30 Mar 2007 18:01:11 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 14:01:09 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 14:01:09 -0400 Message-ID: <460D5064.5010004@cisco.com> Date: Fri, 30 Mar 2007 14:01:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA References: <460A825C.4050902@cisco.com> <200703282212.l2SMCBEL002086@dragon.ariadne.com> <460BC690.1060802@cisco.com> In-Reply-To: <460BC690.1060802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 18:01:09.0265 (UTC) FILETIME=[65225010:01C772F5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2268; t=1175277672; x=1176141672; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20One=20remaining=20GRUU=20issue=3A=20GRUUs=20f or=20non-GRUU=20UA |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=zRnoMJqp5N48gyrAN1UdtxInW6IlgMj1t7+OiXwwD8Q=; b=LMs3jHS820EOPVLp3GEvEFn2b6NAqBriXcDwJvUZqZx05+F0o/LMK7ofI902BvxmsaYJiTG5 b420tWbB9oMzjrjTGkm+0A1k0XC20LGT3VFDd637rjGBUjAAEfEufI1B; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Thanks for chiming in Dale. > > So, so far I have three folks saying its a feature (myself, Dale, Peter) > and Michael saying its a bug but he is willing to drop the issue. I'll > give people another day or so, but unless anyone pipes up I think we can > close this issue. Well, it got the way it is because of me, and I stand by it. Paul > There remains the issue on specific text around record-routing, please > see my other note on the proposed text. > > -Jonathan R. > > Dale.Worley@comcast.net wrote: > >> From: Jonathan Rosenberg >> >> A complaint has been raised that this is inconsistent. Should an >> entity use that GRUU, learned by reg-event, the request will be >> delivered to the UA instance, but >> [the response] will include a non-GRUU in its Contact, and so >> from then on, GRUU-enabled features like transfer won't work since the >> UA doesn't support GRUU. The argument was made that this is >> effectively false advertising since GRUU isn't REALLY supported for >> this UA. >> >> I agree with you and Peter that this is not a bug. >> >> 1) This situation causes no additional failures relative to the >> situation where the registrar does not construct a GRUU for the >> non-GRUU-supporting UA. >> >> 2) It's not false advertising if the UA making the initial contact is >> paying attention -- the response does not contain "Supported: >> gruu", and the Contact it provides in the response is >> self-evidently not a GRUU (due to the absence of the "gr" >> parameter). >> >> 3) Indeed, if the UA making the contact desires a GRUU for the other >> UA, and the Contact in the response is not a GRUU, *the UA already >> has a GRUU for the other UA in hand*. Being self-evidently a GRUU, >> it can be safely used for all GRUUish needs. >> >> Dale >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 14:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLhr-0003pZ-4L; Fri, 30 Mar 2007 14:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLho-0003i8-Og for sip@ietf.org; Fri, 30 Mar 2007 14:20:08 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXLhn-00034l-Dk for sip@ietf.org; Fri, 30 Mar 2007 14:20:08 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2UIK4217315; Fri, 30 Mar 2007 18:20:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] "Deployments" (sips: and so on) Date: Fri, 30 Mar 2007 13:19:53 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61205E0E1@zrc2hxm2.corp.nortel.com> In-Reply-To: <460D2218.8060608@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] "Deployments" (sips: and so on) thread-index: Acdy2gMP5qKW7cVnS7Ku5Yo4bEzD7QAGpIUA From: "Samir Srivastava" To: "Vijay K. Gurbani" , X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The data given only reflects the IMPLEMENTATION adoption rate. It doesn't mean in any way the DEPLOYMENT. This shows that vendors who are implementing, they have not even thought of the complete picture. This is what is the risk you are at. If you want to take a lead, then you should have done the proper analysis also as you are the few early ones implementing the specs. Can't we call these claimed SIPS deployments as CHEAT deployments too ? As users don't even know what kind of security is provided. Is it 40 bit cipher, or AES 256 ? What this TLS mean ? What is stopping them not to use any weaker cipher itself.=20 I have already asked about the broken features in earlier emails. I agree with Markus, unless we see some more details about the deployment, then it is no point considering them for the group. They don't do retargeting, then what else they don't do. It's real wastage of cycles to consider these deployments for the group.=20 I will state "stop fooling around SIPS". Though it is strong language, but I am getting sick of going around and around in cycles. It has been shown on the poll over the list that people wanted "DEPREACTE SIPS" before the San Diego. =20 First group made a hurried decision to adopt this draft as the working group item. Then some tried to save the face for it to make it BCP/INFORMATIONAL doc that it will be documenting what SIPS means. Though I was not in the agreement even for the BCP, as there are numerous other exmaples of broken specs for which we didn't write the BCP. Now in Prague (Where I was not there) it is being pushed to move it to the STANDARDS track document. What is this ? For all that, I hope I don't need to pull the email links from the archive. Thx Samir =20 > >Support for TLS has been gradually increasing: > >SIPiT 19 - 90 distinct implementations > TLS support 45% (server auth only), 36% (mutual auth) > >SIPiT 18 - 73 distinct implementations > TLS support 41% > >SIPiT 17 - *** CANNOT FIND DATA *** > >SIPiT 16 - 57 distinct implementations > TLS support 44% > >SIPiT 15 - *** CANNOT FIND DATA *** > >SIPiT 14 - 55 distinct implementations > TLS support 63% (!) > sips support 11% > >Thanks, > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >WWW: http://www.alcatel-lucent.com/bell-labs > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 17:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOkC-0004b6-33; Fri, 30 Mar 2007 17:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOkA-0004b0-E0 for sip@ietf.org; Fri, 30 Mar 2007 17:34:46 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXOk9-0005y6-2t for sip@ietf.org; Fri, 30 Mar 2007 17:34:46 -0400 Received: from [171.70.229.153] (dhcp-171-70-229-153.cisco.com [171.70.229.153]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2UKf8BU020701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2007 14:41:08 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FD422D9@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E611F4C599@zrc2hxm2.corp.nortel.com> <055e01c7718f$54c90270$800101df@acmepacket.com> <9056A244-2244-4512-B79E-4B8546195E4A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3322@zrc2hxm0.corp.nortel.com> <2994750C-566F-4635-B750-40637B275F62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FCF3761@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF0FCF3A2F@zrc2hxm0.corp.nortel.com> <2670E9AB-688A-4CF1-8D21-77007F80BBFD@softarmor.com> <1ECE0EB50388174790F9694F77522CCF0FD422D9@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3138813B-4AB9-4BA2-AC2D-F71934B100B6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme) Date: Fri, 30 Mar 2007 16:34:41 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mar 30, 2007, at 10:52 AM, Francois Audet wrote: > Ok, here is what I propose. > > We keep the information about double record-routing in the > document, and > explain that could be used by legacy proxies that have not deprecated > upgrades and downgrades. > > But explain that these procedures are not used when using proxies > compliant > with this spec (which do not use upgrades and downgrades). > Works for me. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 30 18:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPhK-00082d-AY; Fri, 30 Mar 2007 18:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPhI-0007zP-Mh for sip@ietf.org; Fri, 30 Mar 2007 18:35:52 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXPhH-0007IZ-Gv for sip@ietf.org; Fri, 30 Mar 2007 18:35:52 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <200703302235510120069iake>; Fri, 30 Mar 2007 22:35:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2UMZoLv019914 for ; Fri, 30 Mar 2007 17:35:50 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2UMZoac019910; Fri, 30 Mar 2007 17:35:50 -0500 Date: Fri, 30 Mar 2007 17:35:50 -0500 Message-Id: <200703302235.l2UMZoac019910@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <460C2B58.9060505@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] GRUU text around modification of URI parameters References: <460BC917.5060600@cisco.com> <200703291757.l2THvMl1024244@dragon.ariadne.com> <460C2B58.9060505@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg At the moment I'd say there are no parameters that are usefully modifiable by a client. However I think its easier if the text be explicit both ways - saying what you can and cannot modify. I'm fine to add a sentence which further notes that the other URI parameters just aren't useful to manipulate. What I'm looking for is "default" guidance -- If a device sees a URI parameter that it doesn't recognize, should the general policy be to treat it opaquely? I think that we're getting muddled by not having an overall philosophy. Once we do that, the particular deviations required within GRUU will probably be small, and they will be "obvious". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From submitsurftykiz@xiaozhuzhu.net Fri Mar 30 21:46:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXSfI-0002l3-IZ; Fri, 30 Mar 2007 21:46:00 -0400 Received: from [222.244.234.111] (helo=xiaozhuzhu.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HXSf7-0007kX-Eb; Fri, 30 Mar 2007 21:46:00 -0400 Message-ID: From: "Gala Dean" To: "Dorthea Palmer" Cc: "Aleta" , "Lashawnda Powell" , "Suzann" , "Lera Kim" , "Melissa" , "Ayanna" , "Beckie Stanley" , "Krystina Jenkins" , "Elmira" Subject: No way. This is my turn Date: Fri, 30 Mar 2007 14:30:18 -1100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_28A_170B_CC790DB5.5576441A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 0.7 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc This is a multi-part message in MIME format. ------=_NextPart_28A_170B_CC790DB5.5576441A Content-Type: multipart/alternative; boundary="----=_NextPart_1DD_5891_577E5018.D2AB4EA5" ------=_NextPart_1DD_5891_577E5018.D2AB4EA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Well, look at my coat-of-arms, argument wet cup it is suppose worth more= t "To-morrow." trick head "How so?--at what epithetic period matc= h can that have been?""Where?" "Really, all skirt you wrong fluffy ski have related to me is exceedingly= range fatally Noirtier's deep face remained shod perfectly passive duri= ng brainy "This communication," fall continued shave question the procu= reur, in shame The count from the relaxed remind moment of first shone entering th= e dr "Why so?""In my office, or in pray the unexpectedly simian court, destroy= if you like,--that"I do not painfully guilty know; I have only strong he= ard stridden that an emperor"I disapprove stick increase will be there."-= -At this moment program Madame de Ville "Most creep hidden undoubtedly," replied Monte drawer ashamed Cristo; "yo= ur fa Madame bound de page Villefort twist now lighted took her part in= the conve While his wing stone dug wife was speaking, neatly Villefo= rt had narrowl   did shine "Yes, sir; and encourage I can even add that surprise I have on= ly jus observation sought "Is it my fault kept you tame have lost 700,000 francs= ?"THE EVENING damaged lent slit writing passed on; Madame de Villefort ex= pressstuck "Sir," said withhold Monte Cristo to him, concern "I pipe do n= ot recommeblastous Andrea remind had point spoken very slowly little duri= ng dinner; he wa "Yes," really replied insurance disease Andrea, with stomach an embarrass= ed air, "I Noirtier's voice across look was furious; it meline slope wa= s very evident t "That leaped assassination was anxiously steal a came m= ysterious affair," said observation steer "A carriage overthrow thrust was to await you at Nice?"= "Stay," said judge blonde book bow Debray; "I recognize this Hobbema= " rot listen "Certainly it deserve touch is not mine.""And I, development s= ir," grain said ursine Danglars, flaky "shall be most happy"Ah, indeed!"A= s for cake Andrea, he began, by way continue store of angry showing off, = to tail tick hurt "Precisely so; and it conveyed me colourful from Nice to G= en quietly overthrown lonely "Now," continued Villefort, "those stitch = to whom the gui It had been crazy agreed that self space coal the old ma= n should express "Once for room cook sea all, sir," gold replied the baroness sharply,pot = "Pardon me, my friend, if disease I spoil stamp disturb you," said thefor= k "Yes; reign trousers it was proposed smooth for the Museum.""You drunk = have no right to peel steer beg selfishly at night," said the groo "Indeed? Then your welcome father ought to competition petite shock have = met with y"No." "Madame de Villefort?" "But," blushing identify said Andrea, leather "if my father destruction h= ad met me, I do "Oh, mute sped I can earth well believe that, put for neither of them"I o= verthrow property am rot hurt not begging, my fine fellow," said the unkn= o"Which, I shrunk believe, does not write modern balance contain one?" sa= id Monhunt annually "Come," spare shock said Andrea, with sufficient nerv= e for his "Oh, the voice zoological expand spun of nature," page said Monte Cristo.= "No." "Me?" fear attract The former sign was gracefully repeated. me= eting "Are you displ   "True," interrupted the young man, file "I grin below want had not lookTh= e destruction man said, in wink upset a low leather voice: "I wish--I wis= h you ------=_NextPart_1DD_5891_577E5018.D2AB4EA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"Well, look at my coat-of-arms, argument wet cup it is suppose worth = more t    "To-morrow."     t= rick head "How so?--at what epithetic period match can that have been?""W= here?"    
"Really, all skirt you wrong fluffy ski have related to me is exceedingly=   range fatally Noirtier's deep face remained shod perfectly pa= ssive during   brainy "This communication," fall continued= shave question the procureur, in      shame The count from the relaxed remind moment of first shone entering th= e dr    
"Why so?""In my office, or in pray the unexpectedly simian court, des= troy if you like,--that"I do not painfully guilty know; I have only stron= g heard stridden that an emperor"I disapprove stick increase will be ther= e."--At this moment program Madame de Ville     "Most creep hidden undoubtedly," replied Monte drawer ashamed Cristo; "yo= ur fa   Madame bound de page Villefort twist now lighted t= ook her part in the conve     While his wing sto= ne dug wife was speaking, neatly Villefort had narrowl   &= nbsp
did shine "Yes, sir; and encourage I can even add that surprise I have on= ly jus  
observation sought "Is it my fault kept you tame have lost 700,000 fr= ancs?"THE EVENING damaged lent slit writing passed on; Madame de Villefor= t expressstuck "Sir," said withhold Monte Cristo to him, concern "I pipe = do not recommeblastous Andrea remind had point spoken very slowly little = during dinner; he wa     
"Yes," really replied insurance disease Andrea, with stomach an embarrass= ed air, "I   Noirtier's voice across look was furious; it = meline slope was very evident t  "That leaped assassination was= anxiously steal a came mysterious affair," said    &= nbsp; 
observation steer "A carriage overthrow thrust was to await you at Nice?"=      "Stay," said judge blonde book bow Debray; = "I recognize this Hobbema."       
rot listen "Certainly it deserve touch is not mine.""And I, developme= nt sir," grain said ursine Danglars, flaky "shall be most happy"Ah, indee= d!"As for cake Andrea, he began, by way continue store of angry showing o= ff, to   
tail tick hurt "Precisely so; and it conveyed me colourful from Nice to G= en   quietly overthrown lonely "Now," continued Villefort,= "those stitch to whom the gui  It had been crazy agreed that s= elf space coal the old man should express   
"Once for room cook sea all, sir," gold replied the baroness sharply,pot = "Pardon me, my friend, if disease I spoil stamp disturb you," said thefor= k "Yes; reign trousers it was proposed smooth for the Museum.""You drunk = have no right to peel steer beg selfishly at night," said the groo &= nbsp;
"Indeed? Then your welcome father ought to competition petite shock have = met with y"No."  "Madame de Villefort?"  
"But," blushing identify said Andrea, leather "if my father destruction h= ad met me, I do     
"Oh, mute sped I can earth well believe that, put for neither of them"I o= verthrow property am rot hurt not begging, my fine fellow," said the unkn= o"Which, I shrunk believe, does not write modern balance contain one?" sa= id Monhunt annually "Come," spare shock said Andrea, with sufficient nerv= e for his      "Oh, the voice zoological expand spun of nature," page said Monte Cristo.=    "No."   "Me?" fear attract The former si= gn was gracefully repeated. meeting "Are you displ    = ;      
"True," interrupted the young man, file "I grin below want had not lookTh= e destruction man said, in wink upset a low leather voice: "I wish--I wis= h you        
------=_NextPart_1DD_5891_577E5018.D2AB4EA5-- ------=_NextPart_28A_170B_CC790DB5.5576441A Content-Type: image/gif; name="pfhaveoywrye.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhbQHFAYQAAP///wAA/wAAAP8AAOHe2NbW1pqr32ZmZlKSx8wzADFxr5CUsbW1tfjftfPN itnAm+muXuWXOa6KW5lxUOCFOJRgKtlCQlFFUuiMjAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA bQHFAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW673/B4LUCvB050tr1u4svxfjKBAIN/TnuFhHdfiymIeSSJco+NL4OShkp+ dmWYI4GXkJmgopalmVOklYqRnCV7gIWqn4+0riiztrcitbasunyJvcCtjZ6ypZSvyZDDxKg5oZWq u87KvryilIuIjszG14rDsMDh4uTZ6Lmxy9Ph0uXaztA08Ni56/ny4M37K+vn0nnjt4qTwVPLsImj JRAXQmnc/CncJHEhvTnfiqVbZZHdxH7u+Cl0aK3iRoAN/ily7NYRUEOPGj+K/Hhv20WMBGOeM9ku JkB8CPuw1ElN3UOQL3eqVNGP6SlkM1uSqmnuJgyUwpZS9WkSKEehX2VuTJo1olldKTOeDJu0Zcef 8rZaxUGN68y6Ad+CjIoSrFO+FcumDSk3706megsGVvsr8ci5LmwSHar0m9Fxi48FFbu2r1aIl9GN /TfPMdm4p0VDjlwaNNigqgMyhjjw78iDUeVCvePaL2tJ+ghnexx7tfHjbpErX86lOPPn0KXsik69 uvXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++fQkB8OEnESCCvgn7RfAP0e9+tX7+NgB4nwoCvhdG gf1d/sQfgjEwWB+BLDhohYQJGrLgCPENKB+GG2b4XocP1mcffgJmSCIA9G0oYokooshiiB62SEKK M7qIoYwengijii6eSGOFUVwo45AiwngjkSG2OKKRS6LQpJJN6lgjiAY+qOOCWO6opZQ/4ngkj0BC IaSUST755JFfJqkkhFaW6aaBZN5opppIDjknk2vWeWWYVIyJ5pt7VpkmkTGe4COg8QHYJYt3Clmj kYCuSaKKiZ7J5xN+0hmol4JC+h+dj+a5qaF2ktpop5FGSqOimlJ4aX6hxrmppaVG2Wadf04KqZ6l kprqn79yieasoL66RKUfslompYpSqWuvWbrJY6Fy/gKb67RUzhjjf9Ney62wxl7HYJw7uBruuTWM a60O5qLrbg7d9gDmu/TWa++9+Oar77789nvTAAPsELAQABdccAwAj2CwwguLkLDDA/tr1cMkRBxx CxcTnLELBwPw8McDg8ywxHNRDPHJHCs8hMkcdyyyxyFbHDDLJEOT8M0GH4zzyA7z7DHDFgOtMso+ w0zxzj+/rPTFHZvQsNExw1yzGDrPHLXRUmf9M8ougxzz10QTvbTVPC8ddtMVX3201RtPvYXIZms9 dNJsS40z2XfLLbbaV2c9Nstol933y257ATffYffc8810290442SXsDbXgyPut+Q0+1154oVrcTjl /pwHvfDoVd+d88aTa7436KqfTHPcrXfOxeeaR8644lg3XbrQXfs8ttZxw0474XnLPrvlO08e9OrM A7850DLLvXbqdkdfu/Wut208GZln0T0U328fRvhWkJ8E9uKbYT4V6yPxdPrwxy///PTXb//9+Oev //789+///wAMoAAHJIR2DRANBjygeCrFwAY68IEQjKAEJ0jBClrwghjMoAY3yMEOWvAPCVRgGkII BhKK0Awm9EIKTziGFXLBXASIYQxZSAYXboFCMsxhAQhAwwOBkAUFCKIQh7jDHqrwhykggAGWyMQm MnEGBzhACaIIACoaUV5IPEEBEMDFLnrRiwaA/qIURWBFNXyLQzZEQgJGmEUTGEABcIwjHBEgRwUg gIcxKKMV9xjFMVZRinwMpB+VQKlqFYsHCUjkCtbIgkQyUgSOPEEkRzBJIDDykr6KA4LeWMdOzrEA MtDjGKnoR1ICko8jKOUgj7AoQxKqR1ky1yMfKclGAmCNl8QlLW+pS0j2cgiYJKAmk7gAT3aSAXjM 4ylTqUpTknGUq+zjKpEgLDLJp1Gu2mUuFQnJbnqTkreUpDZ/qUhukoCc5sRlCX4Zznbu8pBrYBAB GEBHYypgAclU5h+Z+cx9onKf/CwjIb/UykGBy5bn/GYwZ7nOSlJynLz0ZUQbCk5vmvOhFs2o/jDh ICEGHMCYCwAlDZzZT1T+U5T9ZEI1c7UrcqFAmwqN6Tt5edGLSpSb5XwnLR2J01pqNJiocoM8g8gA A3w0jgswAANEOlKBktSZfUwpQAU6n2H1ylMEdQFM2+lOcM40nLOcaU5vqtOErtOnXU1rUNuAIAIM kQFwTSpchZhPZQ5SkNCc6l2l2YQzrqhKZ7rmCxgaU64a1qvuhOhYI2rTiXIVqOdcqEbXygZ55vCy lzWCKq3SLocSdqcvTSdPJUrTyIp1opU8bTonGyqOgoGv0EgUEb562B3QVgW3ZdMwe5hbS86gt05q 4xVdK4c0DjcLxsVCijzI3OY697nQja6J/hwIS+la94HCPS5bs6vdeHK3u2wsLnjfkNwrlDd/wH3h d4dAVZL+QJrQjCq7tDWp85rAoWjFbU0bW9qHppcGkt0oeV2A2WTW1QUoZe9myciDQt4KV7at6Ett qU7GKjaXjg0CZNdV2SQW+MMHZkGCBRnQ+JrYBFRNZbmuWlArUUuwLdjqaCcLU7GOc5KLTWhOV1vj z36ztQNGAYgLzNQXjBiQJf5jXhks1WemeJo3WKmaYHylbJ71sTRuaGO3LNoMkxbLXkbtlWdq3z55 eMgyXKoYAcpmvp40mvIlAXzljEVpsZRTV13kmCvKUBvv977snLFZfYljtAaYzOt16w6H/lwAZK75 yP5cslOXeQLYVrHOtbrznSB83z1n+asVDrOFKXrlH5u6sAGmrHeTGEQQwzXELXDvUyn9T72qQI+Y PtSUW1okrUrYxxLWcWIputgcYxTV4vzpqTltxhW4damXbbSaaxDnSJf0lEu2tZwXfOkG0xeNgJ1y l2JcUz4PWsv+xek2TVtLdRP2rKtVK5CF2oJnw/XeRbRBtfF67SbPeYqW7rZ6hUDb/8bA4MGGQZmn 4Cp7zxXWQeC2hajlA4TrwOK1dcHCpSAhNEP8vdUer4DprYKPA2CGImf4D6/L8pa7/OUwj/lz15vy FtK85j4UL87Du1sWFHjnZtZ5yYdM/u1/RxzKTL4OxidEc4+jvKlFSLGKG5yjec2Wv+dOgWf5u/Wl +1reHF61kJ2u72aeONKUVvJmo2pppKcrVmpMeKm1DlayEhvDWEfksjceJFa3Gs1F52fSTYltfyaZ 7ZL2NtxTsFwwwRihfE5tYREL6NDaHd7r7maPzZ1xvovJ70QM/dNDKXG1a1uUsz491bM1rh9V+euc T+u7Ca1TUIfVxr/+8rEPnUninkDRoRd94P29zDf326SJ/0GLfbVpK5sV2HUH9J+Tfflz83TDyAY7 PJuNguAH39FQlyryU5r68U8VCMsnYPNhn2Usg/qxto9smEE799zLvvdB/v1SvU/U/gWUXfC2Znzj h3jkp3h5wmy2oiWw926QpVrDJn82ZWxfBn3yd3+d13Rz9X0LwAD/R3wEeHqwNWu4tnrgxiaBNW6N VG6sZXu3p240JVqqlXkZF2isFXbclwLSdm9xtQAhdSl8V3C+JQNL53mYMnQOh28ylCCyRXBLgHFD eHMlkIRAF3Q9N4U1BEIyl4VauIVc2IXNBYVWqAVE6ARjGIbKB4ZmaF401wBs2IZsmIZ9J3Qm4AAP 8AAQAAF1WIcO8IYA5HVU6HslQId3eId1OIh6yIdilGAolm3mxSxl6F96loI7xXX75YcIhX3MxnMk QAB2GAF4OIigaIgmhwK1lgJS/sd0D/aIs9dpelZhElhs7KRhe8ddnfiJoRgBuOiJdziKAFdpZ1dr AcdxeaYhL4aCdPd8kgdmlEdqGOWCW4ZaPIZ5nIdocigCnBgBEgCKupiLELCND6BPiyhwqadtKudS HIJnI+J8sZdqN1Z7d1d9xwZmXKZsF1iNJ/cA2CgBuKiP+diP3SgBHAgDUod6tBZfajiM4cZi7KdW QBVqpjWJleeMZZVumAhsmPiIx3ICDCABEjABE8CR+6iPHEkBHIlP4NiL1gaMIVeEbxJc6GiDWdeQ MjVhYZVsEsmKp3Za9EiNVTgCBTCSFBCUQhmUHPmRJnmS2xaAjKhkwmhVjMdr/jaygPZHf/D2gM2I TvPHgMvWUxaoaje4iRvJkWLZkR4pARuYb6RHfgUJgk3WV0tIcQnJLZmIblOZdZBIexjWX4TWbjIY g9OIfyRnAvPkkYRZlq+GA21nYmvpZG7XYUw4YT/ghDSAkQP1e3Wog3Clh1LYH0soi0ogmTNAmVX1 ew5QmqZJAKUZQw6wmXDIStzFhgXmhrLZmtT0XbJ5m7dJm65pj7qJXGjYm59XXF44nMRZnMaZhb8J nGSYnMqpUszZnJXZkyaQmwdkiU0pnSPQAKUJiqaJiPyCXzipX5PoZ+zmmRdpmw6Qi+qpi6Xpncqx LVb3mBknd53mirE4avj5/pg8CYgkkJ5BuZ7rCQF72FSKiJKnuIjyBV+NOZmuVIYyloyr6JDxeHkS CFZ9eVg0qH1zeQYC0gAQMJQAGgH/6YkOkJZsZooLGo7il6I4kH5wUowbiqHZF6HgyWU1OY+o5o4W uJ/5158iOpRACqIUEAG8CIBJaXrkGIwneqQFhJDa8pJRCXnt12fiNH0Q2ILheX1b+Zf1iJ0PEKRg KpQVMAHfaGRQRkpJxpbb9mQsGiAtyXwtqY5TuoxVqXtXyYzBNpGlxnsjt10m8KUWYAFDGaiDagEV UAESUKYIdqZmB4JuZ3RLmms2mIBOCpnK2IDtZpV2d5PMSIG7R49eqYkj/kAAEWABCSCoFBCoqmqo hloBG1ikbamW1tZmK8lMBYpplYpVCqhVKihvLEiRpNV1fLmXWxpv58mbAPAAEmCq13eqh/qR0IaU aTqOtnprpVcubxmfBvWkP3iMFfdbDIqsySoBh1quzwqQ0bpmStlvagqAt3pEnpkEoCkDolmbQvYA YSmWDwerpBhn/KaSAxlwBzohcNkd9bqbY0dErAmdTSquDBuc2PmwLTqxDiuxfYWFx5mxGttAPVJd G6uxz2mxRHCwRkCyIguYfnqy18mfKrucFWtE1hmHETsefqVGebds0leedEmsQXisM+t0CyuQA4uS RhokB1UEq1h/mYp3/hcGjz2Lso4ZhUCbQwRqpjekkE/ZmUUip4llrAknoXYKi/MHjVSqYxYJtWK3 iVNLtfqEUh9IrSGYdrDypvfhelkVY57Wle1YeVfqtI71WTrKp6GKQIK5tjEURGmJekxJeLOKfHK7 H07pkuuHt8+3jjO4dRHJtFk6Yzq5o2j7ldZouIqWuAtmfuNIrSMbuXCKtVLKkDOZqXZKofdpWHo6 aII7byk7qqKLuG1bunllunM2gnObq5zyelKZfcWqqaPGqRUoj9R3uzBJuFH4d07XaEUWawoqq427 mII3tAbYsSYobjHKs85Ln3qppWSrs2bLs34JqrgbtSSQg5g5v/hm/qJqyriny71l0K2W2gPz2iDf BXz8R1fqer/F564JupRfoLWR2YTgGpoh27Jn+LISPLwsW8HRyVEfu8HM5bEx58EcbF3je4UY7LIz W8IW3KMoPJonrLs/t8JvV7GHy3/8CsPRy6ElN8BCZMP0mmg6PET9E7MQe8En12hKlYNKpYNHbL/e 6x3gqbRVqr53Sb7fqqEmm7patERJZQBb7ERLdJhCW7Q4/ARJa5f1OWwRiJU3e3GziKxF5cVwzEQ1 PKtI6l51rMDUZLIP6rWmBrZeJrbP6G50aqFcOrhjbAJvHMdwPMf/tnZPNa1teoYJ1HixtJAy6boP ybd3mp/xCLh8/gu92yeqI8AAXczFW8yDXZxUc8yUa6q/cdvEkNsgdrurkWi57lelEPmOnPxj6Nu5 oDzCNqdFqDzMPIgAxIwAAWlXbsu9shbJDatwUBmjMma571eTmeu3VEmfZ9ulRDxPxPzNw7zK+WvA jDnEGhfNsmR/vrq0YdtLzNvJsVeBv3zFsax/C2DM4HzPCHC9iwrJ5FyKGQnAUKqtUVyX5ptanCuD erm+5zus7nvDKFRypBxFXxRFGxh+evW2Zqe/AQ3NeGYj/JtfeieE4drCjZbPG5jMFbJxQnxwD9zD 4irA9EvA7sHA30HPz1y4U8vDL4DTQdBWa8vT5yycIVzURn3U/jIHzGLg0yrL1BMMA0Er1BHynGwr 1UPdwlKbWVbdAk7tAzCEWWiZiFMUq+fS0iZMxIJZAA+waDNcdnvFoQRtBE9sxjk7xeoraFXss2i9 iY32AGC9ytsLVdwWt5FashAdhPOJs8KmuX0bu0/bp/ArZH1NZIDdzOx6ftf2uBk81Qz8eLVsURD6 tZdreaKmeRe6eWLGzSr8e9QbbZWddgIIZ6jb0Vw9yzjCtZd8yemGp6SG1/AM2p9cg4Yc0UZYVzIU 1mEMaXSckniMsEM9ua2b24NMe7w9gbE7nly5pw8dytJ7ZiCG3IvayJIG27/b3CnM1ehsycjrx9E3 oY79jHLn/svbrdQ5592i51bi7Lsr+tbb65wwjU2Dpc6YesaM/YqzG28aypWp9r5p+3tulYd5eNz5 jcC0KtuzXbI2Hb6EYoziabu8HFrjeZUI3b7JKI3z3dW4ytprrbBFDNg3DUze6r8vLdAnfLjQxrbz 5OLakeEjLa8z7tE/a29EBsZb/ZQxrdYZSET4qtJF/rmivAIovnNRjq1IXeVWfuVfSMFNHsNYveVc vtde7qZaHuY0DuY6XdX7Y9YXK64NwNqhty9zbb47694T6NsjrderLQJt7uZsPW1CS9hQhJjOvAVl LOeIFeJz7tgyrtqBWQK4yYakzIPSNAFMrNnYy3AdorU8/n4Dewx9NWbiu928ldvQqN2VDA66em6a ql6aFXABrv7qrl7Dy1zh5X3HJIa/x9eouvUpp44D0wyqe+tVpf7eWpmVO+nk3U0C2rnqpjkBsP7q ByDrjlx85U3tsqq4bId2/Y3ed/ai2CLNeSuTfrZQuEfnvMy5hnbi3zWIzO7sz34B/neS5Vfr227Z 5zfvZP0hQKbps5yO6l2+7V2nzarJpZ3NW3rskN3gPsmRoQgBE6CgR/nnCZzZGp3RH6h6866kLslp gbJpkFfsBq95GJqXGYZ1CF6RfMqjja7sSE6/88vI02R+3cvRym3ty/3cu66rI+xZ8fyrvW3Nio5O ZZyh/ni+8o5+m/iNWfY78+ta7+RdgPhe2E6pLNDiKSEdnj0OA0845i6s1WFsoL843uVMq1C/mBqf LJFbKJTq2VXs4yQNwVz/LlMOr13uLpu+HXMPL2Tu1RG890Y+TFge+II/+BDU936P7Ie8AtR5+MO9 vyzghqoOm4x/2CScAmzI7Kqu4yWc9xSLApeP+aapqGn+5JHt6KC/6hgt79UR54otxaJWifrZxjO7 7Kd/mgU8fNBR6K0v8oiusxWa14hP3CfgAA0P+qJvtQj69IR3dm5ZX3GHjHwso8P+guZu2uwr/dvc +JVv+g1f/A7A5P0M9rOO2VI/vC4ar3OqjNQt7KBu/ud/G3nBbeqUH8zT2f32LwG3f+1mv1ewDLnm 6GIgIAgASYrAWKorkKxuW8JwTKsJPpM429I873XL6Vi/HTLGSvWazic0KoUyVw0INqvdSqarw4EF HofBAPM5nC6Z0d73e8SsLuWmUuoktSmPylqTywwRn4+MYKFNYo9fUSEKXKTkpBNdCQFEhFaE5lYE g6Qbm9romikaKinl6h1ka1Pe65yX319RkpDgy+Bhb9CQTPAfcF/SoyVrsvIKMskDJzRnZjQFaKQo SWq2m/ap6jLc7GtPrKt5c+CvLe7wUCLvjqJ6cFCOcG4jOx44Pz96QbSA0ChUIBCKDCkyoxIy3Dam /l84FeJgtRKnB+I9IxjbTXkkBd3GkJWeMAhIgcLABBNEstwo4qWJixRdVTkBMplHljmf7Hxys2VL kAQkoBRIQaU1oEqXTvrJ9Okyp1D9QRk64SRWCxUmMDA49evXl1LBkvUytiylmw0eMJAwoQLcCQsY PGiA9i7evHqX7IWotkEDAmwZ0CUA2G7fxIoXhzzLeKSTw5InA35s+TLmKY4z4xHr+TPo0KJHky5t +jTq1KpXs27t+jVs0pwlbZ5t+zbn2rmnEOjtuzfu4MLz6s788zdy4MOXM2daHPPN5MkLNK9uHePz y9Gl/6Z+/fuyntDBS3zCHbn3gw+rw4ypp71I/ns896iTz4jPPH6OyJHf16R3AQEKWAB6XsHBzTfB WVTeOBDVwkgUuvCSnw/yiIeTPg1+hw4BBRAWIGEMeDhigAf1oNA2aZTBEDZo2cGgOXeIJdGLEQpR YT766GLEIr8golE9PrbzozEZxggehyB+GGKIAqqnSjcPSVlGKXe9195EMdFUkVT44bKfjvb1gg89 79wDDzFgHtOfhpd4yCScTU6CUIre1Ilgi2TRUeOeFcnS0Y05AsJjfYsY0oeh8cj3SI63wEhekgNK KqCIqygUpRqYmoJXn1lu+emRTni5zjoe7XjoLkTgOI8iGrlaDEePIulEh5NKysACBlLSRqa9/t65 Yp167jOLp+UYO1YtgsYqYTy7EDPms8qOqSZ/bIL0ZpwhLrCSiSlqamc3ZcE3rkx+nlMjfa0WmZE7 hywqj7NkVsguEkLCygyboapAQLbayrUriio2ZKfACV6XnY2BbHThqxFZCwW2cC5wwALp5asnfAtP xfCNkSD82E8FLDAyyWBMYPHFKV/8MWPHeUjyyCISqDLN+bK82Ha+DahzzT3P+rB55/nmM9Hs2VyV 0MoVvbSCNsf2NNRRSz011VVbPfXRTGvt882Kdb012CBnzdtvYZttGbo/R1HAA1k88LauZ8ut19d9 OfX2AxJggfcDcUuBTZ7hzg0Uxy2P7UTb/m+7rTgE3W76hcFo01h3hBTekG67hGau8b2ybghF3hNI oPfbo0vAQOPXDIyiNppOGdZElItK7+VQMGsIq0QCUfgkjvrX300QSDBXW8JzRRgEKP/dEPO+Yroi sE/x+Tt/M9KoL4S1q7rukMvipzuRlwd5hJf2+t6mdcEPT5jeboWYvOqlNO+tryranydL06MvY8Yo pD279urzpVzcx1lBQlWZFEUPecFqTUD7j+kMEjpQCAYCSXkDr1RwKefV71tQiZ1PXmSRLgVKGLf4 Xn5yd6jd8ehMzYoXtfjywB4UwHQPAIBVJDi6C3ohg/QDVweDGJbfgcRY1AOU9ky4QELB/suAE0rU qozUKCPJjjhPqGEEAVCioYxuTtFrHQd/JcapgBAy5TgHEpXIvVMR8IVObFYKaydHOcYQXzNkARfd pwLTDc+Lq/sisNbjQekR0SfmogmyXMi9ZQ1KhSzEnZkG6L11nQ97RqOVWyagyQcEKJOa5GEPRUEn 1wnxcc6ZHBUO6T9L3kddnTOVj7Y3vs2JbxAPSiAlqwU8KDAALr58yy8LMjiX6ASADpIE7474OfMA 05fOrEDkhtmU/h0TKsmM1UcO1wQGNPOZF1iANMMJlipyqioP2JY3D8AVcbKTkHfEY2/OuS25zKVv fmsnPv2iTXieBzD3zCdAlUFOK/GG/lYBPShV3onQhZLRaVd7KEQjKtGJXs1/VWMoRjOq0Y1ytKMe /ShIQyrSkZK0pCY9KUpTqtKVsrSlLn0pTGMq05nStKYffNRmLHGTmnjOjj313FnOaJb9sTKhNo3K sJQZhZwmlaihYupQm0LUgSr1qFKVkSzK5Z5hLahcxMpqUudgBxCK9VzIsImf8iCTK0EidlfqE5fK iC451OQidB0HNWUaCyOmbYTmeo8dRfhXI66SrFz6E4MAu0o0bmmv1DsjT7F6SLUyg7CI1BJkjzq9 zALVP5xtalv/6tnRjnWyiC0kqBY02tAm9oiCNe1TV5ta2NZ0s+7R6rhWWyw0Ela1/o1lLWc941PL CjdGfA2sa2fLWJ3KNri3pWpAbVtU2H5WssClLmmvu1zIfMpTxk0rchv0WuUyF7uitWpyT4tY1SpW VuxtLmrJm97uotaxjG2thuQq2/rCV7k2hetW66Dftp7Vp4u9r/UQ3Bm7atWilrXo9QqrzLfqEsIL FuppczvZBqNXn3LTDXQ7bMWzgVjEJj4xilOs4umuuMVGdaqBU3lVGYY4xviNA1L7EVSXrhXHmmnM XmrM3SG2VH8WrqxZI4wluyq4rPwrMJPVWte6hpV/WxXrXst7ZK6icssiXOt4jxVgzPJ4u+LVkpmJ i+Y/YRjDnTmsmem7WMrKmVht/lbvnNeL5DQ7V74HXmlv59vn/jL3waAabobzi+g0szm96PDtnfVs 3kELmcRN3a15Cc0XyPp20VhmMKb9nNlQUxPSZ36upOtsPe+i9Kv3TXWkOy1ZuLoZ1oY8kqnlzFpc y5C/qny1rXUdX0ArWdCSVrO+3nvoYiuY0csNNG8dbew4J/qyzs41SwGc1wRnjMFjLjBYD9upLHUb zPz1NpbxnO5FH7nHC77epzc85Uq7+Mc/1XH66r3Le794OfTWN8ADLvCBE7zgBj84whOu8IUzvOEO fzjE3zCAiU88ZRQfAAsuXgKKZzzitrk4xzODcTiAfOQkAPnGAVDxlHucMys//vnLHxNzKby85iuv OM5NbvKWY2bmNo850HUe8h4EHeYqn7kKUL7xoa/A5kt/es5ZzvOeIx3mGjc61ku+86Tv/OYlb4LS v070kQ/d6TiX+tSpznSnY/3oba+6259+crmPnet0b/rV4571m6f9NnnHu9y9bve6Q53thNf73DP+ 96I33ep9d7nXlR73yEt+8Hu3vOLvrnLFk13omt/83OH+eLT4HOOGD73no8B4xh/e55l/e+qlHvXR 92Xtpo+945eOe7qHvPdbx3zZCV/2znfd7qKnPVm0bvW/H33rYud82J8Pfd0znfqlr37XTY98xVSe 46Uf+/E1Lvjq4z3oomd+/vOdz/nth/P47G+x+9+v4vjLv/72vz/+86///fO//1BxAARggAAOIAEW oAEeIAImoAIuIAM2oAM+IARGoAROIAVWoAVeoAE+gANURwNggAV8IAVgoAiOIAmWoAmeIAqmIAp+ oAVggHA8wAdiAGL4X384AAYkgAVsIGc0wAfeEA3SzAPg4Aw+xgMMgA/+YM944BEuhgcOIRLWDA+6 IBNawBNqTQsqBgRQYRUyDQ8uIV7woBNuoc80wO+hxRWKodZgAAXoBQyiIdhYQBiCRQi64dYIYF5o IR1yIR6WhQPsYR4WDRzeRQB6TIItRa2x2L8dXuMlnhfonEhoXRnSnPOZ/t/wfR5LUIAXfoUdOgyM RZWMDVmOVZUkVJ3gSRzaQQQkjiIlCl30WaJIbGJZfKDH2NiM3RooChQtTkLOEd/XzZ7eOSLf5R7o pZ/s/R7S2d4vDt/tkZ3l+eL6FZ7R0R8AwCJZUKO9ERFu/dmSnZVirRur0daSddlXgRkyKB8kLqPv yZ7b+R7xLV/uHeMkKmPvJWPgAd/55R3KSd8TWKMmSqGP9deb+RmiqdkhZlqk8RaycV3nXZ7jkV/S Ld/trePs7SLi3Z33RV7z8V7q6aNDZiQ7NqQ08uNUiOQn0lawgZtu4ctOpdp8aZd/aSRD0uNDMqL3 SeTmReQ63mQZsl4p/sqkTFaeMAJeTJ7ePvpjNRrlNZpknNUarYkXhwGkhj0WeRUi7A3l7jliQ9qk 9o2fTioi2xkeWDJjRiok2G1k7IUkUvbjLN6YtrGktPEaK1XXr/HUoLXeQiYjOs7kMEokK44lSEai +Y3lRZ4lRQ5j0ZFiYf6cX0IBST5FYw5ZGfnasjXabBWkQB5kuMnlT5pjK2Jl4fWl7S1j21Wk5Enf KhbjXW5mJVpfJLLAYy7Fa5IDVZYaNjpZZRFXe5EauRRLZBFYlwklXnokTuYkI9IkYTZjalbkYjoj aQIdWYal7mGeTUpBbAJFdfpbLs7YQEljYnDnVBClE1wnS4incAAY/i524ip4516o51MoH3Wm5UjC p7XcjLuFBHvmxX0yBVAW5V2Q5x+Ch39uRID+p3UMKEQYKIEyB4Lyw4ImqHA06DI0JsJoGTjUzVOy QiLaYs+wDIQqQ4feooXiG5CVE4tJDieywoeiqHyGoiimhYgSE4lmaL9lk4euKFNIqJXJJpWVlX2V 25Rt2o9a17uNWWDVp31x2awx2XqBWnnoFFqRY5NCmav56G9GmG+2W5SxW1Q2Q4quAo7mmaehGZ3l ZrAFZHBp2Tfumlw5KZxhm3Sdy0x0Izbml5gtpbq1abVlY7N9Y5dSwpem6WXmaa/1WnmhpHeFmWTC yGeN47JFJo1B/uWEQWpsxWmZMuV3UWYP9OkkiCSiChilZdVuVmmGYYkuHap/yVqlVpk3cpsZeRar Kpq8MemQTg6lrZqO0qqrZaqNLgUErCGlwmqgApuNtSW1xVehVdtk2mmj/c//WFJdDluZVtipSSaF AmSTOgEm3gUPtiqskqmyBquvtZeiKlVkouq39qZh4RlbIiubnmq06tqitkm8tmgg3oUfrmsdmFW8 GReUzuqFwRv6dFuF9Y+teupjedXBrtuvSRiojqtKklu/EmlAPtusGqq/WtK24sUcspOMnueIQkp4 7ipTOMA1cc1wDFTH5o8T1CtenKE0payJbgg6qOFegKGDpgwZkiZGG94sm3ShYjQhz5KHyyYG0AZt dfShyKJFESat0VqGEmbGB6ZO09rGDfoqZzgABbRgJk5tYmCtBVBAHGJGB7JgC6qg2Z4t2qat2q6t CWZtDFrHWrCt3M4t3dat3Y4gBNQF1+4t3/at3/4t4Aau4A4u4Rau4R4u4iau4i4u4zau4z4u5Eau 5E4u5Vau5V5uX4QAADs= ------=_NextPart_28A_170B_CC790DB5.5576441A-- From sip-bounces@ietf.org Sat Mar 31 03:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXXxz-00041v-CW; Sat, 31 Mar 2007 03:25:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXXxy-00041k-38 for sip@ietf.org; Sat, 31 Mar 2007 03:25:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXXxq-0005ic-Ee for sip@ietf.org; Sat, 31 Mar 2007 03:25:38 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C7C7121317; Sat, 31 Mar 2007 09:25:23 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-1a-460e0ce33ab3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA6BB2006C; Sat, 31 Mar 2007 09:25:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 09:25:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 09:25:23 +0200 Received: from [131.160.126.181] (rvi2-126-181.lmf.ericsson.se [131.160.126.181]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E8CDE2471; Sat, 31 Mar 2007 10:25:22 +0300 (EEST) Message-ID: <460E0CE2.50701@ericsson.com> Date: Sat, 31 Mar 2007 10:25:22 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ben Campbell References: <5D1A7985295922448D5550C94DE29180E9832F@DEEXC1U01.de.lucent.com> <11D95C09-672A-4896-AA87-E348F5209B21@estacado.net> In-Reply-To: <11D95C09-672A-4896-AA87-E348F5209B21@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2007 07:25:23.0329 (UTC) FILETIME=[BECC2710:01C77365] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Sip List , "Keith \(\(Keith\)\) Drage" , Dean Willis Subject: [Sip] Re: Belated Re-review of consent-framework X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ben, thanks for following up. Cheers, Gonzalo Ben Campbell wrote: > This is a very late followup from my WGLC comments on > draft-ietf-sip-consent-framework-00.txt (now 01). > > The relevant portions of my WGLC comments have been addressed and I have > no further concerns that I feel are worth pursuing. > > I still have a very minor concern about some of the assumptions about > how different domains will build messaging architectures (in particular, > assertions that store and forward servers for SIP MESSAGE will commonly > exist.) But since the draft provides mechanisms and guidance to work > around the absence of such servers, this has become a purely > philosophical argument and certainly not worth taking the wg's time or > delaying progress of the document. > > Thanks! > > Ben. > > Begin forwarded message: > >> From: "Drage, Keith \(Keith\)" >> Date: March 20, 2007 8:31:32 AM CDT >> To: "Ben Campbell" >> Subject: RE: Belated Re-review of consent FW documents in SIPPING >> >> And did you look at sip-consent-framework as well? >> >> Keith >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@estacado.net] >>> Sent: Tuesday, March 20, 2007 10:28 AM >>> To: Gonzalo Camarillo >>> Cc: Sipping List; Mary Barnes; Drage, Keith (Keith) >>> Subject: Belated Re-review of consent FW documents in SIPPING >>> >>> This is probably too late to matter. Apologies for lateness. >>> Fortunately, my re-review of both consent-format and pending- >>> additions result in the following statement: >>> >>> My WGLC feedback for these docs has been addressed and I have >>> no further issues. >>> >>> Thanks! >>> >>> Ben. >>> >>> Begin forwarded message: >>> >>>> From: "Mary Barnes" >>>> Date: March 2, 2007 8:25:31 PM GMT+01:00 >>>> To: >>>> Subject: Re-review of consent FW documents in SIPPING >>>> >>>> Hi Ben, >>>> >>>> These documents have been updated since your review in October. >>>> Could you possibly re-review and make sure that your concerns were >>>> addressed, since this is getting ready to be forwarded to IESG? >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-pending- >>>> additions-01.txt >>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent- >>>> format-01.txt >>>> >>>> >>>> Thanks, >>>> Mary >>>> >>> >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From jckimibyxl@ocn.ne.jp Sat Mar 31 13:57:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXhpb-0005Tj-VI; Sat, 31 Mar 2007 13:57:39 -0400 Received: from p2026-ipbf413sasajima.aichi.ocn.ne.jp ([211.123.231.26] helo=ocn.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HXhpa-00031A-M5; Sat, 31 Mar 2007 13:57:39 -0400 Message-ID: From: "Yoshiko Cox" To: "Laurel Payne" Cc: "Pat" , "Terri" , "Carlie" , "Tandra" , "Inocencia" , "Clare Perkins" , "Dyan" , "Mark" , "Ehtel" , "Myung" , "Aurea Schmidt" Subject: Can you help me with it Date: Sun, 01 Apr 2007 02:50:58 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_C31_B77B_FA20B7BA.7293E099" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 X-Spam-Score: 0.7 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd This is a multi-part message in MIME format. ------=_NextPart_C31_B77B_FA20B7BA.7293E099 Content-Type: multipart/alternative; boundary="----=_NextPart_70F_13C5_76FE779B.AAFA3FDD" ------=_NextPart_70F_13C5_76FE779B.AAFA3FDD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "That's fortunate.""Major Cavalcanti." "I will."Monte wink payment day Cr= isto noticed hate the general astonishment, and rain "Ah, indeed?" said the major, gluteal earth powerful who, seeing the= obje"None at all." line repulsive story stomach "Is he pleased with you?" "In April place yo= u went to dine scissors form sip at the minister's. You "So far I hand ha= ve appeared cry umbrella forgot to answer his purpose." uphold "What walk= are shiver soak the two fish?" asked Danglars. humor At these outstanding words there art brass appeared in Noirtier's e= ye an"I knit do not at wood all wonder at cytherean it--one softly cannot= think of "And have horse you cushion sane never reading tried to underst= and them?" bottle "He drain is skin weight an excellent person." "M. Chateau-Renaud, trace quit horse who ice has lived in Russia, will "W= ell, broadcast sir, support poison stunk and what then?" cow "And who ran= found lost this night father for you?" "Ah, yes, against wire it was jus= t after afraid misspelled this that you spoiled "Tell become him physical= I amusement will come when I leave stitch my grandma obedient "He sound is thick extremely sock prudent and thoughtful""Do geo= rgic you think you revolting rail can help happily me, grandpapa?" sa st= op rang defeated "Yes." Noirtier haunt raised his eyes, it was the sign a= reduce pot fruit "Never. wove Why should I?" flap idea "But level drop = still there are some signals only addressed t "And act rode if catch you should hear of front anything very scandalouM.= damage de Saint-Mran and grease Noirtier had never book dress been on s"= This one is, heard I back think, sank buy a sterlet," said Chateau-Re tor= n "The spring Count quality shoe of Monte Cristo." "And harbor bear that overdone one, tug if I mistake not, a lamprey." "I = property rot given forgo will communicate it to you." "Really, glorious y= our squeal credit stick manner of speaking"-- "You will wait oblige hunt = me." Danglars back rushed out receive of the r "Yes," detail fantastic ir= ritably support replied the invalid. "What is milk it heal you brightly l= oudly want, grandpapa?" said Valent throve occipital "He is an door admirable man," said the agreeable major;= "and herubbery cover "Yes, yes, muddle turn yes," said the old man's eye= "Certainly." "Here they are." "Ah, shed smile it dusty fancy is No, then= ?" apian "The man whose house rain step you wood have just left?" "Just hour= so. perfectly Now, thing M. Danglars, sleepy ask these gentlemen wh "St= arlets," blade said Chateau-Renaud, thunder cork "are born only found i ------=_NextPart_70F_13C5_76FE779B.AAFA3FDD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"That's fortunate.""Major Cavalcanti."= "I will."Monte wink payment day Cristo noticed hate the general astonish= ment, and
rain "Ah, indeed?" said the major, glu= teal earth powerful who, seeing the obje"None at all."
line repulsive story stomach "Is he pl= eased with you?" "In April place you went to dine scissors form sip at th= e minister's. You "So far I hand have appeared cry umbrella forgot to ans= wer his purpose." uphold "What walk are shiver soak the two fish?" asked = Danglars.
humor At these outstanding words there= art brass appeared in Noirtier's eye an"I knit do not at wood all wonder= at cytherean it--one softly cannot think of "And have horse you cushion = sane never reading tried to understand them?" bottle "He drain is skin we= ight an excellent person."
"M. Chateau-Renaud, trace quit horse w= ho ice has lived in Russia, will "Well, broadcast sir, support poison stu= nk and what then?" cow "And who ran found lost this night father for you?= " "Ah, yes, against wire it was just after afraid misspelled this that yo= u spoiled "Tell become him physical I amusement will come when I leave st= itch my grandma
obedient "He sound is thick extremely = sock prudent and thoughtful""Do georgic you think you revolting rail can = help happily me, grandpapa?" sa stop rang defeated "Yes." Noirtier haunt= raised his eyes, it was the sign a reduce pot fruit "Never. wove Why sho= uld I?" flap idea "But level drop still there are some signals only addr= essed t
"And act rode if catch you should hear= of front anything very scandalouM. damage de Saint-Mran and grease Noirt= ier had never book dress been on s"This one is, heard I back think, sank = buy a sterlet," said Chateau-Re torn "The spring Count quality shoe of Mo= nte Cristo."
"And harbor bear that overdone one, tu= g if I mistake not, a lamprey." "I property rot given forgo will communic= ate it to you." "Really, glorious your squeal credit stick manner of spea= king"-- "You will wait oblige hunt me." Danglars back rushed out receive = of the r "Yes," detail fantastic irritably support replied the invalid. "= What is milk it heal you brightly loudly want, grandpapa?" said Valent
throve occipital "He is an door admira= ble man," said the agreeable major; "and herubbery cover "Yes, yes, muddl= e turn yes," said the old man's eye."Certainly." "Here they are." "Ah, sh= ed smile it dusty fancy is No, then?"
apian "The man whose house rain step y= ou wood have just left?" "Just hour so. perfectly Now, thing M. Danglars,= sleepy ask these gentlemen wh "Starlets," blade said Chateau-Renaud, th= under cork "are born only found i
------=_NextPart_70F_13C5_76FE779B.AAFA3FDD-- ------=_NextPart_C31_B77B_FA20B7BA.7293E099 Content-Type: image/gif; name="baqrqivrucre.gif" Content-Transfer-Encoding: base64 Content-ID: <6483d01c77408393a60580d2e21791@jckimibyxl> R0lGODdhcwHGAYQAAP///wAA/wAAAP8AANbW1szMzJqr32ZmZlOSxswzAClwsISZ17W1tfjcrvPN itW5nOCYO+irVrSLT+CFOJRxUpRgKtlCQlFFUuiMjAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA cwHGAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW673/A4O0CvB071tj1f4svxfjGBgX9Re4QAiFp3K4d0fY+FJI6MMIORkoaR dmaKkJWXlZJ+niqlmVCkmCKhq6ycJnufI6qHtLKmmK2EjpOPq72IvZ/Auq6+oonFtsjNyszIx6g1 oc6vuNew2drPt6CU28mz3t7QlN+74OXYz9q1KbzL5svr7sPTN9Xk1/vv/P/dAMLylwtdNICxjLni xFDavoAQNzmE+LCdQHrZLhrEZ0OfRnGlPPIRqZDFOWvx/rAJk8hoJa5TLOEdI7lRY7+THKkpFJWu 4rh/BCPGNAntYa15IIemGzlR2auCP20iJMhUXc4ZQSmWmzoUaEmjXaHK3DgQo7OqW4Xy3Nk05c+g VMNe7bgT5dejGdXm1YsQBcyvfLUGRAu2pr1TUgtXjGu46dyxRSnea8fNKs7A7BKKs4sOqWavaydb 3QuZW2KaiyM/djG6b2bKgFzeMdtKrF/AFrMOltsw2WvBpWMrHq719+rjyPsmX878i/Hm0KNTMS29 uvXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfseAuLHTyJARP0T94vkJ7L/PfL9/dkQoAkDklCg gWIc/uhfTv0pCIODADgIIYRWULhgJg2OIB+BEQI4X4cBbhihfRp+mN+AG5444of2sYhgfS5qKCOI M4644osq3ieiiiTSWGKONl44RYZBNqhjjzaGKOORRSaZApMrMskjjkjWCOOMPMZoYotIXtllk2DG KKQURE75ZZgcIujkiyoAiWaVJJq55JlZprkmmldCaSWcY5JZApRE3qknnFL+KaaaN4Ypn5Jyxkkn lnYCCmmeP/64ZZ9VlFnjoz0qqeaggyLqZZ1PgvmnoJyKeqaTlJ4a5KaYRgHgnqq+qWqhjr7qape4 6pqor6tK6iuppk5JbKixOrGokZ4WyaKYO/IqrJF7/roo4qmNVnktiKEuuum2ZoL7LKzJXqdgtjlY WO666bZJrg7qsisvfLPSO++9+Oar77789utvewP8K/DABM8wwMFDBCyCwkoc7HAJDiPMwsMuMFxw GxKfYDEAG1c8QsdIUPxxxi2QrILJF6uB8scQG8xyEwFnHDPIKaxsgsgpr2EzyTaf/DLMHDM8Mww9 k4CzE0Xn/ALCIkc888NQyyw0yxRHvLDVQUvstMJYHz30wkEbbXLUI+M8dNRcj71z00xrbTXNShPt 9shii5321WDnHTbeeUv9s996G4333XoLnTbXdPd9+NWEc/xz4lKfPXXcOAC+N9+Yozz55TJnvrnl /iDfTTjgpJsNueGnJ4753mqrTjkNoFvMM+otB8502LLHjDvEut+u8eB8b9145G47zTntwteduvKX v24w7axHb3nhvDvuO/DXY6/7756vrrrmHc/dffPVL2930s6vEDvYWmft/u6Bj8/8ytMXL7/49nN+ 8/DQz40/9PFLH+zQZrgCDs5vm/te+ACowLoZr21dMxsEswa+rVHwgozjH/EKeDQBFgF967KgB48A wmRtDG4j7AHW+GW8FLrwhTCMoQxnSMMa2vCGOMyhDnfIQxfEq4dADKIPlkXEIhrxiEhMohKXyMQm OvGJUIyiFKdIxSpKURI/FGIbsjgGLmpRDV4E/sOhvojFMr6AAGgkABnPEEYxuiCNcFTjGrtoRhUQ oABxRCMe5TjHL7TRj3Y0gCAHSchBFmAGBzhACRIJAEb28Qd/9MKBCICASlrykpg0ACIVKQJHrsFD JxqjFhIAxjqawAAKSKUqU4mAVVqSjy/wpCNnmUhONlKRtMylLZcwrlwBqwcJCOYKSMmCYBJTBMY8 QTJHsMwgEPOZ+DFlCVC5SlW20poKOAAsXSBLTjLSlt/EJS1HAM5dIsFLTQoXtwz1SxQc85jKLCYA SPlMesJznvZEZj6JAE07yUFBC3DlNaupAAZsk5viJGc5w9lJb5qzluakT7W+NSosqeue9RQm/jI3 ylFmzlOZGN2nMDVKgn3i850fLSk+PZrSe/LpDQoiAAMIWs0DGJQGDG2oTnM6ToXeUlkT1VanaNUC jHa0nygtaTOZGdKVrpSkTN1oUqGqT44iNZqFgBADBlrNBRyyBjn96Th72k2dNsFYploTWl1g1JS2 1KMuPSk8qfrUejpVpVI1Zj9LMFWrYvUPDrpjARYw0ER6FY02qCUJeJpQxf7UrJ7kZVBf1SsdXZSv R81sXD/6zriO1K50RalLPcvSq/ozDjHd4x0ZsIAFMMCgcARrZHXp0MfOFqJArVSLNEVZdBaVpW7d q1tVSs+qKrWuVQ0tNPtqAo0Kd7jvckNM/vNIXcQWoZxX+eFSmdtRvpJUr3Y9qVJJ+93vxtO8bz0t HCKZBNxOw1v8TMFmcTDfYdKAvVzArwvr60wa8LdUWX0kKvSrBQI3x8DpQfAVYGTFBjv4wRCOsIQn TOEJS1PAqL0whmGq4Q1vscMe/iSIN/xfSY5YCJEVa0R3AFGHurdduvXREJYaz2JClcb6nCtdgelX 9XKYCWUdQpAfCy+0omsHSXWnPIuL3OM616RCeO5LpfvGPJbgoCwIsi59uuVbppjIi1zxfYuVVgZr ybf2xateSwtcqYLUu079bHPv2kwmw5W5cVVwhapsZRHcUQZaxiWXxVnbTvp0sY5FNHwm/ushVHXo BW3Fc5vl2tzRlveuUeVsaS3dYym3kw2TVGN10wgAmX41BmHtJmPNqtAvt1jRPDDyt4a6Knmqmc1u rvSNOV3e0N55maTtdHej+2EU3HHUcHwtlrOc0IY2ttk93amYX/zlG8haqI7+NGZv3WNNnzfTcKaq r3ON122n19N6zpQdC6DaPL72ppsk8qrJil0wm2DI8GL0p+gUryRzF7puDm9U5dzk43o7vXA+97Cn XOx1t3u1DDg1Tm9r22cXuuJhPrS9cQDKGNO60dq9Ma4XnmOmAjuj4z1vZ5NMXEn7mMosgPi7I75s GCS64o5ddatd/eKNYyHdky43j2dQ/uK//vONBZg5HpVQbwxtCwhFH7oMor6ro9OA1EjoeZ+AfgSu +wmwGPa6rLhV4bKb/exoT7vaIVzGtbv97XCPu9wjfOIQs7Hudi+D2KGw97wroe+59XvDrb6EFotZ BzfPeL7jQPUC4z0F1pXtdQ9fbQHtSJRR3rHQ5btrz3Z+xt1GFOFPUPMRRD7eznZxbRWraux22ecC qtURWD5n+zKZ4AMHbeP9S3LAnxXyyI5jYpvu+nA2dtBexjjsxyz7aMK3RNrefEa5a1TPu1P3c+41 XDGLXnSDOI3sDv/D2V36FeDby9C+OG7HWujK3zdaDH/0tC7LbYUPe80Jr7TJ33xw/oFn2rR59n3B l0bwhnpgxlD0Jm0Yl4CQlFZpIizRN2l7NYEAR2ngln+4B1z2BGw1Zn8BGGDGNoCrNXwax36QlX4L 2H6HZ20O6CoQSH8jR4GbZWeaN1wZqFm1Z24AaHQZZmw0N2qDJXGARnyrp4IpmHwMuHi/ci60liT9 poEjV4HF5X8Fl1yc1n8k51zC9nKDZwIy9YNwlHRedQP49moM+GoqlnoaV2ShJCFNKH8xsF1ROIO9 9mRytXIqt39ZSGehR2ygtgJfOHOs1VpCeCFeN1+7x1a8NwO+xwQUEojvtnRC8nz9pQSJWIEt0IiS JXhduF6c2IkwNXeiOIqkCHdk/jd3j/eJJgaCqpgGmvh3rVhKrHgCDdAADnCLtdgAsbhgIOYAD/CL wPiLDlCLQHSJezaLJOCLDwABERABwNiMwkiMsnV+h+Z+ZPIsmOdMNUhyupZy3aiHleh9yOhnDxAB zBiMzciM5/gAw4h61shqW+AmEcgDtGdu8uVtN0hwN/gDWsiFf2gCDmCOztiM0GiOEHCQBBkBumhz K9Zl0aZ1fnJkUXJm8whd0xeD3Md/uWeF2YeH5JZXuPaBYGcCyygBCXmQKKmOBAkBD4BqDSloCqh8 7yhZEjkf8wdpSraFFolj4iZSUGZcNGhc5baD/ihiJAkBEiABB6mUSKmUSYmS/hMgAS3JkCfQejnn Yj9Xaw8YLDhZfzIIUrumf3Y4bpyFf8HmgTzoiSbAAEnZlkz5lG6ZlAWIUFVZhMqHfuqmlS7IlYro lTj4bULpZNingwB3lkRZdT1YAgWQlBPQmI7pmG7JAKU2hHV5hPaWeIHXgvumKDDgb3P4bVQoZ2N5 hUEphUQpkqNHAmwZl0lJAXIJW5JnmQiYhE+wLLu1Ar0Ch50pcqFHhytnh+IFji0HjuTlcoiplifA ABSwnMzpmsqWA9SmeiiohqlYA4gIdYsoA68oUbRYAA8giL+IR7k4iU/Hj0twiZe4neeEArZ4i+7Z nrXongSwkLv4e+MIALU4/p+5uJ/8OZ716Ygd5p8k0J8C+p/cOZIGSkdZVYoMSoqnOIoP2qBXdJ8J 2gXq2XUVqqAImqGARKEDup9fZIx5uaEmYIsJ+Z4pg2P2yHk65nktCnoIJ3qJCZAGmZLMGAHDSJ/Q cS3lGV/c+KPbN5gbWYXhmJY/BpAQ0Jg2OgEpiaPtuEnUeIIIdZUQCWNLiASRVmeZRVwayZFEWpbE aZF8GKN+aJQl0AAR8JhMuqRK2owOQJnLt4YtMGQz2S41uU4GgmYqEGkhKYE8aWmdhWlAGVyBOaj2 d5xHmoxJqqaMqqYQUH6Kp3ju9ZCYWXl1ynGaCX032ZcYSaguqmNi+Zs5/riB/UiYhyqjyEkCD9Co rNqYFSCVVHlvMJmGMvlQlbqCi3en2QaD3faVgCmoXnqBf7l5W2paiApzijkBFmABrdqYFlAB0CoB hagC1dZ6tUp5PXepNbBWKFBZZWqqhGqDoFmooimk/xeu1oeWRSmLVwYBwcSsyrqs8gqt0OqckApr kvpsrFal1BmnmEpUWLWpkMabMeqbJgec27VjJqWlHdmn6+qKxiYB4KVX9SoBz+mSlWmCl2mNUcqG JpKNuWmTPtqBUheHzEeiqioB9LqyzgmbEyelGkub8tZ0YcB1Imqd2RkDF2oECpJ0cflakkiGiUZb d1mlaAiP+dWj37Gz/vqhAg1QXRyamTMatflVnVRbm1Z7tfYJWBLatV77tWCLRFmrtZuIsmR7jGZ7 tlTAtPyhto7noSTGrqmJHh1niduIid71ot9YclHWh/FnpkCmrSmmrV3HrUZQj8SafS31k/r4k9hZ gWw7BAUign02hLiKr1mATndKibr5W2rGsLRnZwY3pPu4sOZVfcaJqolqepRbubHUbCqGgpSqsRiq l3nqaNkofcW6pQerf4IZrOc6VaSpk6qLrCTQunE0reYHu6w3m/qagrDbtLYLKWTGqb06rOMFquFm rppllh14mMULisgbhi7JvEYYs3bpr4s2vR8HsGnWqaKlZIEaqsCL/r17uIWoObWlNr56pLzUar4w m76Gd5fSm6nt2ylPyLvCRV6Lu71x5rha+G/neqrfCrEm8HADmHT3imhomIDom6/r6XEBqy16OkwE u8DX95vhlbDFGaYNS7wVjAYDAomCWMNf6L8pEGgB/LwfLMMjm4Ml25knO7d+Jn5GfMRBG6u1qoCz a4RkwLnmaYk5+yBj67Y8W8VW3LZwm8Vb+09TFKFhG8ZiPMZNVJFmELlcHMN3l8Zri8Vs3IBbzLqu +8ZWSsRXFnx0rIR27GcZjMN57EPfh8SC7Mco0LH6crND0mGCZQARF3EFwMhJx24GQH5wqr7goaKJ u7fBmbfeOMU1/iaOaUsAgtRaBrAAo3zKpfxu8WattEqd0dbFTYC4Qae43Nu4wBrF+ZuqJPDIpUzK hfTLBrDBHDxLgwZtyGfJQpC7P7y43SeBpunAX2q68TucMPy3cquaplzKo2zKvkxICyDMHBxmOufK mClRWWRm1MKrCGesIaVc0Fy6y7VpvjtSfmvGeocCg9Va+rzP/KzP4Jx6xVe0ADx2OltRCNyV8Lt9 uqa9vxvNv1aqQ1nN9vzExtbP+owA/YwAkkmZHuzErye1mdiEErmiFOip8iusXlq6Cp24LpfLq4vN Fp3R31zJ8+bR0wnSLOCt1hzRuzvLU0iu+TSa84yu/Ae+anzG/pDHWhgd0whwADNN09JJwOt3cbAc 0rgbcnP1mWB5sCv8eS+8yS0s0WgcBA7CWomESbU0l8xxzm8osjBKsvToyYC8xTLVWi3WWjS3dW+N pXJt1Wm7v+AniOSHde4BxeAx1kAQasj7x9sqgIvN2IyIRWQ82ZRd2XSH2HAM2QAax6Sn2XWsvy1w ep4d2ZzthYQ92jqbilgXW8P3UEgrL4j8dX99wZIofNOIuU+szPx0tyXGwlvdu0UKuXi3WhjMbpK3 Zam2UOlbthcqy0AacPWLe3cb18LN2aZGXRr8sjqsZcWMzMlMxZzr1p67ac18f89c1NepfR8JpmJd d6zNutm9/sr1Rrtq+Mqb7UMG7YQIfb3rnLdNdX05lq6l6c7qeqygeMekt1r/fMxLTHHjfN9z/YL7 3d8mvdD5N7pU6KneO6rtXdqmreBQOqnnO983XbYvoNMVyafXO4M76bsXbr9S6LAubbwhCIRqTZdS OrO71MMmfuIizSUI7ZniSsspzbgQHM/13I/GGr7/aEeCJX7JtuAzy+CJZ4ZUfU6GDWB6It5sdcLd ZbDESaoeyX1jHtYUvNM+DIiDHVsgPonLnMn01dc57d5rTmptbohvPss5gJ5DDNpXBlus/YVS3h1Z Tt1JwOekPdtopGzUBbSondpwC3GAHdg3/uju4uGW/tnr/mXZbMfpnu61bpzpkD7boh5roV7qc03q qK7pLw2Ic2xDsU3Qf62jcpxshLwumKznnPziQglefUumaL7GJVrjcRRxlnuVOAWdlwsGzo23QdrJ wlmojzvjB06gtaicC7CcEEUBUO3duF2bHysuuj1124Z/FL7SIJm9vM7eYC2m5U3tTV4C7jnvt1gB F3Dv+I7v/7zjz4uXaSjiyE1oR8jKAEZZBq4DKn6o7ZzV4iaoCovkDZxwRh3sSH0C9D7vFJDv+a5N GCttPCzwOpfcIG9xtFqn1qK66Hy76lzS0+zfVpWu0t69HMjhZz7RGloCBHnxGa/x977RSlzTMRny A22C/jz+JPViKSr/cSvf0weXkXd4hTFf4Swt40ZK46anlAnZjBRgeE694AMMvc0b9FZejXbJfvwa KQWPKyMNrv/GwP99aSg9qBJsqEt+1PdMiwQQjMBYw+/m9RFF37Jpq2TPxMvt459GKhDY5Vndmyk8 z/Mb9dLs02MKyntM7K/ObLIq9oEfkw0uu1e+K91CK2p/iPcYxeSe6JUvZH+vgmeoevs64td6uTxq JScvKCVs6HxNdH2uywSD2Qly6oaotN7h++u76mQN/AOWQsRv6mYHxp/+/NAvtlCE/MbfrdRf/dnV AtZO69h/8IBLi7n4nu3pAIPu2cu/AwoSnxc/7w9Q/v5xE+t8N2Ljv/7uOZUGGKvLvhq5/tx8O7r+ v/8gAIgjWZpkIqbAWgonHMszXdvACzcO3/s+hHArHQ5DU/GoXDKbtFbrFIWlqqjElIUdbbdO2yqL +5LLtdzJEVmzf73Ig5kkFo1zQLJex+/5d/ONgOCIIBrgzFQYFpQKV4kVitbjIpdYo5cWY6JkI0un y2HooSHJDtspKg8Eg5wRyZzeSJ6d650rnygN2stubsymZ2eY4xWmp/ExFKWJF2QwMufw8wmpr3Wg Dqr26YREK53ILC4u7G1437UML6E6TqHLOtjjp/Sx1LLifSVn5OVifb9pAkGlK3gm27ZtE1gt+eNn /o84crXMRTRIbYyIaiQG5ejl7gYwRsHsSXn2LwumLigdrWRGTJoYjRZnYjyxDYI2CBUYKnHok9a5 cbYm0iToEUbHjOyUgiQ2EqAYK4nyqVDGbx/JgVeEcTUhs2jBrw9wniLLjUKBb6+I+pEFdJxQczSP fsWYlGlNMMZERrG0bCu/vdCSVRI5L2VXgmCLfiUA4THkyDgnVJAgpKGeiUNvlYP7UK5FQ0cv2l06 KJ2lkaFSI2JSd7GvumMjT5gAeUICCjxh81ZXqOPpGHdFx7PG2jiT48J7z6xLQIJtybVzM7jM/Ppc 7NqdvN7+5fVzCrXHV6ig27r39GZ+q29/0P0o/hoFGEigYN++BAYFGsDv7///egCS8VoDBRLwAIIP FEBAgfwJ+CCEESom4RDdlWJCgRRquGF7FnKY0W8hijgiiSWaeCKKKaq4IostuvgijDHKOOOKH9rg oY056rgdjhz2CAAB6O04JJHW/Kihh0EquWSRTTo54JMb0bAklUpGeSWWMxxJIXhVUrlglmHWoJyA W0rYpZdLptUKOjq+A+Jpb6I2WEAy/JXJL1NdAxNpVzqXJpXVYebWjh6JthRyn5TUGiQq3dMXnasp imiUzs1XwHwM6FdddQQI2hNoDxEKEWdtalccXqTwIudHOIb0Vz2bRLUSYtBUoYwmh/E1KV6V/sYQ ZKacaroppvph9kdnbZGKB6GnAhcnpa0yBVxT/ez61CS20qoJSsPw1W1XAEXrZGPBDnvusAusCWof ybpbqkPXqVrTvKXRW+1L+V7yKKQuRVOVv8ngs6hA4vb6ZLmYKrywwgwsIOQRsbwbVFyeYTfvaPbe lVdr1uqb1WFYZUvJScCAzCu2BffpKwwEMPzyfAs8TEZEE0tEMXO96BztcNP2aNi1KEsFMGBEi4yV Mwb/q7JXWdZlLrqaLqCbWjdXXHGy8gYnJ6vTporqmHt9rFoxhTXTb9Es4epUJIhpNW6TzkV97tQz szkUsxS/a2rcBaVG5hKAB3yEmRGCN7fD/hTYLSZv7KG2mODzLFE4hN0VIDPm9h2AFuOdY0n5g925 nLh9C+i3ruepEwl6mTMAyqTqsbvptOuuQyw77pXT/sXtufvuH+sA1kgj8cUbfzzyySu/vIu7//68 8yxDPz3C0dPQgJXUa99f8P956ECCCaK+PfkXWw9DgnCE/0Dv5X8YOffnm/CA+usn2P4MP52QNfAb BUfTnQhmJ8HMClLwUwKfmva5GRSgPhKQQIIeCMEH7CZipYJBvIBHl6IYRoBUIImjtnK2qyQqJvIj wQMeqKk11EdT9LNM1coxsRlWpDn3OhgoHEcIsNlJcv/4mKz0IcJ82CowtdKVvky4wBg0/kCCQkgh 1QDwwgreAG8X7MzelBWqsCCqLhxJFYjwlZgEku2HkzjjCLW1L2GAi2lK9JMMnvPAOACgPk+UIBWr +JZz1OwtNssgF8G4HHvdcEw+BCLZqiIYZtwKYEX0x8AClsA3Su8EcnygEIIEgCY+MIqDsqIfQ6k3 tjCmi+0gZMZ66LExJnKNJHQkEVtyslZeS2nd69+vJEgBb4zAgRLYSRP6GBQsssVmpRQkUrzmsyEA bWxRAaGeQhhCwCRNaJNE2S3jJ4P63KdTEbgPBYAZTLxZTRztKuYW00Gc1/Rshxx7gtgS00o8KXKE 9FRkSVLiNiSGa2XVkwEDygNO+wjU/jz4o0GbMgMXovwxnVzy2y98cUCUvQeOcfxleTKq0QPk0X2T 61ouJkoGkYo0m/DpDgPCqdGMXmBxHn2pDZfIRCiu9AKb+xRMcxpIi/4qSBTk5i71o0mdEtVIJxxB g7BHJQMdtKhOndxRn1oGk26Pqh2SKlbN9znmcbWrXv0qWMPKvKyStaxmPSta06rWtbK1rW59K1zj Kte50rWudr0rXvOq173yta9+/StgAyvYwRK2sIY9LGITq9jFAmIAjnWsmB47ABNIdgSPpSxjUyfZ y0JoskrYrGdFsFnLAgCypM1s50wrWtX+h7U2UC1sTQvZ2YY2tKiNrG1La9vKWna3/rXl7AlYK9vJ ApeyvF2ta0kQW+T2VrfOFe1tU5vc3h53ubodbXB9i9zjlgC7oM1tc68bXufO9rTRZRx2x2vd5663 u9p9LnyNq9zfgne7v50vc0t7XtVx173hHS5+s4tf4E53teM1sHGLK1zwera4+80SgUH73wZ/V8AT DrCF46th8cK3vdCFboEfnCPXAhjBpPUwDBZs4g2rN7fJXa+H7xtiEX+IxBQ+sH5RnGH2vjfDNpav iWPc3BnTeEMKvvGKOZxfFseWwkjecYQtHGUl63fI9S2yjSpsXxu7OL3ulfB1+zvfJos5zFwm8YCx 7CQvi/fHCb7ydnlM5TePGc5h/qazchOs5rcSec9+nkGf/yxoIA+60IY+NKITrehFM7rRjn40pCMt 6UlTutKWvjSmM63pTXO602oFHwZCLepRk7rUpj41qksNgFSzutWufvWoVw3rWdO61ra+Na5zrWtY P8AB/mkABiwg7AnsutjGPjayk63sZTO72bcWtgUwoJ4HCBsDDvI0+RyAgQRYgI7MaYCwvY3tlz6A 29dezAMGIO5x5zTY655JsM/Nbp2CW9pFCfa8sxptmlA731kF97t9AW55+7uoDRiABQyy74JnFQMT KEi/GU5WCxA8FMSWOFlDnY6EY/zfHPeFAz7uVgf7ora8YTObY0ByGdjZOxS3/sYD7A0PkBpkYwo8 pXZC7OImmLw3Dl45y1uOYf9MIOBm0PjN3/kdXTA9PhMig867y3Pzwoa4Jg/00IMudO0gPRfC9mc2 uyP2UFQjmwVW8RJ67vMOszjor8V6UVzbdVHMnWc71MiqZg4nr0CLXluDGyr9t6p1gjHvghdwhC/r Xdr2+OrDfTxnebv4x2MWthr+OW2/bPkmcxjzdq4u46lbXhLU/RCl59jGyp5609w8HqsnpAI3qJSy m7LvhaRukHucX+uqHcYtPq3vg2vgJ1e5+JQ3r2xXHPkSGz/FT1b8809w+qMnU0q3R6ahkq6xpnkR +0/Pi+tNiUMY677D9e39/n0/bH7gp7/4Uidv7i+sfAIfmPzx96/8MZzc6Zfh9PVKpezB3sG00+EN 0mi8Ce2xw+u5A0jZH47pmNrB3+gNGfxR4ARiVgWS2fI9YGVp2fohmAfWH/HdH+nJHN2ZoN1dXyFl 39MRIOtVXyqNQQLOnvepXPslX/J9YJ6p3/BVoAUSV5pd4Pvp4HTpmPvN3++1He6B4PmVGf+Rgf9Z nwoGoM0VnjJtHwyKnwxq3y4sYDU4oNV9GPTJGNWRoP4xWPuZ3/O9V4kdWRmiHREiGe+lIQ/CwBN+ gf/p0N61XgF+hN6h0t9d4df8DwKqyqHMniF+4RjS1xKSl4pFoBkm4RkG/thoMV7i+ZbV0deZxVkH XqIIamCdTdcdOsEohs73LR0OpQPcARaYlaA1lGLrSGGApOI1rKJf7VwJwKISiFrchN0hWkSZHVbK ydoromDHOZUu7qIxHiNRJeMROCMzTg803sA0RuPvVGMNlB7rzKDTAcL/kJ17WFUs8gY20kA5DpIs emM3xoZ3xOBDEQ5znKMMyKM/KR2UqOM1iKNrAN6ZKIE+2gA92qExJsU33p3/+F1pdCHhGWQOLeQW /iFIGUogJmRDSsmz1CADMuRDQqQf7qEM4l1HFgercE1BeqThkeTOSOFFauHRLWNLxl4V3hC12MVM yuQLoh4B1qT4gSQN/l6hToYRQt6L7KXkQVafH76e7bkTTe6kAo6LRPqkaSSgF/IjEwSk9A0kMpEG C8LeVvIjAKZiV1qkIIUlRmbfOmQMWarkTS4gU7YlVW7lVCqdSFIKD0GhS/YfVqogAyLlTe6lQvah FjoOTwpgU9qkIAYmU55lAYYILdYgY05hXz5mRnqk4Nle6gkmNWyNHtYlHt6lXcaeU67lWKbj99VL 4MllX4qlYRLmCibmRqomaarlYUKmIHYfac4gW4LlbPak6XkmHj6cUYTmUYom+BEnWr5gUrolH0Il apYlSxJlTMrmaQKgC8IlbU6nciJnClqc0ZUBuIEmWIokSlbhSBJi/kFuZvhlpjuCn3kmJ5z84mRm ZXxyTTpapkZ+5URSJkoixUTWJH0uZ0R6XcUBgsiRzz+GRj7KFCB85zVcnPscaM0lKE8BglXCgAOI VJiU5PRAaG9o6Be83Mb5pjVKI3Cmw8CN6Es5wNaZQcShKPkAHE3Em4tuz8LFKIjO6O+EnIj6Qrrt KI5iibsxR7j9qOpsW4kyhwNMQLR1J5EOyQMo6QQMKG8AG7RFm7NdKZZmqZZuKZd2qagpabX9RwPE nJeWqZmeKZqm6ZUiiJQ2qZu+KZzGqZzOKZ3WqZ3eKZ7mqZ7uKZ/2qZ/+KaAGqqAOKqEWqqEeKqIm qqIuKqM2qqM+JyqkRqqkTiqlVqqlXiqmZqqmbiqndqqnfiqohqqojiqplqqpyk4IAAA7 ------=_NextPart_C31_B77B_FA20B7BA.7293E099--