From simple-bounces@ietf.org Tue Mar 1 01:25:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24893; Tue, 1 Mar 2005 01:25:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D60pu-00038k-1w; Tue, 01 Mar 2005 01:26:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D60og-00059k-DV; Tue, 01 Mar 2005 01:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D60nq-000507-I9; Tue, 01 Mar 2005 01:24:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24796; Tue, 1 Mar 2005 01:24:17 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D60ok-00037e-3H; Tue, 01 Mar 2005 01:25:14 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2005 01:38:56 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,126,1107752400"; d="scan'208"; a="38791219:sNHT74043240" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j216O51j007841; Tue, 1 Mar 2005 01:24:06 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APL64669; Tue, 1 Mar 2005 01:24:04 -0500 (EST) Message-ID: <42240A84.5060702@cisco.com> Date: Tue, 01 Mar 2005 01:24:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> <421F3406.8020106@nokia.com> <421F6AB1.7040107@cs.columbia.edu> <42233349.3020206@cisco.com> <42236E51.1050705@cs.columbia.edu> <4223B97D.6090806@cisco.com> <4223C55B.8070303@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Paul Kyzivat wrote: > >> > >> Yes, I think that something of that sort may be needed, or at least >> desirable. (glob style anyway.) > > > So far, prefix (for user names) and postfix (for hosts) seems to be > working for the examples (which is also similar to the SQL "LIKE %" > facility). sip:*@*.columbia.edu ??? >> Something else that hasn't been touched upon is watchers whose >> identity is a tel uri. I think we have to expect that there will be >> such. Its ugly, but I think there will be need for special matching on >> various parts of these. > > > I don't see tel:12*15*7 > > as all that useful. agree that there is little utility in *full* generality. But I can see tel:+1978936*, tel:+1900*, or tel:*;phone-context=*.cisco.com. (And tel wildcard matching needs to know to ignore visual separators even when wildcarding - but maybe this is obvious.) >> Yes, these are significant issues. Are you going to keep two different >> sets of business cards and make a decision about which one to give to >> someone? (The plain white ones, and the "platinum" ones.) > > > I suspect this is more useful for the address you put on your web page > ("is my shop open?") vs. your business card. Thing is, the phone number may be gotten any number of ways - even via "callerid" from a missed call. There is interest in using presence as an enabler for callbacks, when that is all you have. >> I haven't got a particular mechanism in mind. But I agree there is >> some similarity between saying "I calling but I just want your >> voicemail server", and saying "I want whatever presence I can get >> without going into pending and requesting approval". > > I wonder if the caller preferences mechanism couldn't be extended to > handle this type of mechanism pretty easily. Well, the callerpref mechanism is structured for allowing the caller to select among alternative contacts in the translation of the R-URI. This doesn't fit well into that paradigm. So it is a least a non-trivial extension. Paul >> The point was that phone numbers are somewhat scarce. You probably >> often won't be willing to have one for your buddies and another for >> everybody else. And then there will just be one on your business card. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Innes@jjapop.com Tue Mar 1 06:53:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15532 for ; Tue, 1 Mar 2005 06:53:39 -0500 (EST) Message-Id: <200503011153.GAA15532@ietf.org> Received: from igld-83-130-128-65.inter.net.il ([83.130.128.65] helo=jjapop.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D65xW-0000v0-Fa for simple-archive@ietf.org; Tue, 01 Mar 2005 06:54:40 -0500 From: "Ethalyn Kitchen" To: "Cilli Curley" Subject: Re: HOU-Pharamacy Date: Tue, 1 Mar 2005 04:49:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C51DCC.4224600B" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C51DCC.4224600B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The new overseer with whom Cowperwood had to deal was a very enough; and it isn't anything that'll be very hard to find out. opinion was that it ought to be and could only be sold at ninety. beauty of life without interfering with his perpetual material to whether it might not be good policy to arrest Cowperwood, and attitude than any one whom he had yet seen in the form of woman. his thought and pains. matters. I am making all of my creditors an offer of fifty cents Have a nice day. ------=_NextPart_000_000E_01C51DCC.4224600B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Visit our Amazing=20 Online SH0P!
 
NOW SPEC  OFF  Cia ls) Vi ra $200(120 = pil itra $300(50 = pil
IAL ER: lis $300(150 pil ag ls) Lev ls)
And MANY OTHER.
 
With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_000E_01C51DCC.4224600B-- From simple-bounces@ietf.org Tue Mar 1 09:16:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28066; Tue, 1 Mar 2005 09:16:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68CI-0004Hu-Ho; Tue, 01 Mar 2005 09:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68AV-0001Ko-M7; Tue, 01 Mar 2005 09:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68AT-0001Ki-9B for simple@megatron.ietf.org; Tue, 01 Mar 2005 09:16:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27986 for ; Tue, 1 Mar 2005 09:16:05 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68BP-0004GQ-DD for simple@ietf.org; Tue, 01 Mar 2005 09:17:09 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21EFqA06724; Tue, 1 Mar 2005 16:15:53 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 16:15:21 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j21EFLXD024285; Tue, 1 Mar 2005 16:15:21 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 005QLf43; Tue, 01 Mar 2005 16:15:20 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21EF5M29518; Tue, 1 Mar 2005 16:15:05 +0200 (EET) Received: from [10.162.24.60] ([10.162.24.60]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 16:13:35 +0200 Message-ID: <4224788E.7030708@nokia.com> Date: Tue, 01 Mar 2005 16:13:34 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell , Rohan Mahy , Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2005 14:13:35.0737 (UTC) FILETIME=[DB770690:01C51E68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Comments to MSRP-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: 7bit I am sending a few comments to version -10 of MSRP. They are mostly editorials. 1) Section 5.3, at the end of the 4th paragraph, the text reads: "A Failure-Report of "partial" is a way to report errors except timeouts. The timeout error reporting requires the sending hop to run a timer and that receiving hop to send an acknowledgment to stop the timer. Some systems don't want the overhead of doing this so choose not to but still allow error ..." Well, in my opinion the sentence about the timeout is unintelligible, because this is the first time in the document we speak about timeouts, and people won't understand where this timeout can occur. Since section 5 is informative in nature, I believe there is not hurry to discuss the timeout, which is further and well discuss later in the document. So I would suggest that Section 5.3 just indicates that Failure-Report can also take the value "partial", and that the concept is further described in Section 7.1.1. Alternatively you may want to add a full description of the timer, the timeout and the value of "partial", but I don't think it is needed in this section. 2) Section 5.4, 3rd paragraph: "Likewise, the active endpoint MUST immediately issue a SEND request. This initial SEND request MAY have a empty body, or MAY carry content." I would like to see some motivational text for such requirement. 3) Section 5.4, 8th paragraph, purely editorial "If the receiving endpoint receives more than one message with the same Message-ID. It SHOULD assume that the messages are duplicates." This should be just one sentence separated by a comma, rather than two sentences separated by a colon. 4) Section 5.4, 8th paragraph, next sentence to the above point: "It MAY take any action based on that knowledge, but SHOULD NOT present the duplicate messages to the user without warning of the duplication." I believe it there is normative text, even a "MAY", we should indicate what this action is, otherwise it is useless to have "you MAY do something" because the MAY should indicate a protocol implementation option, which is not the case. 5) Section 7.1, 2nd paragraph: "It may contain other MIME specific headers." s/may/MAY because this is clearly normative text. 6) Section 7.1.1., 6th paragraph: "Success-Report and Failure-Report MUST NOT be present for any method other than SEND. " I would like to change the above sentence to be positive, rather than negative, and add some scope. The motivation is that, in the future, we may need to extend MSRP with a new method that contains Failure-Report and Success-Report, and in such case we will be violating the above text. So what about this: "Within the scope of the methods defined by this document, Success-Report and Failure-Report headers MUST only be present (if required) in SEND requests". 7) Section 7.3.1, last paragraph in the section "If the Success-Report header was set to "yes", then when a complete message has been received, the receiver MUST send a success REPORT with a byte range covering the whole message. If the Success-Report header is not set to "no", then the receiver MAY generate incremental success REPORTs as the chunks are received. These can be sent periodically and cover all the bytes that have been received so far or they can be sent after a chunk arrives and cover just the part from that chunk." So, if I understand correctly, the receiver has the right to send success REPORTs of chunks when the Success-Report is se to "no". Is this correct? If it is, I find very weird that a receiver generate Success Reports of chunks whenever it wants, especially when the sender has indicated that it does not care to know when the complete message is finally received. Actually, we don't have a mechanism for the sender to request REPORTs of chunks (we do have a mechanism to request reports for the whole message). But the current behavior, leaving anything in the receiver's side, is certainly wrong in my opinion. Any comments? 8) Section 7.3.2, 3rd paragraph: "It is possible to receive a failure report or a failure transaction response for a chunk that is currently being delivered. In this case the entire message corresponding to that chunk should be aborted, by including the "#" character in the continuation field of the closing sequence." s/should/SHOULD But also, is it possible to abort a chunk that hasn't been marked as interruptible (setting a "*" in the last-byte field of the Byte-Range header)? At least section 7.3.1 seems to indicate that it is not legal. Therefore, I suggest to scope the above text by indicating this case: "It is possible to receive a failure report or a failure transaction response for a chunk that is currently being delivered. In this case, if the message is interruptible, the entire message corresponding to that chunk SHOULD be aborted, by including the "#" character in the continuation field of the closing sequence." 9) Section 7.3.2, last sentence "MSRP Modes MUST NOT send a MSRP REPORT in responses to REPORT requests." s/Modes/nodes 10) Section 8.1, SDP terminology. SDP defines its own terminology to refer to the different lines. For instance, SDP refers to the "m=" line, as well as the "a=" line. But MSRP refers to the media-line and the a-line. I suggest to use the SDP terminology. 11) Section 8.1.6. This section seems to include some historical information that won't be applicable once the I-D is published as RFC, so I would suggest to remove this section entirely. 12) Section 9. Status namespace: The Status is defined as: Status = "Status:" SP namespace SP status-code [SP text-reason] namespace = "000" I disagree with having the namespace specified in the ABNF. The purpose of the namespace is to add extensibility to the status, but by adding namespace to the ABNF the extensibility is cut. I suggest to have a namespace defined as a string of digits, and somewhere in the spec explain (if required, I believe it is already explained) that this specification describes namespaces 000 that map to response codes. So I suggest to define namespace as: namespace = *3DIGIT 13) Section 9. alphanum and ALPHANUM The section, in several places, sometimes refers to alphanum and sometimes to ALPHANUM. I guess it should always be ALPHANUM. 14) Section 11. Spaces Most of the examples don't contain a space (SP) in between the From-Path and the URI. The same also applies to the To-Path and Content-Type. So I suggest to do the next global replaces: s/To-Path:msrp:/To-Path: msrp: s/From-Path:msrp:/From-Path: msrp: s/Content-Type:application/Content-Type: application 15) Sections 5.1 and 11.1. Length of Message-ID value. According to the ABNF, Message-ID is defined as: Message-ID = "Message-ID:" SP ident ident = alphanum 3*31ident-char This means that the value in Message-ID should contain at least 4 characters (one alphanum and a minimum of 3 ident-char). However, some examples in Sections 5.1 and 11.1 contain a Message-ID with only 3 digits. So add one more character to those examples. 16) Section 14.2. 1st paragraph reads: "If S/MIME is supported, SHA-1, RSA, and AES-128 MUST be supported." Since this is a normative statement, I would suggest to add normative references to all S/MIME, SHA-1, RSA, and AES-128. 17) Section 14.2. The 2nd paragraph starts with: "This does not actually require the endpoint to have certificates from a well known certificate authority. " I fail to put that sentence into context. What is it that does not require certificates from a CA, the previous paragraph or the paragraph beginning with that sentence. I suspect it is the latter, in which case I will suggest to replace that sentence with: "In another scenario, MSRP can be used without requiring the endpoints to have certificate from a well known certificate authority. In this case ... [bla bla]". 18) Section 18, References. The following references are listed in Section 18, but never referred to from the text. [1], [7], [8], [26] I believe all of them should be referred from the main text of the spec. I will leave to your judgement to decide where to include the reference to the appropriate spec. That's all. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From 722wynizv@netcom.com Tue Mar 1 11:18:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11181; Tue, 1 Mar 2005 11:18:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6A5i-0007Hv-AL; Tue, 01 Mar 2005 11:19:26 -0500 Received: from [210.82.193.6] (helo=SSPC07BBBB) by mx2.foretec.com with smtp (Exim 4.24) id 1D6A4N-0007XQ-Ep; Tue, 01 Mar 2005 11:18:02 -0500 Received: from GVJOU-ZZ84 (210.82.193.6) by 210.82.193.6; Tue, 01 Mar 2005 08:20:16 -0800 From: "Britney divorced" <722wynizv@netcom.com> To: mmusic-request@ietf.org Cc: bofchairs@ietf.org, simple-archive@ietf.org, enum-admin@ietf.org, bmwg-request@ietf.org, ietf-rsvp@ietf.org, mipshop-web-archive@ietf.org Subject: Better than sex Date: Tue, 01 Mar 2005 08:20:16 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-message-flag: Authentic Sender, Hash: LrFfPtBe Message-Id: X-Spam-Score: 8.8 (++++++++) X-Spam-Flag: YES X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer Spyware can hijack your computer, change your settings. --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    =

    Off this camp-aign

    Spyware can hijack your computer, change your settings. --%OLATTACH2-- --%OLATTACH1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODdhwQFRAfcAADOV+QFV5fHv3u7s3AMl0tHMyf7+/tZJIQAYlrTP4ABA2AA7cwJO6vLx6gBZ 8ODbxwBh+8nGt/X08QJq/tTu/vHx7a6vtuzr5oyv5QNl8fLw4Pn592mE7h1hb46KiwR8g3KQpfb1 6gBI8T49OedxVPHu4u+figQKOvf17fj37092mvn47xh69wNx//Lw3x5RgQBb6fb280NCPuXs+wNo +gAAAPP9CxZq7uD21UA/O/Pz7iGH/uPg1tXf6BFT4k19wREAAAAEAAAAeHCPAGD0bgAOAAAA/orU d2D0bgDs////RQmRfE4JkXw4bRgAJAACAET6EgACAAAAkEGRfFj5EgAAAAAAyAWRfGT5EgAAAAAA yAWRfEBtGAAw+hIAUQWRfNgHFABtBZF8XG0YAEhtGAAAAAAAAAAUAAAAAAA4hkgAMGsYAAAAAABY AAAAgQABAAUAAAD8+BIAqEIVAOT5EgAY7pB8cAWRfP////9tBZF8YhmRfJMZkXyAwJd8cBmRfKBt GAA4AAAAXG0YAADQ/X/M+RIAGAIAACj6EgAY7pB8eBmRfP////9wGZF8AAAUAAIZkXxcbRgASG0Y AAAAAADQYhgAyMABAAcAAAB0+RIAAAAAAHT6EgAY7pB8cAWRfP////9tBZF8W/CAfAAAFAAAAAAA Z/CAfN7U1HcAAEAAAQAAAADQ/X8BAAAAAAAAABABAABIbRgAMGsYAAAAAABE+hIAVwBBALD/EgDz mYN8cPCAfP////9n8IB8XFdDAEhtGADe1NR3JAAAACAAAABwOt/g5xfFAUAMJ+HnF8UBQAwn4ecX xQEAAAAAdVIAAOiF11poCR0AAAAAAHB1FABpbmctbmV3LiABAAAA0AB/AAAUANj4EgD4+hIANPsS ABjukHzwBpF8/////+sGkXwPmoB8AAAUAAgAFAAgmoB83tTUdwAAAAAAAAAAAAAAAAAAAABE2kQA 7nUUAPzmFgDydRQAuoZIAP////9wdRQAntpEAO51FABz0EQAcHUUACH5BAAAAAAALAAAAADBAVEB QAj/ABsIbEBhoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePDxEQUKAggMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQF1yGGCChNGjSA8oXcqDA4GnBBAgEDhSAYMAMFQa2Gog5dYTYLea /Bq269exBk5wBas2bQCyZ9Ge8OqWa927bMWuLZu2rdy3cLsC5js3qOHDiBMrXszYJwMDSI/aNbC0 sgGSCp5ObTDyKgwYGTLQoDGhtOnTqFOrXs0a9d7WsGPLnj0Z7OzbuHPr3s27t+/fwIMLHw6BcuXj yJcaEME88+aRNwKMcEG9uvXr2LNr3869u/fv4LUL/xCgQQP18tUFhF/Pvr379/Crl1eP3fx19C7w 67dPfXx88fnxZx192dknYHr5yXdfgevhp+B1BA6YoITp0TfehReuIIICUlGlQHTT/SfiiC4IMECE JKao4oostujii+Kh2J96Mk7YnX8t1tgejjPy6N8AA2jI4XMfStddAxZ8oOSSTDbp5JNQRinllFRW aWWVFMCo5XkLTnjglmDGZ6KO6/F4H45fcmdmjtwBOSCNFgrZIWcEgNgdDkleqWeUHghkw0B/+gno oII24MGfHpyw56JTNhDmo5BGmqKb7o0ZqYX9ZRrfidiZyGmJNLop53N1GskdnoymqmSfDQTaqkCs Uv/AgJKzfsDArR+cIGhBgRagqKqMOupeDdYR64KxxxZLHbHIMlsdssk6a2wN1Dq77LXKJostttVS q+202n77bbfagXstuNKO622z5D7LbX/Wmvtus+EyGyG022ZHLr30vsnemtmNB6R6QI46AJ12npon sHuy6urDFHiQKFtsvdoADg8L5CvDiwrbHr7rWesdAy6QXPKtkd5qMncOukfyyvr+BzJ41V43LbU8 4nszu8YKULPN2FXro4k1EN2tz+0iO17R6Q08nsEIm7odqhzr6bDKWGet9da3BmrBr1Vb6TF7It/s 7rE1i7zsz9qpXB3Wb1u38txu0w0zdW6j5zbedcf/PTffJt8dtLlH98t2u896q63PcKIt7wDdQiuv 44ofrnh6xOZcOdBrm2tp0f4x7imGT28451MJT71w2FRezfXrr3sNNuuNwvczszzrnPbavK/buby4 d5745ZTPayME1iHvgvIQNI/888w3T53y1VGfvPTTY0899MsLID3z7FFapviSjsij0z0KMGoDA6Au tXZU0z6lw4RabH/GhVq88ZRgsT52+QBkWQArJbDRiYh83gFYii60noER0FMlclOGTEeq1MFvdYtS 1OyYxBYqbbBJNrDBkvp3pQ3OjoSq+t+KzBQhHIWugKMjHekGSEPxfAo+CGSPeSBYJjL9i4HXQR8E /8eEIRc47UTri1qIVFelXzkxV7n64AidpEEoKsmJKOSgFfUkxSt28UoqrGEAiXgiGZrxjGiUodNg qEYgwoiH3knTf8g4gDnKsEKdCt2JgFTGglHwYO4LEYEGGT8oPXGLVuzgFaeoSC8e8kn9A0AUF/nE Kj6Sih0kYRZrNyzEcc5dIJsZiUTpnZmR8mPv4o7kvqMz9dSgjthxoHZatqwbhqtpkMtXp0D3nhlS p495hGEZIcjHAaSAguwL5J0wKKVKQrGKU6TkM6dpyUQ60ouTrGb/NLhNblqzVliEZpTCyEp9Set2 49rWzpaGIVgmLV71El48oyVPwpWrWJujJ7cu5/9JxIWSczsDEs8St0d06nKe/qmBBgx3O5wJ9Gxo o1AeQfWjT42umHsc2DGHBCRlIihB6inknqToTEtqs5ojDGEIOfbFEXKzkVAiZykh2tBoxYufOENa vTZHPHFVbme9WxfP6LOvemZOaBG8pdqUdcoECsyBCnyRHIP5rwjCcqIVMqAD0TewYm5UKoAs1RJr JNISLlKalNymFqX5wZVSUX7Z9KaUZHojMClwqmIkERHbOUwzDlNMlhIRwDxlyx3lUZa/zCh9usqp p2KUj1+t4PuyU1ZGOXNWmkRrWlvKulpBMq6czGuMRFu+qJJWUkK80F9dCFVOSbCvESQskCJLFbH/ LhNYKBTnWhlJq0u+9awn1CJnm6RW3T6JrvAx7XtyeNoYBTY8LvShmghW2KzGULoQEtgKEWudProR VFZN7Ixiy1g+ypC2SrwtbqcJSZSaEJGWtdJ7i7tJJyFXldnqz1Xz+69c8vejtssXKZv6UAD1yLsC BljmPMW0oN0IuwHbb36fO88DE7W7oFvwm4ZIoCNm9MPm5SMKkJlehdEus2tVFAByG1dFqdQGGsTs ZrMZxZc+k2KZHC6T7ttACY+IuQnM7l5NS1hMgddCqi1gdX9JI/cAeUCUwusPISwfDZhoRyh6Ki5x BMzEMlCPdVwjiE00Yo6WGMo0qixcoeRZKEnS/61r5hiPyzWwskVUn/xCl5fhmS2diatEmVPsiVZ5 rgARGncPbdZCQcm4Qd8LlK/MpbNEtyykDdqnECqaps/WLMhRms8KtSrTePrnShca0EhzZbI8fa5X Ms7VRoRcLospW2OSWJm0rI6a45wq9gGpAMC2AAUowGswRtiAj+IumouoXDGlj3TKXjYQWfjlMkbY om46UAEF20bwjlZN23mqjJA9Iwlqiq+heqxsDYhejzKR1xQogAUKoLECJCABwZZ3sPHNvnnrG9gA B7i//Q1sfMtbYoni9ZzLBbx0chrQg4YnvnyWSjuPGpSVbjCfP9kzn7H6WBR3pegYN88MN/bjCXbt HbxAvml9snxMmr4h8HA0LXbCGtQ0UtqfX+3OxSU1qxaNLpIt9VjI3tq2Jla4wT0AgKY3XWIEz7fG oh7wAiQK4VjPOsJ13Gu7pptT0Lqyv+wowRbicYGqhe2NuOvC72x77Gck0Q7dDmFyl/uqxLS2VT3s 2KLv/7HdSH93nBuwdKcDwANWl9i/E5Copsd73lq/euSzzvUUCta80E5jhyX8ZSp3qq4U5nbAYmhd NFK0iN4149jDNOQHD33avsyOLO+49z2KO8Tppm37xBp7XTOTdoS3N78bYPgV6+oExQdAAwoe+RNQ vvnF/sDCmytkzwcZy6Xn67MHaX0Db6ePfaU9gq7rwy9BVdwQAr/stUvurrLW2n2vtdGHVFsLUvb3 co43wBPAA8o73wP4Nm8GR28DcG+J53//13yVZ3mnRWTNRn1TpnpG1HlFpCllkn2c13tnl13WNV4B E1vjFl3jNURbpVhjAn4ihky7Z3/YsWvAgiQFwANRR/91BFh1B+gBXwMWk4dwB7eDCSc/03cpPtR6 etV9WwJtIPVAcEJtTfN2WCVtFjhL4bFDRvZRsBQqQQRibiJmtkZ/Z1Zlvhd9mKR4/0ZwsIKD+uaD PlhfwGcjEPiAvSRaXwaBcyRR4VaFQ3ZyFfhCsbZ5+rWES9gfgJc6aeKCYsg//3eDbHiI9gUeHfCI kBiJkOh1ueYvZPR230WHUiVl0DVuS8Z9JbJhN7QmrLWHUHZDjdU0WaVfg2gqcmSIjBiLcDVnHVAB tgiJG2AXHSBe6nRqk4Nnk2NPvnhL8TRQeAZpp/YsIgdyvFNq9CRxGFeMyahQS9UvPoUuF9JyFJdh tQT/PEkTjSx3jDk1aTzXZEe2WGFWR+rRikukie4IKU/2jvJYgavnHgbSIwAWTOPBH0NDJtV2hwik QLNnjp3nba21jkfHgvK4kJcXjwz5kJISeiqSin/4bRz4YK4FfkZWZNTBjhD5kWsXbZBCS0sYfnTE Rh4IkvOYiaNnhN5GIUNjYWkUiqEoAB6pkhFpIRrphDjZkz7JIkAGh0dWXf5BhTGZPhLiKZEVVgoZ JgLCiT8Jkg+wAPe2AVZ5lViZlVq5lVzZlV7plfe2ACVgHVP5lWZ5lmiZllYpAQ0glmS5AGoZl3Kp lmwpljNkIje5bHpHUTsZfoAllFFJh1OJARhgi4Z5/5iImZiJWQOHyZi2yJiO6ZiKOZmKSZhuWR1T qQM6QJmcqZiSSS2PaZiS2ZmkeQE8cJnUkZmb2ZmRGZoV8Jmv6ZqxKZqzGZutKZuKaZp2SV3VsZRf GJjAWT5POQAl0AAokALImZzKuZzM2ZzKOZdfqZwxkAJjWR3EaZzOmZ3auZzQ6ZXSSZ3WeZ3HuZ3k 6Zzd2ZXfWQIfJjB5qSJ+dUZ/hXZq0lf0uZM8yZDtlHYUmCMoOEh1BSpqZ10i2ZMDqh0OeX5wRD6t lY7gRWvh+VcYNR5lNicg0RAHwz6+5ndFV6EdcaEHo6F+x6EdKhAfCqKPJaIjiqEmeqIoyhEemqEr Cv8kLcoRJYEVoBEaOIqjo9ECPNqjPvqjQBqkQjqkRFqkRnqkSJqkSrqkTNqkTvqkUIqkwzGlVJoa QFqlrNECE0ADodE8DgABX9o8OAoaEBAADuAAnxEAJDEQIkESLDEZgoEYYmETc4oWKFGnOYGnjbGn fNqnfvqngKoTj0ECJlCoDwAZSXEABhABlkESmkEkImCjn+E8X0GpaVEcl4qpzVOpmlqpa8GpDvAV oZoWZzqqolqqqDqqYHGmZMGqpKqqnIqpJ7Cpl+qpmWqrs7oWzrOrvNqrvZqqwBqswjqsxFqsxnqs yJqsyrqszNqszvqs0PqslIEUXCEZW3Ecy7EhmuH/IbdiEjAQpr4aruI6ruRaruZ6ruiaruq6ruza ru76rvAar/I6r/Rar/GKqgzgALeCr/vKAMzxr//qHB7SlPjpksF5sD/pkOG5gXb4HlBpPlH4ki9k RkkEHZOFHTwgbxawsRzbsR77sSAbsiI7siRbsiZ7siUbhAirIpXoIg97kaMnIfZhsE7lIi00h7zo XJxSsYF3QbL4AWoYtFj3s+O0skZbhBLZQwwiWGMEihTFswRLHbAoP/STPzbQJwUgK01yKATBtbxi KAsYNirbi6TlZzVkjWASdoCZhSHDVP8FHhRHkwvUh+kGJ1B7sdcxtbRTta2CA4ZiK7eSACN0K2wB siQP47f7E4tjOyxH+x259k+QwpJvm340yyJVGG6FpZ8Tuz4riLfWobesw7f4gzH1kzF+2ythK2fv ETzi6GBLBVHZsTcl4zd4M7u2ezcvU7u6+zYoo7sagLsnU7u9m7vCi1/PCCqsa3Gwm2cCxjbhUmAu R4wNlznSaDM9FS3s1GpIpWk8Z5J+ZGbu5rOy6DqwU75YYwMFkbiMuLiNu7R0uLaYS7NwaIQdxn0a +GAbNkjDFCT/Cem5YTi+fmK+Atw1BfE1n5W6VbK4/AKOhHa8x1hqNwXBFVZyxEJL21M9y4PBzzM9 GnwdF5zBHHzB0QPCEDAA22M9nQi3SyZG4jddZ2cpnBu+AfK5+GdZi/gBknRN8aVIOcxePSxcVcO+ 7XuHMFuP9Qh7vVS5OftG92Fl45Zd8Sl7ftl2mqefd9uO98dFu5ViJwRT0QRfS2J8GURcLsUwQgyx Q/xG6zlHKzxLLwtdTyaUFGYpZlJ2I8i/XijDLVjD0RRcm/ReZfxSwRVFL0YrrGNcP5zAabzIYkKR 2/HG1zaKntjG3xegMZt35TV/pyNW9YkhhvhIJEXG0ERfuiVO/yHUTdMkY4pkUlzsSGDRw5ylwN84 jQ6cvNV7Twt8ZxanZy7HLLkUtz1zy9BIy2hrLJ7mapKzaMPMcnWUy68EOq+2LURTRry0YMm7aNMI zID2LaFzbS2EWJRyghile3qct3xMxrzVx+zVRaF8Y7FoY7HMwkqsJfc4w3RHhwobh/mIlEgpggCJ YH3ItguLbrQ2W/2LxXvMUmj1K+BkTWBTRQxww8VmUhItfZDMX86MacS8jLmsVL04vRUnzL3MzZWW jba0SkXjNNAcxfWRJqEiXXZnj51Ca/DLsFKcdt3VnwUNYu15dqD7Vg/NYohUyuwFxqKszk1ERSvm znO1duKmWv92RcmBGXr53NLhOc9M657RtoWF5WERqm7FNKFT0bkIbc6q8tDYBFyrvFZizCSFPMZs HSX0FVruuV1YDZJV/R1SrY93vSNrNHriY0AiWGvyt542edDqVTVLjda85cf1BWeHbEjURNdOdpB7 HT4+lpP7TMQCZEMB2Vh7FUs+9tRT9pfhQT4O+CZcSF0f1ocR2tMJzTDF9VuDzEG+9cW/1Uy5vUVe fFwBNji+M4wdjS+JNtLIIlDslNwaF43QgtzcyzTbiHHFXWjpQozESDQpt8Dc+NFFZb3e0mgitzT7 4miqZjMC0yzivS7oMy11tmq8NJSrZdiZ14WbbCdT9dNVA8r/CEy0vt2QLeJflUK9DKI0HueSoRax MTO5WDVgXmLVZ6c2YXdp9pyS/Cy9lSy5AY1LG6Zf4IfMRaeUiF0g5oHf/F3iYgPHtuc4w0O2QFVy lGI2eIQzv7NTk2MfusMu0htpDMUuxzzj3i3h0QK92fhp4m3jv/NqIYchy63iZAs0zkzgSDNQAK7j 6T1o1Jy9icZYVjUeN6kjJJ4q6WuAwFZv80aDNlh1FiCDwcY+ssg+GL4dhJNPShU8xjxqMI68PbM5 Ue5KLY422UgtEZdqMBeKhsNyGtdQwgjjT9UzkgZppBZRymyMxDOOOVVnQrXi3BxxBB5RrOs4AqU0 toQ+e3fH/31Xe3gZ4oK3ZsEngPYWcAKh5jY4cDUIcBkbbGq434ocuQOpQHFXfWp0hd2HRn8tZB8o ZCJZoNB1h2/eQzpy2eCWhTEpTMiWyRw5zqguvoNXeMmXfIpnAfy3sYyndQkYtLhOJexrjZKD3QRi T/ziJk2lsyZJZP8JIZlyiUQEgnX3eQKyjxfdHvw4hOHmdpKcZOdIxzoZdLwYzmAt1vXnv1J7zmaM b4xneH2iFBfTACdQcMinfBLffDuYgOWe62yCWpnN1xaWkvArgaHY79s3k80GivTIgY2Tv6JtgaN9 VV0m0B14UQur8CDK8L/ZMl8+UomYb/pGENu+fD34fOMuMf8V3YZjRJJOlXpsNJN16JT8wfLFjuBw +9JIluEU/pJetuU7/82wNPAHz9UrCvTlTMOq7u1V129pnoZYp4MewAPfbgEeH7TAtnWzWPJNi79z a9ORm0apR1F0x0Z77ZJ2px7a5pcfFdpAx2wlOPNalneEfdjg27OdMvRNVPQBF3VkCHBkHvoAJ7Ti Povvm9fU5/j6nGUqb2Bit+wB/4Ru2LA6L7f+LPb4jmyYwmx7GF2+Gb5f4vkn9n9Ut7E3OHlPr/oL uftITPj1Mf0CSvtHqLQ1fR5aX1Vhj4/VR/bQHs4czkBHdJOvCPEmnv7G9h0dwAPuf5iPGAMb0AEK 1MBK6Oz/8FHPeCVHpJSHADFggAABNQQKcOGiRsKFCR0+hBhRYkOHFDUkvKhQIUKCBF141DjAYUeB I0EmFFhDpUqIAzd21FgDYUKCFD2e/OjiIMeSO11+FJBChAIECBo0IEDgRoAREh/isPBB6lSqVa1e xZpV61auXb12FekUYgeyZc2WNanx4cKGFN2uZFiRYkW1CtkydAsRLt67cdXuzVv3r9y+bXMWFFBy 41+WdffaJex3rl/BbD0uLLiyZuOCdF1oaEw5J2S2gF82xozYbluOM1G6TKw4cdChRY8mXdpU7G7e vX3/Bh5c+HDiNA8WR55c+XLmvHE61JDx93Pnrp1KFztzsDZMia63m5x9mDtBxTpFxoYplKhRpEqZ NocfX/58p7GP08cfEXt+/v19W1+Ouv9oguikm9Iy7zUDO+pIPdvay80/CSdEDr3wKMQwQw037A5A BLPzMCIGYWLQuJt+AkpB7tLSjrb1bnNPtw1nG4ikEW+0cTvycMyxRh5R5DBIiXjgAYQXFkAySSWX ZLJJJ5+EEsoXQCDyISKNjDJLLbfkcsoqHbrySC7HJHNML3nYLiwX/x/E7b0ZawRSP/AsjFNIO+d7 YIEEEpCgTz//BDTQP2uQgFA/VzrUUEEXXXTPBUp4KM8YGKV0UUINVRTRSjf1s4ELHh1NUk5VSjRR TE9VtM9LCz1VVVIp9fRRn2p0EIEBIHTzTl135TWhPDHA4AJhhyW2WGOPRTZZZZUFFlSH8lw2Wmmn pVZYIp31dYFqt+W22mtLkK3B2mzFdQQfgTr3IRx75ZXGEXWNjt106+OpXg9BStNHAdl16j7fytst Np1KbM0hxQ4qKV8e7RPovAFqhdGHpRiguGKLGRAhY4035rhjjz8GOWSRRya5ZJNPRjlllVdmuWWX X4Y5ZplnZlkBAv+KuvWoChRQIAMAfgY6aKGHJrpoo49GOmmll2a6aaefhjpqqaemumqrr8Y666t3 2IGFCWw+KmwCGFAgALPPRhttGNZmu22334Y7brnnprtuu+/GO2+99+a7b7//BjxwwQcnPPC0zb6Y Z8UXXzwp9hAggOcAYDi8cssvxzxzzTfnvHPPPwc9dNFHJ710009HPXXVSWfAABJMgB12EmanvfYD bjeAZ8fZi1wBBio3wIATzg5++NUPL57z5AMIPnjihT8+eumnp75666/H/vTWayeh+dkPaP528XO3 +WbeFRBhchgcYL99908Inv3m5z/BgeLdt194+YW/f//6+79f//D/R7/8AVB4J4Af//TnPwYGcIEO rF/+Iog/ClbQghfEYAY1uEEOdtCDHwRhCEU4QhKWMIStOwD3ujc/8bWQfOU73+/Y5oAMQMCGEEBg Dk9wQxzqkIc63KENgbhDBP4wiD28YfF4uEQhHhGJRhyiE4vYRCo+0Yo5VCITtbhFLnbRi18EYxjF OEYyltGMZ0RjGtW4RgjYT3wkKIDrbAc+E7hQYzaLofpgkIEM0GACfwRkIAU5SEIW0pCHRGQiFblI RjbSkY+EZCQlOUlKVtKSl8RkJgEJAQ48oIWfBOXtHsABjA3lZrfhGdkYt0pWttKVr4RlLGU5S1rW 0pa3xGUudblL/1720pe/BGYwhTlLx6EyQvy6zmiQiRzp7Ic5zswJNPEjHYTsJ17QERJ2tIkRbo6k QjORpkSwsy8ReTOcAQLQTBLWGgGsYFzGzNUye1NNZcrTnvfEZ3cGVJ3P0EucvrlIOvPTohIBxZ0v QooCjpnP/4SIQAyF6K6uac9qUhNg9MEJOadDE/IE7Dj+uklHDsomhcZTIg2IyldUulKWttSlXKFA RIM0UZpG9KLAqRNzNAofh4LoIztp5zvLxRuovNSoR0VqUqfSgH9206kP0eY2ZTpV4fS0qlb9pj55 6lPzFHSkvIsRUVOq1K544Cg2CBtaz5pWtvKgAWjlgQc8cAKyvv+UqVTFq64Ephx/4aeiQMEqcCxk nYO55CBfhdFCnVLUunLFrG9l61qPIlfKRtYDam3AXBv7lbvm1bNvEuh/wnKnnQq2QOn0EWKHuhvG bjYrj1UrDtCKAwp44AENkErFqHKCyEK2AQWgq2uz0lnhzOUtkzHMaihjXMnwJS6hCQ1klLuWtqCG JdBFjWceIxq+JLcwkrFuZKgrXcBcF7ngTe5GosvcyegFNZkhzFxK2xLy6Cuk6tIOYgfQJhktdqzC tQps00qBzH6gADhIAAWoQrEcSta3wAUwVogbnMA4xr3LZYxetEuXwJzXwht+bnMrPOK1gDjDGLYw iUHsls4MZrz/Kf6ISgqCovYy1zMxqUiLBXPa4FiVoAJRLX/FGuGrCNjBHviAxZIcXAQ2QCCYtQEO fhtcIlNlwp+V6Dmr2p/5cnVCBXUOgW7U1xSJaCBBDitr/1vlDxhZtm31rW/f7GC18oDKbP7AleHT 3hALhwEb+vNuJiqhLk+EOHxWS2zeouESs7jC0r1xamaT3bW4pjRy4clPEqNfIasZz1OB7cVEPWpS M0CtFrgzm/Xsm758OL13sfGOnRLoQLvgz7S2da5vneuE7JrXu6E1dmrta107hNi97o1hHM1hRleG 2QyBk0ya+1Npdze9zu4zY7b76JVEF8eARYxq5MsdNCtWIq3FvnOoS73uUasVwp/OszzZPW9619ve 96Y3b7rN0eZYqKHDuVCPObqiqgIpPBndUblNGhF0s1nd+Ca1DQj87k+vOj6IxrhTEH1jscRa0BeB gENC3puRR6TkCSn5yYdTEpUDPLDdadjL+bOwMcMJzHQSicL7e+41V/nhEBe1WhPA5A/kMMIWTzZc 8sLtZ3d42t/+drdbHevv9lPkDxl5yFPuAq2L/IZcF0vWeQh2rF896wLIOsoLLnP7yFxDbseXd0D/ wuk0i6XhPqdzb6Gs96NQQOI4eABd6QqAOwu+sUjH8nAWouXdtDxD5XH8v0bLT37BaU5YjftPz/zO /dbdv5s1uuEF74EClL4AFsDB6RNgAQsUYPUJ4EHrW396C8Q+AabHPapTfRXCKxXxiQ8O499esIJy hN98nTzlBV7PeT5nJ/2yTo9uBFhNI4TuERr0U3ruUgSydPdSoTIArvL9qnRfK+RX6e+BD9Aep9M7 G7rpypOfHILze5w33Rc5A/6QwooIPejSuSHzPqsQPAYwv6kwuvErv6mwgQa0gaJDv/PDigN0KfXL KuZDlx0BM4iwpubIPryKP+EIQd74QL2Su5EA/xiP8An7CEBPG8DdEr3uIzryO8Dwg0EGeMHxi8Cu sMD1o6oe8ZGcQg4yE4sSDBAhDJh3+ZCAW5AUQZgBuL6Fg4i7I8DdKror3MFUGzwEJDrwC64GRECv EL8PEL/vI7wd5Ioe9EGYc7s11Lz5S6YhtDyDgcMy2zKuOjj0gBMgG5db4S+rokIrDMNBNL8ujEEt hEAqU8QZFD0sdMRGtMLea0Q0rAo1dMNLTEJ/6g3hg7mBGEHAKg4d8b+a+6iGiTkWFKpOs7vtE0RD fERFBD8s1CEvjMVBxMErpMUrNEBZfERcJEDBm0HNSsPi8DiOkzXuYo5rY7Vkw8BDA45ixJEBkP+x zfCoOrQ645DGgfCwjUiJZ4SqZvS/+HuOwco8dPFEiFmtVVypLlRAREzEWSy6MsRCB3xAGQQ/eQw9 CNTHKOpFdxwuYoyIpWO2huiMcEMMmWAQhGwNgewzhsyxmpDGxJAJhKyRiZTImiCRqtswh0QxvygI 0BAN78o2nXg1ujBIjcQIy5jIRvsMkHTIiZRGqMMMlAgRA1lBhTFFU6wVgVDFz+uKwvNFXzS8lxpK CnStMXzHoLwKS/SrNsyQ5wgNp5QPbwsOIkTBCrE55qMRg7PKaiQoBmkYfhOYmMtJgtjJcrkvdQnE rABKXJxBfOzHV+RCMFzAurRLpaxFLgTGrWD/yh3bOGP0p7/cjYwTLZqryHMhCYUkiRJ7tpCMj3zp yn7zCGnKPyTkscscONiYFVNsu4aBmM47pv/zkbX8Clgcylhkx1osvNRUwKQ6QyDiS+SYun1TtpHs LoUQiZJkOhhbjeuKMYZAiImkTaAoDKWzNuioNsD8sOPTEbAEywBJjnAiCU8MrJrTKM6cTs17jZzM SXTsSYyQDtLkii10xF6cilucwbz0x61wxbtUz32MzWWqv3wqNE2Ejmailyd0zjucOYB7qONTETqk vj3sKoRhmIdJRc9jPvFkzzCERVosStTMS6mgR6tAypaiQVncwb4E0IGSyl4ZR8vs0OKIjvr0/6sn lMzok7v7AIl1OlCGiY2z/E6GY8XSVE3UTDX0lFCjHEQMVanuw0EerUR0ssPHPEFM7JCr0sAPnY8d 4SkPWUH8ijnt5M4DFQjvVFAaPaoTCFIb5EUEkkRCBEowfFAJrYoxpEQu5EWt4FB6YdLd+EQkfQ05 xanpjL7/VBDZYFFPJEvuFAgUSFBz09It7dFF/Mk0bay2PE0Jo484dbkfZCf7YsLqc1TRssbT+r/p eNPsEFES2dMd4UzD4tP6yklARagZncIatVG8JENCtMK9dKkLXUepgEshtTKdQsxKxalLlae9Arcx w9M5bSiCmc9fJahgpS+QMEKAE8L66kSEgP+NgzPQN3TC7gxUKdQ+srozeTTPMj3NCp1QtyzUAWRN q2jTx+NV/NoVIkyTJsxUTOWOiXJW/wOtxChMe0WQFrlJhkmLKe2JJ9TJa925QSXKGy2/tvzFWW1Q G4VNNpXNiVCJ3OSw4lS29JLIRUMvvHAujd1Y81qLg2iImOyMS7vN6RJJSHNMxNDG3gwx+IqJ4+JY 8YKMzZg068oMahyvGWOJi62urrqum20xGfspmJgVjorWsKAVzkPVbE0qdqxBvXzV3aPLKsQKbl1Y GPSKNmUvkM2w2sw2+epGF5PJoG3J72JIm3AJbtMxy+hGp5u2Ygxb33wunf1aGAOJpQtO3Bz/2YqI SBczLo54Sb/M25qICcJNkH+FVj4NVWs91RgpVhdgUG31Vn2Et6Q6V3WJzFDU1QI5DlEsM9Ta3KtS 112F0xqhjxJ9udYQ0XIaOF/9EDHLNKB6FwNFUbMU2OkDicgFvXKt3KO6sg3k1NUVzBtz3eJCVr1o GIQsUgKRJoJ8ubkAjepUtFHUKIO0Dsu4DA4ED6Cak5Q03AJJUuotD+eVu4VUJ5GISewM2MYV1FTt XZUC1/eNz4JLTt6Muma7C4F5NMY8W5OoE+PKiBoAybzVsBnLW4Jcyd+0SAKOtL4tXIPQsZHN3hjD yJgMMYRkr+DUsQvGTdPVTWMM2ZUFTrzd/+AZW9lqg8iF2EzPVNosdV/5heG6Qryt3NRdreH2q68l XV4UbNavnD5QBMs4qS8Z414QUZjfoCYlbNKHApDnA9DmNF1nDeI8XV82STMB0V0ZHgCsoIAu5oHS ez3cw73bK4AGULD3bQAbmVL62Lh3nYuwpQnF/NV5WcaXQEbA9Ldj7DITxsgLUY1J07ji4sTuZeDu 5SiDsGCYm4wNbNdZIb6yDMs1Aav2ZVrhmrjTE+PS44E9KeMBIOMx/mQxhj3Ww+QCiD0LMOMq09q6 3U3WiFtjjElYs81X+15pc8mLqDEcc7S0tV9Zrrr7UExtrMhw02WPVEjhNM4SO0lLe1vNWBSvfUtM DMsMubWR1uU/FJlO083A6f/EUkp2iCxuqQYgYwu4PQu45EyWPdNzstKbvdnLZNOjrHhGVJY61+Gt j8yViM691IBK19Z9XMzVl0zkVCelwxMUkNS90+YLs9Eovhxekf17XTMraG/SQz4tUD+Fk27G1m9W VaQS59LzAACQK9fLPbcagNP7Yncu5dITiAKI55eG6XleqcslDg+ZyZbo5+ZjJxNNUSd+ViPtKur9 0AMJX4E2MyH2jvuwPBe1uWzmTo0e2BcWro92aaORq1Fe6aMo55c+AZj2armS6fRLxsFgjWMOWoxc Ogi255VzTpobj4KxZnXRj3HSV4cap1C8zxvukINOE6/MKG0WUF+taGFdJ4D/1QmoFsCpJuOQJhoP sAC5Epqrdj2v7uqvjmkAq2e4cNmZNVkOS4n3OmD5Cz7M7BGaJMH9AF7Bms8fS+3WPt4ivhe4K4/s FEv3eyjZ1cw9tFKMRmwXVOzJDhqz6mLYm6vZO4Gf+a3Wo2zLBmthxOwnVVLLdKhxTEsuUycVPZG6 xtf/XBdvYr6Awkwc1msTmZM4bREppdQc0cA8Tdw3ZGH23eiEAGd6Xuzg5i2BMOMcQrWfoYDFjunl lmcio2khscn5G2/iWF3/5G69xpeBK90mhkPq2ClxZMJ55Uz31md/PojeHl3I7eijqi0wTmnXIzCk 8eTbA/C5+uqwpucZkRDK/wypH9ZpHYni0jpwfWK8oX6qo665gAlvDRytSXXS806YOc3h97Zib5bv DwfxzALryk6AB3C927s9MwYaqk7xuepqW53qyqtD2qZThYZxItWqIh7aDr/n6ktWbPZpGtc0J65S fZbkxIpvD3ctlCo9HEi9Un5sea7s0pMKdgbp/2ZuP+9yeenhgcJh5VDC1A1f/ZsvnvZuzFXRzKy/ Yp3PKP1UaaVJxrUN0Kzz+c7aKQ90MXay2Ys9l/ZzuerzJy/0QY9nVNusAW/S6lS+f6bP063KySMR Cb/GM/fcYCVqucbcn+K/TPPUM0+YsNQJU03yUGdylgpxl/7k2su9dD4Klf9WdctW7kKnLBafX2Sq Xrs+7W5iPPDOiEE2rc9NaBOxceMbGNtW7/pgv97o3HGXcHvVDiB2d82E0SttYSXXAFHH0D8XdEGf LNLDvQZI9W33dso+7sPr1TD/RjtxJgbXKn5Tc2EFxaC+biY+DNMtD1P03yqeZJPaD4JXKgQa6ZVu vYZv9YfncomnT3Dy9fMGX2Lf4XkC+Zq2eZzH6+NVaA9J94vvJ8z7Rrg+9iNdXn/b9wTx1SlNEw73 yRg+2JFO5xUHd9+DTkLLSiROc4eRVqAX93UvQnUvQuajY61kYsLyMXjn4ae/ySAECarnOav3igTE +1v1jQ4gkr+vgBKoAB3/0IEY6IAb96clPcVq9qumqviW5M+alg8jfD/vTmptJujizXkgPtZ8wVPZ dXcFsXuC3fvSF+u+JxKyKIGy2IDg6YAOnTpGnwkB1t5fx+Ud/4213kbL/8oXQ9mNGtGYKHoWK2St Ss7w2PQSkTQ+Q+ENTpGbhmju9ePyTYzRb4loN/3sj7e+J/wYiIHWnx8DeP0VkToOluWG5K6TdbVm W67+HQm85d/2fzqNIFuoezq3LWYNO3+ZXAz1AggXAmu4qCHAIEGCAwUuFCjgocGBBxkmnNiQIESL DjEKcCFgQEeHDx+6AMkwhQgFCBA0aECAwI0AIxjSrGnzJs6cOnfy7Onz/yfQoDo/mqxh9KhCn0aF Mm3q9KkGDU+n5iT502RNkiG3PgQ50iHDrmGJcvXoFavHjlqthhWIUiVLlzBlUq1r9y7evETz8u3r l+bIkDy5CqYZtSfbkoXbph0wQGhiwI4Xp01s1atgx5MzE+4s4O3Kli9jzvxr+jRqoGRTs27t+mlk vpFj71z8FexYy2l3tx0AOu5ouq+HE687uTjy5MppA6bsMzDWsjdjR8b88bbVwmpvu/gtem5p5eLF E0U7XqoL9Idxbn98ffNI8+PnB3We0/Fg7Y89tr2ee29gItlEVkfeyUUafQmaVp5/yQVGoHXa2acg hQs+NyF/Au7G3Vi4beDlEGbTgeRbSqEdKFyFKdaG2WTyqfgijBXOppaLWUnYIWMBluQeWccpJpBj BgYXXoysXRffWWdhWCSTTaaI33NVdYRffGKZBeR+AVaZ22NCgrdgjw/Kx5yNvJnp5IsPvJAAm226 +Saccco5J511tvnCfgKpmYABffr5J6CBCjoooYUaakACeNK056GNOvpoo4luVpOXCC6X5JY1qZcj mkU+sACbMYg6KqmlmipqDaWmeiqrrbYqAZsLlLDoAq7aeqpRo656K6+lStDABbL692mvu6Laq6nG 6opsDL8GW4Jmmf9ViuJUYooZYY3NQbdkpzF+igEGOog7LrnlmltuDeQila4O7J777rsVgCsrrRJI AC++57Kb7r7juptvvhVcwAO9Dn1qL8D8trswwwvvi5S6DSssMbwCEwwtjyeViMAAJ47woH/ZdcVh tyUT9y0GFai8Msstu/wyzDHLHHMD88562Kcz67wzzz1XAOzFtPo8NNE9Ay0slV5NS6TJTcPIAwgv /MAB1VVbfTXWWWu9NdddvwACCjRBrYIFBZh9Ntppq70222277bYFKoAtNghkv3033nnrHTfYUHZF IlzfkZZplTo6fThe65EXIcmIG5ftgFDu5HdlP360I4jRrmZWkiP/tnjW0k6BbLjjko0On3yKlw6b ZiEOiNt/HmZmEplO+oiY5CLeNimBWE7peZWfC9/6ZiCFTpyW1oLMOLYjj55paujN96HyNJKO+5G0 c4vjVzNe73i0quUe+X65n8XQcekXT7x18JWH2W+OrTQ//fXbfz/++eu/P//9+/8/AAMowAESsIAG PCACE6jABTKwgf1rCQSBpQAYUJCCDrggBjOowQ1ysIMe/CAIQyjCEZKwhCY8IQpTqMIVprCCLnwh DGMowxnSsIY2vKEFNYjDHdIQgwxgQAB+GIAg/vCHIhBBERmQkghGsAITzEAGWCDFKe6gilYEABaz qMUtcrGLXvwi/xjDKMYxkrGMZjwjGtOoxjWysY1ufCMc49hGK9KxjnbcwRRb0AIHKICJClDAEANQ QygSspCGPCQiE6nIRTKykY58JCQjKclJUrKSlrwkJjOpyU1yspMVDCQoQ/nDP5JSJRB8CSBDqcpV srKVrnwlLGMpy1nSspa2vCUuc6nLXfKyl778JTBvCUQOzABSHPjjSwhgIgQQ4I/BfCY0oynNaVKz mta8JjazOUQDmKCb3SQBOMMpThIcoJwzUEAyl9nMVGqzne58JzzjKc950pOVDDAACbxpgnGOs5zl NAAylQmcPwJRlX06AUJP0KdpIjQAC5XlQQMZ0W0a4AS8bGg9M/+q0Y1y9J33BOc+/RTOf/bJnwcA KDoFKhqCrnKiQ8QooEAZU4caQKI1jelC/0RTmdY0lA/9k0UPGlSd0tRPRTUqRSlKVKUitaNOfSpU oxpEfI7TTyctqUlPGlATNVMEQ+wgQv2EwYNekKxkvWBYK1rWigrVATQdqkV3+ta48lSoQI1roBRa 0ROsFaEOMKta2wpYvv5VrSyUKmITq1hbGuAA/CSBVbP6T1Kq1CUK8KogNdinDA42oX4961gNe1DQ Dja0bd0gUAt71tWy1bCFJWxpWctX2bKwtra9LW5zq9vd8ra3IbynY8Up0j6lQLIGSElKB+rVCjoA As6FQF5P4Fz/QCF0uneFLnUP+lztYve52K2ud73L3e+Kd1DSte55taveiqLXukANL3zjK9/50re+ 9r0vfvOr3/3yt7/+/S+AA/zfv5YTnCIdaWT/ecSUKHOlQKQgFGkwgQlTuMIWvjCGM6zhDAt1wx7+ MIhDTOGDirjEJj4xilOs4hVXmAYufjGMYyzjGdO4xja+MY5xfOEc8xjH0DVpPyXrz+MeEZ0DfTAM IjxhPTK5yU5+MpSj7OQNJ5TFHpYylqXs2RNkuct6tDKYwyzmMZO5zGY+s4chMAMhs9mkBlAig48c ALcmOQM9vjOe86znPfO5z37+M6ADLehBE7rQhtazczkAqRlw/wDOcV6pAhhA0CRSutKWvjSmM63p TXO6057+NKhDLepRk7rUprZ0KVOt6lWzutWufjWsY53qSsu61ra+NWUHSpoR8LrXvv41sIMt7GET u9jGPjayk63sZTO72c5+NrSjLe1m52AEObh2tbGt7W1zu9ve/ja4w/1tXmdb3OGWAbrTrW4ZRGBj K7XU6uLdE+nx5DDbU51ONmWYfd+bIYrbHlNql2/GXIjgg9l3evx9E3oLRCoAZ3iGavO6yoBsBe62 LLyZBHB5c7zjAudeSCBecMT4xTmW2c6GHmLxwGGcWt36eMdj7jSYn8nkGKIMSUS+E4dXa+I2ws7K uaqAjL884RqQkznSTTYh6X2oKeNr+E/ss/GhAMZ3uxtA0P917fKm0TzpXq+39HTeGto8HTJDmTrJ M7Sk7PioM1l/99ZrgoMB4GDuHWsA+/Ku973zve9+/zvfWwL4vfOgAV9/Db5RI3LV3bwmR68Lh7ou 8e5Rhne2GZkL3t5yptmEBxb4AOhDL/rRk770pj896lOv+tWzfvWGP7xfEv+kPNUH7SMfu2BoIzKS aL6ZRLfJAD7f+uETv/jGP77qXw97qCe8+c6Xt+SrbvCdR91CtZFQgwTQ+6HHnSY4ED7ywy/+8ZP/ A8r/i9gX3nCG63v5dmkQbCYUfRyVHHbN0Vb3ev8lnXy//P7/PwCa3vmxn/slnfY8RdlBXuXZXlXc R5bknsr/XdyQ7ET/BSDqeYANQFAGtsQGNkAHfqAGesAJWGDxnV8BFuD8Rc5ipF/Ard+ZVIvNgYj1 6N/vyR34kSDpYSAF4IAHaqAPcuAPeqAH4IAI4iDrmeAJwt7t/ATPaYjCyYaH2MVxiAyUVOFj0GD3 MUQFGuHoYWAQgiAQAiEP2sAQtkQRcuHpIWESet1eMMUSIsflwIb9vWDlYCHn2SAaduEGUsAedqAH eEABNAADgN4fhiAQUsAZ5qHoqWFPIMUaBsVRDEdSwB8dLlwcKoUjDkQkNgVH9EXyfI4dUuAN5qEX hiEfNsAQJsDpnYAQbplnKWLoMSJPJEVBJAgt1qJ43GJr/+hixKnG1NFiQlDFANBi9K3FtpwcTYQi /40iGpZiD3IgIDZAIP7QB1Aj6DHACfRhA+ygDVjACMKi+XEiTShEUgDjQpQjLqYjLpJjTSQEO6rj OlLEODZELb5jMJ6jPKLjOC4FPd6jP9IjPvbjPMYjRMSjOpKjBqCjQkzELa4LQOaEOwYkPDaOlFAk WwAI1rnbAEzgMoLjBzjjB3pAAjSABTSAKl5jNWJjNn6hN3qkLO6EOaZjTN5jPcpjPtakQtpkQwqk TrbjRchkQPKiTwIlOwajUd7kQ/YkLjLkT/ZkTnoEQqCFLgolUSIlPEpffqzI1WVdx3BkTmyhIoJk CH5AAf8MIun9EEKBoQe2JDi+pE5kIkXw40BqYjnSJE8WRCTqIzySo1z2Iz/aI13OJV5O5VJIBVzG pEzm5T7uZGIahEW8o00GpiYOo0Yk5WAS5lKUI0Rs4nRsHCWaTsVJ4P59JTNyYSniwAcSYUqaZTV6 1gBoIwcmwDfColvWRV8enuxFJl5Ox4Jky23exBuCSdo5YVjIB3xIRkaynFfiBFiSolpuoAeg5Qlg o0qegGM8p2y65CPmRW6+SGGsBwvyZmp8jwwmBuNkxRL+jfZp5HLeRHM243P64JY9I31+IFvS5l8I pV3mBAO4QH/6J0P8Z2oIqIBqSnjyRH8WaGc+BVW+pW7/BuNH1KVPPiVTAuRtLqRjqsVuVmZl7mdE qCeQKCNpeqRYhmF9fmFLoKYG3qci1iZOGKWE7uZgSqRk4oSC+mcRCcR/JqiO9iiO7iiQKuiN/ih6 5CiA/lCPIqmOKqmSvig7HoRiyiVnwqVkRuQ4uk46TkZRCqZEIkRkeuhNZkREZGJEnGNdQo9jcOVG jiZzlqYRlqiKmigYxmmcemABzGaLiqM+6qUjeihn6sSOBiiAHimhBimP/miT1kSgKk4SDSqhJmmj DulcQmiF1mOfPqhVTmIN7AdkRqhS7uWXFgRJkGNHMOZBNoRV3KOGbipCHAQVjgRXeowokmh8yimK buMH/z4Anuahi94ETf4jZB5lqNqooDoqkBbroBJosiKrsaaHsj6roEJrkjooTlKERvwqUIaqZm6E VVKmr1roUNYkQFZmtg7lU2aIY75j4XiEiLYprd7qidqqnOqqdprMjUpqXXRncXTi+xEI5gEf7UUd 2nUG65znkVxkBConm7qnm+JgicYrxG5gndpAdrbldvrEgcIhA6pgCn7cZ2al2pGnxGmLWWxF8bQr w76rvEbsD55ibO4qGvYqg77oVdoEZDoFYu6cBngXTUDATfhsTgBtzzpXtQit6DxeVQQnXuje88if ++TOyEwGytrEe5pmrbKsKeYqzHKhzOIszX4r2ELkLP9yKU6gh9EaLU6gLUOgrdo2BUm0LVAk4OQg rWnoXNOKTHOED++JZg16X8OS4MNereDywDcmVMxShZViq7bGI2BWZVBm6qQapOKcrUD4rNBarguo LebWxHOtredebuZ+buUOANCWbu3Vh9KSx+1JTshMLR6CY+DCq+Cy6AeMIEKRYNdG7rkipuI27u4a 5LAKJDsyHOWGLuhu7vEGbeVyLvMub+kKgOmGrvgA3ObM3I3UId9moUBU7ZuC4Bj64PeKYcS2JACQ nu0GYO4uZu/+6WWu41PypZT+44zSJTBOacPdIs96buZ2bvTyrOYS7doC8P5eLuaWrmNEr/T6hNyi 58YKgsnBPsjZgdx6wv9FVy4s1f6tBZ7mnG6w7NKu+W4t8qVvx/EjxAmYCZ+wAgcscugre2Dp6VJc wq5EBfetFmJw+G0ZNn4kCFIAy/IwbNbnnZrvB5efCMtcxk4PkGioMKpw0jYwT3iFlERczmnAyTXt 05qE1G7MDHffYXAv8p1v6bmiGI8xGYsx6AEAnoIxGoMw8RVxxx2xbNCOdfAGyvUi3c5t7N0f1fEH d5RHE0uxdNgI64JErC4nvnkx8bGx6YHx6LEmCN/uDSvyEV4s840sVpKseE6fUyxwCutF5BiGVDzd ydFOFM8hSbjPtQRGIYNHdyJy652vGqseJIcezMKyJK+e4YqfGyPG9Zb/rC8LyMf2BRz34hwijxNj yVTYm2embu294d8gcypjiuv67RefXvna7iyH8WwW7gfYgDfbAC0PHyRv7S2n3i4PxgNqRwsr8Ya4 MCUzcyc3hTIPbGpITtsRRtIkJ1dZ8Ou+8ujBsvnmMOg98jeapQfUrjfXrkIn8iIvdAgvh/PAH4YM c05QNIX4ccEKBQtXMsjCYI78KzJbIVFMcw0XHzcPohmHczgD9Czv6jYbHwgL9ENTcpMcbIscswwy oUWvSLYEc2f2MsIC81mQ9Pba8EAf9UrXMjej3paRXvmqNEyLHjbrMk2nHGo8MOM4j5L8BSf7207z MmRYcZ6kJ/5pxo68/92a0nBRi182Q7VCv/RCjzMaO/RAl/M/37VbG985I84pK8nd/jVgQ08K5gU8 v99WW92YQGHmqKf66DPHpLX2uoAr33UauzRSv3XtNnUux/U328Bm+/Mi23UaVvUaurP6eXR28Ia9 BRz0DAgEVobeHc+I4jJUr3EYPzVmu/RSS3VCZ7ZJY7ZUi7YAPuJXr85xVvROv8eI2AfqTN0z98Tn BIjmwGr2fkxQe8Rkq/QJzPVb17JUa/M4szQtT/VUo3R30/UQY7Nw7/Xh4fRylGwVD5zTHWATMyDl ccnpsMhy40fryLa7/nZDXzZdhzdAV2NdZzZ5+/btkrci365KAnfyif+jbk64fvLFzTbi2Lp3g4br RNqGY27EVkDcAjPcQThGzvrOhk94UDhz5GXP+vjHZiwNFMN3R2T3U5czOcOyWRpuGp/3goMxIy94 XDv0CD54XBsua5ZeEZujQm6iPxZlXfKlzf5lPsJoXEK5Jrovlt/snv6llWv5ldevUUAESGToMMYo /GpiqcYvehyFiVvpQHjFppb5TcavlxPEMDYlP1avHvc5Hf9Of1c3V2iPAEz2bnMzkH/3kTtygYte Zwv5jxM5S/M4gss1gvs26i25zUKuP4ZEkyvmlGcmUn66qEuEQVCmY8o5ZVKmq6aqlpc6tjqkXuJi niNkmyekuNqlt+7/KZBkqJem46hWa7ArBK7/rpf+OkYcNnLm3k2r5/u0zmewJz9Tc+rBdRhftnA7 9Qh6cy7bMnAneu3m8KQHOULhtpJL+ECWerWSqq+3uqtm6HW8r/yKaz2OBKsWJEcIq4wGCJ8yLqdj 6kUwJmCWY54TpWF6a677arDPYw20ueMWhIkr5SRWJIRgi+ewDwpoMWTfIbVXu4B/vLUz9D8juo8f dY+Pc26jN6aPNkTDiHNQpXsDRYq3MBMX5zEHCMQdCXoWduxoS4iwxYsrt/Fosax25Ctzt8mvYsqL d1uvvP+Ze3CPtzmPR1dTyOJlxYss8GD7MnO7Tl+LbFmb7BzfDpJo/3W0BIm0WwoVU0Z2QzVck7NT y7JUQz0OvrQki7Cpgu1+Yj3ZwiRUnHZbVET7LI9UHib7zrzbmrUDTxwE8/31rQX60J7hYOTvPDva U/DGb0tbtD1eXzNSZ7sQb/s3q/wje7yit/Tdo/vMI35BMkWFs0f1HKO9o8VXwPypVjji8zSmsMZG 6871YY5r73zFv0/laEbooEdH0BvnBzjpK72iE3lvf7wQ4/X0M/XUu/6nAmuXTmipCi+XZ3nCP66o 1iS+pwWlnmPru/tlXng/Onf73DHyAE/t+TQMHywy78jwGH91N4b1rDVAfBA4kGBBgwQZCDxhcOHA hh8WPlQIMSJEi/8RT2TMSHEjxo4cNyoE4NDiBwASDzZwsZJlS5cva7iIuXImy5kxb8p0WROnAJ0/ dfJsmZPmz5pFjRY9ChQn06QvZQ7waRNqDatWBWQVIDXrAK5atb7UsHLsVKguwZ5V21LD2JdbuUpd ixYsV7VavXptqTdv17x9/6IQoQABggYDCBC4EWAE1LYrcVg4OJnyxMoNMTPUWLkkQZSXQZ8YGZKy yrlrl15F2tSoVZuqZQqoMYCma6dUb9+0TZS3bZmqde/OChv3Ttiz5QJl+Xjt1rpSk989Pf1sVhdm qbdMe90ndr8s9YKPO94r3L8DUgwuPKBB4sWN10bmPN9y54IPPyvVRFmxPkn6nwEsibTJTMvOwAOh sg7BBRlskDrsWHIOrAmhgw5CA8Ny8DQFF+QQrfBWgktEEcvDy8K/BEiPMMPaU4yxt1qSjz7QPPNv oZEu0uwjG3i0oaKOTmBAo800EhLIARkSkLMCD/RQw7sufFLKJt+Kki4KrZySOy2d9Ms5B60zS0Tt 9OKQr6lKPC8vFQtroMX3qoNMshlp7A+j+zQTCMcTePSPzv3wxC/H/Ahici4Jv9OyuiwVbZRLRk97 DERHH+zLSQbhqvK6EsVbqbwKSVRzAMFW/3TTvRfjm5PO+yrCMUn7ACQUT84ATIjWQZc8lFG3KA0x ul6BxfDCSx90btJgD91Syi8/rPAlFEk0D8W/2GTxVPjUknHVPPubtVv9jASJo4uGzCjcj44kNDMk DTK0w+4gZRBEZpGtt9jsuorXXmS/UzBDDkP1KU1LRUVPPWtdxPYsbbelTFCHD5LVIFdfPUjIGpX8 MVdFidWw431BPuvYkEnW1VfaItz0X4GT+9LfsETdqlpTE56L4YYj1nHWPXMUqEcbKsY46G5vxLUy d8FU9lGxSm7ahZEb/NjpSvONcisyLfRULr8q7FrNmd9ENVtVcVZSJMvupIikHzvqs1yPTv/y6E62 2Z0IyI0blRpBeqd2GuoOUcaXU6f5rjK8MZXm+tOvCh71YJrhTLVstesTFF207R56PnVrDPDuoyn9 u0HR+z7t06on1M6srZ9EHMoR9QUv9mLLq9LEEM0cr1+WJQRszcfDVhiqmxverHLKTcqMVbM7C/DP 0HourVe9DyS9dJOb6z3DpwMXNtErU79uOhOpx7B2qAbHmvvuDvdScfYtBPtam8me/GGjPfNc7cuJ FA1ductln8x9TnpgchmoFGU9ezGLeoVDy3JE1j3cTQhREZKgBVMHMCvliyx580lZsJO+vbSMd+wz oXnWd54UAW9+kpucn5SHPD85BCU/e6H/RSg2Q7rhDVMhUlqjFHi9BB2LVxGiINcg9DKzMGd9b7HL 3gzowARlyoJT7A53/nIyxQ1MVPKrmQtv+AFbhQQzxoOVfvzDo9EIbVUSiRW5eIigqyxFfGqho+lS U5ztLYiOd1SKWryyFAo+UFlznMn5aOKW4QygBhDyY+v0VsGdOHGP4ttKTETUyDBtJ4WM452oSNWm 4NEvjPlbm0UudjwZhlFidWol0qjzSKg98lCM5AktG0QUm3BlJrLR3rMYuSjc2XEoSvQlWPyIy9nR 5SyadB1T/PUVpHQlJ9vBSwm5d7LTbed3pRolGEsZKCWNZl0C5A8bRcNGVU7GjK/MZQRZ/xOUPypF l1prSjzxKRukyFOfQqmnbFCmyWD2MycxCaRTePOU2sCGkVdrJCb7Kc+gFJQqj2TNbDCJUev0pKG+ VM4hsRKV5PQkU7oZTlAOysASfWlaXPRi5MZWSo3BUZ3Ng1g4+7OnGIKOQY3cCVzwmRR/Fseeq6mo ETWpyagYdZ5HkUpPgupPoCJUnkIZiksOOs+qykWX8ZzmPntZE4DqM0Kz+ehPT6pVkuJGqU1JazYH NqKvwEtrLxXbwur3QtLU7VVpg4gNx8i8mSbvlAMJrBnnA8tYMnSOtRHqQsH6k/LkcTWuIetvbvma rm4qoFSZykO5g5zGYja0G33NJEf4m/+J7qahqs3NbmByHGf65ipvzWgfI4tZokw2NgdNqk/hSpvw 8KVx0LGr8F5CvBsiVnM0LBeP3hZd6U6XuttS7N6CWL0Ljg9LL1tLX4ZZl2tKUpij264REVmyImZT WMNcn5h+NZXVWeqX2wTl4xDzxZjidHM9W0gq+RtgAk0pvQT+FYbcu8nqgHeB5juveyHIJRAxUTry GqT6RhgmaXLHS2WSK/dmll84XVhOAt6cG02c4na1rsAwiWVqe+pDXhURk5ON14zJ0kvqUfZBj9Sb M5/o1TsykXwTrF0952I9EEE0hOMxazb1Wdzj2u46ylVx/lp55XC6K3ayCSlpJ+pYMOP/RDecLXNs NVubS/rGV5e8rJdvYtqhxNkqAYWtUsYyRwke5zcnjbNW7gnc3QSHJsdU6EOHE9KEzpmghfZybG+Z 0Uf32ZY3seVTfRrIS+eFs16ZsupilFctb8uGo8bZdZvz5MgOVbdR1ZpCUbvQi84xWkRltXKYopeo UjM2jXxqrB/Ky6C4GdC+pE019Zlo1+Akz1dNKpyXXVXOkpXVuPVhWC/blEovm7dP1rRBF0ctFuoX r6aeHAD6ZO6GofpDU1UrVeEtzyMrNK2gbSpRY62Bah/F0oKmqpcBalXcBLyigcyjVCMqk7IgGqMw 4Wq2wbq9zV60mIHMdjALPRuP9vrh/xrfFKKhJW5vtjBloVY3TnN48hWPr8WOeiayUCbeBrYcU/Jt cSbJFz4XMEfDG9Zg+YBYSSPCV0xV83kJ29fJT+98vS6wssrphIPDNADqA77L6RYoOk5yElOs29IR kQjInCMqg3NNIqcKTOEJknhDOX8wd7PHdfJ+PXVlWinBtlie4zbd5FWfDwUocJgCDJ7whW8ABfwu EEOZR4rAomKVjkLtof8wOxDF95a8ikWuxmnoUTJkkWNj5stePlKEhFJ0cPkhpVISfKozOvx8p8Lw HFdgUXq6iQOfAAscXiCBPwwPCl8ACxQgAcEnPA+GP3jAQ/0w+Tpwo/z4TKcCPNEcJv97WBroUZ8W 27YJTm/qm9NRYoupl/uM9YvLexqxegmDGqejdbKqRfmOCenwk5aJoBNKhMG03FrOvfAJb/iG7zCK DwCFL/mML/gSYAEJLwEOw9waYJmuSqIokN+M6pIeSztAy63sTaLa6phwgpckbzkErqDcL94ozgNH xJBWLbSCQt/oaTg2LvP+bKx8YtGOKqzwzafuzMYi71cmhcE2yXfCzmBKRcTuanhEDacoYPcooAEH zwIQkAHdJAATMPgQEAEDsAGy7IXYjZgq8DaYCjkgDtcwLqEoqwRbENekjSdmEAUjKp8Ohwydw9/c MNiYip+4z7Pc8LOMarYSLvTqCNCCVm3zyu9qEkw8FGRxVmaLlq7/UqwBCpD4Am/wJvEKBU8AsTAL DVD4POATP7ELy+YLwRCyHOvggGrWiOrNjOIGWcsU+0zZcmsCY6MOPQoEawvOikOgsAJ+xOo1fGm0 VLEWcfHZUIs4VuOpMC3aHO0quucGf8LYhNGSAofEhhD+aMNYCv8mxEgOEk1MEqEw+TLxCg2vAQxQ AKUwAEFxHUNRxUgRzQDnfMrnQpij6bJr7Y5o6GhuihZsw04mQSilLFrnh2DHivhxikCEdfCvdoiL i75m3PhPCa8MHAvgE4nPEgnv9wJQCw1vAA7QE9kxJD1AFE+NZBCRLeoow8BuJQdJ5/aG65ip7VZq iN4uai7MJbnkQaAkJtsM/rqCvX4yVOzLK/QPcpIwuZZwy4ovATwAAJzSIgtPCnlgHK0wHaPwBEQy K0ly3fal58zPSe5RV+AlHx1v7MLv+ShvJ63PQ2TOY+aCwvTFfbDqGeFFmoaydwimRB5RIt2xAJvS KQETAKDyIgv/UPCwEBSxMitDciuty0GIg7bCqheXLdgqLePAL3tcQu3A7l0yZB/R58AkUGpOcnrE ElKuqVlyh2UybLhQ5u5kby+RciL9MjBp8yk9oACRzwIWsAFEMjEVcx0Zc1XesSr4DDe2reEyEKWO 7V3WcuyIJR9dRjsibFOsyJqsg1c+aC0EcnxMj+/EQpHCz2pwEmu8g/3mj7jqMi7QpDUDJ64cZ+TI jS8jcTZrUzD/EjA/sQCLrzd/kx2Dk06GE9gyEDk9cOc6MASXkzMlsIParrv8UTpT8iX9ZefCS8Ga 7lLG83bSjycnD9R6skuUhYGIDsoc8jxg0yVuL4zAkSkD8xOf/zIKXTQBnLIJkY8/+7Md3XFZVmq8 IKXlgA59IGU7VQc0UTI7aQctXQ9EBxF1/DGJFpTDPHQvYNKJSIiD2M6HVGZL1FNlpKW4JORE+24+ B+8+BdMcLSA/MVI0AMBMmXIxb5SvcCpADzImWfJ7Eiw0s1S+4sQ726s8p23+YGczx8vshIhDO5SZ prSWWmab8K/2MuXuzKNavKIb5fMbi+9MW3Tq2KMATkA3LUBNzZH4bFQrcTRHp+RHm2RY5rTmDNL0 ypNCZIfzGFQt+G40G+9Ocw4gE1WYXm+JUpJHVVIRxzItsFFLvSYvivKb9ktMMRU/NfUEuHD4EgBU CW9U/RM4tf9MTvGlZApM7nzoX0rOvJ4URrB0LdWyLIGpS45lNKFUazB0ZKLJZQJGrlwKIhnjY1L0 hijSTWgzI9yEC50yI5ySIq01FBczWwu1hzAoYcWnVjeESlK1OXvVdh7PiJrjSjQFaqTJfRbyPKMD Lx8SPiNH6PL1hShgEsXxZANTYGnzCUXVTRFTKxGWYW3yxtxCM+fvXppzR8MHUPMmyTgoLYcoLj8T Hy12EZ2UU/jGJ6lxLBlxrrpJlCg1NlUsIyzyEneTAupzYIWvTa91JHvzP7myZPS0ZuuUgngWVUNU O282Mxl2XKXz7LYGdcLVVywICMfSQ+XqioyVw8INMB5R7Ur/VkWt1gMAUDcJL/BocwCSL2z9U2wn R1v5pUfnymJpFliEFGK5U1Y3lrNM7+piDm8lif1CFJFQhHtCjmvAlCUGF2cAb0yBMzEL7wl18/AA AAeqFWYLFzEhtzFp9m9O83LL0pgoxJPGlSzRq2qwakF9lO0qaXvi1ViJdT2NUGrjk2oDzBzZA/gQ 8HEHc066dj9htj/htJQkN1gaLywn91Gs1HKF9nMp1n1TRm3LdWF78lDbTW7Ldl5dM1MQRU30b1Kv F0WT0guDjyqHz3tvUxNf9mtv1HA/tXcJBG57hXToF+4idH0XBXrldTznVDSfVEKklFw990JEKFxt zoTYq0I7/0yFJFVZvTFOCVP3ANAwP1KB/VKBFRMkEVPAIvByQbhDVrV0vKvzQlhPp0LtzrVdh1ZX Sdc7/NZJO/NPnyaFNQ+FTud8uHGAw5S/QnVOrLIctfBMY5d3+zOBZTZ7hfd9LZctVwbB1jiDX9L1 LrZiM4yEcSfmZLV+4w5L6ap24Mf60JN9VrfEBMxlozIKsbAAbDh3Hxh2ydeH41g0kTSO4a4loxSK mJiF42KI5VcniyVL+DZMwKdy72tF2GNqCdjEChf5OpGBozAdDwMBXTmR0fiBSzVOLdmCBaAeG2y9 gFmO4dj15vZqOkbDVhJCK6yDuuws22zybA40tYdp6c5Kn/9DKwrZ6QpYpmS3EzNyAKBSHD2SexsX lw9Wjdf4iSx5nfHYbdsOwlKSyLLjcBq2S1TY7bCvLqDM+vARLk6UV1qXlRLTArj3gHnTA7TwoM35 cSORndnYoTWZiCmYXH+y5IouVv3Yf7c0irGoU15tWHvnhSmVwgIapwrXEjmxCh3ZnMt3yyB6Hus2 /SbagLamcxFESGf6LbETkujqTzkYRhTMo+WRZz0Nv7qx6UpawE6aI7v3gVsanR16QqM0ieCZetbL Z4PaLXFsVnWyiJaJk5T4YsW6iurWNNvNolVTpZJjpbI5qau2m4ePe3/zqRv6pWNOvOCZVsHzW7HR g6fmiLNHo235hZByVhGlQ4TvtqKX9JP6Yun4zq1HrXAJuiIZOvEUD5K6MkvCOrGL7IILdaI3W0Pi y1POE4p/VUx2ToPy1I+jg1GhxUP/2nqbLVs/eHe2C4IUO4AHdHu3K6AEKiAGYqADchpfomlLyY6E 3JJBQtuhBVtoxTOD5muPhoVHidVZULs5J+hkPs07Idu2vfsDcHu3eaC3K6ACOgC4hXu4AQlUgndf mm65qaa9I1pDiCxv2RWts5tM1lOUP7Zs7zifpy28sG4qYvu7Ddx3TyO3S6ADyLsDHHwDNqAD0tIC Dcj81G9WKYxPL5PH9HFHzwe4LByDL0XI5DnEIdSZpk1pSSil4g8RPe6tJijy7NnDGPKCZMaouZh1 ZfvAeRy8qaMDfNvBhXwDDKDIJXyFw3DRipPMjEO1rGrQjCPSwsy1+AzKT2vQyOyh/1Ijs1rjzB4T k8YMGYUCGqsqMhVN0eoN02gxyVUj4RTNtXQR4OguRBk7mxm3x/G8gBL8t3UguIm8yI381XLrnjwQ OLSKrQZ9B4Ft32rLn1CPzLmcKJqN0CkwDzfrj3CL0pP8syAOqmqRw5FC3zr90Err83SsiahRuALH znc8z72bAn68z2MAwg3gzwM9LQ4u0SsL1pSc4ngMn6rtqA79KSK9KEyro3gQ3oJ9qO5I4PhJDxHt AluxDFWGBw+0qvys1G0i2XraPCdUpHPcUw5DVKZOU4tLTcqdPc4d3dN93Nc9L/6VPcz93b3iX9v9 PCigJrFruC8ToqnEszM7aM8ChP/a2YpGG7Gr2KLHQ2kAGXHkYrv9PeIdxTMlPuLVu1ZNk78rOWft 9E6TVPPCC9S2LmezueJN3kDU9+RNcqMBMkKDlKtJGX4J8kGTbG4T5zky+ZNfr4TZZ/JKXuWBnibV O+h7hU8x1jGMHsb4uOROGJSJ2UrsQkP3FyZV21NU5ueJPuhfLuuzHr6xp0GS3kkLPqNfVbqluugq GpvtFbm4vu0pvu3hvr3Q1VBjOq8fSBv/RWnP8zqwPu6jmsH8PvC7LuMt7L32cYOmm3T5+boBv+Qf IAIgP/Ilf/Ipv/It//IxP/M1f/M5v/M9//NBP/RFf/RJv/RN//RRP/VVv/IfAJn/0QTcI1Lw7frt SyeY5V72B1KYmTNi/fS6nxkoxVMv+h73++b+hKi5777+DkjgiT9k/Pu79J0tH7SnuRTtb7KKw2L4 mx9k8H5qvDpNZE7mKnn7iRiUCX/OZRqJixl4b1xkj5L8yTbsruf64D/uZ27887uvJTbkF1uOAUKA gAECU4hQgABBgwYECNwIMMKFxIkUK1q8iDGjxo0cO3r8mHHgwAEEBYI8iTKlypUsW7p8GVKjAIka XMysaNLmTYs3BZr0SXGnSJskbxad+fPoQIkFDyZc2PBhRJhUq1rFKFKgUoJXu3r9Cjas2Is5eYJE ylVnUKZA1f4cytRFTZIGESIY/8DQIcSxfL0OPQp4Z9/BhAsbHkwyZlDBE3O+zdpzAFuJiSkTTGuT qIC6T/NKPbwYZVmPPkv6PD3yNFe4oAsP4PEgtuzZtGvbvo07t27ZPCRPfL07uPDhw3tTBE48ufLk vVWb5HzX896wpVEXNQ0ZtfaS2LFvb9s6PMgHIF5QOI8+vfr17Nu7fw+fwgsQviWSV5HAgP79/Pv7 /w9ggAIK2IMK9FF0X34DLshggw0WSN9bOkEHlV5T+SVehhqq9MACCSjoYIgiOvjhAiUguMCIKq4o 4AYSmIgiizLOaICLJmLHFIXSXZihYKNtCKRYHX64QZFGHolkkkXWgCSTSj4JJcuUMZR44kQdRoml kk4umWWXSsZQwQUw3nRll1ty6WWTT56JJZhilgDeQDpGNZ1hpXEHHkUa1NSYVnkGCehHQyYQQ6GG HopooobWsKiijj4KaQwSUIlipJYiWgOjhWp6aaeGStDAm0N12Gmmi3Lq6aaKomopqG8qpdWcFo6V XWo/kmUra4HuitKgEvwKbLDCDitsDcEa+6uxyCJLbLPD6kCplQs4S62zyiaLbbbVbqtDCW+iuC22 1y4L7LUSMMvsueeSS662z3p742VpQf+HF508ioZndc6dpCuv/rrUIQYYVEBwwQYfjPDBNRi8MMIN JwwxxALDKK0OOkSMccIPZ0rwxhl/XPAFPFBsU4cWf9xwyh0XvLDKGlfgscswYyxyvC5U5gK9O26X r754/gv0vwEPDDLKCnPc8cNFS4wByS50uDTISm+MdNQR11ylfQsUrfTMScucadcts+w1zFVDjHWu M9E7gL1Bvw33eAsIvFDddt+Nd91h7513337/XcLEWT+99d+G370334cvfre3Iw8O9eGJK8545Ys7 bjNlEunsdtyef27RAy8ITHrppp+Oeuqqr8566S80gOALEfBAe+2234577rrvznvvD1j/8Hrss/dO fPHGH//764ndyfmsoD//eW/lLUB99dZfj3322m/PPffzhZACRdK/0H355p+P/vfhMzU++u6//776 ppFEl1MK7Qh9/oHuqX//H430EZxpRCmauRlablafwADQZ/RrIGBkJZWe9Qw1/qPVnzLEvx7RTztC 8U5KtPM8AHqkKB1ZnmN0ApTKXEdektHKagCzQp9AsE5nAWEFVQKZ61ywMBkEUmoywxM/AdEypykg UbiDI9CJcIT1wdUPuaOZyiywgQeEFRJHQsWm2KVeznMJB4t4qw2VZSjZgVV1NMKnHkWGg1+5kwCx whi2/GgnJLzhEkuIGbLkEWd1PKJl2xCYGge6MDCCFAAK7Fehz4ilVvqyDge9U6sJPrI7++pXStJY GAkBcY5XuVMR+6QYtxixMTrJY/+weJI3WkSFpillfaZ4xRVasSS/2eDm7MfFh3ggBLzspS9/Ccxg CnOYxCymMY+JzGQqc5nMbKYznwnNaEpzmtSspjWvycsNIDIvCvCBAr4JznCKc5zkLKc5z4nOdKpz nexspzvfCc94ynOe9KynPe+Jz3zqU5wESAheEgLQgAp0oAQtqEEPitCEKnShDG2oQx8K0YhKdKIU rahFL4rRjGpUoQ0ICAA7 --%OLATTACH1-- From rosabelCFATRsashenka@sapolu.com Tue Mar 1 11:32:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13670; Tue, 1 Mar 2005 11:32:46 -0500 (EST) Received: from [83.201.234.108] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6AJa-0007ny-Ha; Tue, 01 Mar 2005 11:33:49 -0500 Received: from hostpfu.chicagowriters.com (221.198.43.91) by bay-7SKB.chicagowriters.com with Microsoft SMTPSVC(3.26.34.8);Tue, 01 Mar 2005 22:30:16 +0600 Message-ID: Reply-To: "interface beach" From: "interface beach" To: l-admin@ietf.org Cc: manet-admin@ietf.org, rip-admin@ietf.org, hc-admin@ietf.org, cna@ietf.org, simple-archive@ietf.org, imrg-request@ietf.org, seamoby-web-archive@ietf.org, pim-request@ietf.org, asrg@ietf.org, rpsec@ietf.org, ips@ietf.org, iab-wireless-workshop@ietf.org Subject: Re: Your New Details Date: Tue, 01 Mar 2005 09:31:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--76075_5846502.9z691" X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----76075_5846502.9z691 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://s80.lendera.com/?name=rm2342 We look forward to hearing from you. Regards, interface beach JPC Financial Group re*mve. -> http://lendera.com/st.html ----76075_5846502.9z691-- From simple-bounces@ietf.org Tue Mar 1 12:10:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17959; Tue, 1 Mar 2005 12:10:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AuF-0000Q9-R1; Tue, 01 Mar 2005 12:11:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Asf-0005Ao-B0; Tue, 01 Mar 2005 12:09:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Ase-0005Aj-3g for simple@megatron.ietf.org; Tue, 01 Mar 2005 12:09:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17907 for ; Tue, 1 Mar 2005 12:09:53 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Atd-0000Oy-ED for simple@ietf.org; Tue, 01 Mar 2005 12:10:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Mar 2005 09:23:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,127,1107763200"; d="scan'208"; a="617152970:sNHT21716904" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j21H9dq8016122; Tue, 1 Mar 2005 09:09:39 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APL96681; Tue, 1 Mar 2005 12:09:42 -0500 (EST) Message-ID: <4224A1D6.1050701@cisco.com> Date: Tue, 01 Mar 2005 12:09:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Miguel - some good catches. A couple of comments. Paul Miguel Garcia wrote: > 6) Section 7.1.1., 6th paragraph: > > "Success-Report and Failure-Report MUST NOT be present for any method > other than SEND. " > > I would like to change the above sentence to be positive, rather than > negative, and add some scope. The motivation is that, in the future, we > may need to extend MSRP with a new method that contains Failure-Report > and Success-Report, and in such case we will be violating the above > text. So what about this: > > "Within the scope of the methods defined by this document, > Success-Report and Failure-Report headers MUST only be present (if > required) in SEND requests". I don't find that helpful. I understand what the original is requiring, but with your suggestion I don't. > 7) Section 7.3.1, last paragraph in the section > > "If the Success-Report header was set to "yes", then when a complete > message has been received, the receiver MUST send a success REPORT > with a byte range covering the whole message. If the Success-Report > header is not set to "no", then the receiver MAY generate incremental > success REPORTs as the chunks are received. These can be sent > periodically and cover all the bytes that have been received so far > or they can be sent after a chunk arrives and cover just the part > from that chunk." > > So, if I understand correctly, the receiver has the right to send > success REPORTs of chunks when the Success-Report is se to "no". Is this > correct? I don't understand it that way. I believe it specifies: YES: MUST send success report for complete message, MAY send incremental success reports NO: MUST NOT send success reports at all PARTIAL: MAY send success reports, either for the complete message or incrementally. > If it is, I find very weird that a receiver generate Success Reports of > chunks whenever it wants, especially when the sender has indicated that > it does not care to know when the complete message is finally received. > Actually, we don't have a mechanism for the sender to request REPORTs of > chunks (we do have a mechanism to request reports for the whole > message). But the current behavior, leaving anything in the receiver's > side, is certainly wrong in my opinion. > > Any comments? I was in favor of a more explicit mechanism for dealing with incremental reporting, but it got compromised away in the interest of progress. > 8) Section 7.3.2, 3rd paragraph: > > "It is possible to receive a failure report or a failure transaction > response for a chunk that is currently being delivered. In this case > the entire message corresponding to that chunk should be aborted, by > including the "#" character in the continuation field of the closing > sequence." > > s/should/SHOULD > > But also, is it possible to abort a chunk that hasn't been marked as > interruptible (setting a "*" in the last-byte field of the Byte-Range > header)? At least section 7.3.1 seems to indicate that it is not legal. > Therefore, I suggest to scope the above text by indicating this case: > > "It is possible to receive a failure report or a failure transaction > response for a chunk that is currently being delivered. In this > case, if the message is interruptible, the entire message > corresponding to that chunk SHOULD be aborted, by > including the "#" character in the continuation field of the closing > sequence." I guess this doesn't hurt. In practice I doubt it can happen, since an uninteruptible chunk can't be larger than 2k, and it seems unlikely that you would hear about an abort for it while it was still not all transmitted. (Note that in this case transmitted only means handed off to the OS of your node.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 1 12:44:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21306; Tue, 1 Mar 2005 12:44:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BQq-0001Fh-Ir; Tue, 01 Mar 2005 12:45:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BOR-0005K4-9G; Tue, 01 Mar 2005 12:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BOO-0005Jz-Un for simple@megatron.ietf.org; Tue, 01 Mar 2005 12:42:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21099 for ; Tue, 1 Mar 2005 12:42:42 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BPO-0001CU-GG for simple@ietf.org; Tue, 01 Mar 2005 12:43:46 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21HgWc26223; Tue, 1 Mar 2005 19:42:32 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 19:54:47 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j21HsleL000394; Tue, 1 Mar 2005 19:54:47 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00IndKcy; Tue, 01 Mar 2005 19:54:45 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21HeoU16766; Tue, 1 Mar 2005 19:40:50 +0200 (EET) Received: from [10.162.24.60] ([10.162.24.60]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 19:40:42 +0200 Message-ID: <4224A919.7040403@nokia.com> Date: Tue, 01 Mar 2005 19:40:41 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> In-Reply-To: <4224A1D6.1050701@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2005 17:40:43.0048 (UTC) FILETIME=[CAB83280:01C51E85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Paul: Some comments inline, prepended by "Miguel -> " Paul Kyzivat wrote: > Miguel - some good catches. A couple of comments. > > Paul > > Miguel Garcia wrote: > >> 6) Section 7.1.1., 6th paragraph: >> >> "Success-Report and Failure-Report MUST NOT be present for any method >> other than SEND. " >> >> I would like to change the above sentence to be positive, rather than >> negative, and add some scope. The motivation is that, in the future, >> we may need to extend MSRP with a new method that contains >> Failure-Report and Success-Report, and in such case we will be >> violating the above text. So what about this: >> >> "Within the scope of the methods defined by this document, >> Success-Report and Failure-Report headers MUST only be present (if >> required) in SEND requests". > > > I don't find that helpful. I understand what the original is requiring, > but with your suggestion I don't. Miguel -> I don't really care about the exact wording, as long as it does not make any assumptions about future MSRP extensions. The current text implies that the Report headers are meant only for SEND requests, and for no other MSRP methods that any human can think of in the future. So if we invent a new method that can use those headers, this shouldn't create a violation of the MSRP RFC. > >> 7) Section 7.3.1, last paragraph in the section >> >> "If the Success-Report header was set to "yes", then when a complete >> message has been received, the receiver MUST send a success REPORT >> with a byte range covering the whole message. If the Success-Report >> header is not set to "no", then the receiver MAY generate incremental >> success REPORTs as the chunks are received. These can be sent >> periodically and cover all the bytes that have been received so far >> or they can be sent after a chunk arrives and cover just the part >> from that chunk." >> >> So, if I understand correctly, the receiver has the right to send >> success REPORTs of chunks when the Success-Report is se to "no". Is >> this correct? > > > I don't understand it that way. I believe it specifies: > > YES: MUST send success report for complete message, > MAY send incremental success reports > > NO: MUST NOT send success reports at all Miguel -> This is not according to the current text, that says: If the Success-Report header is not set to "no", then the receiver MAY generate incremental success REPORTs as the chunks are received. > > PARTIAL: MAY send success reports, either for the > complete message or incrementally. Miguel -> I think this is not written in the text. > >> If it is, I find very weird that a receiver generate Success Reports >> of chunks whenever it wants, especially when the sender has indicated >> that it does not care to know when the complete message is finally >> received. Actually, we don't have a mechanism for the sender to >> request REPORTs of chunks (we do have a mechanism to request reports >> for the whole message). But the current behavior, leaving anything in >> the receiver's side, is certainly wrong in my opinion. >> >> Any comments? > > > I was in favor of a more explicit mechanism for dealing with incremental > reporting, but it got compromised away in the interest of progress. Miguel -> I don't really know what would be the benefit of getting such incremental report. Is it to allow the sender an early recovery of a failure? In this case it would be governed by the Failure-Report header, or an error response. Miguel -> So I am leaning towards thinking that the chunk reports are useless. But in any case, if we decide to keep them in the spec, they should be sent only when requested by the sender, rather than arbitrarily from the receiver. One can think of a new parameter to the Success/Failure-Reports indicating whether the report generation applies also to chunks, but I am not convinced that chunk reports are needed at all. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 1 13:05:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23116; Tue, 1 Mar 2005 13:05:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BlB-0001ip-TM; Tue, 01 Mar 2005 13:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BiL-0000nq-DG; Tue, 01 Mar 2005 13:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BiF-0000nl-V6 for simple@megatron.ietf.org; Tue, 01 Mar 2005 13:03:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22951 for ; Tue, 1 Mar 2005 13:03:13 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BjF-0001fb-RH for simple@ietf.org; Tue, 01 Mar 2005 13:04:18 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2005 13:03:07 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j21I331j022808; Tue, 1 Mar 2005 13:03:04 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APM01860; Tue, 1 Mar 2005 13:03:02 -0500 (EST) Message-ID: <4224AE56.4050602@cisco.com> Date: Tue, 01 Mar 2005 13:03:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> <4224A919.7040403@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit more inline Paul Miguel Garcia wrote: > Paul: > > Some comments inline, prepended by "Miguel -> " > > Paul Kyzivat wrote: > >> Miguel - some good catches. A couple of comments. >> >> Paul >> >> Miguel Garcia wrote: >> >>> 6) Section 7.1.1., 6th paragraph: >>> >>> "Success-Report and Failure-Report MUST NOT be present for any method >>> other than SEND. " >>> >>> I would like to change the above sentence to be positive, rather than >>> negative, and add some scope. The motivation is that, in the future, >>> we may need to extend MSRP with a new method that contains >>> Failure-Report and Success-Report, and in such case we will be >>> violating the above text. So what about this: >>> >>> "Within the scope of the methods defined by this document, >>> Success-Report and Failure-Report headers MUST only be present (if >>> required) in SEND requests". >> >> I don't find that helpful. I understand what the original is >> requiring, but with your suggestion I don't. > > Miguel -> I don't really care about the exact wording, as long as it > does not make any assumptions about future MSRP extensions. The current > text implies that the Report headers are meant only for SEND requests, > and for no other MSRP methods that any human can think of in the future. > So if we invent a new method that can use those headers, this shouldn't > create a violation of the MSRP RFC OK. I can buy that. I see two ways to achieve that: - Say that Success-Report and Failure-Report MUST NOT be used in a request or response unless permitted by specific normative text. The normative text will only be present for SEND. - Introduce a table like Table 2 of 3261 (I think it is table 2), specifying which headers may be used with which requests and responses. I prefer the table. >>> 7) Section 7.3.1, last paragraph in the section >>> >>> "If the Success-Report header was set to "yes", then when a complete >>> message has been received, the receiver MUST send a success REPORT >>> with a byte range covering the whole message. If the Success-Report >>> header is not set to "no", then the receiver MAY generate incremental >>> success REPORTs as the chunks are received. These can be sent >>> periodically and cover all the bytes that have been received so far >>> or they can be sent after a chunk arrives and cover just the part >>> from that chunk." >>> >>> So, if I understand correctly, the receiver has the right to send >>> success REPORTs of chunks when the Success-Report is se to "no". Is >>> this correct? >> >> I don't understand it that way. I believe it specifies: >> >> YES: MUST send success report for complete message, >> MAY send incremental success reports >> >> NO: MUST NOT send success reports at all > > Miguel -> This is not according to the current text, that says: If the > Success-Report header is not set to "no", then the receiver MAY generate > incremental success REPORTs as the chunks are received. Agree, this isn't explicit in the above paragraph. So we should add another sentence to the end of the above: "If the Success-Report header was set to "no", then success reports MUST NOT be sent." >> PARTIAL: MAY send success reports, either for the >> complete message or incrementally. > > Miguel -> I think this is not written in the text. Well, "partial" is not NO, so it may send an incremental report. And a report for the complete message is indistinguishable from an incremental report so that is permitted too. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 1 13:21:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24437; Tue, 1 Mar 2005 13:21:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6C0t-00023H-P2; Tue, 01 Mar 2005 13:22:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6By9-0003GP-DO; Tue, 01 Mar 2005 13:19:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6By7-0003GK-Nq for simple@megatron.ietf.org; Tue, 01 Mar 2005 13:19:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24310 for ; Tue, 1 Mar 2005 13:19:36 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Bz6-00020a-ED for simple@ietf.org; Tue, 01 Mar 2005 13:20:41 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21IJNc03765; Tue, 1 Mar 2005 20:19:25 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 20:19:19 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j21IJJar024139; Tue, 1 Mar 2005 20:19:19 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003alj9J; Tue, 01 Mar 2005 20:19:17 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21IJHU05338; Tue, 1 Mar 2005 20:19:17 +0200 (EET) Received: from [10.162.24.60] ([10.162.24.60]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 20:19:15 +0200 Message-ID: <4224B221.7020201@nokia.com> Date: Tue, 01 Mar 2005 20:19:13 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> <4224A919.7040403@nokia.com> <4224AE56.4050602@cisco.com> In-Reply-To: <4224AE56.4050602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2005 18:19:15.0393 (UTC) FILETIME=[2CFC0B10:01C51E8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Inline. Paul Kyzivat wrote: > more inline > > Paul > > Miguel Garcia wrote: > >> Paul: >> >> Some comments inline, prepended by "Miguel -> " >> >> Paul Kyzivat wrote: >> >>> Miguel - some good catches. A couple of comments. >>> >>> Paul >>> >>> Miguel Garcia wrote: >>> >>>> 6) Section 7.1.1., 6th paragraph: >>>> >>>> "Success-Report and Failure-Report MUST NOT be present for any >>>> method >>>> other than SEND. " >>>> >>>> I would like to change the above sentence to be positive, rather >>>> than negative, and add some scope. The motivation is that, in the >>>> future, we may need to extend MSRP with a new method that contains >>>> Failure-Report and Success-Report, and in such case we will be >>>> violating the above text. So what about this: >>>> >>>> "Within the scope of the methods defined by this document, >>>> Success-Report and Failure-Report headers MUST only be present (if >>>> required) in SEND requests". >>> >>> >>> I don't find that helpful. I understand what the original is >>> requiring, but with your suggestion I don't. >> >> >> Miguel -> I don't really care about the exact wording, as long as it >> does not make any assumptions about future MSRP extensions. The >> current text implies that the Report headers are meant only for SEND >> requests, and for no other MSRP methods that any human can think of in >> the future. So if we invent a new method that can use those headers, >> this shouldn't create a violation of the MSRP RFC > > > OK. I can buy that. I see two ways to achieve that: > - Say that Success-Report and Failure-Report MUST NOT be used in a > request or response unless permitted by specific normative text. > The normative text will only be present for SEND. > > - Introduce a table like Table 2 of 3261 (I think it is table 2), > specifying which headers may be used with which requests and > responses. > > I prefer the table. I know that some people hates this table... but I am fine with it, I find it very useful. > >>>> 7) Section 7.3.1, last paragraph in the section >>>> >>>> "If the Success-Report header was set to "yes", then when a complete >>>> message has been received, the receiver MUST send a success REPORT >>>> with a byte range covering the whole message. If the Success-Report >>>> header is not set to "no", then the receiver MAY generate >>>> incremental >>>> success REPORTs as the chunks are received. These can be sent >>>> periodically and cover all the bytes that have been received so far >>>> or they can be sent after a chunk arrives and cover just the part >>>> from that chunk." >>>> >>>> So, if I understand correctly, the receiver has the right to send >>>> success REPORTs of chunks when the Success-Report is se to "no". Is >>>> this correct? >>> >>> >>> I don't understand it that way. I believe it specifies: >>> >>> YES: MUST send success report for complete message, >>> MAY send incremental success reports >>> >>> NO: MUST NOT send success reports at all >> >> >> Miguel -> This is not according to the current text, that says: If the >> Success-Report header is not set to "no", then the receiver MAY >> generate incremental success REPORTs as the chunks are received. > > > Agree, this isn't explicit in the above paragraph. So we should add > another sentence to the end of the above: > > "If the Success-Report header was set to "no", then success reports MUST > NOT be sent." > >>> PARTIAL: MAY send success reports, either for the >>> complete message or incrementally. >> >> >> Miguel -> I think this is not written in the text. > > > Well, "partial" is not NO, so it may send an incremental report. And a > report for the complete message is indistinguishable from an incremental > report so that is permitted too. I agree that "partial" is not NO. I am just saying that the text does nos say anything about "partial" and incremental reports. But still I haven't found an answer to what is the usefulness of reports. /Miguel > > Paul -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Enok@keacampers.com Wed Mar 2 07:16:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03486 for ; Wed, 2 Mar 2005 07:16:07 -0500 (EST) Message-Id: <200503021216.HAA03486@ietf.org> Received: from dsl-80-41-10-101.access.as9105.com ([80.41.10.101] helo=keacampers.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6Sn3-0006yi-AO for simple-archive@ietf.org; Wed, 02 Mar 2005 07:17:22 -0500 From: "Toussaint Flores" To: "Parisa Hardin" Subject: Re: Phharmaccy-IEK Date: Wed, 2 Mar 2005 07:12:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C51E97.4225AE78" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C51E97.4225AE78 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_004D_01C51E97.4225AE78 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit Our PharmMail=20 SH0P.
     
    SP  OF  Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.)
    ECIAL FER: ag al it
    And Many Other!
     
    With each purchase you = get:
  • 20%Off All Re-0rders = with us
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_004D_01C51E97.4225AE78-- From simple-bounces@ietf.org Wed Mar 2 09:27:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15324; Wed, 2 Mar 2005 09:27:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UqC-0001ii-0m; Wed, 02 Mar 2005 09:28:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Umc-0007PH-78; Wed, 02 Mar 2005 09:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6UmZ-0007Ou-TV for simple@megatron.ietf.org; Wed, 02 Mar 2005 09:25:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15159 for ; Wed, 2 Mar 2005 09:24:57 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Uni-0001fx-3y for simple@ietf.org; Wed, 02 Mar 2005 09:26:12 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2005 09:24:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22EOh1l023519; Wed, 2 Mar 2005 09:24:45 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APM65867; Wed, 2 Mar 2005 09:24:42 -0500 (EST) Message-ID: <4225CCAA.3070502@cisco.com> Date: Wed, 02 Mar 2005 09:24:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> <4224A919.7040403@nokia.com> <4224AE56.4050602@cisco.com> <4224B221.7020201@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Miguel Garcia wrote: >>> Miguel -> I don't really care about the exact wording, as long as it >>> does not make any assumptions about future MSRP extensions. The >>> current text implies that the Report headers are meant only for SEND >>> requests, and for no other MSRP methods that any human can think of >>> in the future. So if we invent a new method that can use those >>> headers, this shouldn't create a violation of the MSRP RFC >> >> OK. I can buy that. I see two ways to achieve that: >> - Say that Success-Report and Failure-Report MUST NOT be used in a >> request or response unless permitted by specific normative text. >> The normative text will only be present for SEND. >> >> - Introduce a table like Table 2 of 3261 (I think it is table 2), >> specifying which headers may be used with which requests and >> responses. >> >> I prefer the table. > > I know that some people hates this table... but I am fine with it, I > find it very useful. I'm not wild about the table either, but it seems to beat the alternatives. >>>>> 7) Section 7.3.1, last paragraph in the section >>>>> >>>>> "If the Success-Report header was set to "yes", then when a >>>>> complete >>>>> message has been received, the receiver MUST send a success REPORT >>>>> with a byte range covering the whole message. If the >>>>> Success-Report >>>>> header is not set to "no", then the receiver MAY generate >>>>> incremental >>>>> success REPORTs as the chunks are received. These can be sent >>>>> periodically and cover all the bytes that have been received so far >>>>> or they can be sent after a chunk arrives and cover just the part >>>>> from that chunk." >>>>> >>>>> So, if I understand correctly, the receiver has the right to send >>>>> success REPORTs of chunks when the Success-Report is se to "no". Is >>>>> this correct? >>>> >>>> I don't understand it that way. I believe it specifies: >>>> >>>> YES: MUST send success report for complete message, >>>> MAY send incremental success reports >>>> >>>> NO: MUST NOT send success reports at all >>> >>> Miguel -> This is not according to the current text, that says: If >>> the Success-Report header is not set to "no", then the receiver MAY >>> generate incremental success REPORTs as the chunks are received. >> >> Agree, this isn't explicit in the above paragraph. So we should add >> another sentence to the end of the above: >> >> "If the Success-Report header was set to "no", then success reports >> MUST NOT be sent." >> >>>> PARTIAL: MAY send success reports, either for the >>>> complete message or incrementally. >>> >>> Miguel -> I think this is not written in the text. >> >> Well, "partial" is not NO, so it may send an incremental report. And a >> report for the complete message is indistinguishable from an >> incremental report so that is permitted too. > > I agree that "partial" is not NO. I am just saying that the text does > nos say anything about "partial" and incremental reports. Doesn't seem to be an issue. > But still I haven't found an answer to what is the usefulness of reports. They are useful in recovering from loss of the media connection. You can reestablish the connection (with reinvite) and then restart sending the message. Any ranges that were confirmed don't have to be sent again. When the connection hasn't failed, the success reports indicate portions of the message that no longer need to be saved to prepare for error recovery. This might be significant in our frequently cited case of transmitting the Lord of the Rings. (The fact that we use that as an example says something about how long we have been working on this.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Ghani@techie.com Wed Mar 2 12:13:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04125; Wed, 2 Mar 2005 12:13:55 -0500 (EST) Received: from [85.136.8.49] (helo=gomail.com.ua) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6XRH-0005bl-9W; Wed, 02 Mar 2005 12:15:12 -0500 From: "Gray Christine" To: "Sylvain Reynaud" Subject: Re[4]: question with our meds Date: Wed, 02 Mar 2005 10:10:16 +0200 Message-ID: <4fa401c51f4a$0383701b$31088855@gomail.com.ua> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4567_89ABCDEF.01234567" 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: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    SP -M  The  we and  Saf Wa Ph acy 
    UR is  Ne st  The  est  y of  arm

    Inc e Yo xual Des Spe ume by  %
    reas ur Se ire and  rm vol 500
    <= /TABLE>

    100 ural and  de Eff - in con t to wel wn bra
    % Nat No Si ects  tras l-kno nds.
    Expe ce thr es lon gas
    rien ee tim ger or ms

































    Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of ------=_NextPart_000_4567_89ABCDEF.01234567-- From 25qqbkjm@attglobal.net Wed Mar 2 12:47:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08529; Wed, 2 Mar 2005 12:47:04 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6XxL-0006da-RY; Wed, 02 Mar 2005 12:48:22 -0500 Received: from [211.110.123.224] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D6Xw8-0007qN-QI; Wed, 02 Mar 2005 12:47:05 -0500 Received: from YENYQ-MY61 (211.110.123.224) by 211.110.123.224; Wed, 02 Mar 2005 09:50:08 -0800 From: "Molly Hurt" <25qqbkjm@attglobal.net> To: bofchairs@ietf.org, simple-archive@ietf.org, enum-admin@ietf.org, bmwg-request@ietf.org, ietf-rsvp@ietf.org, mipshop-web-archive@ietf.org, rmt-request@ietf.org Subject: Dying to get website traffic? Problem Solved - Read this -leprosy axon Date: Wed, 02 Mar 2005 09:50:08 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-message-flag: Authentic Sender, Hash: AsCaLiRw Message-Id: X-Spam-Score: 17.4 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer Spyware can hijack your computer, change your settings. --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    <= font color=3Dblack>








    Off this camp-aign

    Spyware can hijack your computer, change your settings. --%OLATTACH2-- --%OLATTACH1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODlhmQGIAfQAAAAAADk8OWNlY/8AAP9JR/9tbACCAP/VGf/aOQAA/yko/1JR/5yanP+Qjv+t rf/leIyK/87Pzt7b3v/zvv/r2sbH/+/v7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA mQGIAQAF/+AljmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvV WiLgMFjiTYnP3bR6zT5JyKUvVgK2nOSmSHvP71PfJnhUXxEWgIF6eX6LjI1EhySCUYRwkJGJJZiO m5ydMZYikk90cCKgoZojqZ6sra2nok10diSnF7EXq667vH6wukuFJra4wL3HyFu/UsIlxIUW0dLG ydXWUctRzbWlmWdj1zHROeM65eS0Xec26+bO3ahA6S7bI7by6OR0YhLp+2fwUH2rt4LQwDHzCv4b 2O+FoYMI9QH0x/DOwYQqDB5smOLhGVoL61zIFilkmIC1IP9itBcG40KOt0wm9MhvBE1+K1OYjMDx Js+cIni+GUpnpMhL2wit88hiH8xIHoEKfGozasGIgazaEEq06L6ZR2/Vmcd0hdOV0b6i6Dq0UNho JxHF4coW2NeZThENvcMWFduil/72I4UXTAu1JXnm+kuNYK6weo1KnWXG8VrFl6UG1mnZIsoXjlt2 VEyZM1DIKkidwEwCtSrWNjV9yQkYqWZCc18cKvZuGLjUncUGNxpaRejP3oabAga7xReUtUFDp4ai OYzjLUSbZY4cxfM8Aa2/Dijou5tV5g8npc4tnqL2zpS7j9y0uBmXLnBVDxjdIcH+0sVHg3jZ4ecc e6rwhyD/IglZh5whJBEI4GLiNKOfG3DwBl8tmm3YWnfOYNRYh+akcmFT8MjnXSoqWjQgieSYuCCG mYCYCYRyPbbiajbSKJZuGeqSyj3XDdPjCiNm9AaJOFY3D4EQUhWbhzYtRFspxFi51pE3KiklX8jV A+VQOYlCoIvLTCgWRhdCmJMwJ/b243v2gOimTt2ceKdxxpU5xj4ZjeHaSN3oQsk/1bUm4k9pGZZj Lov206ihMyq6olCOXoqYnEFZhGmmmdTopR2A/KLmbKuh9Y2LGrH50XytcYoIGj6a8plTYfB5336W WkRRrcUkZIsmobkk2xuYFOtbSWoi+Wahfv5q5JR5CIsS/4ufUSIGqeQNiuqjl8wzIZxwuSTpORrW uaK4lPYaH7tm9FmrrU6GCu5JkpIUqyrGEsQTTu6y5O9LMFY7L6H17pvba0Kl1e1qovIIFb1zqXpl qgbL6tgzEFPJb8aXULuwrApjDDKsIn88cpX/FGYypJchlNZptJ0kzZcyWEYQLrE4FguE2lUp5JMo XQiLxbuunDKsGxctJMkUdzmyLfcwJ6/Sc0Lt84I0fbkNkaH8gzPCStqcw9bgqit1yM6JvZKY0CEH dsSJTpt2pyp7nHXJZK/94aPiGRP41WwXHnBQD3Nms1TrOZTX3R09XgPaWMNM99LxLU44hSdDzdlo q0H0dP/ealc+5LVvJ2654Z4niXWw4EFu0Nh0BlWwQCLeLpzuh++Nsu2xVz57wdh2vOV1fp6dTtMu 1t4336WLTPl5xr8c/e+rJ3h3aTHIyHt6qHx/prN2sw785b9zX+TfznsOevM3bMM85KdX77Eg09O/ edSYZ4942uOLRPu+1T14EPA6XOqdvkj3P6UF0CbOGxyeCniwAZVifqZr3fFGlr8MJu1+Qwue4QII NPvhLmdgaVHvWIDB/mFnZSRElv2sc6K5Qc6GBWLg81yowQriz1Wfa58CVdc7GmJCP10b12iEAiRP 4ZB/9DAX/USkOiSKTYnsM5/eoMhFngnmi/KTov70Zhf/1elsgkLU4QLPl0XpTadxaUTKTyIQgDra UQCJsIAA7MjHAAjEjm4QAAAGGQBM7JEBJKgjsdKxRyZegAF1FEBtIBkAPC5qj3gUyB4L2ZpNMgAm X6AkHwUwgk32kZTP2SMhEWkKU0ZSD3RQpAlE2UcW9dGOEcBkVyBJSlfeMRe3tCQdA8BKEWyyTsOs ZFD4SAJIDhIAkhROHT8pAl4+8paRvIAsl8nJD17Pd2zUHgeNNUaotCxsEWDAM9cJAFYKkp2DFEkE nsmAnwQFngBIRACgSYJ49mqe+QSEOp/ZzYESMiAG9acFEprPe65TNrnEJym1iU8/LlSiptgnPOt5 AX+W/4Chz2QRPvM5UGiIYJ+k1Cg7/QjSQdbznbQAaDGRtc5q1tSY+HQLQAMAB0H68Z3wDIAFPJoL olqviyFEX9aSSkaB/ekhmXBpPek4SJwSkwFYxSpUgSqAh0TjoMCsKkUnKgKjCsOgTBykAJw5UbU6 s5gj2Gch5XoLuVLVjxQlJl3r5FMwOBMAdpDrVHMlAULqQY8uHQlK/SpXOyQ2qvkUAzVbE8+PFLad YRgoGeyKhpKGQaOFUOtJAYBXWwF0kGQAKgBsCk07UBWwYHjmRH1qFKy6VAxEBajrQHhUzrGtGOF5 mzj9pls4ANSq17rsOxE30HRQcrP8HIFZLaDSgNJBrP/q9ONxH0laE/jzuEPN50VX29HIbtd2tA2F P1GK0EHOY7kSQOkIBlrWduZBrNcDaHjSe4H0ohQj9FWFPzWrWW7s1L4+FSt7bXLb0wIgtd1FhT9J kVujdm6H4PSfb6Xnq9hYjYtrErB4b7FcxBKzJiQmbXgZMBtBklUSiw3DdBUZzzdk16Hcxet5cVzf 2JJXt+DVrXD6G+GRrJe0gxUGf02B2vhGl7vkdWmKGiwGyGIVIPodLSs5KxrPFuKd+oSmfA2sVn6i tKqXnSxO8ejgXhb5Fg12LGb9amG/IbW3RlRFzOKSMCRKdqSIlIBqZRtXaN5VMWN+XnUfqqhE1FjQ ET7/bnp3XFTyltfHDsW0kefcU7UKAKijhaceEi3dgMr10+/E620hu1LYOJigcNgnIrNMUVFXeqOJ uKyFaZrP7sazqvrtRl9lGs8lX7qfI93tN2Gn1B96Z0nkA3EoDAFSTn4h1XxkpW7HS4sxi0KufJxu qYUy6aqW29I8vvR2gYxfl743p6Gu5Vi9a+qgOjqyhSLkKCWx01GWsrv81ai8X01at/w7su8AaHjn WUhgN5kEw67qqd987FL3sc5DnKIIRRYnFMVGM+AF82J8ekAik7aOj510P9Y6WrJWnI2PPjeRdYzf dFdWrAs/r4Xfiep6xhqaATF2sE/9aRbf2+Aizl5t/yhN2V7bt+XhqSpixZssYCdc4qQ1NJqlnEhD H9fBpe0xsqveUG/e+cJ5Hm5BgPhx4+AXtHqg7QFHilfNAuKd0HW5uHtsY+x2N8A3jgRqK71pMoB3 8JQ2MdsW/NHBH1yxT57ThMluFG+k+wRyrfli70te6qKW8qeTND23y/hNT1WsQA37yxcuYmWf3c4b hhX4LmW92TedwdEddjrrOd4/PzjULxXtvMftrkev2POodLd8BT1R+crd+aTN+8wvIfTAIhkNl7X2 OwNNajw0eKqV9utUK+GWyqIYypFH6ZVztd0vqBX0V18tWrc70K6G9cGaDq+Kxy7hsod/fxjGbG2E Mv9KcSklt0OUICI4B2kNNWj0RGrz9gWLJlQtx39582gmR084tU6G53frhEjjNXrpxE6spBTGBgiL 9ky30FITRVUu5334dGvsRFZ00FLR5X6OF2rwRHhiMVDF9HVz8XUqeF4OSHXnNVCFZFLxpBQV5n/n MRBvcxBP+A1vtCSTQn5QyBd/IinDdBaYdE3YREmfdC6UhBCiBFeHlEjdtByfdWK0kGpnkGratk+t JFsn8VesVIP05BFwwEvfYAe+hEtjoEpIZg+YBBAnhU3phE3E9FGMOFiCpkwQx4gSyFPgcIiMlYR5 UIbDRErD1EwqdWJteAvRkE3/ME0csU3AtIZbcBP/tJMfyMIPrwgmADGLSwBJNeCKvJMFQIMvuvMS tmgEG3ExlRMO1zBPcGWMypgLVQE0qQM5y5gMHReNvWAZsTAhT0SN2riNnNAZ+BI0K8SN4jiOjkAk UYIz00iO6riOXJCOZseO8BiPXNAsLOCO8niP+BgMldJ2+diP/ogNKlSA/ziQBKkECVgmklOQCrmQ Q+ATVLiLDBmREkkDEDmRFnmRGJmRGrmRHNmRHvmRIKmNBjCSI1kCBjADJ8kCJXkCK5kCLYkDKdkE JBmTPrCSLTmTL9kCOWkCNCkEPamTP7kGQakCQ5kDOHmTRemSSTkCOykCTUkCTykDUVkEOBkENpmS /0e5lDyZlFO5A13JklqZBV8JlWGJkjRJkk5ZlmQJlFEwllapljWwk26JAlM5lzZgl2nZB3aJly+Q kyVZlRcAmIF5klkJloSJlYc5mHm5mFc5mH75lz0pmDO5lpPJlJVpmDEpmGSZmIppmZaJlox5mGj5 kqC5mZ2JmYhZmpD5mafpmJ+JlD85mrEpmpSZmaWZlqpJmyYpl6AJmJqJm7AJl5i5lbLpm1nJm8Yp m4vZmVd5lK95m47ZnLnpnNEJncApnbNpnGtZnY2pmFUZnGdJnajJnamJneB5nej5nMh5mck5nZVZ mM+5mcUJmb/Znny5m5d5mkiJm55JnPzpmqHZn//NKaADupusCaC5uZzI+Z9N2ZvdGaAQ+qASmpr/ SZe2SaC2SaH6iZj9yZwFapoICpsMeqEhyqGhaaL7uZwd6qDCOZ4qCpwq2qDhGaMXmqKkaaIvuqHb eaMwaqE7GpQ82pqP2Z0Tep0P2ppbSZw4KqTl6aDquaS8+aPbeaKROaPkmaMbGpUpiqU04KTqSaNg KaUrypkeKqY5uqVlOqbWyaRYGqRByp0RSqLw+aZh+qVsiqHvmaF5OqUdmqZgmp53OqdAGp5riqb3 +aITiqJWaqAEOqWrCaGQiqQ62qh9Gp1JSqmMGqkFSqQ4eqR9WpcZqqlWKqOV+qd8eqR0aqmBOqj/ dSqfl3qnZhmqk+qnklqipgqgojqis3mgXgqpCxqihjmivCqnioqhJ1qhrWqjhKqrvsqpGgqivWqr k8qiwgqssxqlzBqX4jmZguqq+Lmnn+qmiwqf3rqtoyqe8omm6Wqe7Bqnanqj2vmtV4qk5CqZLAqv +WmkJGqn80qu1bmuMOqvPYquXZqv9+qdVTqonEmnt4mqyyqjenqqelqU+amlj2qpwYmwzQqipump upqYCwqv+HmgHburDZudCbuf1rmyJ9ukFhqx7JiqQtmiSECzrVqrQHCobBmSRimwM6sFNquk+eqT QauSRcuzAKuXR+uTPECwQ6CzRou0Uju1VFu1/1Z7tVibtVq7tVzLBnh5kzpAs/vaA1+ppTWblAmQ ACaQtjrAti7gtj0Atx35tUuqrVI5tk2rlU8JtXerAnIrAn9bA4GbAoOLA4WLkTrLt1xKlEvrlUOp uDAwlYF7uDFAuSVguTSAuVzwmK8psXn5pgmKrPT5rTXKnhZ7ry77uc7ZmAZ7sZ7pusqJsNhpoK27 pQkquWp7ubkLuHLLtnCbtrt7Ab8LvME7Ar4LvLo7vMarvJq7BZwLp3+qmSJKpRMLnqybp4W6utxK ncf5qMf5pEKbpdj7nbVrr+CKq667tsUrvLtLvO1LvLyLvOrrvvNLv/Erv8P7vuzbCMqqoeLKqv/W 2r/Vmqa2u6sbe6wK+qyb+qse6r/KGqwI7KUSjLbuC7/7y7vxu7warLsbTALye8H467YiPMIYzAgP jKm0Wpsa26/n+rzWi7KZ2rmw6rC3Gr3naqaeu6oa67EeXMEhbL+9W8H1S7jBS8IbfLz7a8QmTKbi isMq7L3cO66mm8C/Caj4SsO5CqvhasNOzMWNupo83MFHLMQXfL8f3MNnLMZKDMJqi8Rr7AcX28Qo /MQLC8CIOsGl+rKdyqmOCqV+/Kq0isWkisLXu8K4q74lzMFi7LdpXMZs3MMY7Ma527yba7oOPKxK KasBvMCUOr3Y6qcnnMA2/KxbLK1yHMMLrMn/a4oCkzvJRhzErozIiazGrlzLy/u+6+sI0GmuUZzJ JPuv+gq+DZy6pCudLOyqWDyvOXzMeIrK1cuxocvK65u/yovGg+vDspzIZJzB3OzIi8CyQ1rHvoys uCq7pKumv3zOwwrGCRvID2vANCrO6LzMqkqy0XwCrYzGkJy8RNzIjgzLxfvBAp3LfAC5ESmzjMun XavLqyy139uXPrvQ32zQEum0Rju0XODDGr3RHN3RHv3RIL3NEj3SJF3SJn3SKJ3SKr3SLN3SLv3S MB3TMj3TNF3TNn3TOJ3TOr3TPN3TPv3TQB3UQj3URF3URn3USJ3USr3UTN3UTv3UUB3VUj3V/1Rd 1VYdjejWUWqQ1VTA1Svg1U4QZT1QVTU3AwMwACZw1jeg1hfA1mzNA299AmeN1ltQc2B9A5Z21zKg 19IV1i7A1y0A2DAg1jtA2DRA13EtAoktA26N2HQN14+d1pGtBauV1z9g2Tog2IIdBJu92Srg2YFd Vjxg2Izt2EPQ2D6w2COg2ldQ2X1dX15d2VGGbipYXrKd1+2m1a+t21ot28g221yN2ba922Id3Lld 28PtXeX128xdAsiN3M5t17nN283d2/QG3LX93NRNAnON1mr91o2d2OC92t5t2m092eOt2I4N3nN9 3urN3e193uwd1+yt3vXt3vg92KKt28Jdav/1td+YLdwBntUCvtz8/dqxjeAKDuDBveAFHt0AvuDb zdv9vd8HHuETPuDKjeGGPdsqEN74/d3m/d7y/d6ond8kHt8inuKPveIlcOInDt/kHeLmHeMvQNgd vuEUvuEPfuHObd05/uMTLtoPHuAn0OA7buHEzeOfveRC3k8OruOk7eQ4LuEoAOOmHd+SXeJYTuIy 3t5dnt/dLdc1PuJfXuYsbgOWHeRQbuG4LVYCflMJ7tpsLuco4NpunudDntw+zk5SXmrtVtZ6PuTP becZbuVUzuDZvQJhHt6T7d7eTeNp/uKRXt6TPt+PLumaTumaHuY0sOaD7uR9PuhI/uN0ruf/Rn7k ST7qex7lSv7nq77boq7XU+7jiQ7rVf7kV47mKK7l9l3ejf7oYz7mnd7ils7pxU7myb7pM0DbbD7r DE7qiA7tHF7rsp7qtn7rPa7tzy7tTx7ktY7tbX7h4M7ovO7iiw3m923j5A3sM77pLi7jyy7Zxp7m Kp7pX/3tgr7quM3fHg7bsj7uPU7W/63q1W3b1s7n/87nAu/fb37kDw/xzi7ugB7wFY/hCj/uZ37p vv7uYs7ryN7rWr7u6G3s903v8E3fx87a6wjaU+vy3NjxGgnzSEvz2sjyE7nvV80FxL7zPv/zQB/0 Qj/0RF/0Rn/0SJ/0Sr/0TN/0Tv/0UB/1/1I/9VRf9VZ/9Vif9Vq/9Vzf9V7/9WBP9TYf9ld7AAeA AA8AAA8wARNAAWSf0maP9mrP9m7/186+CzpPBHnv31gf92m/9m1/43fvCnt/5zlQ+Abe6kzv93Mf +IJf8ITv8ogf2KA9+UjP+IBf94Iv3YFe8Df12wvf72Qd274N29iNbAYO529+24NP4af/34Gu+ghv +krfAAVw+5hP9zHw+bKf+guP+sut+h6ugoJO/KH/76OP/Mqf+J4v+71v/L4f/dJ/9A5g+wVAAASQ AAoAAAsAAd5fAbs/+M//+3zv/KPf/PSG/uo//urP96gP/dJv/uK//Ehf/baP/drP/d4PAf/gP9jz v/4gAFwjeQGiiZ4mu6ajW7oz+to0rOqlLYv/7STMEVO4oLDGWzKbzic0Kp1Sq9YrNjt1OBqNQiGh ACwg5oo1FiweecekcdcjvWt1tlw9z63g+zVdX56SVqHhIWKi4qIWBVdDUqQelNrd0B+gkSbe0lCb Jc5lKCHfJqDnz84dJmOr6ytsbCNXV9hY2VkaoR9Rm9tlUY9vr50S70uMYGAyKbOPM/OnzqRstfU1 NqwYmRkEWvY1Nfg4ebn5OToTaXqrOPs7fLz8PL2sez1+vv4+f7//P8CA8NYJLGjwIMJ4Bw4geADg wYQJFBJSrGjxYquFDR9GnDilEkGL99r/hQyE8STKERodQpRIBWRKk9hGCotp0+BKji5fyrkJjqYP n0L95WzpkSdIZ0iaibJjUlknYLwkPS0WjSkdmVNTLVPVFOjQsLK+gCnaUZfSVdRGlUIGVSvXU8Xk ZsLj1a5bYpxYie0rq1YBAgS24fKmKyhdTKDiDgOWOG/dyG4ZDyJmrDJfv5pbdfkimHC3bzwRq11n qQXmZ9OaVt3bdVIf1HxYL91LdTPuWI/Igs5VBWbitYMErYoaFzHkxiXh+IHdU1Px3NJfOeoiKdLv y5xo/wqGau4etnWlVh5WijxeqOpTT29/qHqt3oaz/4JpfjbytEyvymwrjLw4SuGn14D6/4HlHoJV yCdagg062F5JD0o4IYUVWnghhhlquOEiEXL4IYjpmLVTiCWaWM6IRyGFyHfR/eThgep4+OIVMZ4I Too12iijbc+pAwtNybwUTBQzHrKjkDfCkyN9O3b3B1hOfmQkkU/cx2M1Tvqo5DlMjgYNQc1d95iY NDiXlV1z8TfZasZxlVSb/ZkJnnD/gYnmMQU6pZeUJpJVgJdT2gklXD2yUWhkZhKo6HrBYQWdCojK SZlrVWGGSlSZJjfKcVxGAdhnt4Q2mqEyllapmJVa5uiqiJoXXardnQrlpexVSRemknnaRGeBDSaq b1Lod+umpd651JlAzFkas46VWqystf/eOuurj4Yim667LrEbGAsiFeuZrIp7JX6xknYZpZlRu2Wj j7kq7ZPnlktbnyFWB8l1zjahR7vyjgvvfd+9++Zd7hprq3+LZUovwuFGYwq52pIA3xfeCrtLuvWt 691WA2o6R8drGhhmxthNC2dQda6pq3PA/UesxE9YHHM2+tIsHZU3k6Qzzz07kafPQQs9NG45E310 hoEivfSHShcJ9JMRz2Q0OfUynZLTVoK3L8I1wxyP1VeflPXPVEodDtXnhC32RWRzbRp6uGon3LDz vhWyVXAf6yaPKL/MdkV/uv22dv9Sqi+d0q5LcJV1dKoqpDC09jXgAIH6KzfBTln3xtn/gutj58Rx /aykpae6duXs9Bpq5vOhNVvoXber3MFpaupiHA6rWXDqCHFrS+sM0kdr7ZJ1/i7pzs6K3DL/ZtZ7 P/fmazOWzrOKeHmgFN9v8f4+Qybq0J9DMfCFCU/JMR2LC5nGu3c1eRwD6524qXCDvFXa4uczszzh C0W9/g6SP2ts7UL+C6ABAeggqCGwgQ58ICUgKMGwDG6CFsQJQ1hylhX5R1A1G6BIqHbAnRHvRhWs T/OGN7XpJOlp9WgYCBN0QtXET4VoS9AIaRSv/phohu/73PvYN7pcZeJ09iNiDWvIQBr+DX9xCyJx 4hQ1mznRUi/zG3N4tzILCS6DOlGR/wuVBbBUPA6FuToVEs8zu55ETDzQkoa8ljc5fhWMUethDPIi Z7AJXY5/6GvB+iDnLzkab4wco5z2wBce4OBOdNXbHnuAaD0LrQ5z5vsStlzURkMu8mSQfM1yTHZH 7rwFisPBnsd4aD04xg52MQzL7/yoNT1qckuDhFfpPvk3F0bLkwQyzh6ZpzyM6bKVwayQ9KZnJNFx ajswNBTDCqnLPUqDfvezVrqqlag6jjGbtfIm5RJEPlmWTXJXzBvpnnW3aE6RYwJKIt3QxcRr1u+Q STxXPIN4PXQda5365BA5q4aSV6KPoOzIocQM2qGBZkmh6UDoBX22xIBANKIWvShGM/+q0Y1ytKMe /ShIQyrSkZK0pCY9KUpTqtKVsrSlLn0pTGMq05nStKY2vSlOc6rTnfK0pz79KVCDKtShEhWBuzDn PJrhtSLZ4yLLSaoSBjCAJUj1CVWFxVWv6gog4OmF6MiZQ2Xg1E6gaUixIIVWSZBWqk4Vq23ValsV wVVzhlWuX/3NK+qqNrIi9SNN5cFapRDYRQR2sIWYKwsSK1akSqWsWUnK957CV1Og0A1lncZj5Sk5 AL0tsymzLGM7GNmEscIxjbVPZTuFvUjRlZ6mEm1V4RrX2L51qoal7QiyOlup7ja3tuWtbLOwp8Qq tbXGVaxWQqtY1sJGuYtF7nIfiyf/5nY1un1V7gzoetTQDvey2GXtc8GbB+1ONrvWDe90j1tc4rL1 t759L299617A/ra2771Ab/FrX/3y97418i50Nwvg7mK3uuy97oGZalllFfi4BiYwaPcEYQaLd7I/ Oq9jG5zg9Uo4w8ida4cRHOIS6Pa+Je5vYfd7YvmquMX91ZEoEQxIDXMYdjbGMGMDhDhArqbCpF0u 1JrzYLIyOHcWhqKHISZk9ZZ3ujuW7nefnGC1uhjFVSZxlYN74i3P97+LBa9Yh+tj9Aa4xqB9LoDD PGMzf9m5F96wmwXM1aeeecwXNvOEB2wlNWv4zWA2cZavTGVAE9rKhcatlxcs4w8P/7nONI4znCNs mjT7OMRi5qt5I+1oSFvazo+2bp4/jeYPU1fEBh60ofkb31RjWb/2XTWXC+1qVAvrR3/OsGmlbJXR 3jPHJAswhgGkWeLuum/ODbJjqZdrTfO6sb621mXrlGzXAhPBsYavoAet5d3Cer9Wzu9fi1oOY6DD sFaNK2HTim4gidsc5B4HuKlg7kKou6Htrtp24b1qK8wbC8C9N8ADLvCBD7zfBgSHAQxAj4QTbd2K cHgTDG4OiNNjva5g+DwwfgGF80ziV/C4x/XdD4u3QuP1MHnM/u1qbr+a5Sx+ubYdjuiVw5zmqka3 yl/+75xTuoVKhWwKe1FZypKA4f8JV7jJj87xjXMc40pfgsadfvSiN73qKH8605kudZRTnetar/oI oj71sI/96123+tLzkVVUbzvQh65ve1ld4rkj+tq4XfGnJ1zqSLMrzV3XetY3TnWyB17qPBB74cGe eKiD3fCLP/zgS2B4x0++8ZYnu+PVjvNus93tqcb72zs/a9F/ft20pfiMQe3hEVd69X4n/OMxj/bI c93oiqe84iWf9Nvn/vBlx7zuYX/1tC++7L/Xx7b9y2WV65b53iZ9cL8daOfTt+Z8Vr2ptfuVTLOZ FLgf/NaXrvTaI533wu/92c8ve6/bnvHfD3zkzx5+2fPD7vkFPatJ32q5Pz++197/P62N3vWxXpOV WQGSWYC93/dlHhO03+O9XwM6IAMyHuy53wMS3/A1gfF5nTzYX8x5XqztG5XNV/TVHdx54M3l37Qx 2aYRII6dl/eZ3wXOoAWqX9aNHfkRngISX+ypn+2ZX+Xp4OzBn+axWP91Gc813+a9WMwFYM5Rn7qJ 4BPWF8VhDD8dYK5dYbzYDASOnw1iXQ3SH/ihnxgintlF4PGd4Q2K3waKnRsOYUqEnL+hXhXIoRbo 1UmkoUrFWyvYYcTRoV1ZCAfuoQi6gh8ywSHakISAIcE1oiM+IiRGokEM4sXx4FIpokB5kCT6nhVY YhSQYZYk2Z4BWygu2pFtohZQ/6IGgmK4Gc2tEZAoniIqFh8b/iAcSuDUOSARLthznBZmYUu13QbE QFfGDKOiAONrGWNbSJiQ4GFGbd0aCmHY0R4uSmMF3s7ejReQZd+BXVoJmRczqtcrNhr3RVc45tQC 7p7u7aAPeuKx5d3rRdg7Aps3uqA37ouoRUrr6dQOZl410qAu+hk5Nho9isKzvWI9DiSktZk4GmSP maJMQSDgsSNAlt8oYh/fxaOluR4WwuNCKqQB3pozalQ6WiNF+qMqJiQL3mN6aRpC6tlKxiNDuiSl QWRM9SMbrp8NRiPwcSQM+tyhyFhsEFvQTdqxAeUNaGRRNttoQdgsPsHvjeRJSP/lUx4CylHlWFXl wumhVnalV34lWIalWI4lWZalWZ4lWqalWq4lW7alW74lXMalXM4lXdalXd4lXualXu4lX/alX/4l YA5NFHJIIv7MQvkFVtqbAt2hIQzmPABiuUFmGgjXmx1cIJ5ZBJFiIrwS/rFDYRZE/hglhjiUaGbm SBJUEu5bZ05h8rUXFdbczNHa/amm/wFXb9Fdqw2WLzZlZv2cZrHkTybkfkCZsoFYkqgWYinZrxXb MOnjMmJHsVUbMg5lY9Jm6FWfqnVelxGa/W3nt2GbrK2YCZIg3LVgNvZZcpnj69ljS5JZOUpag4Hj tChlUjpYtMUnC7pnqaGOY/7/XwCOYLZJIQjK3Al63ouZ4HXO2z5mZAF2WJEpmkcaJgw2aHW5IALi 2anJ5H7aJEgaVH9mGxOCpwraHAqmGH6dKAoeKHkmKMQtGYNOGUyy14MOIEhqzEFSqHFZaE2ap0Ee oBLlaEEtqIcuYemxFXb6J5ataJHS1+kZaGuWqMOxZ0ziqIymHo1OaQvGIkae5wsCJ0Ym2T1uqGZu 6Ud+HJHSHYGKKJLiZul5p3wJ4P9F4WxyZ2Bp44u+ZH46ZV9JKXxOaJ9uZI52H6Yt6IUGJZd+mZAm wlqlZojCJvU16hQ6aqMq3+ZFHxNaJ/9N6lCmDxZ1XyXEohUy0XLuqY4BmYVS/+ekjGrCQJtkdWPQ ycpRVpQ/fKaZSqaRChDYGAJBJebN0Cq/2Wpu/SdFPZSWSuiYZuaxPpCvTgHPCVYhAoSschAWLObT 8GpgXiu2ZmsjWuuoHUk4JFplhluxaiIspg63jutZMeZkbhqyHpYsruslAs65cmi6Uia8yuS73iu9 tuu3Bk0WRtuwCaT22dpvOtmdAaxoddBpGWyrphBy/mKYOQXEHkd0FuNzSuzCvOqyzetmSKmOsiuI 3Q53QZkBkik9DiTGBmp5can9ECWoianLZho5Ftd7dpq/jiKh7lmRhVrJzhlHjhiY4qjP5ueOzqR7 xijL0ifQIq2o9UwWMhf+RP/QzgKNmDnkjc1kxXYWfj5kl/aczDLtlMYYp6FnhHqaROGnsdraml1k 640j0donplUojHZthB6tRwqqPMKtyX7szdjsnSKrl/qtn2It2e7tjvKs37bsmO3jqcat3tppovor apkqU/ooFd1nd12uxzxRsyGlwqLST7psxCbbymTt2P5Yxn6uFnLsibAuv/4PQrgu08hu2g4F7U4r ulZltFYcaO6utv4u8Aav8A4v8Rav8R4v8iav8i4v8zav8z4v9Eav9E4v9Vav9V4v9mav9m4v995l AiTAEnwvIogvNoBvOpjvBZBv+KKvFHyv+h6E+rov+zKB/LIv+b4v/c7v+u7/7/jqL/y+r/v2b/n6 LzjELwHjr8zIL0XcrwI3Qf0G8AgwMBQgMA8gMAVjwQUbBAAT8BVkcCt48DUYsABbhARPsP2WcPty cATrLwhTQQsHBAqv8AaXgAWDbwPLsAivMA1TcP2SwA2vLwT7cA37bw+L7w0bcBALcRD/sBGfcAWj LxM7cfrasPn28A47sRXnb/gKsQ4rMRR/Mf/u8BWLMRKLMUbE8ANzsRpfsRU/cBWDMQ6zcAOnMRAf cRQncRxPMR0zcBbnsR4vcRQ/cRzDcRcXMR3/MRj3sSA7AQrv8Rtr8SIjshe/MSCjxB3LcBdnshKr cQ53MiGvMQTj8RRzMhzn/7AZ6zEpZ3INbzIqt3Ik8zEmjzIpE3IjP7IsM7IKl3AoP/IFu/EuzzIo 2/JJ4O8M37IxazIxVzIS/7AqSzEbP3EbH3IwmzEfc7Apy3Ivl7IUF/MGJ3M0azIkO7At8zAzT3I0 f7M5C/MZzy83O/Ma3/IhN3E6h3ExQ/My77Iiw/M2f7Eo6zM1WzMVvzMaq7MkD/I4q/AxL3IMT7I4 868bI7Mjp0Qy//MpCzQlN7M/J7BF4/JCgzM977M9fzRFN/Q1D7RH//FJd3Qk+3AqJzQqk7NDE7E7 v/NFeHMsl/FK1/IYs/Iq33RPY7Mud3RJHzRN6/NFu7Qft/Iv+/QpwzJQn7h0Tgc1Uz91GAMzVU+1 TQwxIEszRBv0TjN0HQ9y/mZxH+czSrezV0e1HScwO5P1QxvzWxf0VZNzPAtzRHv0T7u1PX9yTcu0 Nwd0VHuxUQMxRwu2OOOxKPczJqN1Ulc0Shf1Vxu2YC+0IiexTh82Y+PwNK80RM+0KyO1XL7wOSB0 97pCOcsDaUOPL682a7e2a782bMe2bM82bde2bd82bue2bu82b7d2af82cAe3cA83cRe3cR/3I4YA ADs= --%OLATTACH1-- From simple-bounces@ietf.org Wed Mar 2 15:15:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21026; Wed, 2 Mar 2005 15:15:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aGd-0001KA-1T; Wed, 02 Mar 2005 15:16:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aDS-00008L-6J; Wed, 02 Mar 2005 15:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aDQ-00008G-Ll for simple@megatron.ietf.org; Wed, 02 Mar 2005 15:13:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20718 for ; Wed, 2 Mar 2005 15:13:02 -0500 (EST) Received: from seldrel01.sonyericsson.com ([212.209.106.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aEc-0001GQ-Ne for simple@ietf.org; Wed, 02 Mar 2005 15:14:20 -0500 Received: from unknown(212.209.106.2) by seldrel01.sonyericsson.com via csmap id 7a69d344_8b57_11d9_9656_0002b3be508e_9634; Wed, 02 Mar 2005 21:13:02 +0100 (CET) Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 21:12:53 +0100 Received: from SELDCON01.corpusers.net ([10.129.0.26]) by seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 21:12:53 +0100 Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 21:12:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2005 21:12:52 +0100 Message-ID: <1AF90E65795A3D45AA116B9264B4DAAFFEDD82@SELDMSX01.corpusers.net> Thread-Topic: draft-ietf-simple-xcap-06 Parsing of an XCAP URI Thread-Index: AcUfZDbdgroTS6wJT66lljP1F6R8/w== From: "Hyttfors, Per" To: X-OriginalArrivalTime: 02 Mar 2005 20:12:52.0939 (UTC) FILETIME=[36F8C1B0:01C51F64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [Simple] draft-ietf-simple-xcap-06 Parsing of an XCAP URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Hello Everyone, =20 Is it possible to parse an XCAP URI and unambiguously identifying all the different XCAP URI segments (like the XCAP root, AUID etc) in an absolute URI? =20 Since the XCAP specification allows the XCAP root (as well as the document selector) to have all kinds of path segments, how can I then find all the XCAP segments in the URI without prior knowledge and removal of the XCAP root? =20 I've looked for a restriction in the XCAP specification to make this parsing possible, like that the "/users/" and the "/global/" segments were disallowed in the XCAP root, but I did not find it. Did I miss something vital or is the XCAP URI not designed to be parsed out of context? =20 I have also not found any restriction that makes the path separator "/~~/" segment globally unique. As I understand only the node selector is prohibited from having that segment, caused by the XML requirements on QName. =20 /Per _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 2 16:11:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27177; Wed, 2 Mar 2005 16:11:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6b92-00031j-AO; Wed, 02 Mar 2005 16:12:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6b6e-00045I-N3; Wed, 02 Mar 2005 16:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6b6d-00045D-BT for simple@megatron.ietf.org; Wed, 02 Mar 2005 16:10:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26992 for ; Wed, 2 Mar 2005 16:10:04 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6b7q-000303-D6 for simple@ietf.org; Wed, 02 Mar 2005 16:11:23 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2005 16:09:57 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22L9t1j028251 for ; Wed, 2 Mar 2005 16:09:55 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APN06037; Wed, 2 Mar 2005 16:09:53 -0500 (EST) Message-ID: <42262BA1.7070408@cisco.com> Date: Wed, 02 Mar 2005 16:09:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-levin-simple-interdomain-reqs-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Orit, There are lots of things in this draft that might be worthy of discussion. There are a few things that I especially want to bring up: 5.3.1 Ensuring User Validity "An edge proxy MAY automatically periodically generate re-SUBSCRIBEs towards an external SIP/SIMPLE community..." Proxies aren't allowed to initiate new requests this way. The resubscribes need to come from the watcher. I don't know what you intended here. "In the absence of any bilateral agreement between the administrative authorities for each community, subscriptions to the same URI MUST NOT occur more frequently than every two hours." That would be really inconvenient if the expiration time on the subscription was less than two hours. Seems like it would be better to suggest that subscriptions not be gratuitously refreshed more frequently than implied by the expiration time of the subscription. I say "gratuitously" because there are other valid reasons to resubscribe: - to change parameters (e.g. filters) - to get a full state snapshot when synchronization has been lost with partial notification state 6.3.2 MESSAGE inside INVITE Session 1) I am somewhat concerned about publishing a document thru the ietf recommending use of MESSAGE inside of an INVITE dialog. I am *especially* concerned about blessing the use of "m=message 5060 sip ". AFAIK the latter is not a valid m-line for SDP. 2) Regarding: "The recipient's UA MUST ignore all INFO messages ... that it doesn't understand." I'm not sure what you mean by "doesn't understand". I presume you mean that the body isn't understood, since headers that aren't understood are always to be ignored. That would perhaps make sense if content-disposition handling parameter is set to "optional" and if the recipient supports the INFO method at all. But it is contrary to 3261 to require support of INFO or the ignoring of required but ununderstood body parts. Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 2 17:40:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06424; Wed, 2 Mar 2005 17:40:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cX2-0005Oq-JP; Wed, 02 Mar 2005 17:41:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cTJ-0005yn-KE; Wed, 02 Mar 2005 17:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cTH-0005ya-Um for simple@megatron.ietf.org; Wed, 02 Mar 2005 17:37:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06252 for ; Wed, 2 Mar 2005 17:37:32 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cUV-0005LH-L5 for simple@ietf.org; Wed, 02 Mar 2005 17:38:53 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 4EAFDA97B0; Wed, 2 Mar 2005 23:37:19 +0100 (CET) Received: from [192.168.0.100] (128.80-203-102.nextgentel.com [80.203.102.128]) by voyager.coretrek.no (Postfix) with ESMTP id E715CA97C1; Wed, 2 Mar 2005 23:37:11 +0100 (CET) In-Reply-To: <421C2702.4010607@nokia.com> References: <42198582.6000405@nokia.com> <421C2702.4010607@nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] draft on MSRP conferencing Date: Wed, 2 Mar 2005 10:07:38 +0100 To: Miguel Garcia X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit On Feb 23, 2005, at 7:47 AM, Miguel Garcia wrote: > Ben Campbell wrote: >> I apologize in advance for offering a knee jerk opinion after having >> done only the briefest scan of this draft: >> Couldn't this be accomplished by simply adding multiple To headers to >> the message/cpim envelope, rather than by adding an extension method? > > What you are proposing is what we have proposed in version -01 of the > draft. However, we went into some problems with that approach: > > a) If the MSRP does not implement this extension, then it will > distributed the message to all the participants of the conference. > Certainly not what the creator of the message wanted. In this draft, you are defining the behaviour of the MSRP conferencing entity that thus far is not defined anywhere. Therefore, you can mandate for this behaviour to be implemented. > > b) Message/CPIM contains To and Cc headeers. However, there wouldn't > be a mechanism to do the effect of a Bcc, because we are linking > routing with presentation. What does it mean to have a cc and bcc in an instant messaging conference? This is not email. But if it is really needed then we can extend message/cpim to have bcc header (I'm on a plane so I cannot validate your claim that there is no bcc header in message/cpim). Regards, Hisham > > So we ended up proposing a new method, because if the MSRP switch > dooes not support, it returns and 501 response, and at least the > message is not distributed to the whole roster. > > Then we added the Distsend header, that contains the desired > distribution list. This list need to not be the same as the To and Cc > headers of the Message/CPIM, so that the creator can create blind > copies. > > /Miguel > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 2 18:58:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14015; Wed, 2 Mar 2005 18:58:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6dlA-00070O-1e; Wed, 02 Mar 2005 19:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6djh-00046J-OG; Wed, 02 Mar 2005 18:58:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6djf-000467-VO for simple@megatron.ietf.org; Wed, 02 Mar 2005 18:58:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13972 for ; Wed, 2 Mar 2005 18:58:32 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6dku-0006yn-8s for simple@ietf.org; Wed, 02 Mar 2005 18:59:53 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 15:58:27 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 2 Mar 2005 15:58:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-levin-simple-interdomain-reqs-02 Date: Wed, 2 Mar 2005 15:58:23 -0800 Message-ID: Thread-Topic: [Simple] Re: draft-levin-simple-interdomain-reqs-02 thread-index: AcUfbI+bF3eCFXENTx+Q2wqsKzzldgAFk88g From: "Orit Levin" To: "Paul Kyzivat" , "Simple WG" X-OriginalArrivalTime: 02 Mar 2005 23:58:23.0840 (UTC) FILETIME=[B8046600:01C51F83] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: Tim Rang X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Paul, Our goal is to gather SIP/SIMPLE interdomain operation experience, document it in a publicly available document and most probably publish it as an informational RFC. Thank you for the comments and we will definitely clarify the language going forward. If you or additional parties are interested in promoting this work in IETF or taking a different approach, we can start discussing during the next week. Thanks, Orit.=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, March 02, 2005 1:10 PM > To: Simple WG > Subject: [Simple] Re: draft-levin-simple-interdomain-reqs-02 >=20 > Orit, >=20 > There are lots of things in this draft that might be worthy=20 > of discussion. There are a few things that I especially want=20 > to bring up: >=20 > 5.3.1 Ensuring User Validity >=20 > "An edge proxy MAY automatically periodically generate=20 > re-SUBSCRIBEs > towards an external SIP/SIMPLE community..." >=20 > Proxies aren't allowed to initiate new requests this way. The=20 > resubscribes need to come from the watcher. I don't know what=20 > you intended here. >=20 > "In the absence of any bilateral agreement > between the administrative authorities for each community, > subscriptions to the same URI MUST NOT occur more frequently than > every two hours." >=20 > That would be really inconvenient if the expiration time on=20 > the subscription was less than two hours. Seems like it would=20 > be better to suggest that subscriptions not be gratuitously=20 > refreshed more frequently than implied by the expiration time=20 > of the subscription. I say "gratuitously" because there are=20 > other valid reasons to resubscribe: > - to change parameters (e.g. filters) > - to get a full state snapshot when synchronization has been lost > with partial notification state >=20 > 6.3.2 MESSAGE inside INVITE Session >=20 > 1) I am somewhat concerned about publishing a document thru=20 > the ietf recommending use of MESSAGE inside of an INVITE dialog. I am > *especially* concerned about blessing the use of "m=3Dmessage=20 > 5060 sip ". AFAIK the latter is not a valid m-line for SDP. >=20 > 2) Regarding: "The recipient's UA MUST ignore all INFO=20 > messages ... that it doesn't understand." >=20 > I'm not sure what you mean by "doesn't understand". I presume=20 > you mean that the body isn't understood, since headers that=20 > aren't understood are always to be ignored. That would=20 > perhaps make sense if content-disposition handling parameter=20 > is set to "optional" and if the recipient supports the INFO=20 > method at all. But it is contrary to 3261 to require support=20 > of INFO or the ignoring of required but ununderstood body parts. >=20 > Thanks, > Paul >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 2 22:18:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01525; Wed, 2 Mar 2005 22:18:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6gsT-0002j4-Ih; Wed, 02 Mar 2005 22:19:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6goj-00085V-Tr; Wed, 02 Mar 2005 22:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6goi-00085Q-NB for simple@megatron.ietf.org; Wed, 02 Mar 2005 22:16:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01403 for ; Wed, 2 Mar 2005 22:15:58 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6gq0-0002gV-4P for simple@ietf.org; Wed, 02 Mar 2005 22:17:20 -0500 Received: from [192.168.0.27] (S01060050baa8032f.vc.shawcable.net [24.85.92.32] (may be forged)) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j233FsK14701; Wed, 2 Mar 2005 19:15:54 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Wed, 2 Mar 2005 19:15:59 -0800 To: Simple WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Simple] comments on RPID X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Hi, I just gave a fresh read to rpid-05 and have a number of comments and suggestions. General Comments: Table 1 is a nice feature. I would add (non-normatively) cipids, servcaps, and devcaps to the table for the convenience of implementers I am a bit unclear where the normative root of the pidf schema belongs. The current organization is a nightmare for implementors. I'm assuming the intent is for the presence-data-model to be the root of things, but the text did not seem to specify this. values with free-text and semantic data should have tags instead to handle the same semantics in multiple languages. for example if i set the sphere to I should be able to set this in a Japanese GUI and have a friend see it semantically in Portuguese. If someone puts in something unregistered, that's fine, just put in free text. I think this is a problem with activity, mood, sphere, relationship, and possibly service-class In the person and tuple tags it would be useful to add an "input-source" element indicating if a human or automata generated the markup. I think we *really* need a way to associate person data with the tuples that contributed it. I suggest a list of contributing-tuples in each person element. Otherwise, there is no way to intelligently tie ambiguous presence data about a person to the service(s) that provided it. For example, I may want to ignore the person information from a service running on my home PC when I am travelling at IETF. (for example if I leave my home PC on and another family member uses the computer). The presence compositor doesn't know how to handle this ambiguous data, but a human might, *IF* they can associate the faulty presence data with the service(s) that contributed it. Many values could use an explicit "unknown" value to override an explicit value somewhere else. (I explicitly want to override some piece of presence data that became stale). I think we really want the note and activity fields to work in an interoperable way. I have no clue how to begin to intelligently resolve a note and an activity, or merge 2 arrays of activities. Even as a human, I can construct two different activity arrays that have very different semantics (both reasonable) when merged one way vs the other. I know the overall approach is that we are not specifying merging algorithms, but this one looks like it is asking for trouble. Wherever we provide URIs (status-icon, and cipids) we have a potential content indirection attack. Comments about characteristics: I would add to : presenting: giving a presentation, lecture, or formal round-table discussion i'm completely unclear what "class" is supposed to convey. I think really belongs under . The text indicates this, but the table and schema do not. Also, I think the device-id MUST always be a urn and SHOULD be UUID URN. this is consistent with the instance parameter used in GRUU. I think should have separate audio, video, and text elements to encourage orthogonality. video: toobright, toodark, ok, unknown audio: tooloud, tooquiet, ok, unknown text: toouncomfortable, notappropriate, ok, unknown I have several proposed additions to cycle: in or on a motor or human-powered cycle classroom: in an academic classroom or lecture hall prison: in a prison, jail, brig, or criminal mental institution hospital: in a hospital, medical clinic, or mental institution bar: in a bar or cafe club: in a dance club or discotheque underway: in a land, water, or air craft which is under way (in motion) i think may more appropriately belong in than in some cases. i propose that it is allowed in either. there is a potentially half or full duplex nature to privacy (ex: a speaker phone), but I am not sure this needs to be included. for I would add "friend" to the list. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 2 22:20:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01710; Wed, 2 Mar 2005 22:20:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6gub-0002lw-4I; Wed, 02 Mar 2005 22:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6gsU-0008Tg-Cx; Wed, 02 Mar 2005 22:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6gsS-0008TV-C5 for simple@megatron.ietf.org; Wed, 02 Mar 2005 22:19:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01628 for ; Wed, 2 Mar 2005 22:19:49 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6gti-0002kX-VG for simple@ietf.org; Wed, 02 Mar 2005 22:21:12 -0500 Received: from [192.168.0.27] (S01060050baa8032f.vc.shawcable.net [24.85.92.32] (may be forged)) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j233JjK14720; Wed, 2 Mar 2005 19:19:46 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71a8b813db34b04b2756c7e4cbcff8b1@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Wed, 2 Mar 2005 19:19:51 -0800 To: Simple WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Simple] UUID in presence data model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hi, I think for things that use SIP me should require that s MUST be a UUID URN, and that this URN SHOULD be the same one as used to obtain a GRUU (if any). thanks, -rohan > This loose contract also provides some guidance on the type of URI > that are most ideally suited for the service URI. A URN [10] can be > used as the service URI. However, since a URI could be resolved to > potentially any number of different URI, the characteristics, > status, > and relative information need to be sensible for all of the URI > which > can be resolved from the URN. As the URN becomes increasingly > "vague" in terms of the service it identifies, the amount of > presence > attributes that can be included become increasingly small. > Unfortunately, due to the variety of different devices in existence, > it is difficult for a single URN scheme to be used that have these > properties. It is anticipated that multiple schemes will be > defined, > with different ones appropriate for different types of devices. For > cellular telephones, the Electronic Serial Number (ESN), for > example, > is a good identifier. For IP devices, the MAC address is another > good one. Unfortunately, neither of these are associated with URN > schemes at this time. In the interim, the UUID URN [14] can be > used. > It has the properties of being globally and temporally unique, but > because of its random component, it is not useful as a correlation > ID > with other presence sources on a network. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 2 22:25:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02078; Wed, 2 Mar 2005 22:25:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6gzF-0002qD-KK; Wed, 02 Mar 2005 22:26:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6gx2-0000wb-Ik; Wed, 02 Mar 2005 22:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6gx0-0000wW-S2 for simple@megatron.ietf.org; Wed, 02 Mar 2005 22:24:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02010 for ; Wed, 2 Mar 2005 22:24:32 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6gyI-0002pS-Ig for simple@ietf.org; Wed, 02 Mar 2005 22:25:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2005 22:24:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j233ON1j019771 for ; Wed, 2 Mar 2005 22:24:24 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APN28435; Wed, 2 Mar 2005 22:24:23 -0500 (EST) Message-ID: <42268367.9010507@cisco.com> Date: Wed, 02 Mar 2005 22:24:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-ietf-simple-msrp-relays-03 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cullen/Rohan, I took a look at the latest. Looks good. I just found a couple of little things: 5.1 Connecting to relays acting on your behalf Clients can be configured (typically through discovery or manual provisioning) with a list of relays they need to use. They MUST be able to form a connection to each relay and send an AUTH command to ^^^^ get a URI that can be used in a To-Path header. The client can There is only a need to form a connection to the *first* relay, since the others are reached indirectly via the first. 5.4 Managing Connections Clients should open connection whenever they wish to deliver a request and no suitable connection exists. For client to client connections, a client should close a connection when there are no longer any sessions associated with the connection. For connections This seems to imply that for direct client to client communication a client may open a connection whenever it wants to send a request. But there is more to it than that, as described in the base draft. I think this statement should restrict itself to client-relay behavior. 6.4.1 Forwarding SEND requests If an incoming SEND request Failure-Report header with a value of ^ contains a "yes", a MSRP relay that receives that SEND request MUST respond with a final response immediately. A 200-class response indicates the Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From chao3dualism@lfchosting.com Thu Mar 3 02:58:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15841; Thu, 3 Mar 2005 02:58:16 -0500 (EST) Message-Id: <200503030758.CAA15841@ietf.org> Received: from [219.250.216.21] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6lF9-00005Q-4f; Thu, 03 Mar 2005 02:59:40 -0500 Received: from mail.prolog.net (219.250.216.21) by 219.250.216.21 (sorav.184) with SMTP id <24973041m0t> (Authid: 765405); Thu, 03 Mar 2005 08:54:57 +0100 Reply-To: "Ivan TerriRyan" From: "Ivan TerriRyan" To: pmtud-web-archive@ietf.org Cc: cfrg-request@ietf.org, asrg-announce-web-archive@ietf.org, ieprep-admin@ietf.org, bdiffserv-interest@ietf.org, adslmib-web-archive@ietf.org, simple-archive@ietf.org, imrg-web-archive@ietf.org, cfrg@ietf.org, xxxx@ietf.org, dn@ietf.org, rmt-admin@ietf.org, nomcom@ietf.org Subject: Congrats. You have been accepted Date: Thu, 03 Mar 2005 05:55:57 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6443709_660527.wTU81" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----6443709_660527.wTU81 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Homeowner, You have been pre-approved for a $450,000 Home at a low fixed rate. We noticed that your current rate is over 5%. We are willing to give you a fixed rate of 2.9%. Take Advantage of this Limited Time opportunity! Only takes a few minutes to see what you can save! Go here: http://ridge.seaquote.com/?partid=aaks9 Best Regards, Ivan TerriRyan, Account Manager Matio Group LLC. r.mv - http//seaquote.com/st.html ----6443709_660527.wTU81-- From simple-bounces@ietf.org Thu Mar 3 04:06:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24301; Thu, 3 Mar 2005 04:06:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mJT-0002JD-My; Thu, 03 Mar 2005 04:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mCL-0006PB-R4; Thu, 03 Mar 2005 04:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mCI-0006Om-Rp for simple@megatron.ietf.org; Thu, 03 Mar 2005 04:00:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23181 for ; Thu, 3 Mar 2005 04:00:41 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mDd-0001ft-5U for simple@ietf.org; Thu, 03 Mar 2005 04:02:05 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2390hA17797; Thu, 3 Mar 2005 11:00:43 +0200 (EET) X-Scanned: Thu, 3 Mar 2005 10:59:52 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j238xqft017142; Thu, 3 Mar 2005 10:59:52 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00QI7rgE; Thu, 03 Mar 2005 10:59:49 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j238xgU10837; Thu, 3 Mar 2005 10:59:42 +0200 (EET) Received: from [10.162.24.60] ([10.162.24.60]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Mar 2005 10:59:38 +0200 Message-ID: <4226D1FA.1050501@nokia.com> Date: Thu, 03 Mar 2005 10:59:38 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> <421C2702.4010607@nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 08:59:38.0575 (UTC) FILETIME=[5477B5F0:01C51FCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Inline comments. Hisham Khartabil wrote: > > On Feb 23, 2005, at 7:47 AM, Miguel Garcia wrote: > >> Ben Campbell wrote: >> >>> I apologize in advance for offering a knee jerk opinion after having >>> done only the briefest scan of this draft: >>> Couldn't this be accomplished by simply adding multiple To headers to >>> the message/cpim envelope, rather than by adding an extension method? >> >> >> What you are proposing is what we have proposed in version -01 of the >> draft. However, we went into some problems with that approach: >> >> a) If the MSRP does not implement this extension, then it will >> distributed the message to all the participants of the conference. >> Certainly not what the creator of the message wanted. > > > In this draft, you are defining the behaviour of the MSRP conferencing > entity that thus far is not defined anywhere. Therefore, you can mandate > for this behaviour to be implemented. I would agree with what you say, if we say that this draft will contain the minimum set of requirements to implement in an MSRP switch, and that none can implement an MSRP switch without implementing this draft. My initial thought would be that this draft would be an enhanced MSRP switch functionality. I am fine with any of both proposals. > >> >> b) Message/CPIM contains To and Cc headeers. However, there wouldn't >> be a mechanism to do the effect of a Bcc, because we are linking >> routing with presentation. > > > What does it mean to have a cc and bcc in an instant messaging > conference? This is not email. But if it is really needed then we can > extend message/cpim to have bcc header (I'm on a plane so I cannot > validate your claim that there is no bcc header in message/cpim). First, what is the meaning of CC and Bcc in instant messaging is something that is, in a way, inherited from Message/CPIM and e-mail. At the end of the day, we are speaking about messaging, no matter whether it is instant or almost instant (e-mail). Second: There is no point in adding a Bcc header to Message/CPIM, because then it would automatically require the MSRP switch to open the Message/CPIM and remove it (the point of Bcc is that others don't know who is receiving the Blind copy). I have been trying to make an effor for the MSRP switch to avoid opening bodies. I think it is a nice requirement for a high performance switch. What we are proposing is to separate the list of recipients (Distribution header) from the presentations aspects (To and Cc in Message/CPIM). This is the approach taken by RFC 822 and seems to be woking fine. I think RFC 822 wouldn't perform that well if SMTP relays would have to open bodies to remove Bcc headers. /Miguel > > Regards, > Hisham > >> >> So we ended up proposing a new method, because if the MSRP switch >> dooes not support, it returns and 501 response, and at least the >> message is not distributed to the whole roster. >> >> Then we added the Distsend header, that contains the desired >> distribution list. This list need to not be the same as the To and Cc >> headers of the Message/CPIM, so that the creator can create blind copies. >> >> /Miguel >> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Research Center Helsinki, Finland >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From huyen@4thwave.co.uk Thu Mar 3 08:40:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23564 for ; Thu, 3 Mar 2005 08:40:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qaJ-0000ZR-Mz for simple-archive@ietf.org; Thu, 03 Mar 2005 08:41:49 -0500 Received: from host104-195.pool8255.interbusiness.it ([82.55.195.104]) by mx2.foretec.com with smtp (Exim 4.24) id 1D6qYt-0007wh-T2 for simple-archive@ietf.org; Thu, 03 Mar 2005 08:40:21 -0500 Message-ID: <9a0801c51ff3$adc12016$228daa6f@4thwave.co.uk> From: "Paul A. Davis" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gTE9XIHByaWNlIQ==?= Date: Thu, 03 Mar 2005 13:19:30 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_29543D7A.EDD8C556" 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.7 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_29543D7A.EDD8C556 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E0BD9261.66B49E2C" ------=_NextPart_001_0001_E0BD9261.66B49E2C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Full & hard erections Long-lasting effects No prescription asked 2 popular medicines: Cialis - http://cia.kghlneihdb.com/?8WG0agFGmILpUs8cia Viagra - http://via.ncbnbihgnk.com/?oaWgW0pqCY_98covia Delivered in a discreet package _________________________________________________________________________ To change your mail preferences, go here: http://www.galamed.ws/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_E0BD9261.66B49E2C Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
    Wor de shi g wit hou
    ld Wi ppin hin 24  rs

    Hard & stable erections
    Long lasting effects
    No prescription asked

    Only $1.60/$2.19 per dose (2 doses in each pill):
    CIALIS - http://cia.kghlneihdb.com/?8WG0agFGmILpUs8cia
    VIAGRA - http://via.ncbnbihgnk.com/?oaWgW0pqCY_98covia

    Select the manufacturer you can trust!


    _________________________________________________________________________
    To be taken out, go here: http://www.galamed.ws/uns.htm
    _________________________________________________________________________

    ------=_NextPart_001_0001_E0BD9261.66B49E2C-- ------=_NextPart_000_0000_29543D7A.EDD8C556-- From listen.2168muzio@thinkmega.com Thu Mar 3 11:40:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15275; Thu, 3 Mar 2005 11:40:39 -0500 (EST) Received: from host176-79.pool8254.interbusiness.it ([82.54.79.176]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6tOl-00050H-Rd; Thu, 03 Mar 2005 11:42:09 -0500 Received: from home11.podemski.com (82.54.79.176) by 82.54.79.176 (CloseForm 1734) with SMTP id <7qm82636rmrlq>; Thu, 03 Mar 2005 15:36:13 -0100 Message-ID: Reply-To: "adi tanio" From: "adi tanio" To: simple-archive@ietf.org Cc: imrg-request@ietf.org, seamoby-web-archive@ietf.org, pim-request@ietf.org, asrg@ietf.org, rpsec@ietf.org, ips@ietf.org, iab-wireless-workshop@ietf.org, ietf-action@ietf.org, ietf-info@ietf.org, owner-ietf-announce@ietf.org, l2tpext-archive@ietf.org, ipoverib-request@ietf.org, avt-request@ietf.org Subject: Top Notch Loans with ease Date: Thu, 03 Mar 2005 12:38:13 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--220558_5033951.wIY49" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----220558_5033951.wIY49 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://www.refi-asap.net/1/index/mal/ellwood We look forward to hearing from you. Regards, adi tanio MortAmerica Financial Group re*mve. -> http://www.refi-asap.net/rem.php ----220558_5033951.wIY49-- From simple-bounces@ietf.org Thu Mar 3 23:58:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24644; Thu, 3 Mar 2005 23:58:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D74uh-0004Me-JI; Thu, 03 Mar 2005 23:59:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D74rl-0007vx-DL; Thu, 03 Mar 2005 23:56:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D74rj-0007vX-9C for simple@megatron.ietf.org; Thu, 03 Mar 2005 23:56:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24504 for ; Thu, 3 Mar 2005 23:56:40 -0500 (EST) 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.33) id 1D74tD-0004KZ-CQ for simple@ietf.org; Thu, 03 Mar 2005 23:58:16 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2005 22:12:34 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,134,1107734400"; d="scan'208"; a="231291790:sNHT378829888" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j244uIq8027459; Thu, 3 Mar 2005 20:56:19 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-1.cisco.com [10.86.240.1]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF68909; Thu, 3 Mar 2005 20:56:20 -0800 (PST) Message-ID: <4227EA74.6070003@cisco.com> Date: Thu, 03 Mar 2005 23:56:20 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] UUID in presence data model References: <71a8b813db34b04b2756c7e4cbcff8b1@ekabal.com> In-Reply-To: <71a8b813db34b04b2756c7e4cbcff8b1@ekabal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Hi, > > I think for things that use SIP me should require that s MUST > be a UUID URN, and that this URN SHOULD be the same one as used to > obtain a GRUU (if any). That doesnt work, though. The GRUU instance ID identifies an instance of a SIP agent. Its role there is solely as a unique identifier. This is a mismatch for the needs of device-ID for several reasons: 1. the device ID should be meaningful, so that you can correlate it with other sources of data about the device. For example, for a cell phone, the ESN, or a PC, the MAC address. 2. there can be multiple SIP UA instances on a single device. Each will have a different instance ID as defined in GRUU, but need to have the same device ID. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From adamsidi@045.it Fri Mar 4 02:25:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02052; Fri, 4 Mar 2005 02:25:27 -0500 (EST) From: adamsidi@045.it Message-Id: <200503040725.CAA02052@ietf.org> Received: from [196.200.115.14] (helo=www.msn.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D77CN-0000Tb-Hg; Fri, 04 Mar 2005 02:27:03 -0500 Received: from nk1.genuity.com ([52.253.127.219]) by nk2.inreach.com with esmtp (Exim 3.35 #1) id 042678E0; Fri, 04 Mar 2005 16:33:43 -0000 Received: from nk3.banelco.com.ar ([96.5.65.194]) by nk4.mx.aol.com with Internet Mail Service id 0DB5CAAB; Fri, 04 Mar 2005 16:33:33 -0000 Received: from mailin-01.hotmail.com ([224.236.126.207]) by mailin-02.mail.lycos.com with Microsoft SMTPSVC id 15B91382; Fri, 04 Mar 2005 16:33:23 -0000 Date: Fri, 04 Mar 2005 08:33:23 -0800 To: adamsidi@045.it Subject: Freindship MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Spam-Score: 11.8 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT Phone: (24 hours): 234 803 096 5979. Email: adams@045.it I am the chairman of the contract award committee of the petroleun and natural resources ministry here in Nigeria, for security reasons, I may not wish to disclose how I got your email address for now. After due deliberation with my partner, I decided to forward to you this business proposal, we want you to assist us receive the sum of Twenty eight million, six hundred thousand united state bills (us28.6m) into your account. This fund resulted from an over-invoiced contract awarded by us under the budget allocation to my ministry and the bill was approved for payment by the concerned ministries. The contract was executed, commissioned and the contractor was paid his actual cost of the contract. Now, we are left with the balance of us28.6m as the over invoiced amount, which we have deliberately over estimated for our own use. Please note that the law forbids civil servants to operate or own foreign accounts hence this contact, we have agreed to share the money in the following percentages: 30 for you, 60 for us 10 for tax as may be required by your government. Note that this transaction is very much free from all sorts of risk hence the business was carefully planned before it was successfully executed and we the officials involved in the deal have put many years in service to our ministry. We have been exercising patience for this privilege for so long not until the presidential announcement last week, that all foreign contractors owed be paid forthwith, this will enable the presidency reconcile our debt ratio with the outside world and to most of us, this is a lifetime blessing we cannot afford to miss. Upon indication of your interest to fully co-operate with us, a payment application/information form will be sent to you via email for completion. Note that the following information: a) bankers name and address, b) account number and account name and c) your private phone number and email address will enable us seek/secure approval of the fund from the concerned government quarters/ministries within 3-4 banking days. As soon as we confirm receipt of this money in your nominated bank account, my partner and I will come over to your country to arrange for our own share and possibly invest part of this money in your country. Let honesty and trust be our watchword throughout this transaction. I shall furnish you with some details about myself. Your prompt reply will be highly appreciated. Best regards. Engr. Adams. I. S. A adamsone@universal.pt From webmaster@wearauction.co.kr Fri Mar 4 08:07:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14937 for ; Fri, 4 Mar 2005 08:07:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7CYe-00021x-40 for simple-archive@ietf.org; Fri, 04 Mar 2005 08:09:32 -0500 Received: from [211.200.89.49] (helo=wearauction.co.kr) by mx2.foretec.com with smtp (Exim 4.24) id 1D7CX4-0001d6-FJ for simple-archive@ietf.org; Fri, 04 Mar 2005 08:07:54 -0500 From: ÀÇ·ù°æ¸Å To: simple-archive@ietf.org Subject: (±¤°í)¼¼»óÀÇ ¸ðµçÀÇ·ù -ÀÇ·ùŬ·´-@ Reply-To: webmaster@wearauction.co.kr Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: Date: Fri, 04 Mar 2005 08:07:54 -0500 X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
    ¾ÕÀ¸·Î ¸ÞÀϼö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯ÁֽʽÿÀ.
    If you do not want to receive this mail, send me your reject e-mail. My email address is webmaster@wearauction.co.kr
    ±ÍÇÏÀÇ e-mail ÁÖ¼Ò´Â 2005-01-15 ¿ÀÀü 12:36:30 ¿¡ www1.ietf.org/spam-archive/rserpool-request/msg01636.html ¿¡¼­ ¼öÁýÇß½À´Ï´Ù.
    From simple-bounces@ietf.org Fri Mar 4 13:03:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15632; Fri, 4 Mar 2005 13:03:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7HAI-0001cD-Al; Fri, 04 Mar 2005 13:04:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7H7T-0000TY-BR; Fri, 04 Mar 2005 13:01:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7H7R-0000SW-8I for simple@megatron.ietf.org; Fri, 04 Mar 2005 13:01:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15305 for ; Fri, 4 Mar 2005 13:01:42 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7H92-0001V5-8D for simple@ietf.org; Fri, 04 Mar 2005 13:03:25 -0500 Received: from [192.168.0.15] (S01060050baa8032f.vc.shawcable.net [24.85.92.32] (may be forged)) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j24I1bK01495; Fri, 4 Mar 2005 10:01:38 -0800 In-Reply-To: <4227EA74.6070003@cisco.com> References: <71a8b813db34b04b2756c7e4cbcff8b1@ekabal.com> <4227EA74.6070003@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9f2a4feccdf81231d6f976d95df5f1b0@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] UUID in presence data model Date: Thu, 3 Mar 2005 21:32:32 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.4 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 20:56, Jonathan Rosenberg wrote: > Rohan Mahy wrote: > >> Hi, >> I think for things that use SIP me should require that s >> MUST be a UUID URN, and that this URN SHOULD be the same one as used >> to obtain a GRUU (if any). > > That doesnt work, though. > > The GRUU instance ID identifies an instance of a SIP agent. Its role > there is solely as a unique identifier. This is a mismatch for the > needs of device-ID for several reasons: > > 1. the device ID should be meaningful, so that you can correlate it > with other sources of data about the device. For example, for a cell > phone, the ESN, or a PC, the MAC address. For the cell phone, I agree that the ESN would be useful. However, as we've already discussed, the mac address is not a reliable indicator of a single PC device. If you switch interfaces you have a different mac address. If I replace the wireless card that finally bit the dust after surviving a fall off the podium with another wireless card, you have a different mac address. Many types of PC hardware now expose a serial number. This might be a good choice, but it needs to be scoped to a manufacturer and model number. > 2. there can be multiple SIP UA instances on a single device. Each > will have a different instance ID as defined in GRUU, but need to have > the same device ID. I see where you are coming from here. My suggestion does not achieve the properties in the data model We do need to come up with some practical implementable guidance for implementors for a few common cases: for example, non-programmable hardware phone, software running on PC, PDA, or programmable hard phone. I don't think the mac address qualifies here. If we don't provide guidance then its unlikely that two services on the same device will pick the same device-id (which I understand was the whole point of this separation exercise in the first place. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 16:05:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03769; Fri, 4 Mar 2005 16:05:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7K0i-00067J-S9; Fri, 04 Mar 2005 16:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Jxn-0002Ao-DX; Fri, 04 Mar 2005 16:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Jxm-00029C-G9 for simple@megatron.ietf.org; Fri, 04 Mar 2005 16:03:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03643 for ; Fri, 4 Mar 2005 16:03:56 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7JzP-00064E-7X for simple@ietf.org; Fri, 04 Mar 2005 16:05:40 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2005 13:05:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j24L3pYO014582; Fri, 4 Mar 2005 13:03:51 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Mar 2005 13:03:51 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 13:03:47 -0800 From: Cullen Jennings To: Rohan Mahy , "simple@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Mar 2005 21:03:51.0122 (UTC) FILETIME=[AA9DF320:01C520FD] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Simple] may-simple-xcap-alternative-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit You don't talk much about how you would uses DAV properties. Thoughts on this? It seems like as long as some of the specific fields that were needed as search indexes where specified as properties in a given schema, we could do all the searches that were needed. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 16:23:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04708; Fri, 4 Mar 2005 16:23:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7KIF-0006RL-G1; Fri, 04 Mar 2005 16:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7KFT-0005Nc-OY; Fri, 04 Mar 2005 16:22:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7KFS-0005NX-CZ for simple@megatron.ietf.org; Fri, 04 Mar 2005 16:22:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04657 for ; Fri, 4 Mar 2005 16:22:12 -0500 (EST) 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.33) id 1D7KH5-0006Pq-6F for simple@ietf.org; Fri, 04 Mar 2005 16:23:56 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2005 14:38:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,136,1107734400"; d="scan'208"; a="231535408:sNHT20832840" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j24LLuuE024740; Fri, 4 Mar 2005 13:21:58 -0800 (PST) Received: from cisco.com ([161.44.79.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APO68092; Fri, 4 Mar 2005 16:21:58 -0500 (EST) Message-ID: <4228D176.2010609@cisco.com> Date: Fri, 04 Mar 2005 16:21:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] UUID in presence data model References: <71a8b813db34b04b2756c7e4cbcff8b1@ekabal.com> <4227EA74.6070003@cisco.com> <9f2a4feccdf81231d6f976d95df5f1b0@ekabal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Rohan, I don't understand. Suppose we have two distinct sip applications running on a single PC. To keep things simple, assume they use separate ports, so their sip addresses are unique, and they don't cooperate with each other in any way. (Maybe one is IM, the other is voice, though it doesn't matter.) They could register with the same AoR, and each request a gruu. For this they each need a unique instance id. They also can both publish presence. For that, the goal of the device-id is that they both reference the same device. If they each use their own instance-id from gruu as their device-id, they won't appear to be from the same device. Depending on how specific we want to get, we could come up with a way that instance-ids for gruu are *derived* from the device-id used for presence, by adding some extra information to the device-id. But I think that might be a bit too constraining. Applications may have more suitable ids for use as instance-id. Paul Rohan Mahy wrote: > > On Mar 3, 2005, at 20:56, Jonathan Rosenberg wrote: > >> Rohan Mahy wrote: >> >>> Hi, >>> I think for things that use SIP me should require that s >>> MUST be a UUID URN, and that this URN SHOULD be the same one as used >>> to obtain a GRUU (if any). >> >> >> That doesnt work, though. >> >> The GRUU instance ID identifies an instance of a SIP agent. Its role >> there is solely as a unique identifier. This is a mismatch for the >> needs of device-ID for several reasons: >> >> 1. the device ID should be meaningful, so that you can correlate it >> with other sources of data about the device. For example, for a cell >> phone, the ESN, or a PC, the MAC address. > > > For the cell phone, I agree that the ESN would be useful. However, as > we've already discussed, the mac address is not a reliable indicator of > a single PC device. If you switch interfaces you have a different mac > address. If I replace the wireless card that finally bit the dust after > surviving a fall off the podium with another wireless card, you have a > different mac address. > > Many types of PC hardware now expose a serial number. This might be a > good choice, but it needs to be scoped to a manufacturer and model number. > > >> 2. there can be multiple SIP UA instances on a single device. Each >> will have a different instance ID as defined in GRUU, but need to have >> the same device ID. > > > I see where you are coming from here. My suggestion does not achieve > the properties in the data model > > We do need to come up with some practical implementable guidance for > implementors for a few common cases: for example, non-programmable > hardware phone, software running on PC, PDA, or programmable hard > phone. I don't think the mac address qualifies here. If we don't > provide guidance then its unlikely that two services on the same device > will pick the same device-id (which I understand was the whole point of > this separation exercise in the first place. > > thanks, > -rohan > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From QHQPRQVFWANZXV@yahoo.com Fri Mar 4 16:31:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06025; Fri, 4 Mar 2005 16:31:00 -0500 (EST) Received: from armageddon.snu.ac.kr ([147.46.76.232]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7KPb-0006Y6-9R; Fri, 04 Mar 2005 16:32:45 -0500 Received: from .starnetusa.net (.starnetusa.net [193.247.116.192]) by .starnetusa.net with ESMTP id 2C573160 for ; Sat, 05 Mar 2005 08:28:31 -0500 Message-Id: <6.0.7.96.2.20031659343053.025b4b48@.starnetusa.net> X-Sender: QHQPRQVFWANZXV@yahoo.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 05 Mar 2005 12:32:31 -0100 From: "Gale Riggs" To: secdir@ietf.org, secdir-admin@ietf.org, secdir-web-archive@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org Subject: Viicodin for 0nly $178 zlvLE X-Spam-Score: 2.7 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Biggest stores of on'line pharmacies. Over than 150 major meds Highest qualities assured on our online generic meds at the most competitive prices. Vi'sit us today's! http://859fs.com/_fd5977142df59d3662baa654773c6a8e/ This is 1 -time mailing. N0-re m0val are re'qui-red XBllzlUZwVVfr5ooCKMFHQ4lBQcnlECmcbrFOmNP7sCz8gBsUCGRtWT3c7IZ81Y3 From simple-bounces@ietf.org Fri Mar 4 18:01:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13989; Fri, 4 Mar 2005 18:01:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7LpI-0000DU-BU; Fri, 04 Mar 2005 18:03:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7LmC-000406-9I; Fri, 04 Mar 2005 18:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Lm7-0003zg-TZ for simple@megatron.ietf.org; Fri, 04 Mar 2005 18:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13865 for ; Fri, 4 Mar 2005 18:00:01 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Lnm-0000Ah-CZ for simple@ietf.org; Fri, 04 Mar 2005 18:01:46 -0500 Received: from [66.103.196.108] (108_196_103_66-WIFI_HOTSPOTS.eng.telusmobility.com [66.103.196.108] (may be forged)) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j24MxvK04457; Fri, 4 Mar 2005 14:59:57 -0800 In-Reply-To: <4228D176.2010609@cisco.com> References: <71a8b813db34b04b2756c7e4cbcff8b1@ekabal.com> <4227EA74.6070003@cisco.com> <9f2a4feccdf81231d6f976d95df5f1b0@ekabal.com> <4228D176.2010609@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] UUID in presence data model Date: Fri, 4 Mar 2005 14:59:56 -0800 To: Paul Kyzivat X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit On Mar 4, 2005, at 13:21, Paul Kyzivat wrote: > Rohan, > > I don't understand. Suppose we have two distinct sip applications > running on a single PC. To keep things simple, assume they use > separate ports, so their sip addresses are unique, and they don't > cooperate with each other in any way. (Maybe one is IM, the other is > voice, though it doesn't matter.) > > They could register with the same AoR, and each request a gruu. For > this they each need a unique instance id. > > They also can both publish presence. For that, the goal of the > device-id is that they both reference the same device. If they each > use their own instance-id from gruu as their device-id, they won't > appear to be from the same device. yes, as I said in my response, JDR is right, I was wrong, the instance will not work. Now more importantly, if we want this property of identical device id's for uncoordinated services, we need to provide some guidance about what the two applications should use as a device-id. I don't think a mac address qualifies for general purpose hardware like PCs, laptops, and PDAs. (since i can construct several cases where the mac address changes so that two apps on the same device would use different mac address. thx, -r > Depending on how specific we want to get, we could come up with a way > that instance-ids for gruu are *derived* from the device-id used for > presence, by adding some extra information to the device-id. But I > think that might be a bit too constraining. Applications may have more > suitable ids for use as instance-id. > > Paul > > Rohan Mahy wrote: >> On Mar 3, 2005, at 20:56, Jonathan Rosenberg wrote: >>> Rohan Mahy wrote: >>> >>>> Hi, >>>> I think for things that use SIP me should require that s >>>> MUST be a UUID URN, and that this URN SHOULD be the same one as >>>> used to obtain a GRUU (if any). >>> >>> >>> That doesnt work, though. >>> >>> The GRUU instance ID identifies an instance of a SIP agent. Its role >>> there is solely as a unique identifier. This is a mismatch for the >>> needs of device-ID for several reasons: >>> >>> 1. the device ID should be meaningful, so that you can correlate it >>> with other sources of data about the device. For example, for a cell >>> phone, the ESN, or a PC, the MAC address. >> For the cell phone, I agree that the ESN would be useful. However, >> as we've already discussed, the mac address is not a reliable >> indicator of a single PC device. If you switch interfaces you have a >> different mac address. If I replace the wireless card that finally >> bit the dust after surviving a fall off the podium with another >> wireless card, you have a different mac address. >> Many types of PC hardware now expose a serial number. This might be >> a good choice, but it needs to be scoped to a manufacturer and model >> number. >>> 2. there can be multiple SIP UA instances on a single device. Each >>> will have a different instance ID as defined in GRUU, but need to >>> have the same device ID. >> I see where you are coming from here. My suggestion does not achieve >> the properties in the data model >> We do need to come up with some practical implementable guidance for >> implementors for a few common cases: for example, non-programmable >> hardware phone, software running on PC, PDA, or programmable hard >> phone. I don't think the mac address qualifies here. If we don't >> provide guidance then its unlikely that two services on the same >> device will pick the same device-id (which I understand was the whole >> point of this separation exercise in the first place. >> thanks, >> -rohan >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 20:40:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00844; Fri, 4 Mar 2005 20:40:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7OJI-0004Df-MY; Fri, 04 Mar 2005 20:42:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OCm-0007Ae-8J; Fri, 04 Mar 2005 20:35:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OCk-0007AV-Ok for simple@megatron.ietf.org; Fri, 04 Mar 2005 20:35:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29006 for ; Fri, 4 Mar 2005 20:35:40 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7OEP-0003yr-Op for simple@ietf.org; Fri, 04 Mar 2005 20:37:27 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/xyGDHdFWLgSOJF4lBzhaM7ZodzgTF9bk@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j251ZUh3004246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2005 20:35:32 -0500 (EST) Message-ID: <42290CF3.5070908@cs.columbia.edu> Date: Fri, 04 Mar 2005 20:35:47 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID (values) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit [responding in parts] Rohan Mahy wrote: > Comments about characteristics: > I would add to : > presenting: giving a presentation, lecture, or formal round-table > discussion Added. > > i'm completely unclear what "class" is supposed to convey. It's a free-form label that allows the publisher to convey information to the PA, e.g., for selection, grouping or filtering. It is not generally meant to be rendered to a human user. > > I think really belongs under . The text indicates > this, but the table and schema do not. Also, I think the device-id MUST Bug; fixed in the table. > always be a urn and SHOULD be UUID URN. this is consistent with the > instance parameter used in GRUU. Changed. > > I think should have separate audio, video, and text elements > to encourage orthogonality. > video: toobright, toodark, ok, unknown > audio: tooloud, tooquiet, ok, unknown > text: toouncomfortable, notappropriate, ok, unknown Changed; roughly in that way. > > I have several proposed additions to > cycle: in or on a motor or human-powered cycle > classroom: in an academic classroom or lecture hall > prison: in a prison, jail, brig, or criminal mental institution > hospital: in a hospital, medical clinic, or mental institution > bar: in a bar or cafe Separated; I don't think you would appreciate being shown as placetype 'bar' as you're ordering your tall capuccino at Starbucks at 10 am. > club: in a dance club or discotheque > underway: in a land, water, or air craft which is under way (in motion) > > i think may more appropriately belong in than > in some cases. i propose that it is allowed in either. Can you describe such cases? > > there is a potentially half or full duplex nature to privacy (ex: a > speaker phone), but I am not sure this needs to be included. I'd rather omit this for now. > > for I would add "friend" to the list. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 20:46:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01686; Fri, 4 Mar 2005 20:46:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7OOt-0004Og-Pz; Fri, 04 Mar 2005 20:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OM4-0000sm-I9; Fri, 04 Mar 2005 20:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OM3-0000sh-PM for simple@megatron.ietf.org; Fri, 04 Mar 2005 20:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01628 for ; Fri, 4 Mar 2005 20:45:18 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ONk-0004NW-0A for simple@ietf.org; Fri, 04 Mar 2005 20:47:04 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/JtTuUY20e+U+UyG5KRl4v1HJfQMRKrns@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j251jEh3004694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2005 20:45:15 -0500 (EST) Message-ID: <42290F3D.2060809@cs.columbia.edu> Date: Fri, 04 Mar 2005 20:45:33 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit [Replying in bits and pieces to keep message sizes in check.] Rohan Mahy wrote: > General Comments: > Table 1 is a nice feature. I would add (non-normatively) cipids, > servcaps, and devcaps to the table for the convenience of implementers Wouldn't it make more sense to add these tables to the respective drafts? > > I am a bit unclear where the normative root of the pidf schema belongs. > The current organization is a nightmare for implementors. I'm assuming > the intent is for the presence-data-model to be the root of things, but > the text did not seem to specify this. I'm looking forward to the schema discussion next week to get this mess cleaned up a bit. > > values with free-text and semantic data should have tags instead to > handle the same semantics in multiple languages. for example if i set > the sphere to I should be able to set this in a Japanese GUI and > have a friend see it semantically in Portuguese. If someone puts in > something unregistered, that's fine, just put in free text. > I think this is a problem with activity, mood, sphere, relationship, and > possibly service-class These are indeed all meant to be tags. Some of the examples need to be cleaned up to reflect this. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 21:00:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02427; Fri, 4 Mar 2005 21:00:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Oce-0004d4-D7; Fri, 04 Mar 2005 21:02:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OZA-0002dZ-Ob; Fri, 04 Mar 2005 20:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OZ9-0002dU-1D for simple@megatron.ietf.org; Fri, 04 Mar 2005 20:58:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02358 for ; Fri, 4 Mar 2005 20:58:49 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Oao-0004bD-FM for simple@ietf.org; Fri, 04 Mar 2005 21:00:35 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX181rs4E+L86MDrcDOQ63148+SfJ7O/49yQ@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j251wih3005378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2005 20:58:46 -0500 (EST) Message-ID: <42291268.9020408@cs.columbia.edu> Date: Fri, 04 Mar 2005 20:59:04 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID (input source) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit [more responses] Rohan Mahy wrote: > In the person and tuple tags it would be useful to add an "input-source" > element indicating if a human or automata generated the markup. If we can keep it simple, this would indeed be helpful for composition. There are probably two types of information: (1) a rough classification of the source ("manual", "calendar", "sensor", "composed"), either as an attribute or as an element: (2) a more detailed labeling of the source, primarily meant for composers (e.g., "sensor17" or "Outlook"). We had previously, I believe, discussed this as future work. I'd rather avoid delaying the completion of this draft if this discussion turns out to be lengthier. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 21:19:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03682; Fri, 4 Mar 2005 21:19:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7OvF-00051e-Eq; Fri, 04 Mar 2005 21:21:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OqM-0005Fe-Ih; Fri, 04 Mar 2005 21:16:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OqL-0005FZ-1a for simple@megatron.ietf.org; Fri, 04 Mar 2005 21:16:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03562 for ; Fri, 4 Mar 2005 21:16:35 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Os1-0004yC-Hh for simple@ietf.org; Fri, 04 Mar 2005 21:18:21 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX18Io9VldU00oI8IeAM7rJAOtG+seXsI/q4@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j252GVh3006230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2005 21:16:33 -0500 (EST) Message-ID: <4229167F.6010002@cs.columbia.edu> Date: Fri, 04 Mar 2005 21:16:31 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > I think we *really* need a way to associate person data with the tuples > that contributed it. I suggest a list of contributing-tuples in each > person element. Otherwise, there is no way to intelligently tie > ambiguous presence data about a person to the service(s) that provided > it. For example, I may want to ignore the person information from a > service running on my home PC when I am travelling at IETF. (for > example if I leave my home PC on and another family member uses the > computer). The presence compositor doesn't know how to handle this > ambiguous data, but a human might, *IF* they can associate the faulty > presence data with the service(s) that contributed it. > This assumes that service tuples provided the person information. That is not likely to be generally true. For example, calendar information would not be associated with a , nor would other sensors that might feed into the compositor. Wouldn't this best be handled as part of the source identification (see separate message)? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 4 21:31:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04449; Fri, 4 Mar 2005 21:31:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7P6W-0005Ed-9j; Fri, 04 Mar 2005 21:33:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7P3h-0007He-2B; Fri, 04 Mar 2005 21:30:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7P3f-0007HZ-Tw for simple@megatron.ietf.org; Fri, 04 Mar 2005 21:30:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04394 for ; Fri, 4 Mar 2005 21:30:21 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7P5M-0005DO-J5 for simple@ietf.org; Fri, 04 Mar 2005 21:32:08 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/cQ5IoAIu2EiG9E+eFTGUgUSUBpJl196s@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j252UDh3006992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2005 21:30:15 -0500 (EST) Message-ID: <422919B6.9080605@cs.columbia.edu> Date: Fri, 04 Mar 2005 21:30:14 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID (note) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit [final response] Rohan Mahy wrote: > I think we really want the note and activity fields to work in an > interoperable way. I have no clue how to begin to intelligently resolve > a note and an activity, or merge 2 arrays of activities. Even as a > human, I can construct two different activity arrays that have very > different semantics (both reasonable) when merged one way vs the other. > I know the overall approach is that we are not specifying merging > algorithms, but this one looks like it is asking for trouble. Can you give examples? Clearly, there's the potential for interesting compositions. One would hope that combinations like are rare, for example. But I don't see how this differs significantly from merging problems that can occur with other elements. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Sherill@gamebird.com Sat Mar 5 08:57:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16479 for ; Sat, 5 Mar 2005 08:57:37 -0500 (EST) Message-Id: <200503051357.IAA16479@ietf.org> Received: from lns-vlq-30-str-82-254-45-152.adsl.proxad.net ([82.254.45.152] helo=gamebird.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7ZoV-00033z-W9 for simple-archive@ietf.org; Sat, 05 Mar 2005 08:59:29 -0500 From: "Temple Franklin" To: "Elin Hinojosa" Subject: DYF 9-Pharmaaccy Date: Sat, 5 Mar 2005 08:28:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C51E97.4229C837" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.8 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C51E97.4229C837 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_004D_01C51E97.4229C837 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit Our PharmMail=20 SH0P.
     
    SP  OF  Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.)
    ECIAL FER: ag al it
    And Many Other!
     
    With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_004D_01C51E97.4229C837-- From simple-bounces@ietf.org Sat Mar 5 11:21:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27374; Sat, 5 Mar 2005 11:21:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7c3o-0006Cu-Ed; Sat, 05 Mar 2005 11:23:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7c10-0002jN-G5; Sat, 05 Mar 2005 11:20:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7c0y-0002i7-9R for simple@megatron.ietf.org; Sat, 05 Mar 2005 11:20:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27303 for ; Sat, 5 Mar 2005 11:20:25 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7c2m-0006BR-8Z for simple@ietf.org; Sat, 05 Mar 2005 11:22:20 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2005 08:22:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j25GKETM007750; Sat, 5 Mar 2005 08:20:15 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 5 Mar 2005 08:20:15 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 05 Mar 2005 08:20:10 -0800 Subject: Re: [Simple] Re: draft-ietf-simple-msrp-relays-03 From: Cullen Jennings To: Paul H Kyzivat , "simple@ietf.org" Message-ID: In-Reply-To: <42268367.9010507@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 16:20:15.0398 (UTC) FILETIME=[36DE4460:01C5219F] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Thank - you. Will fix these. On 3/2/05 7:24 PM, "Paul Kyzivat" wrote: > Cullen/Rohan, > > I took a look at the latest. Looks good. I just found a couple of little > things: > > > 5.1 Connecting to relays acting on your behalf > > Clients can be configured (typically through discovery or manual > provisioning) with a list of relays they need to use. They MUST be > able to form a connection to each relay and send an AUTH command to > ^^^^ > get a URI that can be used in a To-Path header. The client can > > There is only a need to form a connection to the *first* relay, since > the others are reached indirectly via the first. > > 5.4 Managing Connections > > Clients should open connection whenever they wish to deliver a > request and no suitable connection exists. For client to client > connections, a client should close a connection when there are no > longer any sessions associated with the connection. For connections > > This seems to imply that for direct client to client communication a > client may open a connection whenever it wants to send a request. But > there is more to it than that, as described in the base draft. I think > this statement should restrict itself to client-relay behavior. > > 6.4.1 Forwarding SEND requests > > If an incoming SEND request Failure-Report header with a value of > ^ > contains a > > "yes", a MSRP relay that receives that SEND request MUST respond with > a final response immediately. A 200-class response indicates the > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 11:37:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28265; Sat, 5 Mar 2005 11:37:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7cJR-0006Y5-7j; Sat, 05 Mar 2005 11:39:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7cFc-0004ri-Jj; Sat, 05 Mar 2005 11:35:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7cFa-0004rZ-Nu for simple@megatron.ietf.org; Sat, 05 Mar 2005 11:35:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28136 for ; Sat, 5 Mar 2005 11:35:32 -0500 (EST) 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.33) id 1D7cHM-0006Ua-PG for simple@ietf.org; Sat, 05 Mar 2005 11:37:27 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2005 08:48:48 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j25GZKYO013365; Sat, 5 Mar 2005 08:35:21 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 5 Mar 2005 08:35:20 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 05 Mar 2005 08:35:16 -0800 Subject: Re: [Simple] Comments to MSRP-10 - Report on future methods From: Cullen Jennings To: Paul H Kyzivat , Miguel Garcia Message-ID: In-Reply-To: <4225CCAA.3070502@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 16:35:20.0526 (UTC) FILETIME=[525DD6E0:01C521A1] X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Miguel - thank you for the detailed review and comments - they are great. Inline ... On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: >>>> Miguel -> I don't really care about the exact wording, as long as it >>>> does not make any assumptions about future MSRP extensions. The >>>> current text implies that the Report headers are meant only for SEND >>>> requests, and for no other MSRP methods that any human can think of >>>> in the future. So if we invent a new method that can use those >>>> headers, this shouldn't create a violation of the MSRP RFC >>> >>> OK. I can buy that. I see two ways to achieve that: >>> - Say that Success-Report and Failure-Report MUST NOT be used in a >>> request or response unless permitted by specific normative text. >>> The normative text will only be present for SEND. >>> >>> - Introduce a table like Table 2 of 3261 (I think it is table 2), >>> specifying which headers may be used with which requests and >>> responses. >>> >>> I prefer the table. >> >> I know that some people hates this table... but I am fine with it, I >> find it very useful. > > I'm not wild about the table either, but it seems to beat the alternatives. I don't like table 2 in 3261 and think it has done more harm than good. I understand what you want to accomplish here and am fine with that. We need to think a little about how a relay would know how to handle a unknown request. I think we could switch this to just say that Reports where not allowed for REPROT and AUTH messages. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 11:55:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29250; Sat, 5 Mar 2005 11:55:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7caJ-0006tb-Sx; Sat, 05 Mar 2005 11:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7cVq-0007KB-Jq; Sat, 05 Mar 2005 11:52:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7cVo-0007Jz-V1 for simple@megatron.ietf.org; Sat, 05 Mar 2005 11:52:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29051 for ; Sat, 5 Mar 2005 11:52:18 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7cXd-0006pr-5T for simple@ietf.org; Sat, 05 Mar 2005 11:54:13 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2005 08:54:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j25Gq6YO015410; Sat, 5 Mar 2005 08:52:09 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 5 Mar 2005 08:52:06 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 05 Mar 2005 08:52:02 -0800 Subject: Re: [Simple] Comments to MSRP-10 From: Cullen Jennings To: Paul H Kyzivat , Miguel Garcia Message-ID: In-Reply-To: <4225CCAA.3070502@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 16:52:06.0144 (UTC) FILETIME=[A9C2F800:01C521A3] X-Spam-Score: 1.1 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Ok - I got lost on this thread. Do we need to change any text. I'm fine to add in the suggested >>> "If the Success-Report header was set to "no", then success reports >>> MUST NOT be sent." On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: >>>>>> 7) Section 7.3.1, last paragraph in the section >>>>>> >>>>>> "If the Success-Report header was set to "yes", then when a >>>>>> complete >>>>>> message has been received, the receiver MUST send a success REPORT >>>>>> with a byte range covering the whole message. If the >>>>>> Success-Report >>>>>> header is not set to "no", then the receiver MAY generate >>>>>> incremental >>>>>> success REPORTs as the chunks are received. These can be sent >>>>>> periodically and cover all the bytes that have been received so far >>>>>> or they can be sent after a chunk arrives and cover just the part >>>>>> from that chunk." >>>>>> >>>>>> So, if I understand correctly, the receiver has the right to send >>>>>> success REPORTs of chunks when the Success-Report is se to "no". Is >>>>>> this correct? >>>>> >>>>> I don't understand it that way. I believe it specifies: >>>>> >>>>> YES: MUST send success report for complete message, >>>>> MAY send incremental success reports >>>>> >>>>> NO: MUST NOT send success reports at all >>>> >>>> Miguel -> This is not according to the current text, that says: If >>>> the Success-Report header is not set to "no", then the receiver MAY >>>> generate incremental success REPORTs as the chunks are received. >>> >>> Agree, this isn't explicit in the above paragraph. So we should add >>> another sentence to the end of the above: >>> >>> "If the Success-Report header was set to "no", then success reports >>> MUST NOT be sent." >>> >>>>> PARTIAL: MAY send success reports, either for the >>>>> complete message or incrementally. >>>> >>>> Miguel -> I think this is not written in the text. >>> >>> Well, "partial" is not NO, so it may send an incremental report. And a >>> report for the complete message is indistinguishable from an >>> incremental report so that is permitted too. >> >> I agree that "partial" is not NO. I am just saying that the text does >> nos say anything about "partial" and incremental reports. > > Doesn't seem to be an issue. > >> But still I haven't found an answer to what is the usefulness of reports. > > They are useful in recovering from loss of the media connection. You can > reestablish the connection (with reinvite) and then restart sending the > message. Any ranges that were confirmed don't have to be sent again. > When the connection hasn't failed, the success reports indicate portions > of the message that no longer need to be saved to prepare for error > recovery. > > This might be significant in our frequently cited case of transmitting > the Lord of the Rings. (The fact that we use that as an example says > something about how long we have been working on this.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 12:36:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02476; Sat, 5 Mar 2005 12:36:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7dEN-0007rt-TR; Sat, 05 Mar 2005 12:38:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7dAu-0004E6-Gi; Sat, 05 Mar 2005 12:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7dAr-0004Dy-1U for simple@megatron.ietf.org; Sat, 05 Mar 2005 12:34:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02345 for ; Sat, 5 Mar 2005 12:34:42 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7dCe-0007pM-I0 for simple@ietf.org; Sat, 05 Mar 2005 12:36:37 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 05 Mar 2005 12:50:11 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,138,1107752400"; d="scan'208"; a="39385205:sNHT20199280" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j25HYWjI017077; Sat, 5 Mar 2005 12:34:32 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-92.cisco.com [10.86.242.92]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APO98017; Sat, 5 Mar 2005 12:34:30 -0500 (EST) Message-ID: <4229EDA6.5090109@cisco.com> Date: Sat, 05 Mar 2005 12:34:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Comments to MSRP-10 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , Ben Campbell , "simple@ietf.org" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Yes, I think making that change would clarify a fuzzy spot. Paul Cullen Jennings wrote: > Ok - I got lost on this thread. Do we need to change any text. I'm fine to > add in the suggested > >>>>"If the Success-Report header was set to "no", then success reports >>>>MUST NOT be sent." >>> > > > On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: > > >>>>>>>7) Section 7.3.1, last paragraph in the section >>>>>>> >>>>>>> "If the Success-Report header was set to "yes", then when a >>>>>>>complete >>>>>>> message has been received, the receiver MUST send a success REPORT >>>>>>> with a byte range covering the whole message. If the >>>>>>>Success-Report >>>>>>> header is not set to "no", then the receiver MAY generate >>>>>>>incremental >>>>>>> success REPORTs as the chunks are received. These can be sent >>>>>>> periodically and cover all the bytes that have been received so far >>>>>>> or they can be sent after a chunk arrives and cover just the part >>>>>>> from that chunk." >>>>>>> >>>>>>>So, if I understand correctly, the receiver has the right to send >>>>>>>success REPORTs of chunks when the Success-Report is se to "no". Is >>>>>>>this correct? >>>>>> >>>>>>I don't understand it that way. I believe it specifies: >>>>>> >>>>>> YES: MUST send success report for complete message, >>>>>> MAY send incremental success reports >>>>>> >>>>>> NO: MUST NOT send success reports at all >>>>> >>>>>Miguel -> This is not according to the current text, that says: If >>>>>the Success-Report header is not set to "no", then the receiver MAY >>>>>generate incremental success REPORTs as the chunks are received. >>>> >>>>Agree, this isn't explicit in the above paragraph. So we should add >>>>another sentence to the end of the above: >>>> >>>>"If the Success-Report header was set to "no", then success reports >>>>MUST NOT be sent." >>>> >>>> >>>>>> PARTIAL: MAY send success reports, either for the >>>>>> complete message or incrementally. >>>>> >>>>>Miguel -> I think this is not written in the text. >>>> >>>>Well, "partial" is not NO, so it may send an incremental report. And a >>>>report for the complete message is indistinguishable from an >>>>incremental report so that is permitted too. >>> >>>I agree that "partial" is not NO. I am just saying that the text does >>>nos say anything about "partial" and incremental reports. >> >>Doesn't seem to be an issue. >> >> >>>But still I haven't found an answer to what is the usefulness of reports. >> >>They are useful in recovering from loss of the media connection. You can >>reestablish the connection (with reinvite) and then restart sending the >>message. Any ranges that were confirmed don't have to be sent again. >>When the connection hasn't failed, the success reports indicate portions >>of the message that no longer need to be saved to prepare for error >>recovery. >> >>This might be significant in our frequently cited case of transmitting >>the Lord of the Rings. (The fact that we use that as an example says >>something about how long we have been working on this.) > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 13:03:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04198; Sat, 5 Mar 2005 13:03:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7dek-0008QA-41; Sat, 05 Mar 2005 13:05:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7dbo-0006me-K8; Sat, 05 Mar 2005 13:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7dbm-0006mS-QR for simple@megatron.ietf.org; Sat, 05 Mar 2005 13:02:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04103 for ; Sat, 5 Mar 2005 13:02:31 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ddb-0008Nv-HE for simple@ietf.org; Sat, 05 Mar 2005 13:04:28 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j25I1GU09379; Sat, 5 Mar 2005 20:01:16 +0200 (EET) X-Scanned: Sat, 5 Mar 2005 20:00:58 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j25I0wkV026117; Sat, 5 Mar 2005 20:00:58 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00LsVApo; Sat, 05 Mar 2005 20:00:55 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j25I0rM29617; Sat, 5 Mar 2005 20:00:53 +0200 (EET) Received: from [10.163.23.234] ([10.163.23.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 5 Mar 2005 20:00:52 +0200 Message-ID: <4229F3D4.803@nokia.com> Date: Sat, 05 Mar 2005 20:00:52 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Comments to MSRP-10 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 18:00:52.0926 (UTC) FILETIME=[4583EDE0:01C521AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Yes, please. This solves one bug in the current text. But I'm still not happy leaving the decision of whether to send incremental reports in the receiver's hands. The same that other types of reports are requested by the sender, incremental reports should be requested by the sender. One possible solution is to add a parameter to the Success-Report header, so that when it takes the value yes, it can also take the parameter "incremental", meaning that the sender is willing to receive incremental reports. How about that? /Miguel Cullen Jennings wrote: > Ok - I got lost on this thread. Do we need to change any text. I'm fine to > add in the suggested > >>>>"If the Success-Report header was set to "no", then success reports >>>>MUST NOT be sent." > > > > On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: > > >>>>>>>7) Section 7.3.1, last paragraph in the section >>>>>>> >>>>>>> "If the Success-Report header was set to "yes", then when a >>>>>>>complete >>>>>>> message has been received, the receiver MUST send a success REPORT >>>>>>> with a byte range covering the whole message. If the >>>>>>>Success-Report >>>>>>> header is not set to "no", then the receiver MAY generate >>>>>>>incremental >>>>>>> success REPORTs as the chunks are received. These can be sent >>>>>>> periodically and cover all the bytes that have been received so far >>>>>>> or they can be sent after a chunk arrives and cover just the part >>>>>>> from that chunk." >>>>>>> >>>>>>>So, if I understand correctly, the receiver has the right to send >>>>>>>success REPORTs of chunks when the Success-Report is se to "no". Is >>>>>>>this correct? >>>>>> >>>>>>I don't understand it that way. I believe it specifies: >>>>>> >>>>>> YES: MUST send success report for complete message, >>>>>> MAY send incremental success reports >>>>>> >>>>>> NO: MUST NOT send success reports at all >>>>> >>>>>Miguel -> This is not according to the current text, that says: If >>>>>the Success-Report header is not set to "no", then the receiver MAY >>>>>generate incremental success REPORTs as the chunks are received. >>>> >>>>Agree, this isn't explicit in the above paragraph. So we should add >>>>another sentence to the end of the above: >>>> >>>>"If the Success-Report header was set to "no", then success reports >>>>MUST NOT be sent." >>>> >>>> >>>>>> PARTIAL: MAY send success reports, either for the >>>>>> complete message or incrementally. >>>>> >>>>>Miguel -> I think this is not written in the text. >>>> >>>>Well, "partial" is not NO, so it may send an incremental report. And a >>>>report for the complete message is indistinguishable from an >>>>incremental report so that is permitted too. >>> >>>I agree that "partial" is not NO. I am just saying that the text does >>>nos say anything about "partial" and incremental reports. >> >>Doesn't seem to be an issue. >> >> >>>But still I haven't found an answer to what is the usefulness of reports. >> >>They are useful in recovering from loss of the media connection. You can >>reestablish the connection (with reinvite) and then restart sending the >>message. Any ranges that were confirmed don't have to be sent again. >>When the connection hasn't failed, the success reports indicate portions >>of the message that no longer need to be saved to prepare for error >>recovery. >> >>This might be significant in our frequently cited case of transmitting >>the Lord of the Rings. (The fact that we use that as an example says >>something about how long we have been working on this.) > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 13:04:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04317; Sat, 5 Mar 2005 13:04:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7dfn-0008TH-2Q; Sat, 05 Mar 2005 13:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7dcd-0006ny-MP; Sat, 05 Mar 2005 13:03:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7dcb-0006nt-MG for simple@megatron.ietf.org; Sat, 05 Mar 2005 13:03:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04173 for ; Sat, 5 Mar 2005 13:03:22 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7deP-0008Pg-FD for simple@ietf.org; Sat, 05 Mar 2005 13:05:18 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j25I37d26343; Sat, 5 Mar 2005 20:03:08 +0200 (EET) X-Scanned: Sat, 5 Mar 2005 20:03:04 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j25I340I031457; Sat, 5 Mar 2005 20:03:04 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 000fyqy6; Sat, 05 Mar 2005 20:03:02 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j25I32M01573; Sat, 5 Mar 2005 20:03:02 +0200 (EET) Received: from [10.163.23.234] ([10.163.23.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 5 Mar 2005 20:03:02 +0200 Message-ID: <4229F455.4080306@nokia.com> Date: Sat, 05 Mar 2005 20:03:01 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Comments to MSRP-10 - Report on future methods References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 18:03:02.0160 (UTC) FILETIME=[928B7900:01C521AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Any of the proposals look good to me. The point is not to put normative text for future yet unknown extensions. /Miguel Cullen Jennings wrote: > Miguel - thank you for the detailed review and comments - they are great. > > Inline ... > > On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: > > >>>>>Miguel -> I don't really care about the exact wording, as long as it >>>>>does not make any assumptions about future MSRP extensions. The >>>>>current text implies that the Report headers are meant only for SEND >>>>>requests, and for no other MSRP methods that any human can think of >>>>>in the future. So if we invent a new method that can use those >>>>>headers, this shouldn't create a violation of the MSRP RFC >>>> >>>>OK. I can buy that. I see two ways to achieve that: >>>>- Say that Success-Report and Failure-Report MUST NOT be used in a >>>> request or response unless permitted by specific normative text. >>>> The normative text will only be present for SEND. >>>> >>>>- Introduce a table like Table 2 of 3261 (I think it is table 2), >>>> specifying which headers may be used with which requests and >>>> responses. >>>> >>>>I prefer the table. >>> >>>I know that some people hates this table... but I am fine with it, I >>>find it very useful. >> >>I'm not wild about the table either, but it seems to beat the alternatives. > > > I don't like table 2 in 3261 and think it has done more harm than good. I > understand what you want to accomplish here and am fine with that. We need > to think a little about how a relay would know how to handle a unknown > request. I think we could switch this to just say that Reports where not > allowed for REPROT and AUTH messages. > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 14:29:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09687; Sat, 5 Mar 2005 14:29:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ezn-0001jG-BE; Sat, 05 Mar 2005 14:31:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ewu-0005Zm-2k; Sat, 05 Mar 2005 14:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ews-0005Zh-HP for simple@megatron.ietf.org; Sat, 05 Mar 2005 14:28:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09635 for ; Sat, 5 Mar 2005 14:28:25 -0500 (EST) 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.33) id 1D7eyh-0001iO-Ud for simple@ietf.org; Sat, 05 Mar 2005 14:30:20 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 05 Mar 2005 12:44:47 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,138,1107734400"; d="scan'208"; a="231752130:sNHT27149384" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j25JSEYO005974; Sat, 5 Mar 2005 11:28:14 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 5 Mar 2005 11:28:14 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 05 Mar 2005 11:28:09 -0800 Subject: Re: [Simple] Comments to MSRP-10 From: Cullen Jennings To: Miguel Garcia Message-ID: In-Reply-To: <4229F3D4.803@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 19:28:14.0435 (UTC) FILETIME=[79B2BB30:01C521B9] X-Spam-Score: 1.1 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit I would really rather not add yet another variation to the error reporting unless we really needed it. We can't really put a flag that says the receiver must send incremental reports because a relay before the endpoint may aggregate all the chunks into a single one there would be only a single report. We could put a flag that said the receiver MUST NOT generate incremental success reports. A system that did this would really hamper it's ability to recover from errors and eliminate any intermediate feedback that it received about ongoing transfers. All the cases I can think of where you would want this, you would probably just say no to Success-Reports all together. If this turns out to be a mistake, we can easily add it later without violating any of current text. At one point in time I had a Success-Report values of yes, no, and no-incremental. That is why some of the text is somewhat double negative like "if value does not equal no then" so that we can insert another value in the Success-Report and still have all the current stuff operate correctly. So in summary, I think we could do it, but I'd rather not unless we have a strong need for it. The text is written such that we have an insurance policy of being able to easily add it later if this was a mistake. Opinions? On 3/5/05 10:00 AM, "Miguel Garcia" wrote: > Yes, please. This solves one bug in the current text. > > But I'm still not happy leaving the decision of whether to send > incremental reports in the receiver's hands. The same that other types > of reports are requested by the sender, incremental reports should be > requested by the sender. > > One possible solution is to add a parameter to the Success-Report > header, so that when it takes the value yes, it can also take the > parameter "incremental", meaning that the sender is willing to receive > incremental reports. > > How about that? > > /Miguel > > Cullen Jennings wrote: > >> Ok - I got lost on this thread. Do we need to change any text. I'm fine to >> add in the suggested >> >>>>> "If the Success-Report header was set to "no", then success reports >>>>> MUST NOT be sent." >> >> >> >> On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: >> >> >>>>>>>> 7) Section 7.3.1, last paragraph in the section >>>>>>>> >>>>>>>> "If the Success-Report header was set to "yes", then when a >>>>>>>> complete >>>>>>>> message has been received, the receiver MUST send a success REPORT >>>>>>>> with a byte range covering the whole message. If the >>>>>>>> Success-Report >>>>>>>> header is not set to "no", then the receiver MAY generate >>>>>>>> incremental >>>>>>>> success REPORTs as the chunks are received. These can be sent >>>>>>>> periodically and cover all the bytes that have been received so far >>>>>>>> or they can be sent after a chunk arrives and cover just the part >>>>>>>> from that chunk." >>>>>>>> >>>>>>>> So, if I understand correctly, the receiver has the right to send >>>>>>>> success REPORTs of chunks when the Success-Report is se to "no". Is >>>>>>>> this correct? >>>>>>> >>>>>>> I don't understand it that way. I believe it specifies: >>>>>>> >>>>>>> YES: MUST send success report for complete message, >>>>>>> MAY send incremental success reports >>>>>>> >>>>>>> NO: MUST NOT send success reports at all >>>>>> >>>>>> Miguel -> This is not according to the current text, that says: If >>>>>> the Success-Report header is not set to "no", then the receiver MAY >>>>>> generate incremental success REPORTs as the chunks are received. >>>>> >>>>> Agree, this isn't explicit in the above paragraph. So we should add >>>>> another sentence to the end of the above: >>>>> >>>>> "If the Success-Report header was set to "no", then success reports >>>>> MUST NOT be sent." >>>>> >>>>> >>>>>>> PARTIAL: MAY send success reports, either for the >>>>>>> complete message or incrementally. >>>>>> >>>>>> Miguel -> I think this is not written in the text. >>>>> >>>>> Well, "partial" is not NO, so it may send an incremental report. And a >>>>> report for the complete message is indistinguishable from an >>>>> incremental report so that is permitted too. >>>> >>>> I agree that "partial" is not NO. I am just saying that the text does >>>> nos say anything about "partial" and incremental reports. >>> >>> Doesn't seem to be an issue. >>> >>> >>>> But still I haven't found an answer to what is the usefulness of reports. >>> >>> They are useful in recovering from loss of the media connection. You can >>> reestablish the connection (with reinvite) and then restart sending the >>> message. Any ranges that were confirmed don't have to be sent again. >>> When the connection hasn't failed, the success reports indicate portions >>> of the message that no longer need to be saved to prepare for error >>> recovery. >>> >>> This might be significant in our frequently cited case of transmitting >>> the Lord of the Rings. (The fact that we use that as an example says >>> something about how long we have been working on this.) >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 14:34:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10117; Sat, 5 Mar 2005 14:34:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7f4m-0001rV-EF; Sat, 05 Mar 2005 14:36:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7f1d-00064n-Ay; Sat, 05 Mar 2005 14:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7f1c-00064i-2W for simple@megatron.ietf.org; Sat, 05 Mar 2005 14:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10054 for ; Sat, 5 Mar 2005 14:33:18 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7f3Q-0001pS-A9 for simple@ietf.org; Sat, 05 Mar 2005 14:35:14 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j25JXDK13675; Sat, 5 Mar 2005 11:33:13 -0800 In-Reply-To: <42290CF3.5070908@cs.columbia.edu> References: <42290CF3.5070908@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] comments on RPID (values) Date: Sat, 5 Mar 2005 11:33:18 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Mar 4, 2005, at 17:35, Henning Schulzrinne wrote: >> i think may more appropriately belong in than >> in some cases. i propose that it is allowed in either. > > Can you describe such cases? Sure, I have a presentity URI (single person) for which I have several services providing presence data. Some of them are acting in a work context and others in a home context. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 14:35:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10227; Sat, 5 Mar 2005 14:35:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7f5n-0001tM-Oa; Sat, 05 Mar 2005 14:37:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7f32-0006C9-VS; Sat, 05 Mar 2005 14:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7f32-0006C4-1V for simple@megatron.ietf.org; Sat, 05 Mar 2005 14:34:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10140 for ; Sat, 5 Mar 2005 14:34:46 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7f4p-0001re-VT for simple@ietf.org; Sat, 05 Mar 2005 14:36:41 -0500 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j25JYdjA091403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Mar 2005 13:34:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <422A09CC.9030402@nostrum.com> Date: Sat, 05 Mar 2005 13:34:36 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Comments to MSRP-10 References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , Ben Campbell , Paul H Kyzivat , "simple@ietf.org" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >So in summary, I think we could do it, but I'd rather not unless we have a >strong need for it. The text is written such that we have an insurance >policy of being able to easily add it later if this was a mistake. > >Opinions? > > KISS /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 14:47:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10893; Sat, 5 Mar 2005 14:47:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fH3-00026i-0B; Sat, 05 Mar 2005 14:49:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fCc-0007Fv-EN; Sat, 05 Mar 2005 14:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fCb-0007Fq-EJ for simple@megatron.ietf.org; Sat, 05 Mar 2005 14:44:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10750 for ; Sat, 5 Mar 2005 14:44:39 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fER-00023M-2p for simple@ietf.org; Sat, 05 Mar 2005 14:46:35 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j25JicK13764; Sat, 5 Mar 2005 11:44:38 -0800 In-Reply-To: <4229167F.6010002@cs.columbia.edu> References: <4229167F.6010002@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] comments on RPID Date: Sat, 5 Mar 2005 11:44:43 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit On Mar 4, 2005, at 18:16, Henning Schulzrinne wrote: > Rohan Mahy wrote: > >> I think we *really* need a way to associate person data with the >> tuples that contributed it. I suggest a list of contributing-tuples >> in each person element. Otherwise, there is no way to intelligently >> tie ambiguous presence data about a person to the service(s) that >> provided it. For example, I may want to ignore the person >> information from a service running on my home PC when I am travelling >> at IETF. (for example if I leave my home PC on and another family >> member uses the computer). The presence compositor doesn't know how >> to handle this ambiguous data, but a human might, *IF* they can >> associate the faulty presence data with the service(s) that >> contributed it. > > This assumes that service tuples provided the person information. That > is not likely to be generally true. For example, calendar information > would not be associated with a , nor would other sensors that > might feed into the compositor. > > Wouldn't this best be handled as part of the source identification > (see separate message)? Your proposal doesn't address my use case above. Two sources of ambiguous data could have the same source classification (ex: sensor, or manual). This doesn't help the compositor. Then the source reported in the composed document has the source classification of "composed". This doesn't help the client. To be clear, I am proposing a list of contributing sources. Its semantics are that the following tuple tags in this document contributed to the data in this person element. Other sources may or may not have contributed, but these definitely did. one more below... Henning also wrote: > Rohan Mahy wrote: > >> In the person and tuple tags it would be useful to add an >> "input-source" element indicating if a human or automata generated >> the markup. > > If we can keep it simple, this would indeed be helpful for > composition. There are probably two types of information: > > (1) a rough classification of the source ("manual", "calendar", > "sensor", "composed"), either as an attribute or as an element: > > i like this, and i think it should be included, but I think it is orthogonal to the problem I describe above thx, -r > (2) a more detailed labeling of the source, primarily meant for > composers (e.g., "sensor17" or "Outlook"). > We had previously, I believe, discussed this as future work. I'd > rather avoid delaying the completion of this draft if this discussion > turns out to be lengthier. > > Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 14:57:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11480; Sat, 5 Mar 2005 14:57:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fR7-0002JW-Mn; Sat, 05 Mar 2005 14:59:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fNF-0008BG-JQ; Sat, 05 Mar 2005 14:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fNE-0008BA-E2 for simple@megatron.ietf.org; Sat, 05 Mar 2005 14:55:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11311 for ; Sat, 5 Mar 2005 14:55:38 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fP3-0002GH-9l for simple@ietf.org; Sat, 05 Mar 2005 14:57:34 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+jL+mkUoReGmlbvDjZLVgu002aj8IlQWI@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j25JtWh3002761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Mar 2005 14:55:33 -0500 (EST) Message-ID: <422A0EAE.6060002@cs.columbia.edu> Date: Sat, 05 Mar 2005 14:55:26 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID (values) References: <42290CF3.5070908@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Sure, I have a presentity URI (single person) for which I have several > services providing presence data. Some of them are acting in a work > context and others in a home context. This sounds like the home vs. business phone distinction? I think there are really two somewhat distinct concepts here: (1) A service (or possibly device) is located in a home or business environment. This would be indicated by the 'class' identification in the callee caps/prescaps environment. (2) Whether the human is currently thinking of himself wearing his work cap or his off-the-clock/home/leisure cap, for example. This doesn't necessarily depend on my service - my cell phone, for example, may well be used for both and a home office phone service might also serve both spheres. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 15:02:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11824; Sat, 5 Mar 2005 15:02:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fVy-0002RA-M2; Sat, 05 Mar 2005 15:04:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fTP-0000dL-4A; Sat, 05 Mar 2005 15:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fTN-0000dD-5g for simple@megatron.ietf.org; Sat, 05 Mar 2005 15:02:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11801 for ; Sat, 5 Mar 2005 15:01:59 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fVA-0002Q6-Ks for simple@ietf.org; Sat, 05 Mar 2005 15:03:55 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j25K22A06524; Sat, 5 Mar 2005 22:02:03 +0200 (EET) X-Scanned: Sat, 5 Mar 2005 22:01:28 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j25K1S1T009867; Sat, 5 Mar 2005 22:01:28 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00rdLGOn; Sat, 05 Mar 2005 22:01:26 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j25K1PM15649; Sat, 5 Mar 2005 22:01:25 +0200 (EET) Received: from [10.163.23.234] ([10.163.23.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 5 Mar 2005 22:01:24 +0200 Message-ID: <422A1014.9030107@nokia.com> Date: Sat, 05 Mar 2005 22:01:24 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Comments to MSRP-10 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 20:01:24.0692 (UTC) FILETIME=[1BFBD940:01C521BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Ok, I hadn't considered the operation with relays. I agree with you then. /Miguel Cullen Jennings wrote: > I would really rather not add yet another variation to the error reporting > unless we really needed it. > > We can't really put a flag that says the receiver must send incremental > reports because a relay before the endpoint may aggregate all the chunks > into a single one there would be only a single report. > > We could put a flag that said the receiver MUST NOT generate incremental > success reports. A system that did this would really hamper it's ability to > recover from errors and eliminate any intermediate feedback that it received > about ongoing transfers. All the cases I can think of where you would want > this, you would probably just say no to Success-Reports all together. > > If this turns out to be a mistake, we can easily add it later without > violating any of current text. At one point in time I had a Success-Report > values of yes, no, and no-incremental. That is why some of the text is > somewhat double negative like "if value does not equal no then" so that we > can insert another value in the Success-Report and still have all the > current stuff operate correctly. > > So in summary, I think we could do it, but I'd rather not unless we have a > strong need for it. The text is written such that we have an insurance > policy of being able to easily add it later if this was a mistake. > > Opinions? > > > On 3/5/05 10:00 AM, "Miguel Garcia" wrote: > > >>Yes, please. This solves one bug in the current text. >> >>But I'm still not happy leaving the decision of whether to send >>incremental reports in the receiver's hands. The same that other types >>of reports are requested by the sender, incremental reports should be >>requested by the sender. >> >>One possible solution is to add a parameter to the Success-Report >>header, so that when it takes the value yes, it can also take the >>parameter "incremental", meaning that the sender is willing to receive >>incremental reports. >> >>How about that? >> >>/Miguel >> >>Cullen Jennings wrote: >> >> >>>Ok - I got lost on this thread. Do we need to change any text. I'm fine to >>>add in the suggested >>> >>> >>>>>>"If the Success-Report header was set to "no", then success reports >>>>>>MUST NOT be sent." >>> >>> >>> >>>On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: >>> >>> >>> >>>>>>>>>7) Section 7.3.1, last paragraph in the section >>>>>>>>> >>>>>>>>> "If the Success-Report header was set to "yes", then when a >>>>>>>>>complete >>>>>>>>> message has been received, the receiver MUST send a success REPORT >>>>>>>>> with a byte range covering the whole message. If the >>>>>>>>>Success-Report >>>>>>>>> header is not set to "no", then the receiver MAY generate >>>>>>>>>incremental >>>>>>>>> success REPORTs as the chunks are received. These can be sent >>>>>>>>> periodically and cover all the bytes that have been received so far >>>>>>>>> or they can be sent after a chunk arrives and cover just the part >>>>>>>>> from that chunk." >>>>>>>>> >>>>>>>>>So, if I understand correctly, the receiver has the right to send >>>>>>>>>success REPORTs of chunks when the Success-Report is se to "no". Is >>>>>>>>>this correct? >>>>>>>> >>>>>>>>I don't understand it that way. I believe it specifies: >>>>>>>> >>>>>>>> YES: MUST send success report for complete message, >>>>>>>> MAY send incremental success reports >>>>>>>> >>>>>>>> NO: MUST NOT send success reports at all >>>>>>> >>>>>>>Miguel -> This is not according to the current text, that says: If >>>>>>>the Success-Report header is not set to "no", then the receiver MAY >>>>>>>generate incremental success REPORTs as the chunks are received. >>>>>> >>>>>>Agree, this isn't explicit in the above paragraph. So we should add >>>>>>another sentence to the end of the above: >>>>>> >>>>>>"If the Success-Report header was set to "no", then success reports >>>>>>MUST NOT be sent." >>>>>> >>>>>> >>>>>> >>>>>>>> PARTIAL: MAY send success reports, either for the >>>>>>>> complete message or incrementally. >>>>>>> >>>>>>>Miguel -> I think this is not written in the text. >>>>>> >>>>>>Well, "partial" is not NO, so it may send an incremental report. And a >>>>>>report for the complete message is indistinguishable from an >>>>>>incremental report so that is permitted too. >>>>> >>>>>I agree that "partial" is not NO. I am just saying that the text does >>>>>nos say anything about "partial" and incremental reports. >>>> >>>>Doesn't seem to be an issue. >>>> >>>> >>>> >>>>>But still I haven't found an answer to what is the usefulness of reports. >>>> >>>>They are useful in recovering from loss of the media connection. You can >>>>reestablish the connection (with reinvite) and then restart sending the >>>>message. Any ranges that were confirmed don't have to be sent again. >>>>When the connection hasn't failed, the success reports indicate portions >>>>of the message that no longer need to be saved to prepare for error >>>>recovery. >>>> >>>>This might be significant in our frequently cited case of transmitting >>>>the Lord of the Rings. (The fact that we use that as an example says >>>>something about how long we have been working on this.) >>> >>> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 15:14:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13135; Sat, 5 Mar 2005 15:14:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fgq-0002gT-AA; Sat, 05 Mar 2005 15:15:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7feM-0001w4-LV; Sat, 05 Mar 2005 15:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7feL-0001vz-5g for simple@megatron.ietf.org; Sat, 05 Mar 2005 15:13:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13067 for ; Sat, 5 Mar 2005 15:13:19 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fgA-0002fk-06 for simple@ietf.org; Sat, 05 Mar 2005 15:15:15 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX188On2F0pdLSCuD5DLTx1Q5UgbwNJ0hq1k@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j25KD7h3003785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Mar 2005 15:13:09 -0500 (EST) Message-ID: <422A12CE.8010700@cs.columbia.edu> Date: Sat, 05 Mar 2005 15:13:02 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] comments on RPID References: <4229167F.6010002@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > On Mar 4, 2005, at 18:16, Henning Schulzrinne wrote: > >> Rohan Mahy wrote: >> > Your proposal doesn't address my use case above. Two sources of > ambiguous data could have the same source classification (ex: sensor, or > manual). This doesn't help the compositor. Then the source reported in > the composed document has the source classification of "composed". This > doesn't help the client. The second part of the source description (that you clipped) identifies the source. I just don't think that we can count on the source for information being any of the other or tuples in the document. Also, how would you identify or reference calendar information or information provided by non-device sources, such as the BlueTooth beacon in Starbucks that announces the location and the place-type "cafe"? > > To be clear, I am proposing a list of contributing sources. Its > semantics are that the following tuple tags in this document contributed > to the data in this person element. Other sources may or may not have > contributed, but these definitely did. I can see this for device tuples, but that does seem to be the same that I had proposed as part of source identification (as part 2 of that labeling). >> (1) a rough classification of the source ("manual", "calendar", >> "sensor", "composed"), either as an attribute or as an element: >> >> > > > i like this, and i think it should be included, but I think it is > orthogonal to the problem I describe above This should probably be an attribute for each element, as this information can differ across elements in the same , for example. (E.g., time-offset is probably derived automatically, while _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 15:20:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14306; Sat, 5 Mar 2005 15:20:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fn1-0002tj-9Y; Sat, 05 Mar 2005 15:22:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fk7-0002gg-66; Sat, 05 Mar 2005 15:19:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fk5-0002ga-OD for simple@megatron.ietf.org; Sat, 05 Mar 2005 15:19:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14132 for ; Sat, 5 Mar 2005 15:19:15 -0500 (EST) 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.33) id 1D7flu-0002r0-2h for simple@ietf.org; Sat, 05 Mar 2005 15:21:11 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2005 12:32:33 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j25KJ2ZV018582; Sat, 5 Mar 2005 12:19:03 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-92.cisco.com [10.86.242.92]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APP00402; Sat, 5 Mar 2005 15:19:01 -0500 (EST) Message-ID: <422A1435.1050508@cisco.com> Date: Sat, 05 Mar 2005 15:19:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Comments to MSRP-10 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , Ben Campbell , "simple@ietf.org" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit I can see more work on this in the future, around recoverability, but think it is best to leave as is for now. There are multiple complications with mandating incremental reports. As mentioned below, the UAS may receive it all as one chunk. It is also possible that it will receive it as a million tiny chunks, which could result in a flood of reports. For a case where a large message is being received gracefully in order with no problems, it would probably be good to send a report periodically. This would bound the amount of bandwidth consumed in reports, yet would minimize what needs to be retransmitted in case of an error. But working out the details of negotiating that would be a lot of trouble, so I certainly don't want to do it now, if ever. Both ends have an equal interest in this - it minimizes what must be retransmitted and so the time they both must wait for that to happen. Since both benefit, it seems reasonable to just count on the recipient to make a reasonable choice about when and if to send these. Paul Cullen Jennings wrote: > I would really rather not add yet another variation to the error reporting > unless we really needed it. > > We can't really put a flag that says the receiver must send incremental > reports because a relay before the endpoint may aggregate all the chunks > into a single one there would be only a single report. > > We could put a flag that said the receiver MUST NOT generate incremental > success reports. A system that did this would really hamper it's ability to > recover from errors and eliminate any intermediate feedback that it received > about ongoing transfers. All the cases I can think of where you would want > this, you would probably just say no to Success-Reports all together. > > If this turns out to be a mistake, we can easily add it later without > violating any of current text. At one point in time I had a Success-Report > values of yes, no, and no-incremental. That is why some of the text is > somewhat double negative like "if value does not equal no then" so that we > can insert another value in the Success-Report and still have all the > current stuff operate correctly. > > So in summary, I think we could do it, but I'd rather not unless we have a > strong need for it. The text is written such that we have an insurance > policy of being able to easily add it later if this was a mistake. > > Opinions? > > > On 3/5/05 10:00 AM, "Miguel Garcia" wrote: > > >>Yes, please. This solves one bug in the current text. >> >>But I'm still not happy leaving the decision of whether to send >>incremental reports in the receiver's hands. The same that other types >>of reports are requested by the sender, incremental reports should be >>requested by the sender. >> >>One possible solution is to add a parameter to the Success-Report >>header, so that when it takes the value yes, it can also take the >>parameter "incremental", meaning that the sender is willing to receive >>incremental reports. >> >>How about that? >> >>/Miguel >> >>Cullen Jennings wrote: >> >> >>>Ok - I got lost on this thread. Do we need to change any text. I'm fine to >>>add in the suggested >>> >>> >>>>>>"If the Success-Report header was set to "no", then success reports >>>>>>MUST NOT be sent." >>>>> >>> >>> >>>On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: >>> >>> >>> >>>>>>>>>7) Section 7.3.1, last paragraph in the section >>>>>>>>> >>>>>>>>> "If the Success-Report header was set to "yes", then when a >>>>>>>>>complete >>>>>>>>> message has been received, the receiver MUST send a success REPORT >>>>>>>>> with a byte range covering the whole message. If the >>>>>>>>>Success-Report >>>>>>>>> header is not set to "no", then the receiver MAY generate >>>>>>>>>incremental >>>>>>>>> success REPORTs as the chunks are received. These can be sent >>>>>>>>> periodically and cover all the bytes that have been received so far >>>>>>>>> or they can be sent after a chunk arrives and cover just the part >>>>>>>>> from that chunk." >>>>>>>>> >>>>>>>>>So, if I understand correctly, the receiver has the right to send >>>>>>>>>success REPORTs of chunks when the Success-Report is se to "no". Is >>>>>>>>>this correct? >>>>>>>> >>>>>>>>I don't understand it that way. I believe it specifies: >>>>>>>> >>>>>>>> YES: MUST send success report for complete message, >>>>>>>> MAY send incremental success reports >>>>>>>> >>>>>>>> NO: MUST NOT send success reports at all >>>>>>> >>>>>>>Miguel -> This is not according to the current text, that says: If >>>>>>>the Success-Report header is not set to "no", then the receiver MAY >>>>>>>generate incremental success REPORTs as the chunks are received. >>>>>> >>>>>>Agree, this isn't explicit in the above paragraph. So we should add >>>>>>another sentence to the end of the above: >>>>>> >>>>>>"If the Success-Report header was set to "no", then success reports >>>>>>MUST NOT be sent." >>>>>> >>>>>> >>>>>> >>>>>>>> PARTIAL: MAY send success reports, either for the >>>>>>>> complete message or incrementally. >>>>>>> >>>>>>>Miguel -> I think this is not written in the text. >>>>>> >>>>>>Well, "partial" is not NO, so it may send an incremental report. And a >>>>>>report for the complete message is indistinguishable from an >>>>>>incremental report so that is permitted too. >>>>> >>>>>I agree that "partial" is not NO. I am just saying that the text does >>>>>nos say anything about "partial" and incremental reports. >>>> >>>>Doesn't seem to be an issue. >>>> >>>> >>>> >>>>>But still I haven't found an answer to what is the usefulness of reports. >>>> >>>>They are useful in recovering from loss of the media connection. You can >>>>reestablish the connection (with reinvite) and then restart sending the >>>>message. Any ranges that were confirmed don't have to be sent again. >>>>When the connection hasn't failed, the success reports indicate portions >>>>of the message that no longer need to be saved to prepare for error >>>>recovery. >>>> >>>>This might be significant in our frequently cited case of transmitting >>>>the Lord of the Rings. (The fact that we use that as an example says >>>>something about how long we have been working on this.) >>> >>> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Georgeta@jrk.com Sat Mar 5 21:04:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06194 for ; Sat, 5 Mar 2005 21:04:25 -0500 (EST) Message-Id: <200503060204.VAA06194@ietf.org> Received: from 219-68-225-179.adsl.dynamic.giga.net.tw ([219.68.225.179] helo=jrk.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7l9z-0001Mq-FI for simple-archive@ietf.org; Sat, 05 Mar 2005 21:06:25 -0500 From: "Llorenc Beckham" To: "Stasya Leary" Subject: HQO 24-Drrugs Date: Sat, 5 Mar 2005 21:21:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C51E97.422A728C" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 5.9 (+++++) X-Spam-Flag: YES X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C51E97.422A728C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_004D_01C51E97.422A728C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit Our PharmMail=20 SH0P.
     
    SP  OF  Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.)
    ECIAL FER: ag al it
    And Many Other!
     
    With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_004D_01C51E97.422A728C-- From simple-bounces@ietf.org Sat Mar 5 22:11:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09805; Sat, 5 Mar 2005 22:11:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7mDI-0002ZK-AF; Sat, 05 Mar 2005 22:13:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mAO-0007XF-1l; Sat, 05 Mar 2005 22:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mAL-0007X9-JX for simple@megatron.ietf.org; Sat, 05 Mar 2005 22:10:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09745 for ; Sat, 5 Mar 2005 22:10:47 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7mCE-0002YH-Vt for simple@ietf.org; Sat, 05 Mar 2005 22:12:47 -0500 Received: from [192.168.1.102] (c-24-23-89-57.client.comcast.net [24.23.89.57]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j2639XM4021307 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 5 Mar 2005 21:09:34 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9d9eedbca031ced05ec0d12f79c86563@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Comments to MSRP-10 Date: Sat, 5 Mar 2005 21:09:27 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , Rohan Mahy , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit I agree with Cullen on this point. I have trouble imagining a situation where the sender would request success reports, and incremental reports would be a problem. Similarly, I don't think we want to let the sender _require_ them. So, the most we would get out of such a parameter is a hint. I don't think the value of such a hint is worth adding further complexity to the report mechanism--it is complex enough as it it. On Mar 5, 2005, at 1:28 PM, Cullen Jennings wrote: > > I would really rather not add yet another variation to the error > reporting > unless we really needed it. > > We can't really put a flag that says the receiver must send incremental > reports because a relay before the endpoint may aggregate all the > chunks > into a single one there would be only a single report. > > We could put a flag that said the receiver MUST NOT generate > incremental > success reports. A system that did this would really hamper it's > ability to > recover from errors and eliminate any intermediate feedback that it > received > about ongoing transfers. All the cases I can think of where you would > want > this, you would probably just say no to Success-Reports all together. > > If this turns out to be a mistake, we can easily add it later without > violating any of current text. At one point in time I had a > Success-Report > values of yes, no, and no-incremental. That is why some of the text is > somewhat double negative like "if value does not equal no then" so > that we > can insert another value in the Success-Report and still have all the > current stuff operate correctly. > > So in summary, I think we could do it, but I'd rather not unless we > have a > strong need for it. The text is written such that we have an insurance > policy of being able to easily add it later if this was a mistake. > > Opinions? > > > On 3/5/05 10:00 AM, "Miguel Garcia" wrote: > >> Yes, please. This solves one bug in the current text. >> >> But I'm still not happy leaving the decision of whether to send >> incremental reports in the receiver's hands. The same that other types >> of reports are requested by the sender, incremental reports should be >> requested by the sender. >> >> One possible solution is to add a parameter to the Success-Report >> header, so that when it takes the value yes, it can also take the >> parameter "incremental", meaning that the sender is willing to receive >> incremental reports. >> >> How about that? >> >> /Miguel >> >> Cullen Jennings wrote: >> >>> Ok - I got lost on this thread. Do we need to change any text. I'm >>> fine to >>> add in the suggested >>> >>>>>> "If the Success-Report header was set to "no", then success >>>>>> reports >>>>>> MUST NOT be sent." >>> >>> >>> >>> On 3/2/05 6:24 AM, "Paul Kyzivat" wrote: >>> >>> >>>>>>>>> 7) Section 7.3.1, last paragraph in the section >>>>>>>>> >>>>>>>>> "If the Success-Report header was set to "yes", then when a >>>>>>>>> complete >>>>>>>>> message has been received, the receiver MUST send a success >>>>>>>>> REPORT >>>>>>>>> with a byte range covering the whole message. If the >>>>>>>>> Success-Report >>>>>>>>> header is not set to "no", then the receiver MAY generate >>>>>>>>> incremental >>>>>>>>> success REPORTs as the chunks are received. These can be >>>>>>>>> sent >>>>>>>>> periodically and cover all the bytes that have been received >>>>>>>>> so far >>>>>>>>> or they can be sent after a chunk arrives and cover just the >>>>>>>>> part >>>>>>>>> from that chunk." >>>>>>>>> >>>>>>>>> So, if I understand correctly, the receiver has the right to >>>>>>>>> send >>>>>>>>> success REPORTs of chunks when the Success-Report is se to >>>>>>>>> "no". Is >>>>>>>>> this correct? >>>>>>>> >>>>>>>> I don't understand it that way. I believe it specifies: >>>>>>>> >>>>>>>> YES: MUST send success report for complete message, >>>>>>>> MAY send incremental success reports >>>>>>>> >>>>>>>> NO: MUST NOT send success reports at all >>>>>>> >>>>>>> Miguel -> This is not according to the current text, that says: >>>>>>> If >>>>>>> the Success-Report header is not set to "no", then the receiver >>>>>>> MAY >>>>>>> generate incremental success REPORTs as the chunks are received. >>>>>> >>>>>> Agree, this isn't explicit in the above paragraph. So we should >>>>>> add >>>>>> another sentence to the end of the above: >>>>>> >>>>>> "If the Success-Report header was set to "no", then success >>>>>> reports >>>>>> MUST NOT be sent." >>>>>> >>>>>> >>>>>>>> PARTIAL: MAY send success reports, either for the >>>>>>>> complete message or incrementally. >>>>>>> >>>>>>> Miguel -> I think this is not written in the text. >>>>>> >>>>>> Well, "partial" is not NO, so it may send an incremental report. >>>>>> And a >>>>>> report for the complete message is indistinguishable from an >>>>>> incremental report so that is permitted too. >>>>> >>>>> I agree that "partial" is not NO. I am just saying that the text >>>>> does >>>>> nos say anything about "partial" and incremental reports. >>>> >>>> Doesn't seem to be an issue. >>>> >>>> >>>>> But still I haven't found an answer to what is the usefulness of >>>>> reports. >>>> >>>> They are useful in recovering from loss of the media connection. >>>> You can >>>> reestablish the connection (with reinvite) and then restart sending >>>> the >>>> message. Any ranges that were confirmed don't have to be sent again. >>>> When the connection hasn't failed, the success reports indicate >>>> portions >>>> of the message that no longer need to be saved to prepare for error >>>> recovery. >>>> >>>> This might be significant in our frequently cited case of >>>> transmitting >>>> the Lord of the Rings. (The fact that we use that as an example says >>>> something about how long we have been working on this.) >>> >>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 5 22:13:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09916; Sat, 5 Mar 2005 22:13:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7mEu-0002c5-Cq; Sat, 05 Mar 2005 22:15:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mBa-0007dr-3U; Sat, 05 Mar 2005 22:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mBY-0007dl-KI for simple@megatron.ietf.org; Sat, 05 Mar 2005 22:12:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09832 for ; Sat, 5 Mar 2005 22:12:02 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7mDR-0002ZT-90 for simple@ietf.org; Sat, 05 Mar 2005 22:14:02 -0500 Received: from [192.168.1.102] (c-24-23-89-57.client.comcast.net [24.23.89.57]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j2639XM5021307 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 5 Mar 2005 21:09:54 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <4225CCAA.3070502@cisco.com> References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> <4224A919.7040403@nokia.com> <4224AE56.4050602@cisco.com> <4224B221.7020201@nokia.com> <4225CCAA.3070502@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74a84419fcd8aa7b7978c342d3af80da@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Comments to MSRP-10 Date: Sat, 5 Mar 2005 21:09:53 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , Rohan Mahy , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Mar 2, 2005, at 8:24 AM, Paul Kyzivat wrote: [...] > This might be significant in our frequently cited case of transmitting > the Lord of the Rings. (The fact that we use that as an example says > something about how long we have been working on this.) > Actually, I think the seminal example was "The Matrix", which dates us even further. I note that the latest relay draft merely refers to a large mpeg without mentioning specific content. I thought perhaps the authors were trying to avoid any suggestion of copyright violation, but now I realize it was because they got tired of changing to the latest big movie with every version :-) > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 6 02:05:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27970; Sun, 6 Mar 2005 02:05:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7pr7-0006zK-Q7; Sun, 06 Mar 2005 02:07:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7pni-0004r2-OQ; Sun, 06 Mar 2005 02:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7pnb-0004qD-W8 for simple@megatron.ietf.org; Sun, 06 Mar 2005 02:03:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26178 for ; Sun, 6 Mar 2005 02:03:32 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ppU-0006xJ-9g for simple@ietf.org; Sun, 06 Mar 2005 02:05:33 -0500 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j2673NL3037235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 01:03:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <422AAB38.5030100@nostrum.com> Date: Sun, 06 Mar 2005 01:03:20 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> <4224A919.7040403@nokia.com> In-Reply-To: <4224A919.7040403@nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , Paul Kyzivat , Simple WG , Cullen Jennings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > > Miguel -> I don't really care about the exact wording, as long as it > does not make any assumptions about future MSRP extensions. The > current text implies that the Report headers are meant only for SEND > requests, and for no other MSRP methods that any human can think of in > the future. So if we invent a new method that can use those headers, > this shouldn't create a violation of the MSRP RFC. If I recall correctly, MSRP isn't intended to be method-extensible. Once again relying on my memory, I believe that this decision is due to some specific guidance that we have received from the IESG by way of our area director. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Alicja@jensons.com Sun Mar 6 06:11:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27588 for ; Sun, 6 Mar 2005 06:11:11 -0500 (EST) Message-Id: <200503061111.GAA27588@ietf.org> Received: from [159.148.132.226] (helo=jensons.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7thC-0007gz-Qz for simple-archive@ietf.org; Sun, 06 Mar 2005 06:13:16 -0500 From: "Teri Quintana" To: "Verity Santana" Subject: UCL 93-Medicationss Date: Sun, 6 Mar 2005 06:38:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C51E97.422AF2B8" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.4 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C51E97.422AF2B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_004D_01C51E97.422AF2B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit Our PharmMail=20 SH0P.
     
    SP  OF  Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.)
    ECIAL FER: ag al it
    And Many Other!
     
    With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_004D_01C51E97.422AF2B8-- From simple-bounces@ietf.org Sun Mar 6 14:20:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12053; Sun, 6 Mar 2005 14:20:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D81KX-0002eK-VG; Sun, 06 Mar 2005 14:22:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D81Gc-0007cG-Et; Sun, 06 Mar 2005 14:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D81GY-0007bS-N8 for simple@megatron.ietf.org; Sun, 06 Mar 2005 14:18:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11779 for ; Sun, 6 Mar 2005 14:18:12 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D81Ia-0002Ym-NO for simple@ietf.org; Sun, 06 Mar 2005 14:20:21 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j26JI1A00816; Sun, 6 Mar 2005 21:18:01 +0200 (EET) X-Scanned: Sun, 6 Mar 2005 21:31:15 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j26JVFWl027756; Sun, 6 Mar 2005 21:31:15 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00hZpXKw; Sun, 06 Mar 2005 21:31:13 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j26JGnU23355; Sun, 6 Mar 2005 21:16:49 +0200 (EET) Received: from [10.162.16.14] ([10.162.16.14]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 6 Mar 2005 21:16:31 +0200 Message-ID: <422B570C.5040503@nokia.com> Date: Sun, 06 Mar 2005 21:16:28 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] Comments to MSRP-10 References: <4224788E.7030708@nokia.com> <4224A1D6.1050701@cisco.com> <4224A919.7040403@nokia.com> <422AAB38.5030100@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2005 19:16:32.0128 (UTC) FILETIME=[0180F000:01C52281] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Paul Kyzivat , Adam Roach , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Yeap, I agree with Ben, there is an unknown method response. Actually, even the relay spec extends MSRP with the AUTH method, and I think it would be a failure if in year 2005 the IETF produces a protocol that is not extensible. /Miguel Ben Campbell wrote: > It isn't intended to be _very_ extensible, whatever that means. But we > do have a response code for "unknown method" now. It was one of many > compromises over the course of this work. > > On Mar 6, 2005, at 1:03 AM, Adam Roach wrote: > >> Miguel Garcia wrote: >> >>> >>> Miguel -> I don't really care about the exact wording, as long as it >>> does not make any assumptions about future MSRP extensions. The >>> current text implies that the Report headers are meant only for SEND >>> requests, and for no other MSRP methods that any human can think of >>> in the future. So if we invent a new method that can use those >>> headers, this shouldn't create a violation of the MSRP RFC. >> >> >> >> If I recall correctly, MSRP isn't intended to be method-extensible. >> Once again relying on my memory, I believe that this decision is due >> to some specific guidance that we have received from the IESG by way >> of our area director. >> >> /a > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From 4ldtzjwj@blueyonder.co.uk Sun Mar 6 15:17:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20773; Sun, 6 Mar 2005 15:17:10 -0500 (EST) Received: from [38.136.83.69] (helo=MALAWAKI-1KX7VI) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D82Da-0004Ic-6g; Sun, 06 Mar 2005 15:19:17 -0500 Received: from goldenrod (208.124.98.224) by ak4.capitol.thereunder.lubricate.mminternet.com (InterMail vX.3.82.19.33 268-21802-820-84-385-4572659) with ESMTP id <95306204363851.JQJA2459.kn23-mail.strident.blueberry.net.cable.rogers.com@sportsmen> for ; Sun, 06 Mar 2005 18:14:26 -0200 Message-ID: <85010dl8is$502do9$00bt5fw218@monty> Reply-To: "Lionel Slater" <4ldtzjwj@blueyonder.co.uk> From: "Lionel Slater" <4ldtzjwj@blueyonder.co.uk> To: Subject: Become one of the lowest rate borrowers Date: Sun, 06 Mar 2005 16:15:26 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Spam-Score: 4.2 (++++) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer Best Customer Service Lowest Interest-Rates in Years SAVE $100-$400 per month Our easy application only takes 1 minutes. --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    To take Advantage of this Limited Time opportunity
    All we ask is that you visit our Website and complete
    The 1 minute post Approval Form
    Easy application only takes 1 minutes.



    Off this camp-aign

    --%OLATTACH2-- --%OLATTACH1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgA2wISAwEiAAIRAQMRAf/EAK8AAAIDAQEBAAAAAAAAAAAA AAAFAwQGAgEHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwIDAgoGBggEBQUAAAECAwARBCES MRMFQSJRYXGRMlKS0hQVgaHRI1MGsUJysnM0wWKCwjOT0xbw4UMk8aLiYweDo8PjNREAAgIBBAAF AQUIAgMBAAAAAAERAhIhMVEDQWEiEwQycYGhQlLwkbHBcjMUBdGS8WJzI//aAAwDAQACEQMRAD8A +gUUUUAUUVSzEyVDzJMVRRfYBWOy+FXbF2jeODVK5OJVZ5LtFUMXn7Fypp/urEspHlFSx9QxpHCA kE6AkWBrNe+rSdv/AM8vpVmpa5NW6rJuPXju6rYtUV5VU9SxQxG46frW0rduylIysqztJmtLW+lN xwW6KrvmQJEsrE2f0RbU1yc+EwPLGblP1SNbnhesvu61+au2W/huVdd3+V7x95aoqrg5PPiuxvIv p6W4k2+quMzNMEscamwuDIbfq37Kj76LrXbPpcfiVdVnd0jVF2iqEuXy8xCWIhKbtvhJvarEOXBM rMpsE9Ldpale6lrOspNNqH4x4kt1XSTiU1JPRVWPqGNJIEBIJ0UkWBqy3onyVut62TdWrRwS1bVc WTX2ntFU8GcnFaWd77WN2Pg0rqPqGNI4QEgnQEiwNYr3dbVW2q5qUm9SvqunZJO2O7RaoqAZcJWR rkcnRwRrXhzIBEs1ztc7RprfyVr3ev8AVXad/DYmF/0veCxRVabOghfYxJbtAF7eWuny4EiWYtdG 0W3Emnu9ctZV9P1a7D276PF+rYnoqsmdA4ci4KDcykWNq4wMw5G9ZPTBuABoF0qe91u1aqyecxHk X2rxZtRjE/eXKKp9RlkijQoxW7WJHgtUkWdjyyctSdx9G4sD5Ke9TN0bhqN/GeB7dsVdKVrt4QWK KrS5+NE+xiSw42F7V0+XAkaylro5sCKvu9eqzr6d9dh7d9PS/VtoT0VVHUcU37xFvCOPkqSHKhmR nVrBPSvpaou3rs4V6t/aH13Sl1svuJqKqx9QxpJAgJBOikiwNWW9E+StVvWybq1aOCWrariya+09 oqngzk4rSzvfaxux8GldR9QxpHCAkE6AkWBrFe7raq21XNSk3qV9V07JJ2x3aLVFVps6CFyjElhx Ci9q6bMgWJZS3cc2Bt2+Ote71y1nX0767D276PF+rYnoqvFnY8snLUncfRuLA+SpndY0Z29FRc1a 3pZO1bJpbtEdbJw002dUVWjz8aRiFJ0XcSRoAK8TqOM7hASN2gJGhrPvdWnrrrtqX2uzX0208i1R VFM/dmmIn7v0VFtS1xx+upJOoY0blCSSNGIFwKi7+ppvJJK2OvJX1XTSxblZaFqioJcuGJVLEtv1 UKLkiuoMmLIBMZN10IOhFa9ymWOSy4M4WjKHHJLRRRWzIUUVXzMuHEhaaZgqqLkmgK/WOqx9MxWm bV+CL4TXz/qnW8/OmWJ5XJfVUQcAf6oqXqPUp+vdSdVOyCEEoh0LC/Z5qY9PwoMKP4nlmSU25jDV j5LngK5WtrB1p1uJEuN1vrHQprtzGgPpIwIB9q9qX9Q6h1Dqsxzpyz7yRGL6IB2KPFWy6nLDNjWl jDMVukbW3Uq6YMPFZYWhcP6O5gCo7PDpe9M40gvta7mbxus9XwJVaHIkiKkHbc2NvCDxr6f+XOuH qmKry/4tu8PHSDOi6fJA6MkbMovcW3LbxcaS9K60eldPkyY9XdikQPi4GtVvl4bGOzrx8Zk+ptIi +kwHlNAZTwNfG8zqWd1EGeedpGB/WOgv4BwFWOj/AJl6vh5KRjIaSI6GJyWGo/ra3rZg+ullHE2r wOp4GvmGf1L8ydWVtztDjD/proWt4dKihz+s9OKtFPIFBF4uIbz1nNcmsHwfVa9pV0Tq6dRx1kGj HiPAaa1oyFFFFAFFFFAFFFFAFFFFAFFFFAFQZv8AKy/s1PRWbVyq67ZJr95auGnw5FrRvJ0pAguR qQPACajnmjyo4YIEPMBHZbaLWptXlhxrhb40qFbR0rS2m6rxwdV3Q5x/M7V1555OZFLRso4lSAfG RSpZ0TDkxmQ83W+nj4nyU3IuLVSODOVaP4g8pjqpFzbwXvT5FLtp0UvG1Ht4/bBem9UmrOPVW3j4 fYVZAyjFlJKoFtvAvtNzUkCh/ipEZpLxspYqAGJFMY41jjWMeiotrXQAHCpX4sNN28NvOI5/kW3f o0l9/lMlTpkqNjCMHvR33D9okiuOosElxpG9FXJJ+lTV4ADhQQDxro+pvpXVlqlVZR+l6aHNdiXY 7xvOk8lAlZOpRONVMe5fpBqJ0Z5c1U9IgGw8RBNNaKy/jzM23vazhfqriaXdEQtqqu/DkSqVlSKL mOzA2EYUd0+XSnDeifIa9sL3trXta6en205eTtC/d9rZOzsza0iJ/EURxvJ0xgguQ9yB4BXs80eV HDBAh5gI7LbRa1Nq8sONc/8AF9Kqr6Oipb07pccGvf1nH8ztXXnnkVZsbrkmNPRydoPlvRDExzBj H/DhdnHk0t/RTaij+InfLL82UeW+P7wvkPHGPyxPntP7hQ5MOVPzJDFvuQQu7cDravSka4SFhIFL 7lewBXgPDwpqQDxF6Kf4v1erfKJW2Tnkf5G2m0Trx9wuwZJGyWUPzo9ushFj5zrXXSpFCPCdJAxY jxd0VfAA4aUWFap0Wq6POcHbw8LeC1JbtVlZYxlj+BS6qLxRj+uP0GjJAGdjWq9RWrdGVrWn6nR7 foJXthJR9Kst/wBQrhmjxGmjyFO9iTe19wqLlOuHEHFg8twD4CLU4IB417XP/FlYu+iTVfTy515N e/rKrq2m9eOOChKB81h0/U9+odjOc5E4kg2HiYmmtFafx02/V9VrW2/VXGCLuiNNq1X/AFciVSsq RRcx2YGwjCjuny6U4b0T5DXthe9ta9rXT0+2nLydoX7vtbJ2dmbWkRP4iiON5OmMEFyHuQPAK9nm jyo4YIEPMBHZbaLWptXlhxrn/i+lVV9HRUt6d0uODXv6zj+Z2rrzzyLJ5m+IljduVYWUKt2k8Gvj qE2OBEP/AHSD5qc2F79te0fxW3Zu/wBWS25c8lXeklFdoe/H3FHJAGdjWqxl/wAtL+yf0VNRXZdU e5r/AHPw0g5O/wBGn0fjrJRgPL6bvRQzBSbEeOqTyh1hJkLEMNy7dqp4qd14ABw0rlf4zsq1V4Va Ku3HjudK9yTs8ZdrO2/PgUBIsXVJN+nMVVXxk7fsqop5SzRSyMjE6oFvv+mnVhx7aLA621qW+M3+ f817LT9e+zFe9L8v5arf9O3gK5UjSLH3GSMgHbLbhc3sQDepMKd1EzueZFGL7wLE/opgQDxrxl3I VB23Frjsqr47rfKtohbRvpGusEfcnXF13e/3ycwzLNEsqAhWvYHjobVUk6rHHI0ZjYlGK3uOw2q5 FGsUaxp6KiwpFkn/ALiX9tv0msfK7ezr66NNKz+rTxg30ddL3vKmq2Lx6zEBflt5xWN6xmZ/5g6s cWDdDhQAhpCNwDdp8BN9KdzPZdo9JtBoK4g2r3VAFxuuBbjxq/Dv29uVruaLRaRqZ+VXr64VFFn5 +Aug/LODE0cqlxNGO6+7ttYnabjWmCs0cRS11Q2kt6Vx4PLVkmynx1mfzHl5EGWoxZWjeSO0tvRt fQ+WvXeialLY49Xa6uHqmT9Qyo58nFVf8RnDEaXEagkbvASTwqaXLjJChStrlmtfVeA0rP4ceQby qCeSLr4xe7C/bWgimjlh5yMNrjvggEgj9FedrU9VLTwp1RS6hDjfCNk/9UpbQ2O62l7eXWs1mB44 MeAiwUEkeEk1owgz8hYo1tBEfaNTdQ6bCksEhXSM2+g8ayu9Vuqbt/siX6807LRL9mIOm9G6nlFe WnLib0nlHd83GmWX0jHwMjGMY7++7u2ikAeCm8GJFjyK0UrEudUvptt6tQ5GIgyYZmcyiUsFDHcd wW6jXhW3dvxIutJba+Y2xJMcRIWZe+O6TwP00t606RAExnYeBA0q5B8G+JjxkBohYbdDr/41F1Lq PTYHEGVd7WYRKLkW4XsRWVVtpJSy2hJuzjzK/wCWM/kSsDGwUm9uFa75xHb/AA284rJ9Nf4nJkyQ LISAlxrtA0vTi/8AxpXl7vldtbutbQl5I6dfx+u1ZanzkafOIvw284o+cRfht5xSu/8AxYUX/wCL CuX+b3/qX/VG/wDG6v0/ixp84i/DbzirmPMJ4VlAsGvofEbVn7/8WFO+nfycf9r9416fifI7Ozsd buUqTtHijj8jppSidVDyjctUUUV7zyBRRRQBRRRQBRRRQBRRRQBRRUc88ePE0shsq8banXQAUBJR VI58TpKjLJBIsbPZ1s20D0l1tpQOoQxrFHaSWR4lkXat2YEcfLpUyXILtFUPm+MV3hJCg/xGCaRm 9rPUs3UIYpVh2vJI6h1VF3XBJH9FMlyC1RS+fN5iYzwMy7slI5FIsw43VhVhc2FoZJ9QsJYSA8QU 4imSBYorhZUaITHuoV397SwtfWq0fU4JHRdkirIbRystkY+I+OkoFyiqJ6tjAk7ZDCDtM4X7u/lr qXqUMcrxBJJHjALCNd2hAa/HhrTJcguUVSXquMxUhX5bkKJdvc3H9W9dS9RijmeAJJJJHbcqLu0I 3XpkuQW6KoNl83KwTA55M3N3Dw7V7fIa9PVsa5O2Qwg7TOF+7v5amS5BeoqimcfjponDCFFBDW7o tclifAbaV7H1SB2QFJESQ2jlZbIx7LGrkuQXaKjmmjgiaWU7UUXJqCHqMMsixMkkTOLx8xdobyca StgW6KrDOgOH8b3uVx4d7Q7eFct1GETnHCSPINt9q3ADAEE+LWmS5BboqHIyY8ZAzgsWIVFUXZmP YBVPM6huwsgw74Z4tl1cbWG5hr20dkgMqKqQ9RhllWLZJGZATGXXaHA17v0VwerYwJO2Qwg7TOF+ 7v5aZLkF6iqcnUoUmaBUkkkW1xGu7RgCD9dHTsqTJiZpFYMGOpFha5sB5La0yUwC5RSuXLc58gcz JDjru2oAAdtyS3iNtKnHVccxmXbIEFgpK+mW7E8NTJAu0VTTqULcwOkkTxoZCki7WKgXJFc/N8bu krIEcdxyndYjsHjq5V5Beoqvj5keQzIFeORLFkkG1rHgasVU52AUUUUAUUUUAVnsn+Ym/bb941oa zea+2ac3/Xf9414f9h9NP6mev4f1W+wpvulkOw95LbfKNakiIaUkaDaNPAddKjhOxS5BIY3J7akx SrAyD9Yn6tBXt6Ov2+qtOFr9viePtvn2Wty9PsJpW2pesp1Ql89+JsFGvkrSZcgFkuNePkrL5EnO yJJeAY92/gGgrtU5M9gyJMdiyWIbRlOoNSPlQsbrDskbQkG418FV9eAr1UJIUC7EgDyk0t11blo1 XsvVQnoOOjtBEgQHXsJ415113ZAIiA6gugPAuuovTTpvRsSOFebGJJm1dzfj/V8FHUOi7wfhipDf qycV/ZavBf4mPd7lG3/6s9nX8iaYXheYnwHTNVZkG1lHfhY22sO0dtLPzDmKgWCMkzKyu0g0UEcN tqdJ+XcmO8nLBBFhsa9qUfmLpk2PinKnATvKETiTfw+CulKvL6XoW9l7elq/cCfmp48ARRQbclhZ pG1X9oL4aVBwzF3JZ2NyxPE1VViT3uI1+mpv1h2V66UrXY8fZe1vqZpeh5yi0Z01sK0QNxcV8+gn aOS4PA8a2fS8wZECte5tXyv9h8dVsuyu1t/Jnv8AhdzssLb12+wvUV7c0XNfOPaeU86d/Jx/2v3j SS5p307+Tj/tfvGvZ/r/AO7b/wCb/ijy/M/tr+tfwZaooor6p4AooooAooooAooooAooooAqtnru xHHK54Nrxg2JF+It2irNFGpUASqMgiZIDPJjtC4ImU3DFTtVCdTVjDhkXLgZkYKuGiEkEAOCO75a ZUVlU8wKlhlHTsxOW295JCq2N2BIsQO2vGm+H6jEzRs//aqrBRdl73G1Nqi+Hj+J+J15mzl+Lbfd Ux2gCxoZ5HXI5TqJcuNwhHeVEBG5h2V7lQP8d8Kn+DmFZJB4OX6fn0pvVeLEjjnfI3M8j6Xc32qT favgFMP4g6y4mlxZYk9J0IXy2qkmTLLFFipjuJNEkLqQqACxYH9FM6K01PiBOskq4B6eceTn7TH6 Pc1PpbuFqnw4JIsjLDKbbIVVrGzbUsdv00xoqKu2uwFAglHSMePltvDqWTabjvk6iu1yRj9SzLxP IG5esa7iCE0B8tNKijx445pZ1vvm2778O4LC1THaHt/ICyLFn5uKzIy72yHbS/L5i90E9lQJAyY/ wrpkmYHbylYiFrnjexFqf0UwQkVSwSc6fHCt99AqRvYlboDoWqukIkWGDZlGQFQ6OxEabeJvYiw7 Ke0UwBU6lDJLikRDc6srhfW2m9qgeV86fHEcMiLE/MkeRdtrD0fLTKiq6ywIyZk6W3T+RKZ1uDZS Vtv3XvV7Djdc3LdlIVhDtYiwNk1savUUVYjXYFPqShoU3RNKgcFjGSHT+stuNL5Uy5MTKjTnSwWT lc1TzC25b27SLU8oo6z4go50LyZOLsU7QXDMBot1sL1VWSVcA9POPJz9pj9Huan0t3C1OKKOurc7 goYEEkWXk71NtsKq9tG2pY2NddMLLFJC6MjxuxO4EAhmJFj21dooqxH3/iBbPFKcjNIRiHx9qkA9 5rHQeOvJYpUxMGVY2Y4+xpIwO9bbY6eEUzopjuBTkGTNdpYonVIoJVu6lS7Otgqjtrt4ZDj9OXlm 8bRlxY92y67vBrTOimO+u4KSK69RnlKNs5S2IGhI7B46tQyc2NZNrJu/VcWYeUV3RVSgBRRRVAUU UUAVic6afJ6hlWIGLBI6/wBZpAxHmFbasAep4S5ufiSuIZRlZA72it965B3cKLrraydlLpqv+SO9 q1aTjLRl9Wugcdo1Hjr3DcCFb6eKuYlVkshDIfBYjXyVHizKByna0iErt/W0PGuhzWpNkMPSt4vP WZkiMcjxnijFT9FaSR42YgnaqauzaAD6azORlRSZuQQ4KGQ8thwI8tWrnYWTWjUHosNat9Kh52fE DqFO8+Rf+ZqmaY/l5j80CWujROH8Vytq0RbmuiWxA8On9NdSeCiLTaD+qeNTFA41rm3qdCBNVt2W NZ383wtN013tcrtcjxA/ZWlMDcAdO2kv5qzIcPpciFd7zfdIp7Sw/oFVNNkbPnUKk949utSE616q i1l1A8FcMe9bsGpra0RndnSgitH+WcpPi4+nSrdcjWOUekjgX8xrN2UitF+WMDJhnXPZdojB5Qb+ sOPmrHa6YNXhp+BrrVnZYaNGrmxp8e5/xIx+sOI8oqNWDC4NTjqrow5qqU/Wtx+iqM2TAcrfj7hG +jKwKgN4vEa+R8j4tMXfqe29f+D6PT33lU7FvtYsU86d/JR/2v3jSMG4vTzp38lH/a/eNZ/1/wDd t/8AN/xRr5n9tf1r+DLVFFFfVPnhRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRR QBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBRRRQBXyDrCn5z1 DW3/AHU5/wDutX1+vkPWnHzjqFyBbKnH/wBxq317sxfYqrJNCLxuyfskj9FX+j5s/wA2jWaRnEql O8b6jvCl1wwA7K6id4p4pU0Mbqfr7a1es1a8iddosn5jf8z7g0ZuQjEhl7G4EXpKpsbcQda1fVcF cyNd5IIsysOw2rNv0/Kiy+Sq7wQShHosPDfsrl0dlccW4dTt39dnbJKU4/eT47hoxr6OlPPyvDvm nyjwUiJfo7x/TSPH6fmxyNGygaA8b8a1n5dxGx+nxhzqWYlvCWYmuqvV6JzpJxwstWo1j7xtkZC4 2LLkNwjUsfoq6jKyhlNwwuPIaXdTxfjOmZOMmryRsFBNrta6/WK86POxgGNLcTQ6WPEr/wAuFZal BsYM9i3gsKyPVbdQ62IpV3QQReidQXkP9AFajJOyMkVncVVkyp8gcL2ue3aLVz7Xj16b20OnTXLs XC1EfXekYXT4DPE7KzEKsZ1Fzx140ijilmkWOMFnc6AdtXuvdS+OzSEN4YrqngOurfTVzp3TDivH LL/jNZth/VVv6aK7p1p2c2e0mnRX7GqqKreBv0z8uY+PDHlPtl3AXZiDtb1beEUyyMrGx4+8wRQO PCiaFMnAdDdHtuUg27w4VmpVMq7ZLtfhuN9a5Rm5n7ZOjt7ekfY1/MZR9ZwWm3MkkkaG4VF9P6WI 0qeTqGR1GZAmPyIUNwSe8QPJoKOmY0DQKdov20ySJE9EWrxdvy2lbrrWJ0fJ6afHTau3PiuD1AQo Bp707+Sj/tfvGkdPOnfyUf8Aa/eNZ/1/9639D/ih8z+2v61/BlqiiivqngCiiigCivCQBc6AcTUQ leTWFbr67aA+QcTQE1FRbcn109g+/Xm3K/ET2D79ATUVDtyvxE9g+/RtyvxE9g+/QE1FQ7cr8RPY Pv0bcr8RPYPv0BNRUO3K/ET2D79G3K/ET2D79ATUVDtyvxE9g+/RtyvxE9g+/QE1FQ7cr8RPYPv0 bcr8RPYPv0BNRUO3K/ET2D79G3K/ET2D79ATUVDtyvxE9g+/RtyvxE9g+/QE1FQ7cr8RPYPv0bcr 8RPYPv0BNRUO3K/ET2D79G3K/ET2D79ATUVDtyvxE9g+/RtyvxE9g+/QE1FQ7cr8RPYPv0bcr8RP YPv0BNRUO3K/ET2D79G3K/ET2D79ATUVDtyvxE9g+/RtyvxE9g+/QE1FQ7cr8RPYPv0bcr8RPYPv 0BNRUO3K/ET2D79G3K/ET2D79ATUVDtyvxE9g+/RtyvxE9g+/QE1FQ7cr8RPYPv0bcr8RPYPv0BN RUO3K/ET2D79e2yR+sjeLaV+vc1AS0VEJrMElXYx0XtVvI1S0AUV5UXPZyRAu+xsXJ2oCPHrf6KA mrGZv/x2MvOycw9Q2HJmkm2cm+3mMW235ova/GtZtyz/ANSMeLYx/wDyCjbmfix/5bf6tX7wYw// ABmLgr1LafFB/wDursf/ABwQLHqV/D9x/wDtrYbcz8WP/Lb/AFaNuZ+LH/lt/q1cnyTFcClPy2yw pE+VvZFCluXa9hxtvqMflRFJK5ABOp+74n26dbcz8WP/AC2/1aNuZ+LH/lt/q1z9un7SdPdvz/AU j8sDeWORe4A/w/Bf+v46tr0hURY0l2ogAA2/86t7cz8WP/Lb/Vo25n4sf+W3+rW6+nbwMNty34kR wXGiy7R2Db+nvVXHRn5vOM4EnYyJt/vmru3M/Fj/AMtv9Wjbmfix/wCW3+rVl8khcFXJ6ZLPEU54 RiLbtl/q31Qb8rt8J8NFl8u/pvy7kjt/XFOduZ+LH/lt/q0bcz8WP/Lb/VrNkrROsbFq3WY0ncy0 P/x7jRZAnOUH26qnKst+wkcyrEf5OmE8k8vUOYz8BybBdLafeVoduZ+LH/lt/q0bcz8WP/Lb/VqO qe+pa3tXbQXL0FwLfE6fw+z26Xn8l3JtmWF7gcrgPB/iVoduZ+LH/lt/q0bcz8WP/Lb/AFaKlVsL Xtb6tYFOH+WvhV2/E77/ANS396rXyb/3v/L/AOqrm3M/Fj/y2/1aNuZ+LH/lt/q1xt8Tos3Z1lvz Z0XyO2qSVtF5Ip/Jv/e/8v8A6qvY0PIhWK+7bfW1uJvXO3M/Fj/y2/1aNuZ+LH/lt/q1rr+P1dby osW1G7ZL93ZdRZyt9kT0VDuyU1dVkXtKd1vZa/6a7jkSRd6G48xB8BFdTmd0UUUBC45sgi/USzOP Cf1V/poyMmPHTc/boqjiTRBrJOf69vMq0r6m5bKZTwQAD6Rf+ms2cKQSN1ee/dRQOwG5P6RXnzbJ 9VPMfeqjRXPK3JS982yfVTzH3qPm2T6qeY+9VGiplbkF75tk+qnmPvUfNsn1U8x96qNFMrcgvfNs n1U8x96j5tk+qnmPvVRoplbkF75tk+qnmPvUfNsn1U8x96qNFMrcgvfNsn1U8x96j5tk+qnmPvVR oplbkF75tk+qnmPvUfNsn1U8x96qNFMrcgvfNsn1U8x96j5tk+qnmPvV5g8zkZHKNpO5tNwO09pr trfMohazDaHIFgWtqRWptCc7g5+bZPqp5j71HzbJ9VPMfer3IOT8VEJiCnM+7tbhceCpZEAnyJF4 PDID+0pCmnq5YIfm2T6qeY+9R82yfVTzH3qkx/ifgU+HIDbze9uH9qucP4g4chx/8Tf4vAL+lpT1 aavaQc/Nsn1U8x96j5tk+qnmPvVzFvOPml/Tuu7y7jfhUkeVOMFnDd5GCqbDQW8lJfL2kHPzbJ9V PMfeo+bZPqp5j71e47SDEBxbc1STKLAsR2WvVCo3ZRqC982yfVTzH3qPm2T6qeY+9VGiplbkF75t k+qnmPvUfNsn1U8x96qNFMrcgvfNsn1U8x96j5tk+qnmPvVRoplbkF75tk+qnmPvUfNsn1U8x96q NFMrcgvfNsn1U8x96j5tk+qnmPvVRoplbkF75tk+qnmPvUfNsn1U8x96qNFMrcgvfNsn1U8x96u4 urvu+9QbfCuhHnpdRVytyDQ/dzxad6NxXkLMQUc3eM7SfD2g/SKp9IcmORDwUgj6f/CrQNstx4UQ /W9dU5SZAnu7LACQHuXI0IRbX897V7PPDiQ8yTuxroAPqAFcob5kv9WNLfSX+ylP5gkYzxRfqqm6 3jYkf3a6VrlZIzZwpCT8wTlvuokVezddj9RWuPn+b6kXmb36WUV39unByytyM/n+b6kXmb36Pn+b 6kXmb36WVf6MCc2w47G/RUdaJN4rQqtZuJJPn+b6kXmb36Pn+b6kXst79E2PLjdIZJQAxnDCxB02 27PJVkPy86Pplh8KU2Olh3mKlt1/DWfR4VT3/Avq8X+zK3z/ADfUi8ze/R8/zfUi8ze/XeBGPgsm E2LSMY1P9ZEZx+iuZlCdGRP1gVkb/wCoWt9VX0TGPjA9UTPgefP8z1IvM3v0fP8AN9SLzN79TZBz R06HkMBByPvR3bkW1468PBVHpX/9CDyn900Sq03itJE2lKXqWPn+b6kXmb36Pn+b6kXst79QYkKz 9SWJxdS7Ejwhbtb6qsNO+bi5YlseQVeHQDaLkFdPFRqqf0rwn7wnbk8+f5vqReZvfo+f5vqReZvf rvDQfLmht3spZWXyxgW+uuelokmJkxOQBKUQE9jG+3/zWp6NfTs4Hq013PPn+b6kXmb36Pn+b6kX mb368lEanAGQLRhbSA+Jtb1z1U5e4LKQ2OSWgKAbdvZYjxeGiVW0sVqJtyzv5/m+pF5m9+j5/m+p F5m9+llFa9uvCM5W5Gfz/N9SLzN79ejr+ZfVI7eRvepXRT26cIZW5NLgdVizDyyOXNx23uD5DViU cqRZ14MQko7DfRW8oP1VlYpGilSVfSQhh9FarM/lJj2iNiPKBeuPZRVajZnStpWvgTXorm/7t6K5 mziD05/4n9xKXdVhZZud+q4AJ8Y/5Uxg9Of+J/cSpHRXUq4DKeINSylQDOUU4bpWMTcFl8QP2g15 8px/Wfzj7K54WLIoopv8px/Wfzj7KPlOP6z+cfZUwsJFFFN/lOP6z+cfZR8px/Wfzj7KYWEiiim/ ynH9Z/OPso+U4/rP5x9lMLCRRRTf5Tj+s/nH2UfKcf1n84+ymFhIoopv8px/Wfzj7KPlOP6z+cfZ TCwkUUU3+U4/rP5x9lHynH9Z/OPsphYSUcZ4hDPFI+wybdpIJ4E+CpDkw/EwEEmOEBS5Gpt4qtfK cf1n84+yj5Tj+s/nH2VrG3kClJ8Os6ypLvBk3MNpFhe/bUgy4v8AulY919xiNjxYW+urPynH9Z/O Pso+U4/rP5x9lMbcIFNGx5MRYZJeWysW9Et+iuBJGMOSLddy4Kix1A7av/Kcf1n84+yj5Tj+s/nH 2UxtwuAUIJUTGyEY2Zwu0eGxN6FljGE8RPfLggeK1X/lOP6z+cfZR8px/Wfzj7KmNv5ApYrY8RWd pSHW94wp1/tcKrO252a1txJt5abfKcf1n84+yj5Tj+s/nH2UwttoBRRTf5Tj+s/nH2UfKcf1n84+ yphYSKKKb/Kcf1n84+yj5Tj+s/nH2UwsJFFFN/lOP6z+cfZR8px/Wfzj7KYWEiiim/ynH9Z/OPso +U4/rP5x9lMLCRRRTf5Tj+s/nH2UfKcf1n84+ymFhIoopv8AKcf1n84+yj5Tj+s/nH2UwsJFFFN/ lOP6z+cfZXcXTcaNg1i5HDcbjzC1XBiTjpcLRwmRtDIQQPEOFTj+bb+Gn6XqaoR/Nt/DT9L10ShQ Q8i/nJv2I/0yUt6/jMdmUouANj+LW6/pplF/OTfsR/pkqcgMCrAEHQg6git1tjZMjUqDGUVo5Oh4 Ltcb479inT/zA1x/t/D/ABJfOvu1392vmcvbsZ+rfTZ4oMnfK21drC9idSPEDTX/AG/h/iS+dfdo /wBv4f4kvnX3aj7KNRrqVUsnIpWaIdMbHLfembftsfR2gXvwq4uZhmZOoNIROiWMG0957Fb7vBVr /b+H+JL5192j/b+H+JL5192o70fi/wDyXG3kLsfMSGCK7XkXJ5rixvs27Tr569ny4JIstFNgxiEC 2Oqp3fo08NMP9v4f4kvnX3aP9v4f4kvnX3aZ9czqMbbFCdsKfGgvkbJYYguzls12A4buFV+nyxw5 kUsp2opJY2J7COym/wDt/D/El86+7R/t/D/El86+7TOkNS9SY2mYQt5mNi5ceTBNz++Sy7GSwP7X HQ11NLiQ486Y0pkbJYG20rsQEm2vmph/t/D/ABJfOvu0f7fw/wASXzr7tM6csuNuEVI+oxQy4saM DBGgErbdQxvvtcX81VkmhixcmJH7zOhhNjqEa9+GlNP9v4f4kvnX3aP9v4f4kvnX3aZdfmMbeQvz snGy5Mchti7fvbAnazHc3gvrXOTNjphphwSGez8wyFSoGltqg0y/2/h/iS+dfdo/2/h/iS+dfdor 0UavQY210Wpn6K0H+38P8SXzr7tH+38P8SXzr7ta92hnCxn6K0H+38P8SXzr7tA6Bhg+nIfFdfdp 7tBhYTYeM2TkJEouCbufAo4mtNmfyc/8N/3TXuPiwYy7IUCg8TxJ8pNeZn8nP/Df901yvfKy4R0r WEde5RR7lFczR5B6c/8AE/uJU1QwenP/ABP7iVNQBRVHrTZadLyWwgWyAt0A4nUbrePbesh+UMnq eR1wuAwxirDJBvtBA7vi3brfRQGzl6liQ5K4sjOJn0VRHIQeHBlUr2666V2mXjvjNlK94E3lnsdO WSH0tfQqarZX/wDYwP4eR/8AipLHJNj4m+KaRebB1Aldx2q0TkoyjsOvGgNQjrIiuhurAMp8IOor qk/T8h/mRieX4jmRB1KyFuTZYwUkivtBJ1DcaqyZmQsc8ay80LkqJskTMsfKfe23eu7lbbBW2/00 BoqjeeKOWOJ2tJMSI1112jcfqpJiR5WRkiCXLZguIGVoZWKFmkmRH390sQtte061FhZWdLLiztI5 aR3j5RY7WMOMd114ay7qA0lRyTxRyRRO1nmJWMWOpUFzw8QrPNkyNh4mzJN5Q3xksmQ8QjyAgsjO A2zUnu6A2q/kGQTdJM0i80czmSrqu74d7sL20vrQDKeaPHheeZtscYLO1ibAcdBrVP550vkLkc48 pnEanlyXLEbgAuy50qiJml/LuYGYyNEskbTbzIspVf8AERmPA3+g3FVJ48lemdFDTBnefHMLbABG pRdikA97ae2+tAOH690mOKOVsjuSlghCOxultwIVSRbcONSDq/TzlDDEp+IO3ubH/WAZe9ttwPhr KrKIWwnacY06ZOWMjIZd4Eto7ts00IsKZ42Sq/mbKHxIjE3JtGUuZvultY/q2vQGjZlUbmIAHEnQ VxFPFMZBG24wuY5NCLMAGtr4iKW9ZkhyujtPGxaLfE4dSy91ZVDNpbS1z9dU8Y8rLEsEzlH6hybB yyPG2OGubk7joNTQGiorLfEdQbFllbJEcp5azRrMzSxynIQX5bKBGNpIsNDVyB8odW5BnCiGQKsU szb5IBFxWIqQx3d7fuvpagHKTxSSyRI15IbCRbHTcNw+qpKQZ+RKj9QYzlUhmiKxcxozIvJDNFGy m6sx1FuJ8tcfmHIyFyMZYZpYFeDJkYIxQ3jjMi3t4xQGiorI53UOpmLDZJZFd8SN4OXf77ILorhg BZu5c2NMPzJk5cIxgkjwxMspd4iQecsZMKEjsLdnbQDePLx5ciXFR7zwbTKliNu8bl1IsdPBUQ6t 08vy+d3+cca21h96P1eH18Kys+RlJPly82WLqDph7EjuOZKY03K4C+C+lWI5ZEnOxyhbrO19pIuC dR5KA11csyopZyFUalibAVkcTqGUcyB5p53lJyjlYoY2UpGxREXh2aVE2RkZnTepIZJJI0XHmjRp GlK7iC4LELe3aLWBFAa9cvHbJOIrg5CoJCmvoE2vfhU1ZLKy8mKWU9OmklUYCtGSzOdZlDP3u0An WvDlZTMkUGVO2E+bDFBkF23ujqRINzcQDQGuopX+W8ibJ6RDJO5kkuwLsbsQGIFz200oAooooAoo ooAooooAooooAqAfzbfw0/S9T1AP5tv4afpegPIv5yb9iP8ATJViq8X85N+xH+mSrFVg84anhXEe RBKSIpEkK+kFYNby2qr1mHKn6ZkRYZ/7gqNnZexBK6+EaVlPyt03rY638ZlRSQRIrLKXUoHutgoB 4663qqqdW528CNuUoNjlZ2NiFBOxUybtoCs+ii7HuKbACpo5ElRZIyGRwGVhwIOoIpX1hMh8vDGM wWXbkbWK7hfl+UVRjednxY4ZPhoRBjHF3u4HpfeKQq7XY22m9VVlJknUdHqWGJeVzDvMghHdbbzC Cdm7btvp4atVn8aNoBEIi6hupyq/eY3Qc617nhUEE2RBBHMTNOZcadpY+ZJqUkVUtY9yyk6rrTDg ZGnorOY5nm5UDyyGI5roCjyC8Rg32D7t23cdNakwpZJPgBmSyCLluUO5l3zLJtVXYce7wBOtMPMZ D+q652K2QcVXvMLi1jYlRdgGttJAOovS3ojZck7SZEwL7GE8JZywlD+lscAILXGnEWqjHLPDnmbQ STTupiINsUtIqNIddRJGPS8J00JoqatSMth9k9Rw8RxHO5Ripf0WYBAbFmKqQBc9tWQQQCDcHgaU 9QxZMrqiwK/LSXDlSVtu47GeMELqAD49fJVcySxdQGKGkFsyMqvetyPh7ceG3d9dMU1pvEiR/UUW RFMZBG24wuY5NCLOAGtr4iKRQBxh4b5M0wgyJH+KkLuLbdyxruXVV08Xjr1RJDmNkRmS56gUZVZt rxmAE9y+03IGtMN9RkaGis1jTTTQ5gE5xkeGGRS7ysInZmDIXkO65sFYi3nrqSbLnfH2scRWijaD fJIBzOYd44HfcADvfqmmHmMjR0UUVg0FFFFAFQZn8nP/AA3/AHTU9QZn8nP/AA3/AHTRbg69yij3 KKA8g9Of+J/cSpqhg9Of+J/cSpqA8r2qPWcqbD6ZkZMClpI1uAOPEAn6BrWW/K/XupZ3WuS7vJjS IxdXO7YVFwwPZrpQGzlyMeFkWaVI2kNow7BSx8C3413SLqhi5vVPiCLjDT4fd/8AU9H+3t+qu4s/ M3JG8mvxwx2BC35fI3leHrdvGgHVFJopsyb8tzZU85aaSB5AyhU27VOgsO22v1W0rhMrqQnixsZn mEUcEjX5QDrIx37ydhsFFl2DjxoB00kaFQ7BS52oCQNzcbDwnSuqQPLk5mN0/Jacq8+WNqhV2w2W ZbLpcnw7ida4PUepPjhlyNjxY2TM7BEO9seXli4I03DjagNESACWIAGpJ4V4jo6K6EMjAMrA3BB1 BBFIpOo5chYlxsaQ45xwBbacfnc29t3H6LeeuIM/KixsdY32pBBhWisDzviDsbiN2g4bfroDQ0Vn n6h1STvQz2eQZbLAETuHGYKqXIJO4cb+GmOHl5GRgZGYrKd7Sti77KoRLqm4i2hK3uaAYUEAgg8D WTHXepyCOCORviArmQ7IrmZD/h6lV2DwjWxq1k9ay48zFRHIZjjrlQFU2KZ13EBrlyfJoKA0McaR IscYCogCqo4ADQCuVmheR4ldWljtzEBBZb6jcOIvWcbq3VVgycg5CiNcs4aFo1tEN1+ax7bDSq+R k5mFl9Sy4MkO0QxS77FPODKo7NFGvZQGur2s6nV+pS9WaGPWGPJ5DxbUCiK+0yFi2/d2jS1TYHVM s4fUJZ25uViAvywF5QFmZNjJqwIHbrQDuisqOsdUETMuQJgkEOVIyonc3sBJCbDwNfw6VJP1fqiY uMyPeTMed0fbHokf+FGL2Wx7Tx8FAaaikvTszqWX1WWOWURwQRwu8GxT3pYgSofjoxv21XVI4PzI HAiyZckyMjIx5kBjTZZwDtseGv8ARQGirx3REZ3YKigszMbAAcSSaw+PkZS42RJC7GWXEZ8o3JPM +JKFm10YR/VTPD2Jg9bhxzfCjiPJsxYBmhYyAEk9tAN8bpuN8SOoCeTKYg8lncOiK+p5e0AWq/WV +adQxocDFwxwxY5dtlPMJbaVJciwAHZrfxVMvVepjNuZwYPmJw+TsX0CbDvAX0H/ADNAaFpoUkSJ nVZZL8tCQGbbqdo4m1d1jk6plTZuJ1CZ1lljXLdcZQFMWyNrIba627alPW+rrgy5IkJXlxyLIyRj a5kVWRQpa62P62vkoDW0Umx8nqEPV48LMn5iOhMRREAkZRuffxZdt9PFTmgCiiigCiiigCiiigCi iigCoB/Nt/DT9L1PUA/m2/hp+l6A8i/nJv2I/wBMlWKrxfzk37Ef6ZKsVWAoqj1lspOl5D4YLTqt 1A1JFxut/ZvWQ/KWT1PJ66Xsy421xkr3tgIGnHTdutVVZq3OxHaGlG5umkjV1RmAd77FJALW1Nh2 2ojkjlRZImV421VlIKkeIil3Uud8x6fyNol++2l7lfRF77deFK4c3Kx+l4whk5QiwzOmgPMkV1UI d3Zr2eGqqSl5kdoZp6KRS5Oc+YyLkvEhy1x9ihDtR4OYdWQ6hhpUfzHqUuPiJG5E0sMzh/u13yRM EUNzLC2t226/RTB8oZD2fJxsYBsiVIQxspkYICfFuIqQEMAykFTqCNQRSnqrSjI6Y140l3yX5msY PJa97EVDNn5I6iI1yAirkwQjHAWzROgcvr3tTp4LVMZS+yS5Dt3SNGkkYIiglmY2AA4kk16CrKGU gqRcEagis43UciXGdHlDt8NnNIhCtrE+2PctvV8PGpoxkPkZwgnaOf4SBoEG227bJay7eAI7PDVw 5ZMh4zKil2IVVFyx0AA7TXPPhvGOYt5f8LvDv6bu74dNdKWQZMuZ0nNy3J5cyyclexUVNunlYGuB MNvSBGVY7WDaKxUjHY8dSuoqYlkc0VnYupdQixTKZjM8mEuQC6rZHLBCw2qNADfWr0eTnxdNzJ37 7xB3xixRmKhAw38rTQ/VR0a8VwMhlJLHEhkldY411Z2IVR5Sa8fIgji50kiJEQCJGYBbHgdx0pBP LPOghfIaWOPKxAkw23PM2MwO1dvdOo07aYZxjXqeD8SRyAsu0vbbzrLtvfS+3damO33kkZAhgGU3 B1BHAivGZUUsxCqouzHQADtNJZ8zMT4+aOY8uGWOGJFCWRZBDd7sOzdpfTw1Dl5WcIBBlT8mN0ym DkxlpVQLy42Iut7Mb210qqj5QyHyTwyNtSRWbaH2qwJ2t6LadhqSsxks3wc4BCBcLEbcAobVmBu1 r2rSRgCNQHMgsLObEt49LCpasFTk7qDM/k5/4b/ump6gzP5Of+G/7prK3Kde5RR7lFAeQenP/E/u JU1QwenP/E/uJU1AeEAix1B4iooMPExixxoI4S+rmNFTcfHtAqHq2aen9OnzAu4xKCB5SFv9F71n Py/+aszqHWBhy/eQSqxVtoUoVUt2dmlte2gNXJjwSsjyxI7xm8bMoYqfCpPCuTiYpm55hjM1weaV G+4Fh3rXpP1uNjmCJNDnwfD3B8Esd/MjtUOJ1GVUOTGv32Y8cQJR5NohgV27kfePeJGnloDQpFEk YiRFWICwQABbeC3Co/gcIcu2PF9zrF3F7hvfuaaa+Cqkufl/C4LpGIZ8uRY5ElVjyyyOx7t1OhWq +L1jJlRGnMMSzYxyEfaxCFWVLMN/evu7LeCgGgxMUOZBDGHLby20XLgEbr246nWj4TFAIEMdirIR tHoudzrw4MeNKouo5uTLg7XWPdPPFMOWwD8pXsdrMGXQcDwPktXE+TlZkOBlDlqJcpTAhDdwBJh9 4d3e8gA8FAOPhcXmc3kx8zbs37Ru28Nt7cKPhMXdG3Jj3QjbEdougHYumn0VRXqWSemw5pVAecI8 gWJUIJTC7LrceHtquetZggWbZGAsAypQQ3ejeQqip3tDsF76+SgLT9Jd8qTJ5qRSMrrG0UQVhzCL s7Fm3ttW39FXIsaGLGXFVQYVQR7G1BW22x8N6ow9TyJMiGIqm2TJyIGsDfbCHKka8e7rS2XqU+F1 LOGNHGXkysaIly+vMSTj3tPR7BQD5sDBeJYWx4miTVIyilVv4FtYV62Fhu4keCNnW21iikjb6Njb spKOvZwhVpEiTZkvj5GRtdok2Bdp2htw3FrXJrpOoZ0Wd1VpZ4lx8XZtEgbam++y23X9rwnhQDoY uMEeMQoI5SWkQKNrseJYW1Jrj5fgbWT4aLa4UOvLWzBPRvprbspKvX894I9scQyGzPhG3K6rrwO0 ncuvG9cJ1bqWa/SZImSL4kzCRLMUZotDfW9rcB4eNAP2xMVphkNDG06+jKVBceRrXr2HHx4EKQRJ EhNyqKFBPkFZvDz5unwZEyBTA3UZUnLAkqGVdrAg+HjV+bq2djYODmTpGFnBOQArd26mRNvf00Gt /qoBomJiRo8aQRrHLfmIqKFe/HcANaHxMWSJYJIY3hS22NlBQW4WUi1ZrL6xl5nS8sTRR7Yok5y2 dfvWn5drh722rf8A4tUfVp86ROqwNIpxoVxrR2buhijLt14+tegNWkEEbtJHGiO4AdlUAsFFlBI8 AryPGxo5GljiRJZPTdVAZr66kC5pf0zqGTNJmY06Rq+GIypjvYq6lgDu8FqX4/5jzpYt7JED8HJk 6Brb45XjA9PhZaA0K48CGQpGimU3lIUDef63hrxMbGSIwJEiwsCGjVQEIbjdRprSzpXVcvKyvh8p Ixvx0yY2i3aK+3utu7dao4nVuqRxSmRo5pJc34SIsG2o5trofQ8A4+OgH7YeG6xq0EbLF/hKUUhL cNotpR8Hh3vyI77+bfYt+Z6/D0vHS+LrTDpWVm5CKJcR3iYLcKzqQFte+hLCq3ROpMvTuoTzzHLf GkkkBJJ3RhQV234KxU2oB0MTEWXniCMTXLcwIN12FmO619RXHy7p9nX4WG0lt45a2axuN2mtKJuu dRixseQxw83KSXIQDdtWGKPm7Tr6Z81RTfmTPCzzRRQ8iBMeQq27fadFYjQ2Op4/poDQDHx1madY kEzCzShRvIHYW41LWePXeo8sII4Rk/GnCN95j8TDW/Goz+Z8qSDHMUSCaSJppAVkcNtdo9qCO5Fy vE6CgNLRWayuoZ8uXPYquOenNkfDuG0BUXB2lTv3dvg8dRfPMzBxYY8eKIxRYkU7Bt9+86xkKdx9 YW/4FAaqikGX17LjzzBBHHyElghcvuL7pwz3XaQLALUfUM0YHXMnL27zHgiy8LlpkUfWaA0dFZwd f6iQkYiiMrzxQrIUlSNhMG4B7MNrLY1HlddycrpMKrGglzYsnmk32hIUbds8ZHC9AaeisynW5sHF wcaCES2xo5pBZmZlJ2bU2cCONzp2catL1fqjr1GWOCORMN5Io1XdvZlYBSRfgFuTbj2UA8qAfzbf w0/S9c9Pyfi8OLI3K/MF9yAhTrbQNqK6H8238NP0vQHkX85N+xH+mSrFV4v5yb9iP9MlWKrAV5VP rOVNh9MyMmBd0kaggeK4DH6BrWV/LPXup53WxCzPJiyKxdXO7l2FwwP7WlVUbTfBHaGlybUojMrl QWW+1iNRfjY1z8PBZF5abYzeMbRZT/V8FL+pwwz9R6fHOgeM8+4YXGiDX6Ko43Vc5MPGihjM0iwC Uko0jSLvKKt1Isdq3ufFRVbSaYkfcmHdu2Lu3b72F9wG3d5bV42NjNGImiRo11CFQVH0Unw8jKhz JIkKcnJzJ47bSXVwnMD3uAR3eH111Dk5q/lhstpDJkGBnV/1hpxJ1uRxq4vngkrgbywQTALNGsgG oDqGA89Q5HT4JmhYKEaF0cMoFyI+CX8FVWVMBcbF6cqRtlsRzWBcd2Nn3tYjcW2+GqcnXM5ofiIV jVExI8p0dWJJZ2VlUhhYd3jrRVfgw2vEd/DY92blJd7hztF23elfy2ryXHV1bl2imKFEmVRuQHwX FLcjqmVBJlo4VZI9vw0RU2ZHZIxLv3agFu8LCoXyJZ8vFWcKXgyMiEsoKq4EDMDa5to1jrxoqvkS hzBjQwY64yLeJF2WbW4/reG/bXiYmLHblwoljcbVA1It2DwVnZsmaTpKY0apFBHiwSutmJJkewCE toBt7b00HUpn6iMWNlaJzLGH2EbJIxewJfv24NoKOr55EoYLBCttsaiy7BZQO76vkr2OKKFdkSLG vHaoCi/kFZ7Gy5kg6fmZFsiUY2TMrHcH7ixnb6VjfyVZ+a56jltyzNzMZQ4UhLZWlrbie6fHwo6P kZIbjHgVQixqEB3BQoADA3vbw17JFFKuyVFkT1WAYeY1W6bkzZEDmfaZYpZIWZAVVuWxXdtJNr+W rlZcpmjgQxAMoRQH9MWFm0tr4dK5+Fxtix8lNim6rtFgfCBapaKkgj5EFiOWtmUIRtGqjgvkrpVV FCqAqqLKo0AA7BXVFAFQZn8nP/Df901PUGZ/Jz/w3/dNFuDr3KKPcooDyD05/wCJ/cSpqhg9Of8A if3EqagOJI0ljaORQ6OLMp1BB7DVPA6J0rp0jS4WOsUj6M92Y2PYC5Nh5Km6jmx4GFLlyarEL28Z IUfWaRdG/NvzHqgwJI1AkBMMiX4qC5DXv2CgNDLjQTSRSyJueAlojc90kbT9VQ/LMEQiBY9sauZF 2sysrniyuG3Dj2GqfUxljOighldY89RHdWI5bRNzHZfAWj3cPBXR62AsknJ+7Ec8kDbtZPhTtcMN vdueHGgL7YsDrCrgt8OweIlmJDKCoJN7nQ9tQ/KenmNYjF3Ej5Kjc2ibg9uPrKDfjVaTrThtkeNz HMsUKrvtcyxc4EnboBw+vxV7n9Q+CyWkKu+zFeUxh7J3XQejt9LvcfqoC0Om4ahAqEcuQzIwd929 r7ju3XN76340L03DQqVQgJJzUXc21X72qru2j0joBS3O6hmTRNjrFyJkyYYZQJSLrIVZdsiLcbgb HweOpG66IomkaAmIJK0Lb7lxjsI33XXu6nTjfxUBayenh8BsHF2xRyEh912skjFpNt/1tTapZenY UxjMkQPKAVBcgbQQQrAGzAEA2NUpusZEJkDYgvCITKDLqOe2xQLIQSD466k6w8eDJltFGphkkjlR 5doJiJFo2Kd4m2gsKAtL03DXIGSsZEoZpAdzWDuCrMF3bdQddK5k6T0+SZp3ivI8iTM25h34gQja N2bjVDL6lkF8pLbcaMYrRtG5SUc97eow8v8Az0s/N/v2j5X3W6WOOTdq0kC7nBW2g0Njc8OFASHo 3TSLGG6mRpipd9pkbbcsu6x9EaHSvZukdOnllmlhDSTrslN2G5Ra1wDa/dGvGuOn9TfMfZJByS0M eRHZw945L2voLHSoemdSMi4ePtNp4TLzJpLudT3VOwb2HbwsKAsJ0bpsYULDbZKMhe+5+9HBtWoH RemCGGEQ2jx2Lwjc91Ym513XqnlfmE42RkxnFLQYjxrNMHGglGh2W8NV8vrU2QyIsMkEaZq4zTRy gbmBPdttuQRqR9dAXs3osc2McTH2wwTz87KvuZm7TsJOhJUD/jW5k4OLlwDGyIw8IsQlyPR4eiRV DF64+TkfD/DhXXnc77z0OSdvqD0ifFaquT+Y5mwcx8eNEnxTGCwcTJtka25SosT2WoBq3SenvHkR NDdMtuZONzd9gd177tNfBXOR0XpmS7STQ7nkUI5DOt1Ugrfaw4WqjP8AmVcV+VkQgPGEORaVbrzO HLUgF9CCeFqtdW6uOlhGaNZEbj94FfjbuIQS3GgLcOFjQSzTRJtkyNvNa5O7YLLoT46ozdBwlx8g YUSxZEsTxKxZto366i50v4qjl/MPLz2xTjkxrNFCZg44zKWU7Nt+w1Xk6rLldbxIod8ePFNPC5D9 2ZkVSboOxb6X8NAMul9Kx+nwptjUZLRos8ikncygA23cBevW6N0xzMWgB+IYPL3mF3F7MNe6deIq OXrMcWdPium1MaLmySM1iRt3fdpbvePWqS/mqEggwXlcIYI0lVy+87QrEegw7RQDrGxoMSEQY6CO NeCjx9pJ1Ncw4eNAsyxoAuQ7SygksGd/SPevx8FLMz8wS4bSRy4g5kUCzsol7WkWLZfZ2br3om/M XJmyVfGJhxApklDj/qLeMBSAbs2n10Ba+RdK5Ig+HHKVzIq7m0ZhZrHdexA4cK6k6N02USh4BacI soDMoIiACCysLWt2Vz0vqq9QMybFSTHKhwjiVCHF1KutgeGtMKAUdQ6FFkcpcdVVGyhk5QZm79/T 28bE/RVp+j9NeOKMwhVhG2MoWRlHg3IQ311dooCnP0rAyHWSaLc6RmENuYHlsCpU7SL6E1w/ROmS LteG68pYLb3/AMNGDqvpesBV+igE2Z0RsnqUWQFijhjaN3kBfmvyhopX0LePjTCXp2FNM88sQeSS PkuSSQUvuttvbiKs0UBRTo/TkEYERtFIssd3c7XT0SLt2eDhXh6J0s48eKYAYYiWjUs11Lel3t19 fLV+igKTdJ6ewhBit8OoSIhmBCjgtw1yPLXQ6bhCOaMRkLkyc2azuCzkht1w1xqOyrdFARwQQ40K wQIEiQWVRwFcD+bb+Gn6XqeoB/Nt/DT9L0B5F/OTfsR/pkqxVaM2y5v2I/0yVPeqwekAix1B4ioo MPExixx4I4S5u5jRU3Hx7QKg6pnHA6fNlhdxiANvKQt/ovWd6D+aszP6wMOT7zHlVirbQrIVUvrt 7NLVVVtNrZEbSaRp8rBxczb8THzNl9tyR6XHgRe9EmDiyNGzRgNENsZUlCF9Xu2004VV6hkyQZ2C UEjo3N3xR6l7KLd24Bte9U8Tq8sHTcYshyHXG+Jnd372wNtNib7m+yiVoUMkqRrH0/CjyDkpConY sS/E3f0jr4a7hxceCIwxIFjYklNSO9x40vl6xkjJaGLHR154x1dpCpLvHzVJGxtPDXEn5gCY8Moi G+WOSVo2fbpEdpVDt7zMeFMbfsxKLw6XgCHkCICLdvC3butbb3Te4000rp+n4TqytENrRiAqLgcp TdUsOwXqtmZDjL6cyMwSRpSyXIDAQuwDDy1VXr+TyxK+KgQxRZBtKSeXKxj4cv0rjh4O2rFn4/iJ Q0ODiM0jNGGMw2uWJOhN7C5018FeLgYiCMLGByizIbm+6QFXYntJBPGqp6rKuaYGhHIWdcYy7+9u dBIp2beHZxqOLrOTLDE64y78gvyVMmhWIEuzHabaiwqRb9mJRbfpPTpFjV4FYRJy4+OiA3A4+EV2 uBhrkfErGBNdm3XPFxZiBe2vbVIdbLvEscN/iFgeC54rMSH3afqWrvA6ymbk8lUARldkYNuP3b7L Ou3uluI1pF48RNS1H07DiKlIgNm/aCSQBJbeLE8DavE6dhIgRYgAHWTiSd8dthuTfu20pTB1Fvmk rySvyVdgurFJkLLAixR8LpJfcw+u9WOo5kuN1bHfeRjJGeelzt7+4I1r20ZauNpifCRK4GkUEUIY RLtDs0jeNnO5j9JqSkOB1HJx+mNJOwfIEzqVmdgTpzNqd1ybcPrqaTrsgUSx44aEQwZDlnswWckW A2m5HlqOjnkuSHFFL4+pSPnfBmIBxJIrG/8A00RXWS1u3eBS3JzMtc7qUKSPtnCwYup+7lCwqdtj ofv7/R4qKrf7pDsjRUUkx+svFh425DKI8aCTJlZu996eXcXB3G4JOtSv1qSPnM8KrHHP8NG7PYNJ utc93uqF1pgxkhtUGZ/Jz/w3/dNL8XPky83FkF0jaKcSRhiU3JIiA8BfxG1X8w/9pP8Aw3/dNSIa Eyd+5RR7lFQpHG22aZT2sHHkIC/3am31XykdXEqekOI8IPEVymQri4Ovap4ioCXJhhyoJMedd8Uo KuvhBpb0r8tdL6TkNk4wkeUghWkIbYDxC2Vav8yjmUkHUsEcs0E7EhsdmZALWJdShv8AQarr0rEB kuXZHWVFjJG2NZzul2WAPePhJ8VTcyjmUkEEXSseNlfmSO6yJLuYrctHHyVvZRptrvM6fj5jM0rO C8LQHaQO67K5OoOvdqTmUcykg4fp+PJK8pZw0k0U5sRbdCFCgacO7rUL9Gw5FkRnk2SLIqpdbRCZ g8nL7vaR23qzzKOZSQcT9Px53nd2cHI5O+xGnIbeltO08ail6PiSqVLyLuaZiVK3tk/4i6qRb6/H VjmUcykghl6XjSFiZJFEixK6grZuQ2+M6qTfyV78sxee025+8ZGEdxsV5Rtd10vcjx246VLzKOZS Qc42FBjOjxliUgTGG4j0IySp0A11riHpsEQxkEkjR4YHKjYrbcAy7yQoa9m8NvFUvMo5lJAsHRfi ep5s2ZvXGkeJ4lVwFl2Kb71FzofJVr5Lh7Nm+S3xXxt7rfmWtb0fR/4vVnmUcykgiXpWGs2XN3ic 1Ssqk90BhZtthcbu2q8f5fwUhngMksi5KRxuWZbgRehtso4WFXeZRzKSCqeiYvMWYTTCUKqyPuUm ULoN+5DrbTS1ddR6RidRk5kzyI2zlNyyAGTcHAO5W/WF6scyjmUkFWToeFJO07PJueWKYgFbboFZ EHo8LNrXq9FwkzhnK8gcSNKI9wMYeQbXNtt9fLVnmUcykgim6Zi5GUcrIZ5TsZFiZvu0WRdj7bAH UeOoB0DC5BgaWZ49OXdl3RlTcFGVAbjx3q5zKOZSQU8voOHmbTNLMXEQhdw4u6ht4392xNxUrdHw n+L5hdxmiMSgkacod0rYDy1PzKOZSQeYWImErKsjy7rd6TaTZRYDuqv11Z31X5lHMpILG+jfVfmU cykgsb6N9V+ZRzKSCxvo31X5lHMpILG+jfVfmUcykgsb6N9V+ZRzKSCxvqGM7smRhwAVPpF2/vVC +RY7I+9IeA8HjNWMaLlprqTqT4SeJoCMnZmNf9dBb+wf/XUm8Vxlws4Dpo6m6mq6ZAfunuv2oeP/ ADra1IWZBHKjRyAOjizKQCCDVTB6T0rp8jS4eOsUj6FgSxsewbibDxCpd/ko3+SkMhI8Uck8OQ19 8G7Zbh3xY3qt8qwuTFB39kSco2b04yQxR9OFxUu/yUb/ACVdeRoeHBxjLzTu3c4ZHHTeqcodnC1c r07HRIlieSNoA6pIjWbbIdzKdLHXxV3v8lG/yU15GhJNBFNLFK990BYpbwupQ3+g1W+VYZj5Xf28 mPH467Im3r2cb1Lv8lG/yU15GhBD08fHT5c5YgzCSFA3c0jVNzL4RY1J8uxvh4oFZ1EO7lurWcb7 7tbW13eCu9/ko3+SmvI0D4HE52NKFKnDUpCAe6AV2a+Gw4V1j48eMW5Tvy2JIiJuiljuO3S/Hx1z v8lG/wAlNQRHpWIXRwzgRSGaFARtjdjuYqCO09nCpMnBxctnacFhIixst9NqPzB9de7/ACUb/JTX kaHD9NxXYuS4cyPLuVrayKI3UacCBXnyvE5TRXfa0UUB112QG6dnGpN/ko3+SmvI0OYMdh1DIzpF VS6rFEFNzsXVmbxtpp4q9+AxecJ2BaQTHIBJ4OyCPzWWvd/ko3+Smv8AIaEQ6VhhYk7+2JFjI3em kbb0V9NbGpGwcdo5I7sOZKZ9wNmWS4N1NvFXu/yUb/JTXkaEixBHSQyyOyKy95tG3ENdlAAuLV5l ODjuvrjZ7fdqNpVQbmIA8NeQh8iUORaNPRHhPhqebKXfcorq36LUVkp6QCLGqs2Cjm40PYRxq3RQ C74GTsd/aNHwMvrv7RpjRQC74GX139o0fAy+u/tGmNFALvgZfXf2jR8DL67+0aY0UAu+Bl9d/aNH wMvrv7RpjRQC74GX139o0fAy+u/tGmNFALvgZfXf2jR8DL67+0aY0UAu+Bl9d/aNHwMvrv7RpjRQ C74GX139o0fAy+u/tGmNFALvgZfXf2jR8DL67+0aY0UAu+Bl9d/aNHwMvrv7RpjRQC74GX139o0f Ay+u/tGmNFALvgZfXf2jR8DL67+0aY0UAu+Bl9d/aNHwMvrv7RpjRQC74GX139o0fAy+u/tGmNFA LvgZfXf2jR8DL67+0aY0UAu+Bl9d/aNHwMvrv7RpjRQC74GX139o0fAy+u/tGmNFALvgZfXf2jR8 DL67+0aY0UAu+Bl9d/aNejAcnvOxHjJphRUBXhxEiGgqevaKoPCL6Gq0+EkuttatUUAtPTn7GYD9 pvto+Xyeu3tN9tMqK16vMmgt+Xyeu3tN9tHy+T129pvtplRU9XmNBb8vk9dvab7aPl8nrt7TfbTK inq8xoLfl8nrt7TfbR8vk9dvab7aZUU9XmNBb8vk9dvab7aPl8nrt7TfbTKinq8xoLfl8nrt7Tfb R8vk9dvab7aZUU9XmNBb8vk9dvab7aPl8nrt7TfbTKinq8xoLfl8nrt7TfbR8vk9dvab7aZUU9Xm NBb8vk9dvab7aPl8nrt7TfbTKinq8xoLfl8nrt7TfbR8vk9dvab7aZUU9XmNChH05QQzanwnU/XV xECCwruijnxKFFFFQH//2Q== --%OLATTACH1-- From wo16288@126.com Sun Mar 6 17:49:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04852 for ; Sun, 6 Mar 2005 17:49:15 -0500 (EST) Message-Id: <200503062249.RAA04852@ietf.org> Received: from [218.18.5.191] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D84ao-0008Je-8w for simple-archive@ietf.org; Sun, 06 Mar 2005 17:51:27 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?tefE1Mn6sqHBy8jnus7Kx7rDo78=?= To: simple-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 7 Mar 2005 06:48:45 +0800 X-Priority: 2 X-Mailer: FoxMail 4.0 beta 2 [cn] X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 ÎÞ±êÌâÎĵµ

         ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
                ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

           (1)µçÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
           (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
           (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
           (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
           (5)ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
           (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
           (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
           (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
           (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø
           (10)רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì

           * ×¨Òµ×齨ÓÐÅÌÍø°É¹¤³Ì£º
                1¡¢µçÄÔ×é×°  2¡¢°²×°²Ù×÷ϵͳ  3¡¢°²×°¸÷ÖÖ×îÐÂÍøÂç¡¢±¾µØÓÎÏ·
                4¡¢×îо«²ÊµçÓ°´óƬ¡¢MP3ÒôÀÖ   5¡¢ÍòÏó¡¢ÃÀƼÖÇÄÜ»¯ÊÕ·Ñϵͳ
                6¡¢°²×°ÖÇÄÜ»¯»¹Ô­¾«Áé   7¡¢ÍøÂç²¼Ïß¡¢ÍøÂç×ÊÔ´¹²Ïí

           ** µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì **
             * ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔ *
           ** ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú **

           ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
           ÁªÏµÈË£ºÕÅ  ·æ
           ÁªÏµµç»°£º13714661862»ò0755-88363633
           QQ£º282079259   2441630
           E-mail:168it@126.com       

    From simple-bounces@ietf.org Mon Mar 7 00:41:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12053; Mon, 7 Mar 2005 00:41:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8B1v-00010w-U7; Mon, 07 Mar 2005 00:43:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AxA-0003LZ-DV; Mon, 07 Mar 2005 00:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Awx-0003LK-NP for simple@megatron.ietf.org; Mon, 07 Mar 2005 00:38:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11899 for ; Mon, 7 Mar 2005 00:38:36 -0500 (EST) 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.33) id 1D8Az4-0000xQ-GU for simple@ietf.org; Mon, 07 Mar 2005 00:40:51 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2005 22:55:15 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,140,1107734400"; d="scan'208"; a="231984912:sNHT20348264" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j275cRZV025235 for ; Sun, 6 Mar 2005 21:38:27 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-149.cisco.com [10.86.240.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APP26023; Mon, 7 Mar 2005 00:38:26 -0500 (EST) Message-ID: <422BE8D1.2090105@cisco.com> Date: Mon, 07 Mar 2005 00:38:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Subject: [Simple] characteristics vs status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit I was reading the presence data model and the latest versions of prescaps and rpid on the plane and it got me thinking. I've been having a bit of a problem about how to represent a device that dynamically changes its capabilities. For purposes of discussion I offer this one: A softphone with voice and IM capabilities. It can handle calls that use both together, or either one alone. It can also start a call with one and add the other to a call later. This phone can also be configured to disable one or the other of the media, so that they will be refused if offered in a call. (Disabling voice is useful in meetings.) I have always felt that the proper way to reflect this device in presence is to change the prescaps specification of media features (