From Xiaomin.Lu@lsi.com Mon Jan 24 09:45:49 2011 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5113A68F8 for ; Mon, 24 Jan 2011 09:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOAvX6FAsfB2 for ; Mon, 24 Jan 2011 09:45:48 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with ESMTP id ACB433A691A for ; Mon, 24 Jan 2011 09:45:48 -0800 (PST) Received: from source ([192.19.220.66]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTT27e3hTqWtFfYVrKtdt0EPYIzp80eJ3@postini.com; Mon, 24 Jan 2011 09:48:44 PST Received: from coshub01.lsi.com (135.142.2.64) by COSEDGE01.lsi.com (192.19.220.66) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 24 Jan 2011 10:49:09 -0700 Received: from cosmail02.lsi.com ([172.21.36.36]) by coshub01.lsi.com ([135.142.2.64]) with mapi; Mon, 24 Jan 2011 10:49:26 -0700 From: "Lu, Xiaomin" To: "rohc@ietf.org" Date: Mon, 24 Jan 2011 10:49:25 -0700 Thread-Topic: CRC-3 and CRC-7 calculation in ROHCv2 Thread-Index: Acu77woKgSFJC/fVTzOyu9Cf2FfaPw== Message-ID: <4B6A08C587958942AA3002690DD4F8C30107031B20@cosmail02.lsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_" MIME-Version: 1.0 Subject: [rohc] CRC-3 and CRC-7 calculation in ROHCv2 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:45:50 -0000 --_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding the CRC-3 and CRC-7 calculations in ROHCv2, e.g= ., ROHCv2-RTP vs. ROHCv1 (RFC3095). In RFC3095 (Page 10), the spec says that "A CRC over the original header is the primary mechanism used by ROHC to detect incorrect decompression. In order to decrease computational complexity, the fields of the header are conceptually rearranged when the CRC is computed, so that it is first computed over octets which are static (called CRC-STATIC in this document) and then over octets whose values are expected to change between packets (CRC-DYNAMIC). In this manner, the intermediate result of the CRC computation, after it has covered the CRC-STATIC fields, can be reused for several packets. The restarted CRC computation only covers the CRC-DYNAMIC octets. See section 5.9." However, in RFC4997 and RFC5225, it does not mention that concept. Instead,= it says on Page 29 of RFC4997: "That is: field =3D:=3D crc(, , , , ); When specifying the bit pattern for the polynomial, each bit represents the coefficient for the corresponding term in the polynomial. Note that the highest order term is always present (by definition) and therefore does not need specifying in the bit pattern. Therefore, a CRC polynomial with n terms in it is represented by a bit pattern with n-1 bits set. The CRC is calculated in least significant bit (LSB) order. For example: // 3 bit CRC, C(x) =3D x^0 + x^1 + x^3 crc_field =3D:=3D crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH); Usage of the "THIS" keyword (see Section 4.6) as shown above, is typical when using "crc" encoding. For example, when used in the encoding method for an entire header, it causes the CRC to be calculated over all fields in the header." Would that suggest the CRC-3 and CRC-7 calculation change in ROHCv2 and seq= uentially Cover the original IP/UDP/RTP headers, instead of partitioning them into c= rc-static and crc-dynamic Part first? Can anyone confirm or clarify that? Thanks very much for your assistance! Best Regards, Xiaomin Lu --_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a question regarding the CRC-3 and CRC-7 calculations in ROHCv2= , e.g., ROHCv2-RTP vs. ROHCv1 (RFC3095).
 
In RFC3095 (Page 10), the spec says that
 
"A CRC over the original header is the primary mechanism used by<= /div>
      ROHC to detect incorrect decompression.=   In order to decrease
      computational complexity, the fields of= the header are
      conceptually rearranged when the CRC is= computed, so that it is
      first computed over octets which are st= atic (called CRC-STATIC in
      this document) and then over octets who= se values are expected to
      change between packets (CRC-DYNAMIC).&n= bsp; In this manner, the
      intermediate result of the CRC computat= ion, after it has covered
      the CRC-STATIC fields, can be reused fo= r several packets.  The
      restarted CRC computation only covers t= he CRC-DYNAMIC octets.  See
      section 5.9."
 
 
However, in RFC4997 and RFC5225, it does not mention that concept. Ins= tead, it says on Page 29 of
RFC4997:
 
"That is:
 
     field   =3D:=3D   crc(<= ;num_bits>, <bit_pattern>, <initial_value>,
           &nbs= p;           <block_da= ta_value>, <block_data_length>);
 
   When specifying the bit pattern for the polynomial, each = bit
   represents the coefficient for the corresponding term in = the
   polynomial.  Note that the highest order term is alw= ays present (by
   definition) and therefore does not need specifying in the= bit
   pattern.  Therefore, a CRC polynomial with n terms i= n it is
   represented by a bit pattern with n-1 bits set.
 
   The CRC is calculated in least significant bit (LSB) orde= r.
 
   For example:
 
     // 3 bit CRC, C(x) =3D x^0 + x^1 + x^= 3
     crc_field =3D:=3D crc(3, 0x6, 0xF, THIS.CVALU= E, THIS.CLENGTH);
 
   Usage of the "THIS" keyword (see Section 4.6) a= s shown above, is
   typical when using "crc" encoding.  For ex= ample, when used in the
   encoding method for an entire header, it causes the CRC t= o be
   calculated over all fields in the header."
 
 
 
Would that suggest the CRC-3 and CRC-7 calculation change in ROHCv2 an= d sequentially
Cover the original IP/UDP/RTP headers, instead of partitioning  t= hem into crc-static and crc-dynamic
Part first?
 
Can anyone confirm or clarify that?
 
Thanks very much for your assistance!
 
 
Best Regards,
Xiaomin Lu
 
 
 
 --_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_-- From cabo@tzi.org Mon Jan 24 10:04:02 2011 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145F83A6923 for ; Mon, 24 Jan 2011 10:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.381 X-Spam-Level: X-Spam-Status: No, score=-106.381 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY7m+gGT-bme for ; Mon, 24 Jan 2011 10:04:01 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id C81E73A691C for ; Mon, 24 Jan 2011 10:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p0OI6mJg017140; Mon, 24 Jan 2011 19:06:48 +0100 (CET) Received: from [192.168.217.112] (p5489FF28.dip.t-dialin.net [84.137.255.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9B648578; Mon, 24 Jan 2011 19:06:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4B6A08C587958942AA3002690DD4F8C30107031B20@cosmail02.lsi.com> Date: Mon, 24 Jan 2011 19:07:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B6A08C587958942AA3002690DD4F8C30107031B20@cosmail02.lsi.com> To: "Lu, Xiaomin" X-Mailer: Apple Mail (2.1082) Cc: "rohc@ietf.org" Subject: Re: [rohc] CRC-3 and CRC-7 calculation in ROHCv2 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:04:02 -0000 On Jan 24, 2011, at 18:49, Lu, Xiaomin wrote: > Would that suggest the CRC-3 and CRC-7 calculation change in ROHCv2 = and sequentially > Cover the original IP/UDP/RTP headers, instead of partitioning them = into crc-static and crc-dynamic > Part first? Indeed, this partitioning was an optimization that sounded clever at the = time we did RFC 3095 but apparently made it harder to implement ROHC for = some, so it is not used in ROHCv2. Gruesse, Carsten From lars.eggert@nokia.com Mon Jan 31 04:18:51 2011 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768AA3A6BEC for ; Mon, 31 Jan 2011 04:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.781 X-Spam-Level: X-Spam-Status: No, score=-103.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBcoEfQco3rs for ; Mon, 31 Jan 2011 04:18:50 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 8E1F33A6938 for ; Mon, 31 Jan 2011 04:18:50 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0VCM2J0032692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 14:22:03 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-8-341733932; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 31 Jan 2011 14:21:53 +0200 Message-Id: <8BFE2075-5B98-4B58-B66D-0A8F3B9C70DA@nokia.com> To: rohc@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 31 Jan 2011 14:21:59 +0200 (EET) X-Nokia-AV: Clean Cc: David Harrington Subject: [rohc] Errata against ROHC RFCs X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:18:51 -0000 --Apple-Mail-8-341733932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, several errata have been submitted against ROHC RFCs: = http://www.rfc-editor.org/errata_search.php?rec_status=3D2&area_acronym=3D= tsv&wg_acronym=3Drohc&presentation=3Dtable The TSV ADs would like to enlist the help of the RFC authors and the = broader ROHC community in order to determine how to process these, i.e., = which should be "verified", "held" or "rejected". Please discuss these errata on this list. Lars PS: IESG guidelines on errata handling: In order to help you determine the correct handling for the errata in step (4), the IESG has come up with a few guidelines: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. 3. Errata on obsolete RFCs should be treated the same as errata on RFCs that are not obsolete where there is strong evidence that some people are still making use of the related technology. 4. Trivial grammar corrections should be Hold for Document Update. 5. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update. 6. Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. 7. Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Rejected. --Apple-Mail-8-341733932 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEzMTEyMjE1NFowIwYJKoZIhvcNAQkE MRYEFIduujTNrNFgmxfge40bSnG1os5kMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AJuFopjKhT/MoLScm9JPbw7+vvfffSQhaEZAZC/P0nJt6MCLRpDMOEMK6mcehBOSXAzjCM2ObIB0 xP3/YAKhyD8aLocTsEXGEe6YtX6EJutL9ODRfcdTZo96dcaCeMA5LtWv/ygvdJtH0qidpEkpknHh SUSoovIije9HhLko/GgINnkqTS7o3ci0riHs5sJvxP67C5vaR4SAzxVIZypIzIh9nL1PtfSfbs43 AvRTOUUgv167XzBc1UYibTaTe+VWlqTrNkZ8EytQNAZphP2ZdrkzoTlUfKUHZmNYdXcJZ9vb/PFd ms36EVGZtaf7q7+9ZCnrfBj7adNDXoWxpOPYaUAAAAAAAAA= --Apple-Mail-8-341733932-- From cabo@tzi.org Mon Jan 31 10:59:26 2011 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17583A6B32 for ; Mon, 31 Jan 2011 10:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.371 X-Spam-Level: X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNv4ZRLEaaDg for ; Mon, 31 Jan 2011 10:59:25 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 60A8D3A6C4C for ; Mon, 31 Jan 2011 10:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p0VJ1mVe017154; Mon, 31 Jan 2011 20:01:48 +0100 (CET) Received: from [192.168.217.112] (p5489B7BC.dip.t-dialin.net [84.137.183.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 395F352D; Mon, 31 Jan 2011 20:01:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <8BFE2075-5B98-4B58-B66D-0A8F3B9C70DA@nokia.com> Date: Mon, 31 Jan 2011 20:02:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: <3FE00204-1925-45D7-B04A-BCAAFB9CF8F3@tzi.org> References: <8BFE2075-5B98-4B58-B66D-0A8F3B9C70DA@nokia.com> To: Lars Eggert X-Mailer: Apple Mail (2.1082) Cc: rohc@ietf.org, David Harrington Subject: Re: [rohc] Errata against ROHC RFCs X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:59:26 -0000 On Jan 31, 2011, at 13:21, Lars Eggert wrote: > Please discuss these errata on this list. Here is my assessment. Thanks for bringing these up! Gruesse, Carsten * RFC 3816: http://www.rfc-editor.org/errata_search.php?eid=737 -- many typos, some opportunity for editorial improvement -- very little risk for misinterpretation, except maybe for 2f -> Hold for Update (The large number of errata leaves the document in a somwhat sorry state. It might be worthwhile to look at the implementation status of RFC 3816 to assess the need for a re-spin.) * RFC 5795: http://www.rfc-editor.org/errata_search.php?eid=2107 -- opportunity for minor editorial improvement -- no risk -> Hold for Update http://www.rfc-editor.org/errata_search.php?eid=2108 -- errata submission simply misreads text (reads verb as noun) -- could be improved editorially anyway (but not in the way proposed) -- no risk -> Reject, but make note to improve this text in next update http://www.rfc-editor.org/errata_search.php?eid=2109 -- proposed change is somewhat pedantic; -- it actually might reduce readability for some readers -- no risk -> Reject http://www.rfc-editor.org/errata_search.php?eid=2110 "RFC Errata Report" -- punctuation fix (typo) -- no risk -> Hold for Update * RFC 5857 http://www.rfc-editor.org/errata_search.php?eid=2274 -- editorial fix required: the wording on top of page 4 can be misread (the section reference parenthesis is about the new Notify Message Type value, not about the channel parameters carried by this message type). -- also: this (and another) reference that should point to section 5 (IANA considerations) incorrectly say "Section 4" (they should not say 3.1.2 as the errata states either). -- annoying, but very little risk of misunderstanding -> Hold for Update http://www.rfc-editor.org/errata_search.php?eid=2275 -- typo -- no risk -> Hold for Update * RFC 5858 http://www.rfc-editor.org/errata_search.php?eid=2276 -- typos -- no risk -> Hold for Update http://www.rfc-editor.org/errata_search.php?eid=2277 -- idea for a very desirable editorial improvement -- can probably be improved on further -- even without that improvement, minimal risk of misinterpretation -> Hold for Update From lars.eggert@nokia.com Mon Jan 31 23:59:26 2011 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69273A6B98 for ; Mon, 31 Jan 2011 23:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.258 X-Spam-Level: X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwQja83Gcc5h for ; Mon, 31 Jan 2011 23:59:25 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id A12C43A6B75 for ; Mon, 31 Jan 2011 23:59:25 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1182a9e014834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 10:02:38 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-27-412568671; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <3FE00204-1925-45D7-B04A-BCAAFB9CF8F3@tzi.org> Date: Tue, 1 Feb 2011 10:02:28 +0200 Message-Id: <95BB5766-B716-48E3-9D52-70E9B3C9DDCB@nokia.com> References: <8BFE2075-5B98-4B58-B66D-0A8F3B9C70DA@nokia.com> <3FE00204-1925-45D7-B04A-BCAAFB9CF8F3@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 01 Feb 2011 10:02:33 +0200 (EET) X-Nokia-AV: Clean Cc: rohc@ietf.org, David Harrington Subject: Re: [rohc] Errata against ROHC RFCs X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 07:59:27 -0000 --Apple-Mail-27-412568671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, Carsten. I'll wait a few days to give others a chance to chime = in, but your suggestions seem reasonable to me. On 2011-1-31, at 21:02, Carsten Bormann wrote: > On Jan 31, 2011, at 13:21, Lars Eggert wrote: >=20 >> Please discuss these errata on this list. >=20 > Here is my assessment. > Thanks for bringing these up! >=20 > Gruesse, Carsten >=20 >=20 > * RFC 3816: >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D737 > -- many typos, some opportunity for editorial improvement > -- very little risk for misinterpretation, except maybe for 2f > -> Hold for Update > (The large number of errata leaves the document in a somwhat sorry > state. It might be worthwhile to look at the implementation status of > RFC 3816 to assess the need for a re-spin.) >=20 > * RFC 5795: >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2107 > -- opportunity for minor editorial improvement > -- no risk > -> Hold for Update >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2108 > -- errata submission simply misreads text (reads verb as noun) > -- could be improved editorially anyway (but not in the way proposed) > -- no risk > -> Reject, but make note to improve this text in next update >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2109 > -- proposed change is somewhat pedantic; > -- it actually might reduce readability for some readers > -- no risk > -> Reject >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2110 > "RFC Errata Report" > -- punctuation fix (typo) > -- no risk > -> Hold for Update >=20 > * RFC 5857 >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2274 > -- editorial fix required: the wording on top of page 4 can be misread > (the section reference parenthesis is about the new Notify Message > Type value, not about the channel parameters carried by this > message type). > -- also: this (and another) reference that should point to section 5 > (IANA considerations) incorrectly say "Section 4" (they should not > say 3.1.2 as the errata states either). > -- annoying, but very little risk of misunderstanding > -> Hold for Update >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2275 > -- typo > -- no risk > -> Hold for Update >=20 > * RFC 5858 >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2276 > -- typos > -- no risk > -> Hold for Update >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D2277 > -- idea for a very desirable editorial improvement > -- can probably be improved on further > -- even without that improvement, minimal risk of misinterpretation > -> Hold for Update >=20 --Apple-Mail-27-412568671 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIwMTA4MDIyOFowIwYJKoZIhvcNAQkE MRYEFJhcZA0RtH6QqTLD6lA+3wjvkBr7MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AFiHBu9msvzW73u9FN/lElpUWyPD15F0+pTL4sIDLlBt5PG+Vjvs2ANl7MBKJ90SLJqoFrvlDJAs c0d0dtxgzNTIGSOX83Jrry5e32/EjX64NDEjuMqTYOTWJdxFTABadITqwUQdI2qdnJhBUZMsHt+6 9XgwZCP93X+UHZzyU6EluQw5ulqQEBuBqcRKkHZgqgIouQ60uVj+du9TpodJ75mB+BHte5PDHDyV H0nSoUziXrMlhjxhSY37rrQM7w8oJpNuMkGRaVTtP1plgq21B5c6ztWZ/dJxp3TbQzhTPMsXJ7jJ rR+3frsqgQPWIscppLDFbfitWiS15scwdYEod1kAAAAAAAA= --Apple-Mail-27-412568671--