From sm@elandsys.com Fri Apr 1 13:45:42 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B122828C0D8 for ; Fri, 1 Apr 2011 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 0m9ax2WKZQMw for ; Fri, 1 Apr 2011 13:45:41 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id ACADA28B23E for ; Fri, 1 Apr 2011 13:45:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.115]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p31KlEkm029026 for ; Fri, 1 Apr 2011 13:47:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1301690841; bh=jCRfaNLWWQ9bl3suC15vDlVHyxY=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=bZgFTrbevC8WhOsONZRZtZ4zwNDusTW1NNQaJ1Of//exWRuB63tyJ7qgMe67xFr47 Fys74JQ5upcUYktILCnWkFPhEmQnfDA6u+/3yltTUsNFJTyiPu4KryBcjYUuiyY2/l bg7rt4J5AAkX2cvnujIyyoc9Ajh2Ow/077q6MmYg= Message-Id: <6.2.5.6.2.20110401112230.0e0e5dc8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Apr 2011 12:02:38 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Review Team Report for March 2011 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 20:45:42 -0000 Hello, The Applications Area Review Team provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The members of the team are selected from the IETF community based on their expertise in doing away with luxuries such social life and sleep. The team did not perform any reviews in March 2011. Regards, S. Moonesamy On behalf of the Apps Review Team http://www.apps.ietf.org/content/applications-area-review-team From alexey.melnikov@isode.com Sun Apr 3 12:45:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608BC3A67E4 for ; Sun, 3 Apr 2011 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 pW86B9l4mjT3 for ; Sun, 3 Apr 2011 12:45:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E02BF3A67B5 for ; Sun, 3 Apr 2011 12:45:42 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.19]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 3 Apr 2011 20:47:23 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D98CEC2.6060909@isode.com> Date: Sun, 03 Apr 2011 21:47:14 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org References: <4D6E578D.9080707@isode.com> In-Reply-To: <4D6E578D.9080707@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Alexey's final Apps AD report X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 19:45:44 -0000 Alexey Melnikov wrote: > I meant to write a "Christmas edition" of my usual AD report, but > things got a bit out of hand with trying to finish various IESG > related tasks. > > At the moment, I am holding a DISCUSS on a single document > (draft-ietf-tls-rfc4347-bis-04 > .txt), I let Sean (the responsible AD) hold a DISCUSS for me on this document. I managed to accumulate DISCUSSes on 3 SIDR documents, but I passed most of them to Stewart (the responsible AD). > but this should be resolved before or around Prague. Other DISCUSSes > were either cleared, or were taken by other ADs who would remain on > IESG after Prague. > > At the moment I am concentrating on finishing sponsoring of a few > remaining drafts: > > 1) draft-ietf-httpbis-content-disp-06 - in IETF LC and I hope to get > it approved on March 17th IESG telechat. If this doesn't happen, Peter > will be taking over the sponsoring of this document. Approved on Monday, March 28th. > 2) draft-holsten-about-uri-scheme-06 - I am trying to get this > approved, but authors are not responding to my emails recently. Peter > will take over this document, if I don't get it approved for publication. Peter Saint-Andre took over this document, I became the document shepherd. > 3) draft-meadors-multiple-attachments-ediint-10 - This should be > reviewed by IESG on March 17th. I am hoping this can get approved > before my AD term ends at the end of March. Pete Resnick took over this document. > 4) draft-salowey-secsh-uri-00 - Waiting for the author to revise the > draft to address IETF LC comments. I am not certain that this document > will be approved before Prague. Sean Turner took over this document, I became the document shepherd. > 5) draft-ietf-tsvwg-iana-ports-10 - Reviewed by IESG. I need to enter > some RFC Editor notes to address IESG and some IETF LC comments. I > hope to get this approved before Prague. Approved on Wednesday, March 30th. > 6) draft-bryan-metalinkhttp-21 - In IESG review on March 3rd. Good > effort from editors to clear DISCUSSes on the document. I am hoping to > get this approved before Prague. Approved last week. > I am spending a significant amount of my time tracking EAI and HYBI WGs. > I am planning to close MORG WG before Prague. Done. > I am hoping to either close or start rechartering discussion for YAM > before Prague. I didn't have time to do this. I will followup with Pete Resnick (who took over the WG). > I am also trying to finish some IESG/IETF related projects: > 1). Trying to finish Sieve External List (one of my documents) with > Barry Leiba. Approval of this document would release 3 related Sieve RFCs. A new version was posted by Barry. The document is in WGLC now. > 2). Several related discussions on making URI/Media Type review > processes easier and more transparent. I am hoping to discuss some > proposed changes in Prague (during the Apps Area meeting), plus make > some process/tool changes on IESG side (at least for MIME types) I now have lots of emails to read, reply and process. Somebody mentioned that I should have lots of free time now ;-). > If you think this list is missing something, please let me know. Other things of interest: RFC 6186 (Use of SRV Records for Locating Email Submission/Access Services) and RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) got published on March 30th. After consulting with my co-ADs, there were some changes to WG chairs of several WGs: Gabriel Montenegro replaced Joe Hildebrand as a co-chair of the HYBI WG. SM replaced Chris Newman as a co-chair of YAM WG. I became the 3rd co-chair of the APPSAWG. The OAUTH WG was moved to the Security Area (it wasn't my WG, but I participated in the talks.) From cabo@tzi.org Sat Apr 9 13:29:12 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92803A6972; Sat, 9 Apr 2011 13:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.049 X-Spam-Level: X-Spam-Status: No, score=-105.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_35=0.6, 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 XBiV0K3c0SJX; Sat, 9 Apr 2011 13:29:11 -0700 (PDT) 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 E078E3A694F; Sat, 9 Apr 2011 13:29:10 -0700 (PDT) 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 p39KUjNL021905; Sat, 9 Apr 2011 22:30:46 +0200 (CEST) Received: from [10.128.2.214] (unknown [80.187.210.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4DFD83CC; Sat, 9 Apr 2011 22:30:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Carsten Bormann Date: Sat, 9 Apr 2011 22:30:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9780CDCD-0C08-4D19-B63F-240D8FDA6425@tzi.org> To: draft-ietf-sidr-rescerts-provisioning.notify@tools.ietf.org X-Mailer: Apple Mail (2.1084) Cc: The IESG , Apps Discuss Subject: [apps-discuss] apps-team review of draft-ietf-sidr-rescerts-provisioning-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:29:12 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-rescerts-provisioning-09 Title: A Protocol for Provisioning Resource Certificates Reviewer: Carsten Bormann Review Date: 2011-04-09 SUMMARY: This document is ready for publication after a number of relatively simple changes have been performed. A slightly larger set of potentially desirable improvements have also been identified. PURPOSE: The draft describes a protocol for provisioning resource certificates. A resource in this context is an Internet Number Resource (INR), i.e., IP Address or Autonomous System (AS) Number. The protocol is used between a client "Subject" (such as an ISP) and a server "Issuer" (such as a registry, acting as a CA). The protocol will thus be used between in a very specialized setting between members of two closely-knit communities; there is little danger of properties of this protocol spilling over into mainstream application protocols. REVIEW: Several properties of this protocol represent current practice, but not necessarily best practice, in application protocol design. The message transport used is an HTTP POST request, which is used as a request-response vehicle for carrying around CMS objects which in turn carry XML-encoded messages that are the subject of this protocol. Given the specialized status of this protocol, this may be acceptable. Major Issues: 1. The media type used for requests and responses cannot be registered under the name 'application/x-rpki' (section 4.2 of RFC 4288). Unless significant deployment makes this prohibitive, a permanent name SHOULD be chosen and the media type be registered according to RFC 4288 (BCP 13). 2. There is an explicit mandate for serializing the processing of all requests between one server/client pair, without it being fully clear what exactly constitutes that pair (i.e., when are two requests from the *same* client)? Similarly, it is not quite clear how to "Check that the XML sender and recipient attributes reference a known client and this server's system respectively" (the underlying data type is an xsd:token). Details: 3. There is no such thing as a "HTTP 400 Bad Data" response to an HTTP POST. Status code 400 stands for "Bad Request". 4. It may be worthwhile to mention the use of the Retry-After: HTTP header with a 503 status. 5. My ASN.1 is a bit rusty, but the content of 3.1.1.3.2 looks strange to me and is rejected by asn1c. Has this been validated? Same comment for Appendix A. Remove duplicate definition of ContentType as well. 6. re 3.2 Common Message format: The reader's mind should be put at ease here by quickly pointing to the Relax-NG spec in Annex B. It should be clarified that the text in 3.2 is specifying the message format by way of examples, and that the actual (also normative) format is specified in Appendix B. 7. re 3.2 Common Message format: please remove the spaces around the '=' in 'recipient = "recipient name"' to minimize confusion. 8. The use of a comma-separated list of URIs (which in turn requires escaping commas in the URIs themselves) in the attribute "cert_url" in the context of a class or certificate element is suboptimal. Allowing one or more cert_url elements nested in the class element would be more natural XML. 9. It is unclear why a new convention for the representation for IPv6 addresses needs to be invented. One should simply make use of RFC 5952. The example given in the text for resource_set_ipv6 does not conform to either RFC 5952 (it uses upper case, as seems to be recommended by the somewhat opaque reference to http://www.w3.org/TR/xmlschema-2/#hexBinary and its canonical form) nor the new convention (it uses leading zeros). (The reference to RFC 3779 seems to point to section 2.2.3.6 in that RFC?) 10. re 3.4: I have trouble understanding: If any of the req_resource_set attributes are specified in the request, then any missing req_resource_set attributes are to be interpreted as specifying the complete set of the corresponding resource type that match the client's current resource allocation. If the value of any req_resource_set attributes is the null value (""), then this indicates that no resources of that resource type are to be certified with this request. What is the semantics if none of the req_resource_set attributes are specified? 11. What are the circumstances under which the following SHOULD is not required, and what can the client rely on to happen in this case? o If the resource class is not defined by the server, then the server SHOULD return error code 1201. 12. (The reviewer got curious why ski is using base64url and all other binary data are encoded in base64.) 13. What is the point of limiting the error_response status code to one quadrillion minus one? The set of status codes ever standardized is likely to be smaller, not requiring a 50 bit number. Right now, they are all four-digit numbers, which might be a hint to a more reasonable upper limit. 14. There is no way in the schema to include a second description element, as is require in the description of "description" in 3.6. 15. The schema allows zero-length certificates throughout -- this will be caught at the semantic level, but it is probably worthwhile spending a couple of minLength constraints on the xsd:base64Binary. Similar comment for the xsd:token in class_name. 16. (There are some indentation idiosyncrasies in the schema, e.g. in issue_request and in revocation. The schema might also be improved by factoring out some common types such as xsd:base64Binary { maxLength="512000" } xsd:token { maxLength="1024" } as was done e.g. in draft-ietf-sidr-publication.) From stpeter@stpeter.im Wed Apr 13 19:50:47 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B324E0668 for ; Wed, 13 Apr 2011 19:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA1QZd1YZbkp for ; Wed, 13 Apr 2011 19:50:45 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id BA478E0707 for ; Wed, 13 Apr 2011 19:50:45 -0700 (PDT) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F408F40D20 for ; Wed, 13 Apr 2011 20:53:48 -0600 (MDT) Message-ID: <4DA66102.4060200@stpeter.im> Date: Wed, 13 Apr 2011 20:50:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080802070405080909030204" Subject: [apps-discuss] draft IETF 80 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 02:50:47 -0000 This is a cryptographically signed message in MIME format. --------------ms080802070405080909030204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These are draft minutes: http://www.ietf.org/proceedings/80/minutes/apparea.txt Corrections are welcome. Many thanks to Bert Greevenbosch for scribing! /psa =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AppsArea / APPSAWG Meeting Minutes IETF 80 Monday, March 28, 2010, 0900-1130 Prague, Czech Republic Hilton Prague, Congress Hall II Area Directors: Alexey Melnikov, Peter Saint-Andre, Pete Resnick APPSAWG WG Chairs: Barry Leiba, Jiankang Yao Scribe: Bert Greevenbosch Agenda: Slides: Audio: Chat Log: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MINUTES Chairs: Note well reviewed Logistics reviewed Agenda bashed Paul Hoffman: Draft-hoffman-server-has-tls-04 Question: Should it be a service discovery protocol? Group is requested to consider. Question: Is there a way to securely negotiate usage of this secure protocol? Remark: We should do this in a separate working group Question: Conflict with W3C security policy? Need to coordinate making sure there are not many different formats. Remark: Requirements in APPAREA is OK, but we need experts. New working group or current DNS based working group? Maybe it can be built on top of DNSsec. Question: Does it require something we already have? Maybe UNAPTR. Don't focus on new protocol, but see if needed, and if so, which technology can be re-used. Show of hands on the following: * Who thinks we should not do it? (small support) * Who thinks we should do it in a separate working group? (medium support) * Who thinks we should do it in apparea? (small support) * Who thinks we don't know enough yet? (highest support) Patrik Faltstrom: Unicode and IDNA Remark: Seems network issue, should be in lower layer. Mark Nottingham: draft-nottingham-http-portal Question: HTTPS could also allow this? More discussion needed. Murray S. Kucherawy: Draft-kucherawy-mta-malformed Several problems could arise when browsers/mail readers give some leeway to malformed messages. There are security issues involved. IETF should consider these and give some guidance. Question: Separate WG or in APPSAWG? Individual draft? Draft-kucherawy-rfc3462bis Question: Connection to SpamRep in OMA? YAM WG is going to recharter. Right place could become YAM. Wait until YAM recharters. If doesn't, then APPSAWG makes sense. Draft-lear-iana-timezone-database More discussion is needed, and a side meeting on Wednesday morning 8:00 =C3=A2=E2=82=AC=E2=80=9C 9:00 is planned. Eliot Lear: draft-lear-iana-timezone-database-02 IANA Procedures for Maintaining the Timezone Database Volunteers are needed to provide feedback on the document. Eric Rescorla: Draft-rescolra-jsms-00 Bar BoF about cryptography 20:00 in Karlin I. Question: Is there a need for a http-URI or is https-URI enough? Bernie H=C3=83=C2=B6neisen: IANA Registration of Enumservices for Internet Calendaring Session chair: Look for experts on calendaring (small group) first. Question: Why shut down ENUM and not work on that there? Answer: Leadership wants wg to be shut down. Alexey Melnikov: Draft-melnikov-smtp-altrecip-on-error-00 Remark: Threat analysis is needed. Draft-melnikov-smtp-priority-01 Discussion on mailing list. Florian Echtler: Draft-echtler-gispl-specification-01 Question: Is this related to W3C web-actions? Answer: Yes, it is. Remark: Transmitting the format could be work for another organization. Close relationship to eventing and API. Chris and Mark should look for a suitable WG. Dave Crocker Draft-crocker-doseta-base Remark: Semantics need thorough considerations, as they cannot be changed after implementation. Question: Where is the work to be done? Answer: Not looking for a working group, but for people that are interested. If the interest is there, we can have a look at the mechanics. Chris Lilley http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20 More discussion needed. Bhumip Khasnabish Virtual Desktop Infrastructure List of possible work items Remark: Proposal in OMA also to set-up virtual experience work item. Next discussions from AD? Work of IETF? Is it a protocol or an API? Need to discuss with ADs. END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------ms080802070405080909030204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx NDAyNTA0MlowIwYJKoZIhvcNAQkEMRYEFGZBA2+EGO7rGAxJ0bTxoNvr0o1jMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBiiYshWgz497bU47hk3djB76mxVPEKFzpEoleoD8EoIkjwuHOlKHV3FTus i3+d7l5KhO903B6Cb4x0Q2cRXNjJmgkQDebVbgNozE0wzE0m87TgiJ+Cakd6M4U6Jbe72zUt IaO5Wm9gRQL7N558xIrGdSr5GwiPzDAxqV5Cv+QNSaN+SRmEVsjK8APF1Bt5IyC00GAUiV9d aOPiIADziHrdSsSic7Fom6R3PAF6+4Iko9xh9QveH17NQat/tsH7zIm8nCRYIoTUT7WQ9BBG D4Gy3VO7Tq4RQaiUzdWjr3Hnsihpu1HAvFBKVXxu474uWleP44Vcg3Cd2c3UgeMNQzX3AAAA AAAA --------------ms080802070405080909030204-- From barryleiba.mailing.lists@gmail.com Wed Apr 13 20:14:37 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E08E2E07E3 for ; Wed, 13 Apr 2011 20:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kylou4pSv2TS for ; Wed, 13 Apr 2011 20:14:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id D4690E00BE for ; Wed, 13 Apr 2011 20:14:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so1142113wyb.31 for ; Wed, 13 Apr 2011 20:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dwQ1hADOaQgGDKCiFTtxNz7JgxrUin2P/O4RTScsklc=; b=e8d6dPXOr8evVsaV2yFbEuONTN7bcBH0xu2tkFyb9TNuKQnWQmUAy1g318VYsvYP60 txtZWjcefHJ+pT24EfdnylCWKzQYtkjCrbgo+jP5elI1gmaSt8kh2ICoAG/ivLVgfwG0 1wnnvqEYZ0YiDXJwiD63qgE4sAqddDt1Zj/v4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ILAlcvZMMGfytartA9JF3BCUhG5dk876Ef0gUowyAQjJx5SaMd7RO6YeKA0EUONtxF FsGU5+dTpq+VE2jx80X9lV3ZAgbo5V3N08Z3h4A7NzLZMfdQIozDXNBAMQCojYJ503X4 Vm/BV8TaB9uMKwtXfrRlt80+eJqUJ2kzmaEoQ= MIME-Version: 1.0 Received: by 10.227.139.19 with SMTP id c19mr259426wbu.13.1302750876129; Wed, 13 Apr 2011 20:14:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.227.146.197 with HTTP; Wed, 13 Apr 2011 20:14:35 -0700 (PDT) In-Reply-To: <4DA66102.4060200@stpeter.im> References: <4DA66102.4060200@stpeter.im> Date: Wed, 13 Apr 2011 23:14:35 -0400 X-Google-Sender-Auth: npiLj6OxQ1kl6xnD93JAlM7AJfw Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft IETF 80 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:14:38 -0000 > Bernie H=C3=B6neisen: > IANA Registration of Enumservices for Internet Calendaring > Session chair: Look for experts on calendaring (small group) first. > Question: Why shut down ENUM and not work on that there? > Answer: Leadership wants wg to be shut down. More complete answer was that the WG is ending its useful life and is ready to be shut down, and that at this point this document is more a calendar issue than an enum issue, so there's little reason to do it in enum anyway. Add: "Action: Ask Cyrus and Bernard to review and address open calendar question= s." Barry From stpeter@stpeter.im Wed Apr 13 20:21:42 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2887E07AA for ; Wed, 13 Apr 2011 20:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHLEjqnKVqGZ for ; Wed, 13 Apr 2011 20:21:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 3118AE0668 for ; Wed, 13 Apr 2011 20:21:42 -0700 (PDT) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 267F440D20; Wed, 13 Apr 2011 21:24:44 -0600 (MDT) Message-ID: <4DA66842.3070307@stpeter.im> Date: Wed, 13 Apr 2011 21:21:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Barry Leiba References: <4DA66102.4060200@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000702040003080806050202" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft IETF 80 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:21:43 -0000 This is a cryptographically signed message in MIME format. --------------ms000702040003080806050202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/13/11 9:14 PM, Barry Leiba wrote: >> Bernie H=C3=83=C2=B6neisen: >> IANA Registration of Enumservices for Internet Calendaring >> Session chair: Look for experts on calendaring (small group) first. >> Question: Why shut down ENUM and not work on that there? >> Answer: Leadership wants wg to be shut down. >=20 > More complete answer was that the WG is ending its useful life and is > ready to be shut down, and that at this point this document is more a > calendar issue than an enum issue, so there's little reason to do it > in enum anyway. >=20 > Add: > "Action: Ask Cyrus and Bernard to review and address open calendar ques= tions." Fixed. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000702040003080806050202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx NDAzMjEzOFowIwYJKoZIhvcNAQkEMRYEFMxas7mEUzrwAzrLbb9wERhlvydJMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBiOjgANznB5eZ1xDZMm0OrhnJIJ8NM2ePT7w5VZ4Xl0YiyQRgh5vpaNQlT Pkpc98gz9zH892m0Ij4IspAeMi1nm6KGmzp8JfQzAlX+kv9WQuYD6z25ihj1DJ6wxxishUls 2K+19dnXW5OZPO3emRmoMf8YhhqDetfxh7AEvCjL2xPODlqF29q3fp9aw6j5iDr4h4/mZIgx GcfZ70/vT77L8nhauthkAvQ6Ea1p0hzYYfzIFuVRyNLgJexwrPznGEPCuiRYWfOCaKQMKHfU Tx+PogblcvajmvI/4FvyV3MxZy3kDMJD0ZWjb4A9iOjkXMLRuk6lBMv2vsxaLQ77NmI2AAAA AAAA --------------ms000702040003080806050202-- From styler@mimecast.com Thu Apr 14 02:58:54 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA79BE06AD for ; Thu, 14 Apr 2011 02:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl1FPU+PZ0ZU for ; Thu, 14 Apr 2011 02:58:53 -0700 (PDT) Received: from serviceA.mimecast.com (serviceA.mimecast.com [213.235.63.104]) by ietfc.amsl.com (Postfix) with ESMTP id 6C4FEE0669 for ; Thu, 14 Apr 2011 02:58:53 -0700 (PDT) Received: from remote.mimecast.com (146.101.202.133 [146.101.202.133]) (Using TLS) by serviceA.mimecast.com; Thu, 14 Apr 2011 10:58:46 +0100 Received: from MC-LON-EXCH02.mcsltd.internal ([::1]) by MC-LON-EXCH02.mcsltd.internal ([::1]) with mapi id 14.01.0255.000; Thu, 14 Apr 2011 10:58:42 +0100 From: Simon Tyler To: "apps-discuss@ietf.org" Thread-Topic: Comments on Malformed Message BCP draft Thread-Index: Acv6ioaMMlVzZylWW0aABPApC7cyaQ== Date: Thu, 14 Apr 2011 09:58:42 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 x-originating-ip: [86.152.50.249] MIME-Version: 1.0 X-MC-Unique: 111041410584600202 Content-Type: multipart/alternative; boundary="_000_C9CC83DE7031stylermimecastcom_" Subject: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:58:55 -0000 --_000_C9CC83DE7031stylermimecastcom_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, Having read the Malformed Message BCP draft I am interested in getting some= discussion going on its content and to find the best way forward. For those who missed it, the draft is at: https://www1.tools.ietf.org/html/draft-kucherawy-mta-malformed-00 I have a few comments on it. One thing that concerns me is the proposal that processing should stop when= certain malformations are identified. For example it is proposed that should a badly wrapped header field be foun= d (quite how we define this is left open, I presume a line that does not st= art with a valid header field name followed by a colon) then the processing= agent should treat this as the end of the header. My feeling is that this = opens up a greater potential hole than the one closed and that can be explo= ited. An example of the type of issue this could is cause is that should such a m= alformation occur before the MIME header fields in the header then this wou= ld cause the rest of the header and the message body to be treated as plain= text. This could cause content analysis system to fail as they would not i= nterpret the MIME content in the way that was presumably intended. Given that these recommendations are unlikely to be followed by all clients= and servers, I feel that this suggestion will allow content through an age= nt without suitable processing. My preference on this particular malformati= on would be to continue processing the header fields, this is based on the = assumption that what follows the malformed header field is more likely to b= e further header fields and not body content. What we do with the malformed= header field I am less certain about. We could just ignore it or we could = treat it as part of the previous header field - both will be right as often= as they wrong. I would welcome some additional thoughts on this. I have similar feelings about some of the other suggestions including the l= ack of a MIME-Version header. We cannot ignore intended meaning just becaus= e a non-compliant application made a small error in the header fields. Ever= yone will be best served if we subject such messages to more analysis, not = less. On the whole I think a set of guidelines in this area is good but it will b= e hard to reach consensus without agreement on some basic underlying princi= ples. I would suggest that one such principle is to try to do what the int= ended recipient would most likely prefer, which is generally to fix and del= iver non-spam messages. I would also propose some additions to the draft. At Mimecast we see a lot = of messages generated by all sorts of systems and amongst these we see a lo= t of different kinds of message malformations. I'll suggest more as I think of them but for starters here are a few: 1. Excessively long lines in both headers and body. I commonly see lines th= at are several hundred Kbs in length. These are often valid messages in the= sense that the content is desired by the receiver and in all respects othe= r than line length are well formed. Obviously a limit has to be enforced an= d I would like to find a consensus on what sort of limit is reasonable. Ini= tially I felt 8K was a good limit - it is after all 8 times the limit in RF= C 5321. But it appears that this is too small a limit in real situations. W= hen the limit is exceeded, what is the best option =96 a rejection or forc= ed line wrap. I am open to both. 2. Invalid characters in headers. I often see headers with un-encoded 8bit = characters. These are often displayed correctly to the recipient where the = client happens upon the correct character set by virtue of chance. 3. 8bit characters in MIME sections with a content-transfer-encoding of 7bi= t. If you have read this far then I think you will agree with me that Murray h= as made a good start on a much needed set of guidelines. Now let's see if w= e can support him to expand on the work he has done and reach a consensus o= n the best approaches. Simon --_000_C9CC83DE7031stylermimecastcom_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: <50E5B33CB13B6D4B971D0579BA270728@mimecast.com> Content-Transfer-Encoding: quoted-printable Comments on Malformed Message BCP draft Hi,
 
Having read the Malformed Message BCP draft I am interested in getting some= discussion going on its content and to find the best way forward.
 
For those who missed it, the draft is at:

https://www1.tools.ietf.org/html/draft-kucher= awy-mta-malformed-00

I have a few comments on it.

One thing that concerns me is the proposal that processing should stop when= certain malformations are identified.

For example it is proposed that should a badly wrapped header field be foun= d (quite how we define this is left open, I presume a line that does not st= art with a valid header field name followed by a colon) then the processing= agent should treat this as the end of the header. My feeling is that this opens up a greater potential ho= le than the one closed and that can be exploited.

An example of the type of issue this could is cause is that should such a m= alformation occur before the MIME header fields in the header then this wou= ld cause the rest of the header and the message body to be treated as plain= text. This could cause content analysis system to fail as they would not interpret the MIME content in th= e way that was presumably intended.

Given that these recommendations are unlikely to be followed by all clients= and servers, I feel that this suggestion will allow content through an age= nt without suitable processing. My preference on this particular malformati= on would be to continue processing the header fields, this is based on the assumption that what follows the m= alformed header field is more likely to be further header fields and not bo= dy content. What we do with the malformed header field I am less certain ab= out. We could just ignore it or we could treat it as part of the previous header field - both will be righ= t as often as they wrong. I would welcome some additional thoughts on this.=

I have similar feelings about some of the other suggestions including the l= ack of a MIME-Version header. We cannot ignore intended meaning just becaus= e a non-compliant application made a small error in the header fields. Ever= yone will be best served if we subject such messages to more analysis, not less.

On the whole I think a set of guidelines in this area is good but it will b= e hard to reach consensus without agreement on some basic underlying princi= ples.  I would suggest that one such principle is to try to do what th= e intended recipient would most likely prefer, which is generally to fix and deliver non-spam messages.

I would also propose some additions to the draft. At Mimecast we see a lot = of messages generated by all sorts of systems and amongst these we see a lo= t of different kinds of message malformations.

I'll suggest more as I think of them but for starters here are a few:

1. Excessively long lines in both headers and body. I commonly see lines th= at are several hundred Kbs in length. These are often valid messages in the= sense that the content is desired by the receiver and in all respects othe= r than line length are well formed. Obviously a limit has to be enforced and I would like to find a consensus = on what sort of limit is reasonable. Initially I felt 8K was a good limit -= it is after all 8 times the limit in RFC 5321. But it appears that this is= too small a limit in real situations. When the limit is exceeded, what is the best option =96 a rejection or &nb= sp;forced line wrap. I am open to both.

2. Invalid characters in headers. I often see headers with un-encoded 8bit = characters. These are often displayed correctly to the recipient where the = client happens upon the correct character set by virtue of chance.
 
3. 8bit characters in MIME sections with a content-transfer-encoding of 7bi= t.

If you have read this far then I think you will agree with me that Murray h= as made a good start on a much needed set of guidelines. Now let's see if w= e can support him to expand on the work he has done and reach a consensus o= n the best approaches.

Simon --_000_C9CC83DE7031stylermimecastcom_-- From bernie@ietf.hoeneisen.ch Thu Apr 14 05:29:43 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2084EE089A for ; Thu, 14 Apr 2011 05:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICUlNPLwQrYv for ; Thu, 14 Apr 2011 05:29:42 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfc.amsl.com (Postfix) with ESMTP id 272BDE068E for ; Thu, 14 Apr 2011 05:29:41 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1QALg6-0000vK-VT; Thu, 14 Apr 2011 14:29:43 +0200 Date: Thu, 14 Apr 2011 14:29:42 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Peter Saint-Andre In-Reply-To: Message-ID: References: <4DA66102.4060200@stpeter.im> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft IETF 80 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:29:43 -0000 Hi Peter et al. On Wed, 13 Apr 2011, Barry Leiba wrote: >> Bernie Hoeneisen: >> IANA Registration of Enumservices for Internet Calendaring >> Session chair: Look for experts on calendaring (small group) first. >> Question: Why shut down ENUM and not work on that there? >> Answer: Leadership wants wg to be shut down. > > More complete answer was that the WG is ending its useful life and is > ready to be shut down, and that at this point this document is more a > calendar issue than an enum issue, so there's little reason to do it > in enum anyway. Correct. My I ask to adjust the minutes to emphasize the fact that the Caldenaring issues are the tricky ones (as the ENUM issues are trivial, once the Calendaring issues are resolved). Proposal: OLD: Question: Why shut down ENUM and not work on that there? Answer: Leadership wants WG to be shut down (outlived its useful life). NEW: Question: Why shut down ENUM and not work on that there? Answer: IETF Leadership wants ENUM WG to be shut down (outlived its useful life). Furthermore, the issues with this document are in the Calendaring space (as opposed to ENUM). cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization From cyrus@daboo.name Thu Apr 14 06:37:33 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9438E089C for ; Thu, 14 Apr 2011 06:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUK1ISY7jqkN for ; Thu, 14 Apr 2011 06:37:33 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfc.amsl.com (Postfix) with ESMTP id 95F5DE087E for ; Thu, 14 Apr 2011 06:37:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B4C881C733473; Thu, 14 Apr 2011 09:37:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXzNlEEjTlCs; Thu, 14 Apr 2011 09:37:19 -0400 (EDT) Received: from [10.0.1.7] (unknown [17.101.34.182]) by daboo.name (Postfix) with ESMTPSA id 2A3811C733466; Thu, 14 Apr 2011 09:37:17 -0400 (EDT) Date: Thu, 14 Apr 2011 09:37:15 -0400 From: Cyrus Daboo To: Barry Leiba , Peter Saint-Andre Message-ID: In-Reply-To: References: <4DA66102.4060200@stpeter.im> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=278 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft IETF 80 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:37:33 -0000 Hi Barry, --On April 13, 2011 11:14:35 PM -0400 Barry Leiba wrote: > Add: > "Action: Ask Cyrus and Bernard to review and address open calendar > questions." And Barry did carry out that action and I am in the process of reviewing. -- Cyrus Daboo From stpeter@stpeter.im Thu Apr 14 06:39:56 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 401F8E0896 for ; Thu, 14 Apr 2011 06:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrl+ThmL0f-5 for ; Thu, 14 Apr 2011 06:39:55 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 5F336E0768 for ; Thu, 14 Apr 2011 06:39:55 -0700 (PDT) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E071240D20; Thu, 14 Apr 2011 07:43:00 -0600 (MDT) Message-ID: <4DA6F929.9070004@stpeter.im> Date: Thu, 14 Apr 2011 07:39:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bernie Hoeneisen References: <4DA66102.4060200@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020507050804060609020303" Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft IETF 80 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:39:56 -0000 This is a cryptographically signed message in MIME format. --------------ms020507050804060609020303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/14/11 6:29 AM, Bernie Hoeneisen wrote: > Question: Why shut down ENUM and not work on that there? > Answer: IETF Leadership wants ENUM WG to be shut down (outlived its > useful life). Furthermore, the issues with this document are in > the Calendaring space (as opposed to ENUM). Fixed. --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020507050804060609020303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx NDEzMzk1M1owIwYJKoZIhvcNAQkEMRYEFLn+/e9M8dBa4dTXWuKRaF8wnkkqMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC4KRfHMtOgqzhl9MNJwR2Pwmt4GucQhDMjwff+hWrAdDYpw3Ww8AhkhuGf wV7NiMjFgnVfl70ZxDN/jZA2Oer07djjChxHYayuzVAkPAHaPW3G+kDIVeardRmqSn2U5IDc HkxHHP35ZcAyg34yBoAc8rl21xC1mtUwPTT9kQmvjuBTYEWqdqcQD5Y8nBSGQSHtu71AjBDp 1CBKQoDHIf4AeeGMiNF7JbSqW4giOyFNI5bUDTzQFDC14aRmdZBl7o7IaOglPnjrcn+tsEvQ cB6O5hw1bu+1+n7ir/rf4lkKKFEAycViftdMAHm9f8uVkh4AO2ujees7yl8AX36ksI+BAAAA AAAA --------------ms020507050804060609020303-- From nsb@guppylake.com Fri Apr 15 02:19:50 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9EA03E065A for ; Fri, 15 Apr 2011 02:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+BNkDKxWt1l for ; Fri, 15 Apr 2011 02:19:49 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfc.amsl.com (Postfix) with ESMTP id 914FFE0693 for ; Fri, 15 Apr 2011 02:19:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=B1juqvmmSk9HYUAbvl1+QJE7Z7Y1dOW71GfjCfabi9y/T/SVkGjsYJnGflsxXXFQsBz/UlaTipwdwQ3cZk1HzForvycUmpc+ErW2LJOBX5PSFlFDXAwrHif/U5CEi0wm; Received: from [213.235.60.14] (helo=[192.168.55.155]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QAfBm-0006gj-QJ for apps-discuss@ietf.org; Fri, 15 Apr 2011 05:19:44 -0400 From: Nathaniel Borenstein Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-46-281949055 Date: Fri, 15 Apr 2011 10:19:39 +0100 In-Reply-To: To: apps-discuss@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:19:50 -0000 --Apple-Mail-46-281949055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2011, at 10:58 AM, Simon Tyler wrote: > https://www1.tools.ietf.org/html/draft-kucherawy-mta-malformed-00 ....... > If you have read this far then I think you will agree with me that = Murray has made a good start on a much needed set of guidelines. Now = let's see if we can support him to expand on the work he has done and = reach a consensus on the best approaches. +1 I have found that a lot of smart, well-intentioned people are repeatedly = reinventing this wheel. Completing and reaching consensus on this = document would be a good way to ease their burden while increasing the = overall consistency of the behavior of email as a complete system. I = encourage everyone who has worked on MTA's to have a look at this = document. -- Nathaniel= --Apple-Mail-46-281949055 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://www1.tools.ietf.org/html/draft-kucherawy-mta-malformed-00=
.......
If you have read this far then I think = you will agree with me that Murray has made a good start on a much = needed set of guidelines. Now let's see if we can support him to expand = on the work he has done and reach a consensus on the best = approaches.

+1

=
I have found that a lot of smart, well-intentioned people are = repeatedly reinventing this wheel.  Completing and reaching = consensus on this document would be a good way to ease their burden = while increasing the overall consistency of the behavior of email as a = complete system.  I encourage everyone who has worked on MTA's to = have a look at this document.  -- Nathaniel
= --Apple-Mail-46-281949055-- From vesely@tana.it Fri Apr 15 07:20:34 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DF26E06A7 for ; Fri, 15 Apr 2011 07:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k01FnRxUHtiq for ; Fri, 15 Apr 2011 07:20:33 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfc.amsl.com (Postfix) with ESMTP id 1EB64E066A for ; Fri, 15 Apr 2011 07:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1302877231; bh=3GbhrzdARO2C0y2aaZNCkLtt8Cr5YftDSG9iACR185Y=; l=765; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=fJT6EPs+7pKCTTF+xpEMAucJ4Vs3PDPLkOKbeTBj4AXyHJcnETkib8LbfIS8JPLHf Xl13Ah1zrNhDZ1DwFIHgq44F3OuD4oVl574Sv1/bepyFk+DH6027uquPxfVFWaSwTR kd0EilTvTi7TbuR/62cZnjteEJxXrMU2L1IJiC3c= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 15 Apr 2011 16:20:31 +0200 id 00000000005DC044.000000004DA8542F.00006458 Message-ID: <4DA8542F.9040003@tana.it> Date: Fri, 15 Apr 2011 16:20:31 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ietf-822 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: apps-discuss Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:20:34 -0000 On 15/Apr/11 14:50, Keith Moore wrote: > I'm strongly opposed to MTAs "fixing" malformed messages (other than > submission servers fixing a small number of known problems caused by > broken mail clients). +1, standardizing fixes implies a standard status for malformed messages. > If an MTA does anything at all when it thinks that a message is > malformed, it should be to bounce it _exactly as it received it > originally_. Bouncing is not quite practical. Rejecting is more viable, but it has to be coordinated with any backup MX. > MTAs trying to fix malformed messages, at best, mask problems further > upstream that should be fixed. At worst, they exacerbate existing > problems and make such problems harder to diagnose. > > Keith From msk@cloudmark.com Fri Apr 15 09:44:19 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0156130028 for ; Fri, 15 Apr 2011 09:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.075 X-Spam-Level: X-Spam-Status: No, score=-104.075 tagged_above=-999 required=5 tests=[AWL=-1.476, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01DEgojoF4Am for ; Fri, 15 Apr 2011 09:44:19 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfc.amsl.com (Postfix) with ESMTP id 35F4D130022 for ; Fri, 15 Apr 2011 09:44:19 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 15 Apr 2011 09:44:18 -0700 From: "Murray S. Kucherawy" To: ietf-822 Date: Fri, 15 Apr 2011 09:44:16 -0700 Thread-Topic: [apps-discuss] Comments on Malformed Message BCP draft Thread-Index: Acv7eEpjy88xpyS2SLKvHto/ZccLaQAE8QAw Message-ID: References: <4DA8542F.9040003@tana.it> In-Reply-To: <4DA8542F.9040003@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: apps-discuss Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:44:20 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Alessandro Vesely > Sent: Friday, April 15, 2011 7:21 AM > To: ietf-822 > Cc: apps-discuss > Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft >=20 > On 15/Apr/11 14:50, Keith Moore wrote: > > I'm strongly opposed to MTAs "fixing" malformed messages (other than > > submission servers fixing a small number of known problems caused by > > broken mail clients). >=20 > +1, standardizing fixes implies a standard status for malformed > messages. The intended status of this document doesn't give any kind of standard stat= us to malformations. It recommends the safest way of handling them if you'= re in an environment where you have to do so rather than simply rejecting t= hem. And the reality is that we (the industry) usually have to do that, so= it seems like a good idea to share the collected wisdom about the best/saf= est way to do so. The fact that MTAs will do one thing with, for example, malformed MIME and = browsers/MUAs do something else is a real problem. From dhc@dcrocker.net Fri Apr 15 09:48:08 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 527A8130044 for ; Fri, 15 Apr 2011 09:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM9G5CR081Dy for ; Fri, 15 Apr 2011 09:48:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id 02996130045 for ; Fri, 15 Apr 2011 09:48:03 -0700 (PDT) Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3FGlsZw017230 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 09:47:59 -0700 Message-ID: <4DA876B6.9050700@dcrocker.net> Date: Fri, 15 Apr 2011 09:47:50 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4DA8542F.9040003@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 15 Apr 2011 09:48:00 -0700 (PDT) Cc: ietf-822 , apps-discuss Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:48:08 -0000 On 4/15/2011 9:44 AM, Murray S. Kucherawy wrote: > The intended status of this document doesn't give any kind of standard status to malformations. It recommends the safest way of handling them if you're in an environment where you have to do so rather than simply rejecting them. And the reality is that we (the industry) usually have to do that, so it seems like a good idea to share the collected wisdom about the best/safest way to do so. Perhaps we need to add a new document classification, given this long-term need to acknowledge and deal with real-world operational pragmatics and the benefit of regularizing them: Best Current Bad Practices d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Fri Apr 15 09:50:37 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EAE9B130043 for ; Fri, 15 Apr 2011 09:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJA3TSKBVink for ; Fri, 15 Apr 2011 09:50:31 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfc.amsl.com (Postfix) with ESMTP id 0667B13001A for ; Fri, 15 Apr 2011 09:50:31 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 35C76116808D; Fri, 15 Apr 2011 17:50:30 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HTo23OV88dq; Fri, 15 Apr 2011 17:50:23 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EC8141168067; Fri, 15 Apr 2011 17:50:22 +0100 (BST) References: <4DA8542F.9040003@tana.it> In-Reply-To: MIME-Version: 1.0 Message-Id: <3111.1302886222.968467@puncture> Date: Fri, 15 Apr 2011 17:50:22 +0100 From: Dave Cridland To: "Murray S\. Kucherawy" , General discussion of application-layer protocols , ietf-822 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:50:38 -0000 On Fri Apr 15 17:44:16 2011, Murray S. Kucherawy wrote: > The fact that MTAs will do one thing with, for example, malformed > MIME and browsers/MUAs do something else is a real problem. I'd be willing to bet that such differences represent a vector for (for example) mail-based trojans. I agree that in the event that MIME is incorrect, there is strong pressure to do *something* with it, and we should try to ensure that that something is aligned. It may be that the discussion suggests rejecting, in which case I suggest the document should clearly explain why, and what the implications of not doing so are, beyond "it makes some problems harder to diagnose". Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Fri Apr 15 09:54:44 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE36D13001A for ; Fri, 15 Apr 2011 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bujh7exJyrOK for ; Fri, 15 Apr 2011 09:54:39 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfc.amsl.com (Postfix) with ESMTP id 7477D13005C for ; Fri, 15 Apr 2011 09:54:39 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 99D251168090; Fri, 15 Apr 2011 17:54:38 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rttgEgdWXzdC; Fri, 15 Apr 2011 17:54:31 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id C32E71168067; Fri, 15 Apr 2011 17:54:30 +0100 (BST) References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> In-Reply-To: <4DA876B6.9050700@dcrocker.net> MIME-Version: 1.0 Message-Id: <3111.1302886470.781218@puncture> Date: Fri, 15 Apr 2011 17:54:30 +0100 From: Dave Cridland To: Dave CROCKER , ietf-822 , General discussion of application-layer protocols , "Murray S\. Kucherawy" Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:54:45 -0000 On Fri Apr 15 17:47:50 2011, Dave CROCKER wrote: > > > On 4/15/2011 9:44 AM, Murray S. Kucherawy wrote: >> The intended status of this document doesn't give any kind of >> standard status to malformations. It recommends the safest way of >> handling them if you're in an environment where you have to do so >> rather than simply rejecting them. And the reality is that we >> (the industry) usually have to do that, so it seems like a good >> idea to share the collected wisdom about the best/safest way to do >> so. > > > Perhaps we need to add a new document classification, given this > long-term need to acknowledge and deal with real-world operational > pragmatics and the benefit of regularizing them: Best Current Bad > Practices I've heard the suggestion of LWP - Least Worst Practise - before. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dhc@dcrocker.net Fri Apr 15 09:56:36 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A417713001A for ; Fri, 15 Apr 2011 09:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM3CZ7Ua0YEJ for ; Fri, 15 Apr 2011 09:56:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id 5EDF113005A for ; Fri, 15 Apr 2011 09:56:32 -0700 (PDT) Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3FGuPtm017613 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 09:56:30 -0700 Message-ID: <4DA878B4.9060007@dcrocker.net> Date: Fri, 15 Apr 2011 09:56:20 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dave Cridland References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> In-Reply-To: <3111.1302886470.781218@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 15 Apr 2011 09:56:30 -0700 (PDT) Cc: ietf-822 , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:56:36 -0000 On 4/15/2011 9:54 AM, Dave Cridland wrote: > I've heard the suggestion of LWP - Least Worst Practise - before. I like that /much/ better than what I suggested. Concise, accurate and appropriately apologetic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From styler@mimecast.com Fri Apr 15 10:26:12 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F38813002E for ; Fri, 15 Apr 2011 10:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+nvSYK8XDnW for ; Fri, 15 Apr 2011 10:26:11 -0700 (PDT) Received: from serviceB.mimecast.com (serviceb.mimecast.com [195.130.217.19]) by ietfc.amsl.com (Postfix) with ESMTP id 5E277E0698 for ; Fri, 15 Apr 2011 10:26:11 -0700 (PDT) Received: from remote.mimecast.com (146.101.202.133 [146.101.202.133]) (Using TLS) by serviceB.mimecast.com; Fri, 15 Apr 2011 18:26:10 +0100 Received: from MC-LON-EXCH02.mcsltd.internal ([::1]) by MC-LON-EXCH02.mcsltd.internal ([::1]) with mapi id 14.01.0255.000; Fri, 15 Apr 2011 18:26:09 +0100 From: Simon Tyler To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Comments on Malformed Message BCP draft Thread-Index: Acv6ioaMMlVzZylWW0aABPApC7cyaQATJ3GgACMOAgAAAyIhgAAFBToAAAAf5AAAADuaAAAAEGQAAAMh1YA= Date: Fri, 15 Apr 2011 17:26:08 +0000 Message-ID: In-Reply-To: <4DA878B4.9060007@dcrocker.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 x-originating-ip: [86.165.30.192] Content-ID: <6010F71055EEE54B81E61BA19BBD318F@mimecast.com> MIME-Version: 1.0 X-MC-Unique: 111041518261000201 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:26:12 -0000 >=20 >=20 > On 4/15/2011 9:54 AM, Dave Cridland wrote: >> I've heard the suggestion of LWP - Least Worst Practise - before. >=20 >=20 > I like that /much/ better than what I suggested. Concise, accurate and > appropriately apologetic. I like this to. It sums it all perfectly - there is no right solution to most of these problems. A best practise implies goodness. A least worst practise implies the minimum badness which is eactly the problem. Simon From moore@network-heretics.com Fri Apr 15 10:38:58 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3B5B6E067E for ; Fri, 15 Apr 2011 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocPH1JuWlaz9 for ; Fri, 15 Apr 2011 10:38:53 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfc.amsl.com (Postfix) with ESMTP id E65F8E0678 for ; Fri, 15 Apr 2011 10:38:52 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 519CC22585; Fri, 15 Apr 2011 13:38:52 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 15 Apr 2011 13:38:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=gVolGe0B/RpBt0ApHGJIZpy+PLk=; b=ZtKYFilYYikUPcHCKJN+VYKhPJd5jNJ5kgro4TWA/HGOp8FLVPOYjPIJrC0H4ihdlVHVGjgaZ3jcSNk6mGbXKnuzdFQRJ+SC6IpqLmvjn51yosZBA191YXe2U3ybI+nYRYRc9okZm0JJ+4Ar2gk3b6BBeuRnjgvqUKyeNLrCZC8= X-Sasl-enc: 3JcWBXk1iJZwDwnffh53p4ThPetGZJjNU6wZnHvuyhLT 1302889131 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id ADDD84033B1; Fri, 15 Apr 2011 13:38:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4DA8542F.9040003@tana.it> Date: Fri, 15 Apr 2011 13:38:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5FBD6703-40D0-482F-B6A5-4C17EC88B9D3@network-heretics.com> References: <4DA8542F.9040003@tana.it> To: Alessandro Vesely X-Mailer: Apple Mail (2.1084) Cc: ietf-822 , apps-discuss Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:38:58 -0000 On Apr 15, 2011, at 10:20 AM, Alessandro Vesely wrote: > On 15/Apr/11 14:50, Keith Moore wrote: >> I'm strongly opposed to MTAs "fixing" malformed messages (other than >> submission servers fixing a small number of known problems caused by >> broken mail clients). >=20 > +1, standardizing fixes implies a standard status for malformed = messages. >=20 >> If an MTA does anything at all when it thinks that a message is >> malformed, it should be to bounce it _exactly as it received it >> originally_. >=20 > Bouncing is not quite practical. Rejecting is more viable, but it has > to be coordinated with any backup MX. Bouncing is absolutely what should happen if the message is merely = malformed. Otherwise, the sender has no idea that his message didn't = arrive (or why), and nothing will ever be done to fix the problem. Keith From moore@network-heretics.com Fri Apr 15 10:48:42 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2982AE0801 for ; Fri, 15 Apr 2011 10:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLP-E6imkVN2 for ; Fri, 15 Apr 2011 10:48:37 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfc.amsl.com (Postfix) with ESMTP id 7C787E07F7 for ; Fri, 15 Apr 2011 10:48:37 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 12D1321E1C; Fri, 15 Apr 2011 13:48:37 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 15 Apr 2011 13:48:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=yb7oRCX59zsD6IpVpdvJZgJCGks=; b=jqgXbpT1NGUfQBj0XGGRhMBBTSurih5uw4+ow9kXAdXJtaFTACEUjhTM9I0hnmzpA8CG3ruoWcNjTwiiC1ZfCKIcnDzBOzeFCbsU7Wz4t9HuiB6/bJLDh7yvLJHrYMHzOpVqqaGEubRzUa/2ily1aMxELmqVLHF6qAMbqvlQ5a0= X-Sasl-enc: fhDbgG+e2t35eEksh4ixm1NiMxpoYe4rlmtfyZrnug5Y 1302889716 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 392C6404659; Fri, 15 Apr 2011 13:48:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4DA878B4.9060007@dcrocker.net> Date: Fri, 15 Apr 2011 13:48:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1084) Cc: ietf-822 , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:48:42 -0000 I do think there's room for some sort of "if you must do this bad thing, = please do it this way" document series from IETF. However, I don't think that would be applicable to having third party = mail relays repair malformed messages. I think that's no longer "best = way to do something that has the potential to do harm" and closer to = "how to make a bad situation worse". =20 Of course, the devil is in the details. Keith On Apr 15, 2011, at 12:56 PM, Dave CROCKER wrote: >=20 >=20 >=20 > On 4/15/2011 9:54 AM, Dave Cridland wrote: >> I've heard the suggestion of LWP - Least Worst Practise - before. >=20 >=20 > I like that /much/ better than what I suggested. Concise, accurate = and appropriately apologetic. >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 From dave@cridland.net Fri Apr 15 10:50:51 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D6D1E06A4 for ; Fri, 15 Apr 2011 10:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxl8Z8KU63F5 for ; Fri, 15 Apr 2011 10:50:46 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfc.amsl.com (Postfix) with ESMTP id 0572FE0663 for ; Fri, 15 Apr 2011 10:50:46 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id D85BC1168087; Fri, 15 Apr 2011 18:50:44 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ5q0MZb+hcS; Fri, 15 Apr 2011 18:50:37 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B37A51168067; Fri, 15 Apr 2011 18:50:36 +0100 (BST) References: <4DA8542F.9040003@tana.it> <5FBD6703-40D0-482F-B6A5-4C17EC88B9D3@network-heretics.com> In-Reply-To: <5FBD6703-40D0-482F-B6A5-4C17EC88B9D3@network-heretics.com> MIME-Version: 1.0 Message-Id: <3111.1302889836.721157@puncture> Date: Fri, 15 Apr 2011 18:50:36 +0100 From: Dave Cridland To: Keith Moore , ietf-822 , General discussion of application-layer protocols , Alessandro Vesely Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:50:51 -0000 On Fri Apr 15 18:38:50 2011, Keith Moore wrote: > Bouncing is absolutely what should happen if the message is merely > malformed. Otherwise, the sender has no idea that his message > didn't arrive (or why), and nothing will ever be done to fix the > problem. But the problem is that the message didn't arrive. The reason is that it's malformed, but that's not the problem that people care most about. Now, *we* may care, but that's a wholly different thing, and largely irrelevant to the average user. Bouncing has problems too - it's trivial to use such a server to bounce malformed MIME back to some other address which then processes the MIME and allows some malware through. As I said before, differences in error handling behaviour may result in malware vectors being available. If you standardize the error handling (to whatever you like - pass through, bounce, or reject) then the net result is that exploits of this form cannot happen. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From msk@cloudmark.com Fri Apr 15 10:58:30 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71D5FE0747 for ; Fri, 15 Apr 2011 10:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.033 X-Spam-Level: X-Spam-Status: No, score=-104.033 tagged_above=-999 required=5 tests=[AWL=-1.434, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6-95NL2eryx for ; Fri, 15 Apr 2011 10:58:29 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfc.amsl.com (Postfix) with ESMTP id C4269E0663 for ; Fri, 15 Apr 2011 10:58:29 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 15 Apr 2011 10:58:29 -0700 From: "Murray S. Kucherawy" To: Keith Moore , "dcrocker@bbiw.net" Date: Fri, 15 Apr 2011 10:58:28 -0700 Thread-Topic: [apps-discuss] Comments on Malformed Message BCP draft Thread-Index: Acv7lVmz58aJDS1WT7+4a0TUielzcgAAT2GA Message-ID: References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ietf-822 , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:58:30 -0000 > -----Original Message----- > From: Keith Moore [mailto:moore@network-heretics.com] > Sent: Friday, April 15, 2011 10:49 AM > To: dcrocker@bbiw.net > Cc: Dave Cridland; ietf-822; General discussion of application-layer prot= ocols; Murray S. Kucherawy > Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft >=20 > I do think there's room for some sort of "if you must do this bad > thing, please do it this way" document series from IETF. >=20 > However, I don't think that would be applicable to having third party > mail relays repair malformed messages. I think that's no longer "best > way to do something that has the potential to do harm" and closer to > "how to make a bad situation worse". >=20 > Of course, the devil is in the details. I don't think this work is targeted at intermediaries. In fact, I'd be com= pletely fine with expressly saying it's meant to address processing at ingr= ess MTAs only. From moore@network-heretics.com Fri Apr 15 11:00:29 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FA7DE0886 for ; Fri, 15 Apr 2011 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki7ZZjWpuTk5 for ; Fri, 15 Apr 2011 11:00:24 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfc.amsl.com (Postfix) with ESMTP id A70ECE07CF for ; Fri, 15 Apr 2011 11:00:24 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 71B8D223AE; Fri, 15 Apr 2011 14:00:24 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 15 Apr 2011 14:00:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=kKkpLuNUCMIN72S2CLgN05CzuAk=; b=mp9UdGSkLwGHidSkB5J4mkr4vPFAkYMbXcSeo4ElGugQv8nqzfIAdw5EAXSk/RX19vV1Z6E2gr/4zX2IMU05Ou9hlMTfv4pOh/Qbzmem9/ZH6Kulc1cKnUooiq86SEnk/cltbuWrCkC+Ah42XLvwiTcBpu7xBqWhqLI/DbQBlCk= X-Sasl-enc: wwPunYhhuyEguHXadkKmTExWgHsyX8j23JwNe4+ogYzC 1302890424 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B6151400969; Fri, 15 Apr 2011 14:00:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <3111.1302889836.721157@puncture> Date: Fri, 15 Apr 2011 14:00:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38DD2AED-CDEC-4AFE-80B9-DB8867B715FA@network-heretics.com> References: <4DA8542F.9040003@tana.it> <5FBD6703-40D0-482F-B6A5-4C17EC88B9D3@network-heretics.com> <3111.1302889836.721157@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1084) Cc: ietf-822 , General discussion of application-layer protocols , Alessandro Vesely Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:00:29 -0000 By default, MTAs should not care about the contents of a message. To do = so is a layering violation. The message should be opaque and the MTA = should look only at the envelope. The only "standard" exception is = 8bit to 7bit conversion, which hopefully is rarely an issue these days. =20= So the fact that a message is "malformed" should not prevent delivery of = that message. But if MTAs are going to care about contents of messages (say, for the = purpose of filtering spam or viruses, which pretty much everyone will = acknowledge as necessary measures against evil these days), then there = will inevitably be cases where the MTAs are unable to parse those = contents, presumably because the messages are malformed. If the spam or = virus filter can reliably tell that the message is spam or a virus, = dropping it is the proper thing to do. But if the filter cannot tell, = or cannot parse the message because it is malformed, bouncing it is = probably better. The problem of using MIME to send malware exists whether or not the = message is bounced. Bouncing messages, if properly done, does not = amplify the problem, because there should never be more than one bounce = address. Either the message containing malware is delivered (in which = case the recipient UA deals with the threat) or it is bounced (in which = case the "return-path" UA deals with the threat). And again, if = properly done, bouncing should not "mask" the source of the malware, = because the Received headers should be present in the returned content = in any case. =20 Keith On Apr 15, 2011, at 1:50 PM, Dave Cridland wrote: > On Fri Apr 15 18:38:50 2011, Keith Moore wrote: >> Bouncing is absolutely what should happen if the message is merely = malformed. Otherwise, the sender has no idea that his message didn't = arrive (or why), and nothing will ever be done to fix the problem. >=20 > But the problem is that the message didn't arrive. The reason is that = it's malformed, but that's not the problem that people care most about. = Now, *we* may care, but that's a wholly different thing, and largely = irrelevant to the average user. >=20 > Bouncing has problems too - it's trivial to use such a server to = bounce malformed MIME back to some other address which then processes = the MIME and allows some malware through. >=20 > As I said before, differences in error handling behaviour may result = in malware vectors being available. If you standardize the error = handling (to whatever you like - pass through, bounce, or reject) then = the net result is that exploits of this form cannot happen. >=20 > Dave. > --=20 > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From moore@network-heretics.com Fri Apr 15 11:03:48 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC2C1E08CB for ; Fri, 15 Apr 2011 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnAHKxgkeVgz for ; Fri, 15 Apr 2011 11:03:44 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfc.amsl.com (Postfix) with ESMTP id 80E08E08C5 for ; Fri, 15 Apr 2011 11:03:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 48F5E220FE; Fri, 15 Apr 2011 14:03:44 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 15 Apr 2011 14:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=1baJbPfeOoM28aIKJQ4gXrO8VqQ=; b=rkIVTDdfJsfzwoM/k+jdFtpwc11GKIoP9x8kkSMYxPPvudH239vyPFImr29oM/SqZ3tLS831B5KNGFf+jHybbym1T/IOektLDXSGspTe6g6TArPkXyDuTrtXuZhObT7NH8L/bg+AqyN/Qfvt9Ty8odNxZL23kS7pi7kKVtTYLBk= X-Sasl-enc: EnW9KHh9aI/MS/RTK0JAL48Kaux42Z7i1dE5Rh1Ak4x/ 1302890623 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7BEF4400969; Fri, 15 Apr 2011 14:03:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 15 Apr 2011 14:03:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31CA05AC-E602-48EE-B78E-8B093B3C8CE4@network-heretics.com> References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1084) Cc: ietf-822 , "dcrocker@bbiw.net" , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:03:48 -0000 Well, I'm all for having submission servers (listening to port 587, = requiring authentication, etc.) check for *822/MIME syntax errors, and = correct obvious flaws in the message content. Though I still think that = sometimes it's better if they bounce those messages, so that users can = know that their MUAs are broken. Of course there will be pressure on = ISPs to support messages generated by broken MUAs. Accepting mail submissions on port 25 is something that should have been = phased out 10 years ago. Keith On Apr 15, 2011, at 1:58 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Keith Moore [mailto:moore@network-heretics.com] >> Sent: Friday, April 15, 2011 10:49 AM >> To: dcrocker@bbiw.net >> Cc: Dave Cridland; ietf-822; General discussion of application-layer = protocols; Murray S. Kucherawy >> Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft >>=20 >> I do think there's room for some sort of "if you must do this bad >> thing, please do it this way" document series from IETF. >>=20 >> However, I don't think that would be applicable to having third party >> mail relays repair malformed messages. I think that's no longer = "best >> way to do something that has the potential to do harm" and closer to >> "how to make a bad situation worse". >>=20 >> Of course, the devil is in the details. >=20 > I don't think this work is targeted at intermediaries. In fact, I'd = be completely fine with expressly saying it's meant to address = processing at ingress MTAs only. >=20 From jdfalk-lists@cybernothing.org Fri Apr 15 11:26:09 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 625CFE0716 for ; Fri, 15 Apr 2011 11:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpcBVQKWeYiI for ; Fri, 15 Apr 2011 11:26:08 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfc.amsl.com (Postfix) with ESMTP id 7E8D2E0690 for ; Fri, 15 Apr 2011 11:26:08 -0700 (PDT) Received: from [192.168.11.34] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3FIQ4vN013914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 11:26:07 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p3FIQ4vN013914 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1302891967; bh=0UQ07+USBkJYqlznW/gt5FBrS2ByEVeTYiknH33Ca vg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=dfpHpXm9CpNt fsfsg3nUsyVG8faJwqUNjEe1B4rjh384KymfP9gjDMRFzQ9FI3xoSA8ZT7wq+EG6/qg 3+sg+X4iyOWZLaYcCO1muaTFT5BfVO6ovqeCocjo5n63D+MyAhXXLnUQW/EZgMlh6jx wsydGrPrqWa/lzb4Ntpq5m/qE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: Date: Fri, 15 Apr 2011 11:26:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:26:09 -0000 On Apr 15, 2011, at 10:26 AM, Simon Tyler wrote: >> On 4/15/2011 9:54 AM, Dave Cridland wrote: >>> I've heard the suggestion of LWP - Least Worst Practise - before. >>=20 >>=20 >> I like that /much/ better than what I suggested. Concise, accurate = and >> appropriately apologetic. >=20 > I like this to. It sums it all perfectly - there is no right solution = to > most of these problems. A best practise implies goodness. A least = worst > practise implies the minimum badness which is eactly the problem. +1 But in the meantime, I think the BCP stream is the right place for this = document. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From arnt@gulbrandsen.priv.no Fri Apr 15 14:25:54 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA789E06B8 for ; Fri, 15 Apr 2011 14:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6wx9QZ8ot+6 for ; Fri, 15 Apr 2011 14:25:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfc.amsl.com (Postfix) with ESMTP id 40EC0E0673 for ; Fri, 15 Apr 2011 14:25:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id 79378F8C008; Fri, 15 Apr 2011 21:25:52 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.3) with esmtpsa id 1302902751-1279-1278/9/450; Fri, 15 Apr 2011 23:25:51 +0200 Message-Id: <4DA8B7DD.3030909@gulbrandsen.priv.no> Date: Fri, 15 Apr 2011 23:25:49 +0200 From: Arnt Gulbrandsen Organization: Me, http://arnt.gulbrandsen.priv.no User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 Mime-Version: 1.0 To: "Murray S. Kucherawy" References: <4DA8542F.9040003@tana.it> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: ietf-822@imc.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:25:55 -0000 I found the advice rather na=EFve. Not bad, but also not very=20 sophisticated, and I fear that extending it to be comprehensive will not=20 produce a readable document. Still, I can see value in a document whose abstract says "here are some=20 of the bad things you must expect to receive, and not just from=20 spammers". Is that the goal of your draft? Arnt From msk@cloudmark.com Fri Apr 15 15:20:54 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F976E06B1 for ; Fri, 15 Apr 2011 15:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.553 X-Spam-Level: X-Spam-Status: No, score=-104.553 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feNHp8+Ee8Dj for ; Fri, 15 Apr 2011 15:20:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfc.amsl.com (Postfix) with ESMTP id C2BB0E0688 for ; Fri, 15 Apr 2011 15:20:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 15 Apr 2011 15:20:52 -0700 From: "Murray S. Kucherawy" To: Arnt Gulbrandsen Date: Fri, 15 Apr 2011 15:20:50 -0700 Thread-Topic: [apps-discuss] Comments on Malformed Message BCP draft Thread-Index: Acv7s7gPWXfDv5H3Sjii4WO/iHLk/wAB4aRw Message-ID: References: <4DA8542F.9040003@tana.it> <4DA8B7DD.3030909@gulbrandsen.priv.no> In-Reply-To: <4DA8B7DD.3030909@gulbrandsen.priv.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-822@imc.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:20:54 -0000 > -----Original Message----- > From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] > Sent: Friday, April 15, 2011 2:26 PM > To: Murray S. Kucherawy > Cc: ietf-822@imc.org; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft >=20 > I found the advice rather na=EFve. Not bad, but also not very > sophisticated, and I fear that extending it to be comprehensive will not > produce a readable document. It's meant only as a starting point. And I think extending it, if done car= efully, will produce something readable and valuable. > Still, I can see value in a document whose abstract says "here are some > of the bad things you must expect to receive, and not just from > spammers". Is that the goal of your draft? "...and what the consensus view is about what to do with them," precisely. From masinter@adobe.com Fri Apr 15 18:46:20 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8DD27E06A5 for ; Fri, 15 Apr 2011 18:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL9RptatMkCm for ; Fri, 15 Apr 2011 18:46:18 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfc.amsl.com (Postfix) with ESMTP id 56039E061E for ; Fri, 15 Apr 2011 18:46:17 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTaj03MC/vMcOqpTDzscDjweaM1c/8tM6@postini.com; Fri, 15 Apr 2011 18:46:18 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p3G1j9ES008437; Fri, 15 Apr 2011 18:45:10 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p3G1jx1R029517; Fri, 15 Apr 2011 18:46:00 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 15 Apr 2011 18:45:59 -0700 From: Larry Masinter To: "Murray S. Kucherawy" , Arnt Gulbrandsen Date: Fri, 15 Apr 2011 18:45:57 -0700 Thread-Topic: [apps-discuss] Comments on Malformed Message BCP draft Thread-Index: Acv7s7gPWXfDv5H3Sjii4WO/iHLk/wAB4aRwAAcDhhA= Message-ID: References: <4DA8542F.9040003@tana.it> <4DA8B7DD.3030909@gulbrandsen.priv.no> In-Reply-To: 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_C68CB012D9182D408CED7B884F441D4D05A07766EDnambxv01acorp_" MIME-Version: 1.0 Cc: "ietf-822@imc.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 01:46:20 -0000 --_000_C68CB012D9182D408CED7B884F441D4D05A07766EDnambxv01acorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One might note that the same kind of difficult debate over 'error handling'= has been at the root of much controversy in HTML land. Don't many MTAs actually implement the same "sniffing" for content-type and= charset as is being proposed in http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-02 It was my impression they did. Is "wrong content-type" a "malformed message"? Larry -- http://larry.masinter.net -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Friday, April 15, 2011 3:21 PM To: Arnt Gulbrandsen Cc: ietf-822@imc.org; apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft > -----Original Message----- > From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] > Sent: Friday, April 15, 2011 2:26 PM > To: Murray S. Kucherawy > Cc: ietf-822@imc.org; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft > > I found the advice rather na=EFve. Not bad, but also not very > sophisticated, and I fear that extending it to be comprehensive will not > produce a readable document. It's meant only as a starting point. And I think extending it, if done car= efully, will produce something readable and valuable. > Still, I can see value in a document whose abstract says "here are some > of the bad things you must expect to receive, and not just from > spammers". Is that the goal of your draft? "...and what the consensus view is about what to do with them," precisely. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_C68CB012D9182D408CED7B884F441D4D05A07766EDnambxv01acorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

One might not= e that the same kind of difficult debate over 'error handling' has been at = the root of much controversy in HTML land.

 

Don’t many MTAs ac= tually implement the same "sniffing" for content-type and charset= as is being proposed in

http://tools.ie= tf.org/html/draft-ietf-websec-mime-sniff-02

It was my impression they did.

 

Is “wrong content-t= ype” a “malformed message”?

 

Larry

<= p class=3DMsoPlainText>--

http://larr= y.masinter.net

 

<= p class=3DMsoPlainText>-----Original Message-----
From: apps-discuss-bou= nces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S.= Kucherawy
Sent: Friday, April 15, 2011 3:21 PM
To: Arnt Gulbrandsen<= br>Cc: ietf-822@imc.org; apps-discuss@ietf.org
Subject: Re: [apps-discus= s] Comments on Malformed Message BCP draft

=  

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

> From: Arnt Gulbrandsen [mailto:arnt= @gulbrandsen.priv.no]

> Sent: Frid= ay, April 15, 2011 2:26 PM

> To: M= urray S. Kucherawy

> Cc: ietf-822@= imc.org; apps-discuss@ietf.org

> S= ubject: Re: [apps-discuss] Comments on Malformed Message BCP draft

>

&= gt; I found the advice rather na=EFve. Not bad, but also not very

> sophisticated, and I fear that extending = it to be comprehensive will not

> = produce a readable document.

&nb= sp;

It's meant only as a starting point.= =A0 And I think extending it, if done carefully, will produce something rea= dable and valuable.

 =

> Still, I can see value in a document whose= abstract says "here are some

&g= t; of the bad things you must expect to receive, and not just from

> spammers". Is that the goal of your= draft?

 

"...and what the consensus view is about what to do wi= th them," precisely.

 =

_________________________________________= ______

apps-discuss mailing list=

= apps-discuss@ietf.org=

https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>

= --_000_C68CB012D9182D408CED7B884F441D4D05A07766EDnambxv01acorp_-- From nsb@guppylake.com Sat Apr 16 01:27:48 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C30EE06ED for ; Sat, 16 Apr 2011 01:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mUCMOvQBHCN for ; Sat, 16 Apr 2011 01:27:46 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfc.amsl.com (Postfix) with ESMTP id 48A18E06C9 for ; Sat, 16 Apr 2011 01:27:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=NdOSbS2TlBHPzLC/8/fP4QlF+ElE1cmXisWt6qipycwJDJ1K0DdaqtgNEucZpP9i2xr2MTtejzAMAmIKwZ1kJndIoBrUnq94EBMdsbxQpSQ6djKZXQ4ewGJJXTL7qpYa; Received: from cpc6-acto6-0-0-cust187.4-2.cable.virginmedia.com ([86.13.124.188] helo=[192.168.0.2]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QB0qw-0005kn-Vj; Sat, 16 Apr 2011 04:27:39 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25-365224745 From: Nathaniel Borenstein In-Reply-To: Date: Sat, 16 Apr 2011 09:27:35 +0100 Message-Id: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> References: To: Keith Moore X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: ietf-822@imc.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 08:27:48 -0000 --Apple-Mail-25-365224745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Although all my basic instincts are in agreement with Keith's position = -- the only way you will ever persuade message senders to comply more = fully with the standards is to reject their non-compliant messages -- my = recent experience has turned me 180 degrees and convinced me that this = position is hopelessly idealistic. =20 As some of you know, I have only recently returned to work at a company = (Mimecast) whose primary business includes the maintenance and operation = of a large-scale MTA. The situation has changed a lot in the last ten = (not to say twenty) years, and in many ways not for the better. Today's = commercial reality is a race to the bottom that more or less guarantees = that MTAs will do precisely what Keith says they should not do, which = means, to my mind, that it behooves us to document our collective wisdom = on the least harmful and most consistent way to do it. A single example should make this clear: Nearly every business now = receives its mail via some third party email security mechanism -- = perhaps an appliance, perhaps locally installed code, and increasingly a = cloud-based service. Competition among these third parties is fierce, = and inevitably standards compliance is far less of a driver of business = decisions than customer satisfaction. Imagine, then, that company X, = which enforces the standards very strictly, as Keith advocates, manages = to "steal" a customer from company Y, which does not. All of a sudden = -- and I assure you this really happens -- a host of = slightly-misformatted but customer-desired messages which were delivered = by company Y will start getting blocked by company X. The customer, = inevitably, will scream bloody murder. They won't care that company X = is doing a better job of enforcing the standards, they will only care = that company X is -- wrongly, in their eyes -- blocking desirable = streams of messages that the previous vendor delivered with no visible = problem. The generalization is clear: the financial and business = incentive is to deliver every message that you can possibly figure out = how to deliver, so that your service doesn't appear "inferior" to = customers who don't give a rat's rump about the details of standards = compliance. I'm not sure why this came as such a surprise to me, as it is actually = just another instance of Postel's Law. Being liberal in what we accept = means, in this case, accepting and delivering any message where we = believe, with a high level of confidence, that the sender's intentions = are clear despite its standards violations. I can tell you that nothing the IETF says is likely to have any effect = on whether or not Mimecast tries to "fix" and deliver such messages -- = we do and we will, as do nearly all of our competitors, because although = we care what the IETF says, we have no choice but to care what our = paying customers say even more. However, if the IETF offered guidance = on the least harmful way to do this, the odds are good that we would = follow it. And I think it would be better if vendors who felt the need = to "fix" messages would at least be mutually consistent in how they fix = them. One (probably controversial) idea that might reduce our collective angst = would be to specify that, when an MTA fixes such a message, it also = generates an explanatory/warning message back to the sender or the = sender's postmaster (perhaps limited to 1 message per day per = malformation type). That way we might not be exacerbating existing = problems quite as much as Keith and other (myself included) fear. And = the senders of misformatted messages might eventually fix their code, if = only to shut up the annoying warning messages. -- Nathaniel On Apr 15, 2011, at 1:50 PM, Keith Moore wrote: > I'm strongly opposed to MTAs "fixing" malformed messages (other than = submission servers fixing a small number of known problems caused by = broken mail clients). > If an MTA does anything at all when it thinks that a message is = malformed, it should be to bounce it _exactly as it received it = originally_. >=20 > MTAs trying to fix malformed messages, at best, mask problems further = upstream that should be fixed. At worst, they exacerbate existing = problems and make such problems harder to diagnose. >=20 > Keith >=20 > On Apr 14, 2011, at 3:07 PM, Murray S. Kucherawy wrote: >=20 >> This is some work starting up in the APPS area. Please comment on = the apps-discuss list if you=92re interested in participating. >> =20 >> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Simon Tyler >> Sent: Thursday, April 14, 2011 2:59 AM >> To: apps-discuss@ietf.org >> Subject: [apps-discuss] Comments on Malformed Message BCP draft >> =20 >> Hi, >> =20 >> Having read the Malformed Message BCP draft I am interested in = getting some discussion going on its content and to find the best way = forward. >> =20 >> For those who missed it, the draft is at: >>=20 >> https://www1.tools.ietf.org/html/draft-kucherawy-mta-malformed-00 >>=20 >> I have a few comments on it. >>=20 >> One thing that concerns me is the proposal that processing should = stop when certain malformations are identified. >>=20 >> For example it is proposed that should a badly wrapped header field = be found (quite how we define this is left open, I presume a line that = does not start with a valid header field name followed by a colon) then = the processing agent should treat this as the end of the header. My = feeling is that this opens up a greater potential hole than the one = closed and that can be exploited. >>=20 >> An example of the type of issue this could is cause is that should = such a malformation occur before the MIME header fields in the header = then this would cause the rest of the header and the message body to be = treated as plain text. This could cause content analysis system to fail = as they would not interpret the MIME content in the way that was = presumably intended. >>=20 >> Given that these recommendations are unlikely to be followed by all = clients and servers, I feel that this suggestion will allow content = through an agent without suitable processing. My preference on this = particular malformation would be to continue processing the header = fields, this is based on the assumption that what follows the malformed = header field is more likely to be further header fields and not body = content. What we do with the malformed header field I am less certain = about. We could just ignore it or we could treat it as part of the = previous header field - both will be right as often as they wrong. I = would welcome some additional thoughts on this. >>=20 >> I have similar feelings about some of the other suggestions including = the lack of a MIME-Version header. We cannot ignore intended meaning = just because a non-compliant application made a small error in the = header fields. Everyone will be best served if we subject such messages = to more analysis, not less. >>=20 >> On the whole I think a set of guidelines in this area is good but it = will be hard to reach consensus without agreement on some basic = underlying principles. I would suggest that one such principle is to = try to do what the intended recipient would most likely prefer, which is = generally to fix and deliver non-spam messages. >>=20 >> I would also propose some additions to the draft. At Mimecast we see = a lot of messages generated by all sorts of systems and amongst these we = see a lot of different kinds of message malformations. >>=20 >> I'll suggest more as I think of them but for starters here are a few: >>=20 >> 1. Excessively long lines in both headers and body. I commonly see = lines that are several hundred Kbs in length. These are often valid = messages in the sense that the content is desired by the receiver and in = all respects other than line length are well formed. Obviously a limit = has to be enforced and I would like to find a consensus on what sort of = limit is reasonable. Initially I felt 8K was a good limit - it is after = all 8 times the limit in RFC 5321. But it appears that this is too small = a limit in real situations. When the limit is exceeded, what is the best = option =96 a rejection or forced line wrap. I am open to both.=20 >>=20 >> 2. Invalid characters in headers. I often see headers with un-encoded = 8bit characters. These are often displayed correctly to the recipient = where the client happens upon the correct character set by virtue of = chance. >> =20 >> 3. 8bit characters in MIME sections with a content-transfer-encoding = of 7bit. >>=20 >> If you have read this far then I think you will agree with me that = Murray has made a good start on a much needed set of guidelines. Now = let's see if we can support him to expand on the work he has done and = reach a consensus on the best approaches. >>=20 >> Simon >> >=20 --Apple-Mail-25-365224745 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I'm not = sure why this came as such a surprise to me, as it is actually just = another instance of Postel's Law.  Being liberal in what we accept = means, in this case, accepting and delivering any message where we = believe, with a high level of confidence, that the sender's intentions = are clear despite its standards violations.

I = can tell you that nothing the IETF says is likely to have any effect on = whether or not Mimecast tries to "fix" and deliver such messages -- we = do and we will, as do nearly all of our competitors, because although we = care what the IETF says, we have no choice but to care what our paying = customers say even more.  However, if the IETF offered guidance on = the least harmful way to do this, the odds are good that we would follow = it.  And I think it would be better if vendors who felt the need to = "fix" messages would at least be mutually consistent in how they fix = them.

One (probably controversial) idea that = might reduce our collective angst would be to specify that, when an MTA = fixes such a message, it also generates an explanatory/warning message = back to the sender or the sender's postmaster (perhaps limited to 1 = message per day per malformation type).  That way we might not be = exacerbating existing problems quite as much as Keith and other (myself = included) fear.  And the senders of misformatted messages might = eventually fix their code, if only to shut up the annoying warning = messages.  -- = Nathaniel



On Apr = 15, 2011, at 1:50 PM, Keith Moore wrote:

I'm strongly opposed to MTAs = "fixing" malformed messages (other than submission servers fixing a = small number of known problems caused by broken mail clients).
If an = MTA does anything at all when it thinks that a message is malformed, it = should be to bounce it _exactly as it received it = originally_.

MTAs trying to fix malformed = messages, at best, mask problems further upstream that should be fixed. =   At worst, they exacerbate existing problems and make such = problems harder to = diagnose.

Keith

On Apr = 14, 2011, at 3:07 PM, Murray S. Kucherawy wrote:

This = is some work starting up in the APPS area.  Please comment on the = apps-discuss list if you=92re interested in = participating.
 apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@= ietf.org] On Behalf = Of Simon = Tyler
Sent: Thursday, April 14, 2011 = 2:59 AM
To:  [apps-discuss] Comments on = Malformed Message BCP draft
 
<ATT00001..= txt>

=
= --Apple-Mail-25-365224745-- From jaap@bartok.nlnetlabs.nl Sat Apr 16 01:39:20 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5F5FBE06AB for ; Sat, 16 Apr 2011 01:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRKW9+M6fYYm for ; Sat, 16 Apr 2011 01:39:19 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfc.amsl.com (Postfix) with ESMTP id B7026E0675 for ; Sat, 16 Apr 2011 01:39:19 -0700 (PDT) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3G8dD5X087566; Sat, 16 Apr 2011 10:39:13 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201104160839.p3G8dD5X087566@bartok.nlnetlabs.nl> To: Nathaniel Borenstein In-reply-to: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> References: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> Comments: In-reply-to Nathaniel Borenstein message dated "Sat, 16 Apr 2011 09:27:35 +0100." Date: Sat, 16 Apr 2011 10:39:13 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.6 (bartok.nlnetlabs.nl [127.0.0.1]); Sat, 16 Apr 2011 10:39:14 +0200 (CEST) Cc: ietf-822@imc.org, Keith Moore , apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 08:39:20 -0000 And the senders of misformatted messages might eventually fix their code, if only to shut up the annoying warning messages. And the easiest way to do that is declare these as spam, so nothing will be fixed in the end. jaap From sm@elandsys.com Sat Apr 16 06:46:35 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8CB13E06B9; Sat, 16 Apr 2011 06:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td6czDip2G8V; Sat, 16 Apr 2011 06:46:33 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 2163EE06B5; Sat, 16 Apr 2011 06:46:32 -0700 (PDT) Received: from subman.elandsys.com ([41.136.238.139]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p3GDkHhk018537; Sat, 16 Apr 2011 06:46:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1302961586; bh=6Y+SVYxi38nC9+uv1qrZOpVjoXc=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=kzmdGMCrkqmPvkEimXIP5X67YXGw/AdCsA0uEsbg6whxYj1h3wcQZidBwJCnynqBY KJll5Z2cSd/ICAh8aWlLgN3l1ucE3yWYKdRBF+SCccQgeozixtDuJqThw99NRYpCf9 V1heLTn3V/g2RRKs6gOWONGVX4JvxR2AGSOVGil0= Message-Id: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Apr 2011 06:43:30 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Randall Gellens , Per Frojdh , David Singer , iesg@ietf.org Subject: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 13:46:35 -0000 Hello, I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-gellens-mime-bucket-bis-03 Reviewer: S. Moonesamy Review Date: April 16, 2011 IETF Last Call Date: Unknown IESG Telechat Date: Unknown Summary: This draft is almost ready for publication as a Proposed Standard but has a few nits that should be fixed before publication. The Codecs Parameter for "Bucket" Media Types was specified in RFC 4281. This draft specifies the Codecs and Profiles Parameters for "Bucket" Media Types. As it is a significant change from RFC 4281, it does not fit the requirements specified in RFC 2026 for Draft Standard. Please refer to RFC 5657 for additional information about how to advance a protocol to Draft Standard. Please note that I have not read ISO/IEC 14496-15:2010, a normative reference, as it is not freely available. Major Issues: None Minor Issues: None Nits: draft-gellens-mime-bucket-bis-03 obsoletes RFC 4281 but there is no mention of that in the Abstract Section or the rest of the document. In Section 3.1: "An element MAY include an octet that must be encoded in order to comply with [RFC2045]" I suggest capitalizing the "must" as key words are capitalized in that sentence. "Note that, when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so must themselves be encoded." I suggest capitalizing the "must". In Section 4.2: "An element MAY include an octet that must be encoded in order to comply with [RFC2045]" I suggest capitalizing the "must". "Note that, when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so must themselves be encoded." I suggest capitalizing the "must". Regards, S. Moonesamy From moore@network-heretics.com Sat Apr 16 07:45:40 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7588EE06EC for ; Sat, 16 Apr 2011 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSnyqxeklLj6 for ; Sat, 16 Apr 2011 07:45:39 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfc.amsl.com (Postfix) with ESMTP id 3722BE06A0 for ; Sat, 16 Apr 2011 07:45:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 598E320907; Sat, 16 Apr 2011 10:45:38 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 16 Apr 2011 10:45:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=QSBn/XG6HUGTa7tjjZhZAn3CPRo=; b=O5Y9rEOizOIoza3n72v89EasBwd+W1vFE2vdNjOoUKZ8HpptB3TyZ5K/TBI7fhQAiPrzLQowmdfMdCFB8Tj2sHYkMnu9sqU1O1hEEvyZwT/9TXfoMlP5rWj7X0752NfCCmQoyK/gMFrbaqtbBlCyT9alpO7hAr0VT41nMA/8puo= X-Sasl-enc: 4OBAk9oBoPENErHdQS7CD+LllMRcD7NhZf4hdqjKi7kq 1302965137 Received: from [10.59.1.54] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id C696040820E; Sat, 16 Apr 2011 10:45:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> Date: Sat, 16 Apr 2011 10:45:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B400643-FD39-43EE-8AE7-E17030765CCE@network-heretics.com> References: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> To: Nathaniel Borenstein X-Mailer: Apple Mail (2.1084) Cc: ietf-822@imc.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 14:45:40 -0000 On Apr 16, 2011, at 4:27 AM, Nathaniel Borenstein wrote: > Although all my basic instincts are in agreement with Keith's position = -- the only way you will ever persuade message senders to comply more = fully with the standards is to reject their non-compliant messages -- my = recent experience has turned me 180 degrees and convinced me that this = position is hopelessly idealistic. =20 >=20 > As some of you know, I have only recently returned to work at a = company (Mimecast) whose primary business includes the maintenance and = operation of a large-scale MTA. The situation has changed a lot in the = last ten (not to say twenty) years, and in many ways not for the better. = Today's commercial reality is a race to the bottom that more or less = guarantees that MTAs will do precisely what Keith says they should not = do, which means, to my mind, that it behooves us to document our = collective wisdom on the least harmful and most consistent way to do it. >=20 > A single example should make this clear: Nearly every business now = receives its mail via some third party email security mechanism -- = perhaps an appliance, perhaps locally installed code, and increasingly a = cloud-based service. Competition among these third parties is fierce, = and inevitably standards compliance is far less of a driver of business = decisions than customer satisfaction. Imagine, then, that company X, = which enforces the standards very strictly, as Keith advocates, manages = to "steal" a customer from company Y, which does not. All of a sudden = -- and I assure you this really happens -- a host of = slightly-misformatted but customer-desired messages which were delivered = by company Y will start getting blocked by company X. The customer, = inevitably, will scream bloody murder. They won't care that company X = is doing a better job of enforcing the standards, they will only care = that company X is -- wrongly, in their eyes -- blocking desirable = streams of messages that the previous vendor delivered with no visible = problem. The generalization is clear: the financial and business = incentive is to deliver every message that you can possibly figure out = how to deliver, so that your service doesn't appear "inferior" to = customers who don't give a rat's rump about the details of standards = compliance. This is why I think the checking for syntax and either correct or = rejection of malformed messages needs to be done on the sender's side, = by the MSA. But there's also the opposite argument - say that handling of incoming = messages moves from company X to company Y, and malformed messages that = were blocked by company X are now passed by company Y. As a result, the = client company receiving such messages, now finds itself subject to = drastically increased attacks that use malformed messages (and UA = susceptibility to them) as a vector. Now the client will scream bloody = murder because Y did not block such messages. Both scenarios argue for more uniform handling of messages, and/or more = strict adherence to *822/MIME syntax. so there will be less variation = between how different MTAs/providers handle mail. (Though the mail = screen/delivery providers might want to distinguish themselves from one = another by how strict/tolerant/clever they are, thus increasing the = variation between providers.) But yes, the desire for uniform handling might argue for defining a = standard syntax verifier (with some recommendations about correction, = where appropriate) and encouraging MSAs to implement it. The desire = for more uniform handling of messages might also argue for trying to = move such verification/correction to MSAs and having downstream MTAs = treat such messages as opaque, so that there will be fewer opportunities = for messages to be subjected to variable amounts of = verification/correction. =20 (Honestly, I have long thought that traditional SMTP store-and-forward = these days is more trouble than it's worth, and what we need is to = reduce the number of hops that a message endures as it goes from sender = to recipient. To this end, I'd support some sort of pass-through = extension to SMTP to allow SMTP to continue to be used as a means to let = messages get through firewalls, but without actually doing = store-and-forward when not necessary.) > I'm not sure why this came as such a surprise to me, as it is actually = just another instance of Postel's Law. Being liberal in what we accept = means, in this case, accepting and delivering any message where we = believe, with a high level of confidence, that the sender's intentions = are clear despite its standards violations. Postel's Law was great in ARPAnet days, but I have long wondered how = well it scales to a network with billions of users and thousands or tens = of thousands of implementations. But I don't really have any problem in principle with correcting = messages where "the sender's intentions are clear". In practice, I = wonder how many cases exist for which code can reliably detect that "the = sender's intentions are clear". For example, a missing Date header = field - sure the MSA or downstream MTA can supply one, but it doesn't = really know the date/time at which the sender caused the message to be = sent. > I can tell you that nothing the IETF says is likely to have any effect = on whether or not Mimecast tries to "fix" and deliver such messages -- = we do and we will, as do nearly all of our competitors, because although = we care what the IETF says, we have no choice but to care what our = paying customers say even more. However, if the IETF offered guidance = on the least harmful way to do this, the odds are good that we would = follow it. And I think it would be better if vendors who felt the need = to "fix" messages would at least be mutually consistent in how they fix = them. >=20 > One (probably controversial) idea that might reduce our collective = angst would be to specify that, when an MTA fixes such a message, it = also generates an explanatory/warning message back to the sender or the = sender's postmaster (perhaps limited to 1 message per day per = malformation type). That way we might not be exacerbating existing = problems quite as much as Keith and other (myself included) fear. And = the senders of misformatted messages might eventually fix their code, if = only to shut up the annoying warning messages. -- Nathaniel Well, if there were a standard set of tests to apply to outgoing mail, = and these tests were implemented by MSAs, those MSAs could presumably = make such data available to sending UAs and/or their users. And yes, = hopefully MUA vendors would make sure that messages generated by their = MUAs passed such tests. That would be, IMO, the best of all possible = outcomes. Keith From sm@elandsys.com Sat Apr 16 10:19:33 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B6A60E0731; Sat, 16 Apr 2011 10:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIPlG4rbP2rK; Sat, 16 Apr 2011 10:19:31 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 6DA4AE0689; Sat, 16 Apr 2011 10:19:31 -0700 (PDT) Received: from subman.elandsys.com ([41.136.238.139]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p3GHJEVY031981; Sat, 16 Apr 2011 10:19:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1302974369; bh=kRJD0f/LdxnxBTwlVYll0u4ug4A=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=R2qxMdCGID4Z2Dp8cu8DLH/UD0brHsJiPjmG2tVQ/X/W9hRu3GMFnBVcIAiF/BQ2V QWk/DBU6xttMYlbXB4oB8s80vKueu3xkZHvlv7XfGfqWXmgFcD+7mbM7XfdHs+lwFz YC+nNMuPsbYZGxnjD4AruqkLrTvr7Zk5MIGXjX5k= Message-Id: <6.2.5.6.2.20110416083146.05030430@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Apr 2011 09:18:52 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch , iesg@ietf.org, "Mark P. Andrews" Subject: [apps-discuss] Apps-team review of draft-ietf-dnsop-default-local-zones-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 17:19:33 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dnsop-default-local-zones-15 Reviewer: S. Moonesamy Review Date: April 16, 2011 IETF Last Call Date: 2011-04-11 IESG Telechat Date: 2011-04-28 Summary: This draft is ready for publication as a BCP. The draft specifies the DNS zones all iterative resolvers and recursive nameservers should automatically serve. Major Issues: None Minor Issues: None Nits: In Section 1: "Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035]) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers SHOULD automatically serve, unless intentionally configured otherwise." The "SHOULD" should not be capitalized as the RFC 2119 key words are only defined in Section 1.1. "Additionally, queries from clients behind badly configured firewalls that allow outgoing queries for these name spaces but drop the responses, put a significant load on the root servers (forward but no reverse zones configured)." According to RFC 5855, the load would be going to "reverse" servers instead of root servers due to an operational change for the in-addr.arpa zone. Regards, S. Moonesamy From sm@elandsys.com Sat Apr 16 10:19:54 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BCD4DE073C; Sat, 16 Apr 2011 10:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-OpP8mcdBq2; Sat, 16 Apr 2011 10:19:53 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 23679E073D; Sat, 16 Apr 2011 10:19:53 -0700 (PDT) Received: from subman.elandsys.com ([41.136.238.139]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p3GHJEVW031981; Sat, 16 Apr 2011 10:19:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1302974363; bh=efeQz+y7s3kBWgZUjW5qlY8/Flk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=tDGI52yhG1cJJu1MghrRkw1styLNRUyJRyU1xNMn7GWoxw8I8yV5HEN0XAcMgQuLP +Yb3JV5dXxnNDWkPnMc7xIQQpolCxUf/e/WEYaM5DcptLVuOQY+BRAmlGNv3nS4zNM xrTPqEcA16NqqA00u0uIV8Feo3kP3aG5P3Ai33BE= Message-Id: <6.2.5.6.2.20110416073707.04f64b78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Apr 2011 08:28:51 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch , Joe Abley , iesg@ietf.org Subject: [apps-discuss] Apps-team review of draft-ietf-dnsop-as112-under-attack-help-help-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 17:19:54 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dnsop-as112-under-attack-help-help-05 Reviewer: S. Moonesamy Review Date: April 16, 2011 IETF Last Call Date: 2011-04-11 IESG Telechat Date: 2011-04-28 Summary: This draft is ready for publication as an Informational RFC. The draft provides background information and technical advice to firewall operators about DNS answers from AS112 servers. Major Issues: None Minor Issues: None Nits: In Section 4: 'From the perspective of the public DNS, these queries are junk -- they cannot be answered usefully and result in unnecessary traffic being received by the nameservers which underpin the operation of the public DNS (the so-called root servers which serve "IN-ADDR.ARPA")' According to RFC 5855, the (DNS) root servers no longer server "IN-ADDR.ARPA". See output from dig: ;; QUESTION SECTION: ;in-addr.arpa. IN NS ;; ANSWER SECTION: in-addr.arpa. 29139 IN NS a.in-addr-servers.arpa. in-addr.arpa. 29139 IN NS f.in-addr-servers.arpa. in-addr.arpa. 29139 IN NS e.in-addr-servers.arpa. in-addr.arpa. 29139 IN NS c.in-addr-servers.arpa. in-addr.arpa. 29139 IN NS d.in-addr-servers.arpa. in-addr.arpa. 29139 IN NS b.in-addr-servers.arpa. I suggest a minor change with a reference to RFC 5855: (the so-called reverse servers which serve "IN-ADDR.ARPA" [RFC 5855]) 'These servers are deployed in many places in a loosely-coordinated effort known as the "AS112 Project". More details about the AS112 Project can be found at .' I suggest moving the last sentence into an informational reference: These servers are deployed in many places in a loosely-coordinated effort known as the "AS112 Project" [AS112-Project]. [AS112-Project] AS112 Project In Section 10: "The purpose of this document is to help site administrators properly identify traffic received from AS112 nodes, and to provide background information to allow appropriate measures to be taken in response to it." I suggest moving the above paragraph to the Introduction Section as it does not fit under Security Considerations. Regards, S. Moonesamy From sm@elandsys.com Sat Apr 16 10:20:03 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2694EE073E; Sat, 16 Apr 2011 10:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3ufYvAdk9Lb; Sat, 16 Apr 2011 10:20:02 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 64FF5E0731; Sat, 16 Apr 2011 10:20:02 -0700 (PDT) Received: from subman.elandsys.com ([41.136.238.139]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p3GHJEVa031981; Sat, 16 Apr 2011 10:19:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1302974378; bh=BeLDbPb3q0lKO3lrMNQkAWFjfbo=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=TLpNrEmUXgOZ7WSNL8SmFFHRgXHUEckraiXr/wS/WtGggHKCmxFqjKizjYpuyJ+xN 5m5P6/qAHuY7mgqdOjH9/5Q1ki6ufeU4017JNaEIEOkYY5oLft56j3ie1lWHgxTVqf UpZxNfhFx6TRvHYo4/I6oNo81WB4yiyQCOMxG8Eo= Message-Id: <6.2.5.6.2.20110416094610.04f49468@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Apr 2011 10:06:40 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch , Joe Abley , iesg@ietf.org Subject: [apps-discuss] Apps-team review of draft-ietf-dnsop-as112-ops-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 17:20:03 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dnsop-default-local-zones-15 Reviewer: S. Moonesamy Review Date: April 16, 2011 IETF Last Call Date: 2011-04-11 IESG Telechat Date: 2011-04-28 Summary: This draft is ready for publication as an informational RFC. The draft describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation. Major Issues: None Minor Issues: None Nits: In Section 1: "The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authoritative servers" Does it reduce load on the root or on IN-ADDR.ARPA authoritative servers only? In Section 3.4: "The examples in this document are based on Quagga." I suggest adding "and Linux" as the example uses "eth0". Regards, S. Moonesamy From tbray@textuality.com Sat Apr 16 10:29:15 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D296E073C for ; Sat, 16 Apr 2011 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA4XIq+XcPEJ for ; Sat, 16 Apr 2011 10:29:14 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 367C3E0735 for ; Sat, 16 Apr 2011 10:29:14 -0700 (PDT) Received: by pxi20 with SMTP id 20so2432981pxi.27 for ; Sat, 16 Apr 2011 10:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.48.38 with SMTP id i6mr3994319pbn.515.1302974952442; Sat, 16 Apr 2011 10:29:12 -0700 (PDT) Received: by 10.68.60.193 with HTTP; Sat, 16 Apr 2011 10:29:12 -0700 (PDT) X-Originating-IP: [216.113.203.64] Date: Sat, 16 Apr 2011 10:29:12 -0700 Message-ID: From: Tim Bray To: apps-discuss@ietf.org, esg@ietf.org, S Moonesamy , alan.b.johnston@gmail.com, Oscar.Novo@ericsson.com, Gonzalo.Camarillo@ericsson.com, Dave.Morgan@fmr.com, jari.urpalainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Apps-team review of draft-ietf-xcon-common-data-model-25.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 17:29:15 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). I'm not a strong enough SIP expert to express an opinion as to whether this is ready for publication in the sense of it being a useful and problem-free extension of the SIP standards framework. However, it seems a reasonable specification of a reasonable XML language extension and I didn't see anything obviously broken at the SIP level; there are a few nits, noted below, that should be addressed: Observation: Element names given in double quotes, attribute names in single quotes. Odd. Is this a convention? General issue: There is much discussion of the values of various elements. There seems little discussion of whether exact case matching is required, whether white-space on either side of the designated values is allowed, and so on. Is this obvious from the context of the other SIP RFCs? It would trouble me as an implementor. There are a couple of nits below where I've called this out. Apology in advance: There are quite likely things I've called out that would be obvious to a seasoned SIP implementor who is after all the target of this draft; pardon the irritation. Nits: 1. 3rd para "specifies by whom, and in which way that information" - needs comma after 'way' 3.4 "defined in the data model" is unclear. You mean "the data model in this specification" I think? But I'm not sure. 4.1 " A conference object document begins with the root element tag " - the word 'tag' is superfluous here, not part of the idiom used elsewhere in this document 4.2 takes a "lang" attribute. Is this free text, ISO 639, or takes its definition from elsewhere in the SIP suite? Shouldn't something be said? 4.2.6 "The element represents a boolean value. If set to TRUE" Does this mean the content of the element must be the string TRUE? Case-sensitive? White-space before and after allowed? 4.2.9 2nd bullet - 'This attribute contains one of the following values: "none", "administrator", "moderator", "user", "observer", and "participant". ' Is it obvious to a reader whether exact-matching is required or case-mixing is allowed? Is white space allowed? Apologies if this is defined elsewhere and I missed it. 4.2.9 2nd bullet - " The roles semantic" - missing apostrophe after "roles". Also grammatically awkward, maybe "The roles' semantic definitions are.." 4.2.9 3rd bullet - "The child element specifies the time a conference media mixing stops" - superfluous "a" after "time" 4.2.13 4th bullet - missing comma after "values" 4.4.1 "The element represents a boolean action. " - should 'action' be 'value'? (this idiom also appears several more times in the draft) 4.5 " Other elements from different namespaces MAY be present for the purposes of extensibility." I was a bit surprised to encounter this for the first time here; does such extensibility not apply to all the elements defined previously? If it's generally true, maybe move it up to an introductory section? If child namespaces are generally disallowed and this is an exception, that also deserves saying at the top of the document. Section 6 suggests that extensibility is generally allowed for elements in this language, in which case the statement here is superfluous? 4.6.2 ""closedAuthenticated": A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list (listed under the XML element" - 'XML' is superfluous, appears a couple of times in this section 4.6.5 "4.6.5. and Its Sub-elements" - title looks funny, is the second superfluous? 8. "Futhermore, users may use different namespaces to access to a conference as explained in Section 4.6.5." I revisited 4.6.5 and it doesn't contain the word "namespace", it discusses user identifiers. Should "namespace" be replaced by "identifier" in this paragraph? Also "Futhermore" is misspelled. From peter@denic.de Sat Apr 16 10:54:52 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26754E0689 for ; Sat, 16 Apr 2011 10:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.803 X-Spam-Level: X-Spam-Status: No, score=-6.803 tagged_above=-999 required=5 tests=[AWL=1.446, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxuLywNumYm4 for ; Sat, 16 Apr 2011 10:54:51 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by ietfc.amsl.com (Postfix) with ESMTP id 4101FE0681 for ; Sat, 16 Apr 2011 10:54:50 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QB9hp-0004RN-CZ; Sat, 16 Apr 2011 19:54:49 +0200 Received: from localhost by x27.adm.denic.de with local id 1QB9hp-00084b-6I; Sat, 16 Apr 2011 19:54:49 +0200 Date: Sat, 16 Apr 2011 19:54:49 +0200 From: Peter Koch To: apps-discuss@ietf.org Message-ID: <20110416175449.GR1366@x27.adm.denic.de> Mail-Followup-To: apps-discuss@ietf.org, ietf-822@imc.org References: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: ietf-822@imc.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 17:54:52 -0000 On Sat, Apr 16, 2011 at 09:27:35AM +0100, Nathaniel Borenstein wrote: > The generalization is clear: the financial and business incentive is to deliver every message that you can possibly figure out how to deliver, so that your service doesn't appear "inferior" to customers who don't give a rat's rump about the details of standards compliance. Sure, the same way taxis will speed to outperform their competitors striving to improve their own customers' experience. Something is wrong in this picture. Standards are only partly about that customer experience, they are about interoperability, security, scalability, and, at least back in the day, overall architecture. This theme fits painfully nicely into that IETF80 technical plenary about the post standardization world and dominance of applications. > I'm not sure why this came as such a surprise to me, as it is actually just another instance of Postel's Law. Being liberal in what we accept means, in this case, accepting and delivering any message where we believe, with a high level of confidence, that the sender's intentions are clear despite its standards violations. I believe the Robustness Principle has been abused and perverted for too long now. You can only be so liberal that you are still able to be conservative on the emitting side. The problems in Murray's draft are with those cases where the intent was not clear or not clear enough to allow or support that balance. > However, if the IETF offered guidance on the least harmful way to do this, the odds are good that we would follow it. And I think it would be better if vendors who felt the need to "fix" messages would at least be mutually consistent in how they fix them. First, it is about interoperability issues, not an abstract "compliance", i.e., we're already in "following the rules by spirit rather than letter" space. Who can I as an operator file a bug report with when there is a standard that says "A" rather than "B" and a BCP that says "well, you should really treat B, which should not have happened, this way"? If there's an ambiguity in the standard that harms interoperability and/or poses security risks, shouldn't it be corrected in the standard for that to be self consistent? > That way we might not be exacerbating existing problems quite as much as Keith and other (myself included) fear. And the senders of misformatted messages might eventually fix their code, if only to shut up the annoying warning messages. -- Nathaniel Or they'd add additional code to suppress these warnings and market that as a feature? -Peter From randy@qualcomm.com Sun Apr 17 14:55:02 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D2946E0687; Sun, 17 Apr 2011 14:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2JSsPu8JLq9; Sun, 17 Apr 2011 14:55:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfc.amsl.com (Postfix) with ESMTP id 8CC2CE065F; Sun, 17 Apr 2011 14:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1303077301; x=1334613301; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<6.2.5.6.2.20110416051507.05ba6868@elandn ews.com>|References:=20<6.2.5.6.2.20110416051507.05ba6868 @elandnews.com>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |Date:=20Sun,=2017=20Apr=202011=2010:34:07=20-0700|To:=20 S=20Moonesamy=20,=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20Apps-team=20review=20of=20draft-gellens -mime-bucket-bis-03|CC:=20Randall=20Gellens=20,=20David=20Singer=20,=20Per =0D=0A=20Frojdh=20,=20|MIME-Version:=201.0|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.4 8.1]; bh=acoeIHBPK4s4/H8B6jIyLL6oAmcT6MYtcvJKK/MpKXM=; b=jF38CkyVPxhDlErP7GVHeF3ngHKuUg9WDIBON5WxL5QmuYBF052PTPcr Gl/niSL7g2C+3jOe3cAJRolMFdNpQ8gvlXskWPLOP3IbOLip7MCHVpxs4 JWo7O1FsUn75jvuHHT6A/nzH7gyA2S+CptdbpR6aMMpbc+E/KJUuKVzkP M=; X-IronPort-AV: E=McAfee;i="5400,1158,6319"; a="86308910" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 17 Apr 2011 14:55:00 -0700 X-IronPort-AV: E=Sophos;i="4.64,227,1301900400"; d="scan'208";a="136037732" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 17 Apr 2011 14:55:00 -0700 Received: from [10.10.34.68] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 17 Apr 2011 14:52:22 -0700 Message-ID: In-Reply-To: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> X-Mailer: Eudora for Mac OS X Date: Sun, 17 Apr 2011 10:34:07 -0700 To: S Moonesamy , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: Randall Gellens , Per Frojdh , David Singer , iesg@ietf.org Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 21:55:03 -0000 Hi sm, Thanks for the helpful review. I appreciate it. All: Please see below for my thoughts: At 6:43 AM -0700 4/16/11, S Moonesamy wrote: > Hello, > > I have been selected as the Applications Area Review Team reviewer > for this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call > comments you may receive. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > Document: draft-gellens-mime-bucket-bis-03 > Reviewer: S. Moonesamy > Review Date: April 16, 2011 > IETF Last Call Date: Unknown > IESG Telechat Date: Unknown > > Summary: > > This draft is almost ready for publication as a Proposed Standard > but has a few nits that should be fixed before publication. > > The Codecs Parameter for "Bucket" Media Types was specified in RFC > 4281. This draft specifies the Codecs and Profiles Parameters for > "Bucket" Media Types. As it is a significant change from RFC 4281, > it does not fit the requirements specified in RFC 2026 for Draft > Standard. Please refer to RFC 5657 for additional information > about how to advance a protocol to Draft Standard. > > Please note that I have not read ISO/IEC 14496-15:2010, a normative > reference, as it is not freely available. > > Major Issues: > > None > > Minor Issues: > > None > > Nits: > > draft-gellens-mime-bucket-bis-03 obsoletes RFC 4281 but there is no > mention of that in the Abstract Section or the rest of the document. There is a document header for it, but I agree that for clarify, there should be a statement to this effect in the text. My suggestion is to add text at the end of the second paragraph of the Abstract (which starts 'This document specifies two parameters, "codecs" and "profiles"'. The new text can say something along the lines of 'RFC 4281 added the "codecs" parameter, which this document retains in a backwards compatible manor; the "profiles" parameter is added by this document.' I think this makes the situation clear to those readers who aren't familiar with RFC 4281 > > In Section 3.1: > > "An element MAY include an octet that must be encoded in order to > comply with [RFC2045]" > > I suggest capitalizing the "must" as key words are capitalized in > that sentence. This is a little tricky, because the "MAY include" in normative in this document (this document is imposing the rule) while the "must be encoded in order to comply" is descriptive; it describes the octet to which the rest of the clause applies. I think simply capitalizing the "must" in this instance would make the text less clear. What would people (especially my other authors) think about using wording such as: An element MAY include an octet that [RFC2045] REQUIRES to be encoded. In this case, [RFC2231] is used: > > "Note that, when the [RFC2231] form is used, the percent > sign, asterisk, and single quote characters have special meaning and > so must themselves be encoded." > > I suggest capitalizing the "must". I agree. > > In Section 4.2: > > "An element MAY include an octet that must be encoded in order to > comply with [RFC2045]" > > I suggest capitalizing the "must". I suggest using the wording from above: An element MAY include an octet that [RFC2045] REQUIRES to be encoded. In this case, [RFC2231] is used: > > "Note that, when the [RFC2231] form is used, > the percent sign, asterisk, and single quote characters have special > meaning and so must themselves be encoded." > > I suggest capitalizing the "must". I agree. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- He who would travel happily must travel light. --Antoine St. Exuperey From fanf2@hermes.cam.ac.uk Mon Apr 18 05:08:20 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75D75E066F for ; Mon, 18 Apr 2011 05:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[AWL=1.874, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F-PHkxyEkQi for ; Mon, 18 Apr 2011 05:08:16 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfc.amsl.com (Postfix) with ESMTP id 36900E065A for ; Mon, 18 Apr 2011 05:08:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36402) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QBnFV-0006rt-Do (Exim 4.72) (return-path ); Mon, 18 Apr 2011 13:08:13 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QBnFV-0005qh-6Q (Exim 4.67) (return-path ); Mon, 18 Apr 2011 13:08:13 +0100 Date: Mon, 18 Apr 2011 13:08:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland In-Reply-To: <3111.1302886222.968467@puncture> Message-ID: References: <4DA8542F.9040003@tana.it> <3111.1302886222.968467@puncture> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-822 , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:08:20 -0000 Dave Cridland wrote: > > It may be that the discussion suggests rejecting, in which case I suggest the > document should clearly explain why, and what the implications of not doing so > are, beyond "it makes some problems harder to diagnose". It does not make sense to have a uniform policy for dealing with corrupt messages. Some kinds of corruption are caused by common legitimate software, in which case you will want to treat it leniently; others are caused by malware or rare kinds of incompetence, in which case it makes more sense to reject. You can only determine which is which based on operational experience, and the least-worst response changes from time to time. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From eburger@standardstrack.com Mon Apr 18 05:11:05 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71AA1E06AF for ; Mon, 18 Apr 2011 05:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud3ipBGRelBr for ; Mon, 18 Apr 2011 05:11:00 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [66.117.3.189]) by ietfc.amsl.com (Postfix) with ESMTP id 8439AE066F for ; Mon, 18 Apr 2011 05:11:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=CWiqa12Dg+GiDg8I73NhRe8C971T5zIIKjARveGZGjKOnXOFvnjt1/wz1mTqi73PURjh7AONY6N2Y404CxS7AQjdagDKombwgCRmPDaazWA0eja4sE+vBikmkQsIDASJ; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.171]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QBnH1-0004H4-4H; Mon, 18 Apr 2011 05:09:47 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-29-551424564; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Mon, 18 Apr 2011 08:10:55 -0400 Message-Id: <857EBD9A-2457-4A45-B3A1-8E162338757A@standardstrack.com> References: <4DA8542F.9040003@tana.it> <3111.1302886222.968467@puncture> To: ietf-822 X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:11:05 -0000 --Apple-Mail-29-551424564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This whole discussion makes me think what we are really doing is = changing 2822 to make these messages "well formed." Is that the intent? On Apr 18, 2011, at 8:08 AM, Tony Finch wrote: > Dave Cridland wrote: >>=20 >> It may be that the discussion suggests rejecting, in which case I = suggest the >> document should clearly explain why, and what the implications of not = doing so >> are, beyond "it makes some problems harder to diagnose". >=20 > It does not make sense to have a uniform policy for dealing with = corrupt > messages. Some kinds of corruption are caused by common legitimate > software, in which case you will want to treat it leniently; others = are > caused by malware or rare kinds of incompetence, in which case it = makes > more sense to reject. You can only determine which is which based on > operational experience, and the least-worst response changes from time = to > time. >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first = in > Rockall and Malin, veering west or northwest 4 or 5, then backing = southwest 5 > or 6 later. Rough or very rough. Occasional rain. Moderate or good, > occasionally poor. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-29-551424564 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MTgxMjEwNTVaMCMGCSqGSIb3DQEJ BDEWBBTjOpD81JeoeKc57uvHQPOVarqctzCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAKSgDHiuHOAf5yZDnNKBm3hRULpuuYWR5LLHPo6hgcbznw+Q 5s34ksSGNzXi7ThOoV5pfPptACNgDL5GiMvRYlSfnvNlmb512E7UTose3JgEyFR1hT7otSUhtc4I rKF7c01gX0KjbPVMDc/uY7jrjMlxciHp3h4lIS7XnGjfARyiSBwvDyrqWuAC9Y6+8/dFm4jg2N7C IuastyT2SuTWR36IB36qY8Tjos/8xTJb1YhGaski1j0RejuqCluC7mhYgEj7LaOCf5revb2rr+yP H9edMFk3aIhtgT8x4z5WsFzZHQCvPQWtqEnJ3j3zZFlBOsK/DDN2EwQM7/7eovnPj7gAAAAAAAA= --Apple-Mail-29-551424564-- From fanf2@hermes.cam.ac.uk Mon Apr 18 05:20:02 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2578CE07BC for ; Mon, 18 Apr 2011 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl59D9mDKqHD for ; Mon, 18 Apr 2011 05:19:58 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfc.amsl.com (Postfix) with ESMTP id C6340E06ED for ; Mon, 18 Apr 2011 05:19:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52457) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QBnQj-0001RT-Xr (Exim 4.72) (return-path ); Mon, 18 Apr 2011 13:19:49 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QBnQj-0007L0-FX (Exim 4.67) (return-path ); Mon, 18 Apr 2011 13:19:49 +0100 Date: Mon, 18 Apr 2011 13:19:49 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-822 , Keith Moore , General discussion of application-layer protocols , "dcrocker@bbiw.net" Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:20:02 -0000 Murray S. Kucherawy wrote: > > I don't think this work is targeted at intermediaries. In fact, I'd be > completely fine with expressly saying it's meant to address processing > at ingress MTAs only. If you are going to make that kind of restriction, it should happen at submission servers only. There is a history of MX servers making "helpful" fix-ups to messgaes (e.g. inserting missing message-id or from headers) before handing them over to anti-spam software, which can make spam/legit checks invalid in both the positive and negative senses. So I think MXs should be as transparent as possible so that downstream security software is less likely to have interop problems. Intermediate relays should also be as transparent as possible. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From fanf2@hermes.cam.ac.uk Mon Apr 18 05:47:19 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 237F5E069D for ; Mon, 18 Apr 2011 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.037 X-Spam-Level: X-Spam-Status: No, score=-5.037 tagged_above=-999 required=5 tests=[AWL=1.562, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKBxxZtwsDAI for ; Mon, 18 Apr 2011 05:47:14 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfc.amsl.com (Postfix) with ESMTP id D6ABEE0664 for ; Mon, 18 Apr 2011 05:47:14 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53843) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QBnrA-00057v-EO (Exim 4.72) (return-path ); Mon, 18 Apr 2011 13:47:08 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QBnrA-0002M5-EZ (Exim 4.67) (return-path ); Mon, 18 Apr 2011 13:47:08 +0100 Date: Mon, 18 Apr 2011 13:47:08 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nathaniel Borenstein In-Reply-To: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> Message-ID: References: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-822@imc.org, Keith Moore , apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:47:19 -0000 Nathaniel Borenstein wrote: > > One (probably controversial) idea that might reduce our collective angst > would be to specify that, when an MTA fixes such a message, it also > generates an explanatory/warning message back to the sender or the > sender's postmaster (perhaps limited to 1 message per day per > malformation type). That's likely to cause too much spam backscatter. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From john-ietf@jck.com Mon Apr 18 05:49:16 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ED895E06ED for ; Mon, 18 Apr 2011 05:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMMASYHTypd0 for ; Mon, 18 Apr 2011 05:49:16 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 35EE7E06D6 for ; Mon, 18 Apr 2011 05:49:16 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QBnsx-000JPe-Kf; Mon, 18 Apr 2011 08:48:59 -0400 Date: Mon, 18 Apr 2011 08:48:58 -0400 From: John C Klensin To: Tony Finch , "Murray S. Kucherawy" Message-ID: In-Reply-To: References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ietf-822 , Keith Moore , General discussion of application-layer protocols , dcrocker@bbiw.net Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:49:17 -0000 --On Monday, April 18, 2011 13:19 +0100 Tony Finch wrote: > Murray S. Kucherawy wrote: >> >> I don't think this work is targeted at intermediaries. In >> fact, I'd be completely fine with expressly saying it's meant >> to address processing at ingress MTAs only. > > If you are going to make that kind of restriction, it should > happen at submission servers only. > > There is a history of MX servers making "helpful" fix-ups to > messgaes (e.g. inserting missing message-id or from headers) > before handing them over to anti-spam software, which can make > spam/legit checks invalid in both the positive and negative > senses. So I think MXs should be as transparent as possible so > that downstream security software is less likely to have > interop problems. Intermediate relays should also be as > transparent as possible. Of course, this is exactly what RFCs 4409, 5068, and 5321 say: considerable flexibility for making fixes for the submission server, which is presumably under the control of (or at least responsible to) the sender; relays don't mess with message contents until they get to the delivery server. Various operational considerations have modified that somewhat but, if this specification doesn't apply to intermediaries, it changes nothing except, as Eric Burger points out, the practical definition of well-formed messages. IMO, if we want to do that (and I'd personally not favor it), we should do so in some 5322bis, not try to sneak the changes in via a BCP that is inconsistent with 5322. john From ned.freed@mrochek.com Mon Apr 18 10:01:16 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50846E0694 for ; Mon, 18 Apr 2011 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9jUPqMRkONr for ; Mon, 18 Apr 2011 10:01:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfc.amsl.com (Postfix) with ESMTP id 27E3DE0684 for ; Mon, 18 Apr 2011 10:01:14 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O09A027MTC00S603@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 18 Apr 2011 10:01:11 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O07W6AHITS007FL5@mauve.mrochek.com>; Mon, 18 Apr 2011 10:01:09 -0700 (PDT) Message-id: <01O09A012280007FL5@mauve.mrochek.com> Date: Mon, 18 Apr 2011 09:45:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 18 Apr 2011 13:08:13 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4DA8542F.9040003@tana.it> <3111.1302886222.968467@puncture> To: Tony Finch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1303145635; bh=SeYSlScem8rghOvTqdOxgFlF1605VI4ApaoLqRomz+g=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=JKmUsLpkwMcpDrXE3P35UoyE4+h18GlsyjfEiFhbFvHW9MAKq0dtebmoizT5KaZpy VFd4UBXZrYBpY8CygFzrXWM0wPlOuhXiDyDyU+Srp9ixPut++AqB0MWpjSYgafSLb/ 2OHzf71/wVH28u/ew4XfI/H1DdFFjR/9VaOc5O0M= Cc: ietf-822 , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:01:16 -0000 > Dave Cridland wrote: > > > > It may be that the discussion suggests rejecting, in which case I suggest the > > document should clearly explain why, and what the implications of not doing so > > are, beyond "it makes some problems harder to diagnose". > It does not make sense to have a uniform policy for dealing with corrupt > messages. Some kinds of corruption are caused by common legitimate > software, in which case you will want to treat it leniently; others are > caused by malware or rare kinds of incompetence, in which case it makes > more sense to reject. You can only determine which is which based on > operational experience, and the least-worst response changes from time to > time. Bingo. This is precisely the concern I have with this effort - the IETF consensus process operates in a time scale that will make it very difficult to capture a sensible set of recommendations in a specification. And even if we do manage to capture something useful, it will need to be updated regularly to remain useful. Are we prepared to do that? And it isn't a binary choice between rejection and fixup either. What sort of fixup makes sense can change over time. Consider the invalid header line case. There was a period a few years ago when it seemed like half the email agents out there couldn't consistently fold header lines. As a result the strategy of accepting such messages and not terminating the header seemed to work best. But as this issue was starting to disappear, a new one, where some group of agents decided that the blank line between the header and body was superfluous and could be omitted, started to show up. A strategy of treating an invalid header line as a stopping point works best in this case. But who's to say what's going to happen next month? This sort of behavior shifting over time is especially prevalent in certain problem areas like CJK charset usage and labeling. Another aspect to this that hasn't been discussed yet is where some agent can only tolerate a subset of what the standards allow. Is it OK to reformat messages to avoid using legitimate but neverthless problematic features? My personal favorite of these was the one where, several years back, a very popular product refused to accept MIME messages where the content-tranfer-encoding field appeared prior to the content-type in the message header. Ned From fanf2@hermes.cam.ac.uk Mon Apr 18 12:13:36 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8EB0DE0741 for ; Mon, 18 Apr 2011 12:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=1.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DVFkrxCVAg1 for ; Mon, 18 Apr 2011 12:13:35 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfc.amsl.com (Postfix) with ESMTP id A4B6DE0694 for ; Mon, 18 Apr 2011 12:13:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36445) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QBtt6-0005BU-Pu (Exim 4.72) (return-path ); Mon, 18 Apr 2011 20:13:32 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QBtt6-0006Dj-0V (Exim 4.67) (return-path ); Mon, 18 Apr 2011 20:13:32 +0100 Date: Mon, 18 Apr 2011 20:13:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: ned+ietf-822@mrochek.com In-Reply-To: <01O09A012280007FL5@mauve.mrochek.com> Message-ID: References: <4DA8542F.9040003@tana.it> <3111.1302886222.968467@puncture> <01O09A012280007FL5@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-822 , General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:13:36 -0000 ned+ietf-822@mrochek.com wrote: > > And it isn't a binary choice between rejection and fixup either. What sort of > fixup makes sense can change over time. The draft suggests an intermediate option, which is to process the message using a grammar with more lenient handling of error cases but to pass on the message unchanged (if it gets passed on). A lot of the risk comes from doing this (or rather, from doing this inconsistently). I think I'd like to make a distinction between a relay (which is transparent) and a security gateway (which does fixups). They should have consistent behaviour, by which I mean that if a transparent relay is presented with a corrupt message, it should treat it in the same way as a standard parser would treat the same message after it has been fixed up by a security gateway. Whether a message gets rejected or not is a somewhat different matter. I think submission servers can and should be a lot stricter than an MX can be. Either way, every system needs to parse borderline cases more consistently. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From randy@qualcomm.com Mon Apr 18 12:16:19 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 478F3E0694; Mon, 18 Apr 2011 12:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEIAgbiKtYHt; Mon, 18 Apr 2011 12:16:18 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfc.amsl.com (Postfix) with ESMTP id BE173E0670; Mon, 18 Apr 2011 12:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1303154177; x=1334690177; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<147FB978-70D1-452A-BA57-6D31EC1B7C43@app le.com>|References:=20<6.2.5.6.2.20110416051507.05ba6868@ elandnews.com>=0D=0A=20=0D=0A=20<147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.c om>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Mon, =2018=20Apr=202011=2012:06:35=20-0700|To:=20David=20Singe r=20|From:=20Randall=20Gellens=20|Subject:=20Re:=20Apps-team=20review=20of =20draft-gellens-mime-bucket-bis-03|CC:=20S=20Moonesamy =20,=20,=20P er=20Frojdh=0D=0A=09,=20,=20Randall=20Gellens=0D=0A=09 |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.48.1]; bh=9xvInpzuDvLaabdqCmYTlU+ddXfRJg2Lnj3IOZsDohA=; b=ZJUdL0h15Bnxc7gCb/2Ay0svtHNXkn0pQ3AXWJT/yIkLcoCtSrV7m30T 6i1p0izYsrKJSeQa4GykrMymZwFFTc1YY5wQ5PZ6gNZrWY1PGqgeRqe5A m4pRNpOa5xqRD2N7AXBhiM54foMXdXzWF1xs0vZk/XSxU+0f4UHKerrV1 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6320"; a="86288970" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 18 Apr 2011 12:16:12 -0700 X-IronPort-AV: E=Sophos;i="4.64,232,1301900400"; d="scan'208";a="66886697" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 18 Apr 2011 12:16:12 -0700 Received: from [10.10.34.68] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 12:14:42 -0700 Message-ID: In-Reply-To: <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> X-Mailer: Eudora for Mac OS X Date: Mon, 18 Apr 2011 12:06:35 -0700 To: David Singer From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: Randall Gellens , Per Frojdh , S Moonesamy , apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:16:19 -0000 At 11:36 AM -0700 4/18/11, David Singer wrote: > On Apr 17, 2011, at 10:34 , Randall Gellens wrote: > >> Hi sm, >> >> Thanks for the helpful review. I appreciate it. > > I also appreciate it. Thanks > >> >> All: Please see below for my thoughts: >> >> At 6:43 AM -0700 4/16/11, S Moonesamy wrote: >> >>> Hello, >>> >>> I have been selected as the Applications Area Review Team >>> reviewer for this draft (for background on apps-review, please >>> see >>> http://www.apps.ietf.org/content/applications-area-review-team). >>> >>> Please resolve these comments along with any other Last Call >>> comments you may receive. Please wait for direction from your >>> document shepherd or AD before posting a new version of the draft. >>> >>> Document: draft-gellens-mime-bucket-bis-03 >>> Reviewer: S. Moonesamy >>> Review Date: April 16, 2011 >>> IETF Last Call Date: Unknown >>> IESG Telechat Date: Unknown >>> >>> Summary: >>> >>> This draft is almost ready for publication as a Proposed Standard >>> but has a few nits that should be fixed before publication. >>> >>> The Codecs Parameter for "Bucket" Media Types was specified in >>> RFC 4281. This draft specifies the Codecs and Profiles >>> Parameters for "Bucket" Media Types. As it is a significant >>> change from RFC 4281, it does not fit the requirements specified >>> in RFC 2026 for Draft Standard. Please refer to RFC 5657 for >>> additional information about how to advance a protocol to Draft >>> Standard. >>> >>> Please note that I have not read ISO/IEC 14496-15:2010, a >>> normative reference, as it is not freely available. >>> >>> Major Issues: >>> >>> None >>> >>> Minor Issues: >>> >>> None >>> >>> Nits: >>> >>> draft-gellens-mime-bucket-bis-03 obsoletes RFC 4281 but there is >>> no mention of that in the Abstract Section or the rest of the >>> document. >> >> There is a document header for it, but I agree that for clarify, >> there should be a statement to this effect in the text. My >> suggestion is to add text at the end of the second paragraph of >> the Abstract (which starts 'This document specifies two >> parameters, "codecs" and "profiles"'. The new text can say >> something along the lines of 'RFC 4281 added the "codecs" >> parameter, which this document retains in a backwards compatible >> manor; the "profiles" parameter is added by this document.' > > and makes other clarifications to the use of the codecs parameter. > >> >> I think this makes the situation clear to those readers who aren't >> familiar with RFC 4281 > > OK, I wasn't sure whether such textual backwards-pointers were even > allowed. Now I know that they are encouraged. > >> >>> >>> In Section 3.1: >>> >>> "An element MAY include an octet that must be encoded in order to >>> comply with [RFC2045]" >>> >>> I suggest capitalizing the "must" as key words are capitalized in >>> that sentence. >> >> This is a little tricky, because the "MAY include" in normative in >> this document (this document is imposing the rule) while the "must >> be encoded in order to comply" is descriptive; it describes the >> octet to which the rest of the clause applies. I think simply >> capitalizing the "must" in this instance would make the text less >> clear. What would people (especially my other authors) think >> about using wording such as: >> >> An element MAY include an octet that [RFC2045] REQUIRES to be >> encoded. In this case, [RFC2231] is used: > > I agree, I think it best if capitalized verbs are used for > requirements expressed in the document. So I would not capitalize > 'requires' in this case, but it's OK by me. Dave made my point, which is that it can be confusing when normative directives are used for informative purposes. One approach I try to use is to reword to be descriptive, but it's hard in this case. I think "requires" can be written lower case here. > > >> "Note that, when the [RFC2231] form is used, the percent >>> sign, asterisk, and single quote characters have special meaning and > >> so must themselves be encoded." >>> >>> I suggest capitalizing the "must". >> >> I agree. >> > > Existing text from 4281. Can I have MUST in a 'Note' sentence? > Most bodies don't allow that. I think that the 'Note that,' should > go: > When the [RFC2231] form is used, the percent > sign, asterisk, and single quote characters have special meaning and > so MUST themselves be encoded. I've used MUST in notes before; I think it's fine here. > > Similarly below.... > > New suggested text (not yet uploaded, as per intsructions) > > > Attachment converted: TiLand:draft-gellens-mime-#29C6465.txt > (TEXT/R*ch) (029C6465) > >> >>> >>> In Section 4.2: >>> >>> "An element MAY include an octet that must be encoded in order to >>> comply with [RFC2045]" >>> >>> I suggest capitalizing the "must". >> >> I suggest using the wording from above: >> >> An element MAY include an octet that [RFC2045] REQUIRES to be >> encoded. In this case, [RFC2231] is used: >> >>> >>> "Note that, when the [RFC2231] form is used, >>> the percent sign, asterisk, and single quote characters have special >>> meaning and so must themselves be encoded." >>> >>> I suggest capitalizing the "must". >> >> I agree. >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> He who would travel happily must travel light. --Antoine St. Exuperey > > David Singer > Multimedia and Software Standards, Apple Inc. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The trouble with the world is not that people know too little, but that they know so many things that ain't so. --Mark Twain From sm@resistor.net Mon Apr 18 12:42:23 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF740E070C for ; Mon, 18 Apr 2011 12:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKcxOtpoR8uG for ; Mon, 18 Apr 2011 12:42:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id AE26CE06EC for ; Mon, 18 Apr 2011 12:42:20 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3IJgCPu019905; Mon, 18 Apr 2011 12:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1303155739; bh=Rr9wTlU5YvwMJe7u0wLb9Md3mRa19EUf2btiro7OlLs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:Mime-Version: Content-Type; b=aSieifWEp7hAzsp8R7qM/HBnFoIyTwzwGhBAHEh3JAfHCxkSKIQtycLqmdS1nU621 twelvtsFxQ4ywQVbzTud+IXyXZRfnf3oTpy/z7LM45adgcqzDALo6T1XsZ1JsvRtxt y5lnKFMLIJ74dqWouxMRjn+JMVowHXriTD02za7A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1303155739; bh=Rr9wTlU5YvwMJe7u0wLb9Md3mRa19EUf2btiro7OlLs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:Mime-Version: Content-Type; b=WCouKXNiWDJYdiJ5F5E1TknhYrCPgUC+/VVAQlHOUwuyokbnhaVISK+t0aid3FYPP SguMNhGdptzNkMnjndXWaEW2VfFrsWFDCQSGK2yvgtd8StzUPDHVt3iyvmUqvnkG1R 9AFB+ZG/b4H2USZt9R4tvVJeBWl7Bdb6BtMIdaQM= Message-Id: <6.2.5.6.2.20110418113432.0501e038@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 18 Apr 2011 12:40:42 -0700 To: "Murray S. Kucherawy" From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Comments on draft-kucherawy-mta-malformed-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:42:24 -0000 Hi Murray, I have a few comments about draft-kucherawy-mta-malformed-00. From Section 4: "This situation is exacerbated when a claim of message validity is inferred by something like a valid [DKIM] signature." From the discussions in the DKIM working group, I guess that this draft was written to address a DKIM/RFC 5322 issue. It's the usual IETF issue where it's difficult to get one of two WGs to fix a problem as nobody wants to claim the baby. It's good to document brokenness and even better if it can be fixed. Sometimes a problem cannot be fixed but that's another story [1]. From Section 3: "Of particular interest is the Internet Message Format, detailed in [MAIL]. Throughout this document, the use of the term "messsage" should be assumed to mean a block of text conforming to the Internet Message Format." There is a typo for "messsage". As this draft recommends fixes that affect RFC 5322, it should not be published as a BCP. If it is the consensus to have such fixes, it can be expressed through a Proposed Standard that updates RFC 5322. From Section 5.1: "Consensus indicates the preferred implementation is to terminate header processing before the first character in line four, as described in (2) above. Thus, a module compliant with this specification MUST terminate header processing upon encountering the first line of text that is not a valid header field." Is the module a filter or a MTA? As you are aware, "SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network". If any fixes are to be made, it is better to have them done by the MSA instead of the MTA. Having the MTA make changes to address header anomalies creates another set of "middleboxes". From Section 6.3 of RFC 4409: "The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, or seems inconsistent with permissions given to the user (if known), or violates site policy in some way." You could use the above to fix the problem closer to the source instead of doing it in the MTA. It should be easier for the postmaster to identify the source of the problem and take any action. On an unrelated note, I received the following bounce (edited version) a few days ago: From: Date: Sat, 16 Apr 2011 13:44:01 Subject: Impossibile recapitare Irrespective of whether the above is good practice, I found the message useful as it got the "message" through. Regards, -sm 1. http://asset.rue89.com/files/imagecache/panorama/files/illustration/niqabitch_burqa_illus.jpg From jyee@afilias.info Mon Apr 18 21:08:36 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6501E06AA for ; Mon, 18 Apr 2011 21:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nijh0YzE+BME for ; Mon, 18 Apr 2011 21:08:36 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfc.amsl.com (Postfix) with ESMTP id 0FF6FE0611 for ; Mon, 18 Apr 2011 21:08:36 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QC2Et-0000Ph-5j for Apps-Discuss@ietf.org; Tue, 19 Apr 2011 04:08:35 +0000 Received: from mail-iw0-f178.google.com ([209.85.214.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QC2Et-0001QZ-51 for Apps-Discuss@ietf.org; Tue, 19 Apr 2011 04:08:35 +0000 Received: by iwn9 with SMTP id 9so23544337iwn.9 for ; Mon, 18 Apr 2011 21:08:35 -0700 (PDT) Received: by 10.42.115.67 with SMTP id j3mr1809728icq.302.1303186115148; Mon, 18 Apr 2011 21:08:35 -0700 (PDT) Received: from [192.168.0.100] (69-196-161-240.dsl.teksavvy.com [69.196.161.240]) by mx.google.com with ESMTPS id y10sm3108186iba.46.2011.04.18.21.08.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 21:08:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Joseph Yee Date: Tue, 19 Apr 2011 00:08:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: To: Apps-Discuss@ietf.org X-Mailer: Apple Mail (2.1082) Cc: klaus.darilion@nic.at, edguy@CleverSpoke.com Subject: [apps-discuss] Apps-Review Team Review: draft-ietf-enum-iax-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 04:08:36 -0000 (Resend with different mail address, sorry for duplication) Greeting, I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please see = http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-ietf-enum-iax-10 Title: IANA Registration for Enumservice 'iax' Reviewer: Joseph Yee Review Date: April 18, 2011 Summary: This draft is almost ready for publication as an Informational RFC but = has a few nits that should be fixed before publication. Major Issues: None Minor Issues: None Nits: (1) In Section 5, IANA Considerations, words suggested to make = registration type more specific Original This document requests registration of the 'iax' Enumservice according.... Suggestion This document requests registration of the Enumservice Type 'iax' according..... (2) In Section 5, IANA Considerations, specifications reference should = include RFC6116 Original according to the guidelines and specifications in [RFC6117]=20 and the definitions in Section 2 in this document. Suggestion according to the guidelines and specifications in [RFC6117],=20 [RFC6116] and the definitions in Section 2 in this document. Best Regards, Joseph Yee= From sm@elandsys.com Tue Apr 19 00:44:49 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C312CE068E for ; Tue, 19 Apr 2011 00:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25-OpTiyNniT for ; Tue, 19 Apr 2011 00:44:48 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 0EDCFE0655 for ; Tue, 19 Apr 2011 00:44:47 -0700 (PDT) Received: from subman.elandsys.com ([41.136.236.170]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p3J7iWZe021691; Tue, 19 Apr 2011 00:44:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1303199081; bh=cN1qP2yrASuWU3WERgvaQmoStYY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=k+9PQKShx/hOjhVjQUMMb4p2Zo+fradnGYVi5uQZZ1Wvh3KnCTmZTE4VGZybHTg0y iu1NPbZBHKhwPaCV9uC5uD6YErlgcClpD8Y0r1/zOM9s9+A1BeVTyQrNsAKqvRjrVc UqZ4CMne7dZZtSCAIU0YjmfGT0FxZptfa2NIPa4w= Message-Id: <6.2.5.6.2.20110418231517.068b9298@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 18 Apr 2011 23:59:55 -0700 To: Randall Gellens From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Randall Gellens , Per Frojdh , David Singer , apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 07:44:49 -0000 Hi Randy, I removed the IESG from the Cc as the Apps Area ADs read the apps-discuss mailing list and can provide feedback to the IESG. At 10:34 17-04-2011, Randall Gellens wrote: >There is a document header for it, but I agree that for clarify, >there should be a statement to this effect in the text. My >suggestion is to add text at the end of the second paragraph of the >Abstract (which starts 'This document specifies two parameters, >"codecs" and "profiles"'. The new text can say something along the >lines of 'RFC 4281 added the "codecs" parameter, which this document >retains in a backwards compatible manor; the "profiles" parameter is >added by this document.' I noticed the document header. As this is an editorial nit, feel free to ignore the comment. Section 4.1.1 of the RFC Style Guide mentions that "Authors often also include a statement in the Abstract and/or Introduction sections". That is flagged as a "should" by ID-nits by the way. Your above comment sums up the changes in this draft. You could also have: This document specifies two parameters, "codecs" and "profiles", which are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs and/or profiles employed by the media formats contained within. This document obsoletes RFC 4281 and retains the "codecs" parameter in a backwards compatible manner; the. "profiles" parameter is added by this document. >I think this makes the situation clear to those readers who aren't >familiar with RFC 4281 Yes. >This is a little tricky, because the "MAY include" in normative in >this document (this document is imposing the rule) while the "must >be encoded in order to comply" is descriptive; it describes the >octet to which the rest of the clause applies. I think simply >capitalizing the "must" in this instance would make the text less >clear. What would people (especially my other authors) think about >using wording such as: Thanks for explaining the subtlety of the "must". > An element MAY include an octet that [RFC2045] REQUIRES to be > encoded. In this case, [RFC2231] is used: Ok. >I suggest using the wording from above: > > An element MAY include an octet that [RFC2045] REQUIRES to be > encoded. In this case, [RFC2231] is used: Ok. Best regards, S. Moonesamy From sm@elandsys.com Tue Apr 19 00:44:49 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CEE33E0655 for ; Tue, 19 Apr 2011 00:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4ZmCtpPEPin for ; Tue, 19 Apr 2011 00:44:48 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 8600EE0665 for ; Tue, 19 Apr 2011 00:44:48 -0700 (PDT) Received: from subman.elandsys.com ([41.136.236.170]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p3J7iWZg021691; Tue, 19 Apr 2011 00:44:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1303199085; bh=YCo5SfXArzATZgtMjpp1A64c7bs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=VazT5g91TY+fzJzTm0SyeRaSneRrTKE1rBZnh/p6Ps5ODB91kPdaLDaQofPLlqufw Z43o5GlE29sgxGHiQC+s/DmaCLMHV7be0kdPHbvojBSTARXtmJMzMeVozo7FImtGR5 BSAZoAO7tToAWlr35+nW9R707Jf/AMK0cQJ4hPlc= Message-Id: <6.2.5.6.2.20110419000054.055c8c10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Apr 2011 00:41:30 -0700 To: David Singer , Randall Gellens From: S Moonesamy In-Reply-To: <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Per Frojdh , apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 07:44:50 -0000 Hi David, At 11:36 18-04-2011, David Singer wrote: >I agree, I think it best if capitalized verbs are used for >requirements expressed in the document. So I would not capitalize >'requires' in this case, but it's OK by me. Randy commented on this in another message. The "requires" should be clear enough. >Existing text from 4281. Can I have MUST in a 'Note' >sentence? Most bodies don't allow that. I think that the 'Note >that,' should go: >When the [RFC2231] form is used, the percent > sign, asterisk, and single quote characters have special meaning and > so MUST themselves be encoded. I have seen "MUST" used in "Note" sentences in other RFCs. You already had similar text in the RFC published in 2005. As it hasn't been a problem, I don't see why it should be a problem now. By the way, I gave an "almost ready for publication" rating as the document state is "Publication Requested" and the authors already know how to address editorial nits. Regards, S. Moonesamy From bernie@ietf.hoeneisen.ch Tue Apr 19 03:22:52 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61CE2E0738 for ; Tue, 19 Apr 2011 03:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j40B9mHPE-xF for ; Tue, 19 Apr 2011 03:22:51 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfc.amsl.com (Postfix) with ESMTP id 67F7DE0731 for ; Tue, 19 Apr 2011 03:22:51 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1QC857-0001Iy-7r; Tue, 19 Apr 2011 12:22:53 +0200 Date: Tue, 19 Apr 2011 12:22:53 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Joseph Yee In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: klaus.darilion@nic.at, ed guy , Jason Livingood , Apps-Discuss@ietf.org Subject: Re: [apps-discuss] Apps-Review Team Review: draft-ietf-enum-iax-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 10:22:52 -0000 Hi Joseph Thanks for your review and feedback on draft-ietf-enum-iax-10. My comments inline. On Tue, 19 Apr 2011, Joseph Yee wrote: > Nits: > (1) > In Section 5, IANA Considerations, words suggested to make registration type more specific > > Original > This document requests registration of the 'iax' Enumservice > according.... > > Suggestion > This document requests registration of the Enumservice > Type 'iax' according..... Could be changed, although IMHO not really needed. > (2) > In Section 5, IANA Considerations, specifications reference should include RFC6116 > > Original > according to the guidelines and specifications in [RFC6117] > and the definitions in Section 2 in this document. > > Suggestion > according to the guidelines and specifications in [RFC6117], > [RFC6116] and the definitions in Section 2 in this document. Adding a reference to RFC 6116 just confuses the reader, as RFC 6116 does not contain any specifications concerning IANA registration. When we revised RFC 3761, we purposly made a split between ENUM (as protocol) and the Enumservices (IANA registration, process). (A reader who tries to find IANA Enumservices related content in RFC 6116 due to such a reference will be disappointed, as all he finds is a reference to RFC 6117.) Therefore, a reference to RFC 6116 to the IANA considerations section of draft-ietf-enum-iax should not be added. cheers, Bernie (document shephard of draft-ietf-enum-iax & author of RFC 6117) PS: I added Jason (the designated Expert for this document) to the Cc. -- http://ucom.ch/ Tech Consulting for Internet Standardization From dotis@mail-abuse.org Mon Apr 18 15:56:20 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38AE5E082A for ; Mon, 18 Apr 2011 15:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWtoQ4gwGWtF for ; Mon, 18 Apr 2011 15:56:19 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by ietfc.amsl.com (Postfix) with ESMTP id 9D608E083C for ; Mon, 18 Apr 2011 15:56:16 -0700 (PDT) Received: from us-dougo-mac.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EABF6A94452; Mon, 18 Apr 2011 22:57:03 +0000 (UTC) Message-ID: <4DACC188.7010305@mail-abuse.org> Date: Mon, 18 Apr 2011 15:56:08 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ietf-822 References: <4DA8542F.9040003@tana.it> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Apr 2011 08:07:29 -0700 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:56:20 -0000 On 4/18/11 5:48 AM, John C Klensin wrote: > --On Monday, April 18, 2011 13:19 +0100 Tony Finch > wrote: >> Murray S. Kucherawy wrote: >>> I don't think this work is targeted at intermediaries. In >>> fact, I'd be completely fine with expressly saying it's meant >>> to address processing at ingress MTAs only. >> If you are going to make that kind of restriction, it should >> happen at submission servers only. >> >> There is a history of MX servers making "helpful" fix-ups to >> messgaes (e.g. inserting missing message-id or from headers) >> before handing them over to anti-spam software, which can make >> spam/legit checks invalid in both the positive and negative >> senses. So I think MXs should be as transparent as possible so >> that downstream security software is less likely to have >> interop problems. Intermediate relays should also be as >> transparent as possible. > Of course, this is exactly what RFCs 4409, 5068, and 5321 say: > considerable flexibility for making fixes for the submission > server, which is presumably under the control of (or at least > responsible to) the sender; relays don't mess with message > contents until they get to the delivery server. Various > operational considerations have modified that somewhat but, if > this specification doesn't apply to intermediaries, it changes > nothing except, as Eric Burger points out, the practical > definition of well-formed messages. > > IMO, if we want to do that (and I'd personally not favor it), we > should do so in some 5322bis, not try to sneak the changes in > via a BCP that is inconsistent with 5322. Fully Agree. -Doug From jyee@afilias.info Mon Apr 18 21:00:47 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A75CDE0696 for ; Mon, 18 Apr 2011 21:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuD+ULScSSYc for ; Mon, 18 Apr 2011 21:00:46 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfc.amsl.com (Postfix) with ESMTP id 204F1E0611 for ; Mon, 18 Apr 2011 21:00:42 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QC27G-0007y2-3X for Apps-Discuss@ietf.org; Tue, 19 Apr 2011 04:00:42 +0000 Received: from mail-iy0-f178.google.com ([209.85.210.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QC27F-0002rU-9M for Apps-Discuss@ietf.org; Tue, 19 Apr 2011 04:00:41 +0000 Received: by iyi12 with SMTP id 12so23541549iyi.9 for ; Mon, 18 Apr 2011 21:00:41 -0700 (PDT) Received: by 10.231.179.143 with SMTP id bq15mr4389432ibb.99.1303185640999; Mon, 18 Apr 2011 21:00:40 -0700 (PDT) Received: from [192.168.0.100] (69-196-161-240.dsl.teksavvy.com [69.196.161.240]) by mx.google.com with ESMTPS id hc41sm3104774ibb.47.2011.04.18.21.00.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 21:00:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Joseph Yee Date: Tue, 19 Apr 2011 00:00:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6DFEEB02-0428-4138-9F9E-33D8995A8A30@afilias.info> To: Apps-Discuss@ietf.org X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 19 Apr 2011 08:07:53 -0700 Cc: klaus.darilion@nic.at, edguy@CleverSpoke.com Subject: [apps-discuss] Apps-Review Team Review: draft-ietf-enum-iax-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 04:00:47 -0000 Greeting, I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please see = http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-ietf-enum-iax-10 Title: IANA Registration for Enumservice 'iax' Reviewer: Joseph Yee Review Date: April 18, 2011 Summary: This draft is almost ready for publication as an Informational RFC but = has a few nits that should be fixed before publication. Major Issues: None Minor Issues: None Nits: (1) In Section 5, IANA Considerations, words suggested to make = registration type more specific Original This document requests registration of the 'iax' Enumservice according.... Suggestion This document requests registration of the Enumservice Type 'iax' according..... (2) In Section 5, IANA Considerations, specifications reference should = include RFC6116 Original according to the guidelines and specifications in [RFC6117]=20 and the definitions in Section 2 in this document. Suggestion according to the guidelines and specifications in [RFC6117],=20 [RFC6116] and the definitions in Section 2 in this document. Best Regards, Joseph Yee= From oscar.novo@ericsson.com Tue Apr 19 05:16:55 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 688DCE06DB for ; Tue, 19 Apr 2011 05:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi9CCsc4muo1 for ; Tue, 19 Apr 2011 05:16:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id F07E5E00BE for ; Tue, 19 Apr 2011 05:16:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-bd-4dad7d34ca9a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id ED.CE.11171.43D7DAD4; Tue, 19 Apr 2011 14:16:53 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.138]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 19 Apr 2011 14:16:53 +0200 From: Oscar Novo To: Tim Bray , "apps-discuss@ietf.org" , "esg@ietf.org" , S Moonesamy , "alan.b.johnston@gmail.com" , Gonzalo Camarillo , "Dave.Morgan@fmr.com" , "jari.urpalainen@nokia.com" Date: Tue, 19 Apr 2011 14:16:52 +0200 Thread-Topic: Apps-team review of draft-ietf-xcon-common-data-model-25.txt Thread-Index: Acv8W8+FeEf6SU4NReuOnE5ER3Aw6QCKYAfQ Message-ID: <58E207308662A748A4AC1ECB4E88561408142CB8CA@ESESSCMS0355.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 19 Apr 2011 08:08:07 -0700 Subject: Re: [apps-discuss] Apps-team review of draft-ietf-xcon-common-data-model-25.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:16:55 -0000 Hi Tim, I've created a new version of the draft with your comments: http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-26 My comments inline as a [ON] Cheers, Oscar -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com]=20 Sent: 16. huhtikuuta 2011 20:29 To: apps-discuss@ietf.org; esg@ietf.org; S Moonesamy; alan.b.johnston@gmail= .com; Oscar Novo; Gonzalo Camarillo; Dave.Morgan@fmr.com; jari.urpalainen@n= okia.com Subject: Apps-team review of draft-ietf-xcon-common-data-model-25.txt I have been selected as the Applications Area Review Team reviewer for this= draft (for background on apps-review, please see http://www.apps.ietf.org/= content/applications-area-review-team). I'm not a strong enough SIP expert to express an opinion as to whether this= is ready for publication in the sense of it being a useful and problem-fre= e extension of the SIP standards framework. However, it seems a reasonable= specification of a reasonable XML language extension and I didn't see anyt= hing obviously broken at the SIP level; there are a few nits, noted below, = that should be addressed: Observation: Element names given in double quotes, attribute names in singl= e quotes. Odd. Is this a convention? [ON] That's only a way to facilitate the reader a better understanding of t= he documents.=20 General issue: There is much discussion of the values of various elements. = There seems little discussion of whether exact case matching is required, = whether white-space on either side of the designated values is allowed, and= so on. Is this obvious from the context of the other SIP RFCs? It would = trouble me as an implementor. There are a couple of nits below where I've called this out. [ON] The RELAX NG shema is defining the syntactic of the elements. That's w= hy the text is not giving any clear guidance about it. The implementor just= has to follow the RELAX NG schema defined in this document.=20 Apology in advance: There are quite likely things I've called out that woul= d be obvious to a seasoned SIP implementor who is after all the target of t= his draft; pardon the irritation. Nits: 1. 3rd para "specifies by whom, and in which way that information" - needs = comma after 'way' [ON] OK 3.4 "defined in the data model" is unclear. You mean "the data model in thi= s specification" I think? But I'm not sure. [ON] OK 4.1 " A conference object document begins with the root element tag " - the word 'tag' is superfluous here, not part of the idiom use= d elsewhere in this document [ON] OK 4.2 takes a "lang" attribute. Is this free text, = ISO 639, or takes its definition from elsewhere in the SIP suite? Shouldn'= t something be said? [ON] the precise type of the attribute is defined in the RELAX NG Schema. I= t would be redundant to mention it in the text.=20 4.2.6 "The element represents a boolean value. If set to= TRUE" Does this mean the content of the element must be the string TRUE? = Case-sensitive? White-space before and after allowed? [ON] The type of is defined in the RELAX NG schema as a bo= olean value. The implementor should follow the XML rules to define it.=20 4.2.9 2nd bullet - 'This attribute contains one of the following values: "none", "administrator", "moderator", "user", "observer", and "par= ticipant". ' Is it obvious to a reader whether exact-matching is required = or case-mixing is allowed? Is white space allowed? Apologies if this is de= fined elsewhere and I missed it. [ON] The RELAX NG schema defined the type of this attribute in the single-r= ole-type element. An implementor should follow the exact syntactic format d= efined in this attribute.=20 4.2.9 2nd bullet - " The roles semantic" - missing apostrophe after "roles"= . Also grammatically awkward, maybe "The roles' semantic definitions are..= " [ON] OK 4.2.9 3rd bullet - "The child element specifies the tim= e a conference media mixing stops" - superfluous "a" after "time" [ON] OK 4.2.13 4th bullet - missing comma after "values" [ON] OK 4.4.1 "The element represents a boole= an action. " - should 'action' be 'value'? (this idiom also appears several= more times in the draft) [ON] I would say it's right. The element represents a boolean action. That'= s mean, the action can only take two boolean values.=20 4.5 " Other elements from different namespaces MAY be present for the purpo= ses of extensibility." I was a bit surprised to encounter this for the firs= t time here; does such extensibility not apply to all the elements defined = previously? If it's generally true, maybe move it up to an introductory section? If child namespaces are generally disallowed and this is an exception, that also deserves saying at the top o= f the document. Section 6 suggests that extensibility is generally allowed= for elements in this language, in which case the statement here is superfl= uous? [ON] Right, I've removed it from that section. It creates unclarity and con= fision in this part of the text. As you point out, section 6 explains the e= xtensibility of the elements.=20 4.6.2 ""closedAuthenticated": A 'closedAuthenticated' policy MUST have eac= h conference participant in the allowed users list (listed under the XML element" - 'XML' is superfluous, appears a couple of tim= es in this section [ON] OK 4.6.5 "4.6.5. and Its Sub-elements" - title looks funny, is = the second superfluous? [ON] This document extends RFC4575. The name of that section comes from it: http://tools.ietf.org/html/rfc4575#page-18 =20 8. "Futhermore, users may use different namespaces to access to a conferenc= e as explained in Section 4.6.5." I revisited 4.6.5 and it doesn't contain= the word "namespace", it discusses user identifiers. Should "namespace" be replaced by "identifier" in this paragraph? Also "Futhermore" is misspelled. [ON] OK From singer@apple.com Mon Apr 18 11:36:24 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 324A5E070A; Mon, 18 Apr 2011 11:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utpgcuIVfhqx; Mon, 18 Apr 2011 11:36:20 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id B6AB3E083C; Mon, 18 Apr 2011 11:36:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Mmgfj2177wQsPQR0h9rPCQ)" Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00E7M2CF2271@mail-out.apple.com>; Mon, 18 Apr 2011 11:36:19 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-88-4dac84a109d7 Received: from [17.153.52.21] (Unknown_Domain [17.153.52.21]) by relay11.apple.com (Apple SCV relay) with SMTP id AF.CF.23242.1A48CAD4; Mon, 18 Apr 2011 11:36:18 -0700 (PDT) From: David Singer In-reply-to: Date: Mon, 18 Apr 2011 11:36:17 -0700 Message-id: <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> To: Randall Gellens X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 19 Apr 2011 08:08:17 -0700 Cc: Per Frojdh , S Moonesamy , apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:36:24 -0000 --Boundary_(ID_Mmgfj2177wQsPQR0h9rPCQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Apr 17, 2011, at 10:34 , Randall Gellens wrote: > Hi sm, > > Thanks for the helpful review. I appreciate it. I also appreciate it. Thanks > > All: Please see below for my thoughts: > > At 6:43 AM -0700 4/16/11, S Moonesamy wrote: > >> Hello, >> >> I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). >> >> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. >> >> Document: draft-gellens-mime-bucket-bis-03 >> Reviewer: S. Moonesamy >> Review Date: April 16, 2011 >> IETF Last Call Date: Unknown >> IESG Telechat Date: Unknown >> >> Summary: >> >> This draft is almost ready for publication as a Proposed Standard but has a few nits that should be fixed before publication. >> >> The Codecs Parameter for "Bucket" Media Types was specified in RFC 4281. This draft specifies the Codecs and Profiles Parameters for "Bucket" Media Types. As it is a significant change from RFC 4281, it does not fit the requirements specified in RFC 2026 for Draft Standard. Please refer to RFC 5657 for additional information about how to advance a protocol to Draft Standard. >> >> Please note that I have not read ISO/IEC 14496-15:2010, a normative reference, as it is not freely available. >> >> Major Issues: >> >> None >> >> Minor Issues: >> >> None >> >> Nits: >> >> draft-gellens-mime-bucket-bis-03 obsoletes RFC 4281 but there is no mention of that in the Abstract Section or the rest of the document. > > There is a document header for it, but I agree that for clarify, there should be a statement to this effect in the text. My suggestion is to add text at the end of the second paragraph of the Abstract (which starts 'This document specifies two parameters, "codecs" and "profiles"'. The new text can say something along the lines of 'RFC 4281 added the "codecs" parameter, which this document retains in a backwards compatible manor; the "profiles" parameter is added by this document.' and makes other clarifications to the use of the codecs parameter. > > I think this makes the situation clear to those readers who aren't familiar with RFC 4281 OK, I wasn't sure whether such textual backwards-pointers were even allowed. Now I know that they are encouraged. > >> >> In Section 3.1: >> >> "An element MAY include an octet that must be encoded in order to >> comply with [RFC2045]" >> >> I suggest capitalizing the "must" as key words are capitalized in that sentence. > > This is a little tricky, because the "MAY include" in normative in this document (this document is imposing the rule) while the "must be encoded in order to comply" is descriptive; it describes the octet to which the rest of the clause applies. I think simply capitalizing the "must" in this instance would make the text less clear. What would people (especially my other authors) think about using wording such as: > > An element MAY include an octet that [RFC2045] REQUIRES to be > encoded. In this case, [RFC2231] is used: I agree, I think it best if capitalized verbs are used for requirements expressed in the document. So I would not capitalize 'requires' in this case, but it's OK by me. > >> >> "Note that, when the [RFC2231] form is used, the percent >> sign, asterisk, and single quote characters have special meaning and >> so must themselves be encoded." >> >> I suggest capitalizing the "must". > > I agree. > Existing text from 4281. Can I have MUST in a 'Note' sentence? Most bodies don't allow that. I think that the 'Note that,' should go: When the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be encoded. Similarly below.... New suggested text (not yet uploaded, as per intsructions) --Boundary_(ID_Mmgfj2177wQsPQR0h9rPCQ) Content-type: text/plain; name=draft-gellens-mime-bucket-bis-04.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-gellens-mime-bucket-bis-04.txt Network Working Group R. Gellens Internet-Draft QUALCOMM Incorporated Obsoletes: 4281 (if approved) D. Singer Intended status: Standards Track Apple Inc. Expires: October 20, 2011 P. Frojdh Ericsson Research April 18, 2011 The Codecs and Profiles Parameters for "Bucket" Media Types draft-gellens-mime-bucket-bis-04.txt Abstract Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered. This document specifies two parameters, "codecs" and "profiles", which are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs and/or profiles employed by the media formats contained within. RFC 4281, which this document obsoletes, defines the "codecs" parameter, which this document retains in a backwards compatible manor, with minor clarifications; the "profiles" parameter is added by this document. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Gellens, et al. Expires October 20, 2011 [Page 1] Internet-Draft MIME codecs and profiles April 2011 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 20, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gellens, et al. Expires October 20, 2011 [Page 2] Internet-Draft MIME codecs and profiles April 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . . 7 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . 9 3.3. ISO File Format Name Space . . . . . . . . . . . . . . . . 10 3.4. ISO Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Use in Additional Media Types . . . . . . . . . . . . . . 12 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Additional Media Feature Details . . . . . . . . . . . . . 13 4. The Profiles Parameter . . . . . . . . . . . . . . . . . . . . 14 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Formal Declaration . . . . . . . . . . . . . . . . . . . . 14 4.3. Profiles Parameter Definition . . . . . . . . . . . . . . 15 4.4. Profiles for files carrying registered brands . . . . . . 15 4.5. Profiles Parameter BNF Definition . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Gellens, et al. Expires October 20, 2011 [Page 3] Internet-Draft MIME codecs and profiles April 2011 1. Introduction One of the original motivations for MIME is the ability to identify the specific media type of a message part. However, due to various factors, it is not always possible from looking at the MIME type and subtype to know which specific media formats are contained in the body part, or which codecs are indicated in order to render the content. There are several media type/subtypes (either currently registered or deployed with registration pending) that contain codecs chosen from a set. In the absence of the parameters described here, it is necessary to examine each media element in order to determine the codecs or other features required to render the content. For example, video/3gpp may contain any of the video formats H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate - WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or Enhanced aacPlus, as specified in [3GPP-Formats]. In some cases, the specific codecs can be determined by examining the header information of the media content. While this isn't as bad as examining the entire content, it still requires specialized knowledge of each format and is resource consumptive. This ambiguity can be a problem for various clients and servers. For example, it presents a significant burden to Multimedia Messaging (MMS) servers, which must examine the media sent in each message in order to determine which codecs are required to render the content. Only then can such a server determine if the content requires transcoding or specialized handling prior to being transmitted to the handset. Additionally, it presents a challenge to smart clients on devices with constrained memory, processing power, or transmission bandwidth (such as cellular telephones and PDAs). Such clients often need to determine in advance if they are currently capable of rendering the content contained in an MMS or email message. Ambiguity: o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or Enhanced aacPlus contents as specified in [3GPP-Formats]. o audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), Enhanced Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or VMR-WB, as specified in [3GPP2-Formats]. Gellens, et al. Expires October 20, 2011 [Page 4] Internet-Draft MIME codecs and profiles April 2011 o video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC, or Enhanced aacPlus, as specified in [3GPP-Formats]. o video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [RFC3625]), EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats]. o audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 or registered at the MP4 registration authority [MP4RA]. o video/mp4 has the same issues as audio/mp4, and in addition many video codecs, and especially the MPEG codecs, have a variety of profiles and levels, not all of which are supported by every implementation. Note that there are additional media types that are ambiguous, but are outside the scope of this document, including: o video/mpeg4-generic, which can contain anything allowed by the MPEG-4 specification, or any codec registered with the MP4 registration authority [MP4RA]; With each "bucket" type, a receiving agent only knows that it has a container format. It doesn't even know whether content labeled video/3gpp or video/3gpp2 contains video; it might be audio only, audio and video, or video only. A solution that permits a receiving agent to determine the specific codecs or profiles required to render media content would help provide efficient and scalable servers, especially for Multimedia Messaging (MMS), and aid the growth of multimedia services in wireless networks. Gellens, et al. Expires October 20, 2011 [Page 5] Internet-Draft MIME codecs and profiles April 2011 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] . The syntax in this document uses the BNF rules specified in [RFC2045] and [RFC2231]. Gellens, et al. Expires October 20, 2011 [Page 6] Internet-Draft MIME codecs and profiles April 2011 3. The Codecs Parameter 3.1. Introduction This section adds a parameter to allow unambiguous specification of all codecs indicated to render the content in the MIME part. This parameter is optional in all current types to which it is added. Future types that contain ambiguity are strongly encouraged to include this parameter. This parameter applies to: 1. Files in the family based on the ISO Base Media File Format [ISO14496-12]. 2. The QuickTime file format, owned by Apple Inc. This includes the media types: 1. audio/3gpp, video/3gpp 2. audio/3gpp2, video/3gpp2 3. audio/mp4, video/mp4, application/mp4 4. video/quicktime 5. application/mp21 (see note below) Note that MPEG-21 files under the type application/mp21 may, but are not required to, contain a top-level 'moov' atom providing a timed, coded, resource. The codecs parameter SHOULD only be used for MPEG-21 files when this timed material is also present in the file. Parameter name: codecs Parameter value: A single value, or a comma-separated list of values identifying the codec(s) indicated to render the content in the body part. Each value consists of one or more dot-separated elements. The name space for the first element is determined by the MIME type. The name space for each subsequent element is determined by the preceding element. The precise syntax is given below in the Generic Syntax (Section 3.2). Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value Gellens, et al. Expires October 20, 2011 [Page 7] Internet-Draft MIME codecs and profiles April 2011 be enclosed in quotes. An element MAY include an octet that [RFC2045] REQUIRES to be encoded. In this case, [RFC2231] is used: an asterisk ("*") is placed at the end of the parameter name (becoming "codecs*" instead of "codecs"), the parameter value usually starts with two single quote ("'") characters (indicating that neither character set nor language is specified), and each octet that requires encoding is represented as a percent sign ("%") followed by two hexadecimal digits. When the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be encoded. Examples of Generic Syntax: codecs=a.bb.ccc.d codecs="a.bb.ccc.d, e.fff" codecs*=''fo%2e codecs*="''%25%20xz, gork" When the codecs parameter is used, it MUST contain all codecs indicated by the content present in the body part. The codecs parameter MUST NOT include any codecs that are not indicated by any media elements in the body part. In some cases, not all indicated codecs are absolutely required in order to render the content. Therefore, when a receiver does not support all listed codecs, special handling MAY be required. For example, the media element(s) MAY need to be examined in order to determine if an unsupported codec is actually required (e.g., there may be alternative tracks (such as English and Spanish audio), there may be timed text that can be dropped, etc.) NOTE: Although the parameter value MUST be complete and accurate in 'breadth' (that is, it MUST report all four-character codes used in all tracks for ISO-family files, for example) systems MUST NOT rely on it being complete in 'depth'. If the hierarchical rules for a given code (e.g., 'qvxy') were written after a server was implemented, for example, that server will not know what elements to place after 'qvxy'. If a receiver encounters a body part whose codecs parameter contains codecs that are not indicated by any media elements, then the receiver SHOULD process the body part by discarding the information in the codecs parameter. If a receiver encounters a body part whose codecs parameter does not contain all codecs indicated by the media elements, then the receiver Gellens, et al. Expires October 20, 2011 [Page 8] Internet-Draft MIME codecs and profiles April 2011 MAY process the body part by discarding the information in the codecs parameter. 3.2. Generic Syntax The codecs parameter takes either of two forms. The first form is used when the value does not contain any octets that require encoding. The second form uses [RFC2231] to allow arbitrary octets to be encoded. With either form, quotes allow for commas and other characters in (quotes MAY be used even when not required). This BNF uses the rules specified in [RFC2045] and [RFC2231] . Implementations MUST NOT add CFWS between the tokens except after ",". TOKEN is defined in [RFC2045], and and are defined in [RFC2231]. The BNF syntax is as follows: codecs := cod-simple / cod-fancy cod-simple := "codecs" "=" unencodedv unencodedv := id-simple / simp-list simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE id-simple := element ; "." reserved as hierarchy delimiter element := 1*octet-sim octet-sim := ; Within a codecs parameter value, "." is reserved ; as a hierarchy delimiter cod-fancy := "codecs*" ":=" encodedv encodedv := fancy-sing / fancy-list fancy-sing := [charset] "'" [language] "'" id-encoded ; Parsers MAY ignore ; Parsers MAY support only US-ASCII and UTF-8 fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE ; Parsers MAY ignore ; Parsers MAY support only US-ASCII and UTF-8 id-list := id-encoded *( "," id-encoded ) id-encoded := encoded-elm *( "." encoded-elm ) ; "." reserved as hierarchy delimiter encoded-elm := 1*octet-fancy octet-fancy := ext-octet / attribute-char DQUOTE := %x22 ; " (double quote) Gellens, et al. Expires October 20, 2011 [Page 9] Internet-Draft MIME codecs and profiles April 2011 Initial name space: This document only defines values for files in the ISO Base Media File Format, and QuickTime, families. Other file formats may also define codec naming. 3.3. ISO File Format Name Space For the ISO Base Media File Format, and the QuickTime movie file format, the first element of a codecs parameter value is a sample description entry four-character code as registered by the MP4 Registration Authority [MP4RA]. Values are case sensitive. Note that there are potentially multiple tracks in a file, each potentially carrying multiple sample entries (some but not all uses of the ISO File Format restrict the number of sample entries in a track to one). When the first element of a value is 'mp4a' (indicating some kind of MPEG-4 audio), or 'mp4v' (indicating some kind of MPEG-4 part-2 video), or 'mp4s' (indicating some kind of MPEG-4 Systems streams such as MPEG-4 BIFS), the second element is the hexadecimal representation of the MP4 Registration Authority ObjectTypeIndication (OTI), as specified in [MP4RA] and [MP41] (including amendments). Note that [MP4RA] uses a leading "0x" with these values, which is omitted here and hence implied. One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio). For this value, the third element identifies the audio ObjectTypeIndication (OTI) as defined in [MP4A] (including amendments), expressed as a decimal number. For example, AAC low complexity has the value 2, so a complete string for AAC-LC would be "mp4a.40.2". One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2 video). For this value, the third element identifies the video ProfileLevelIndication as defined in [MP4V] (including amendments), expressed as a decimal number. For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so a complete string for MPEG-4 Visual Simple Profile Level 0 would be "mp4v.20.9". When the first element of a value is a code indicating a codec from the Advanced Video Coding specification [AVC], specifically one of the sample entries defined in [AVC-Formats] (such as 'avc1', 'avc2', 'svc1', 'mvc1' and 'mvc2') - indicating AVC (H.264), Scalable Video Coding (SVC) or Multiview Video Coding (MVC), the second element (referred to as 'avcoti' in the formal syntax) is the hexadecimal Gellens, et al. Expires October 20, 2011 [Page 10] Internet-Draft MIME codecs and profiles April 2011 representation of the following three bytes in the (subset) sequence parameter set NAL unit specified in [AVC]: (1) profile_idc, (2) the byte containing the constraint_set flags (currently constraint_set0_flag through constraint_set5_flag, and the reserved_zero_2bits) and (3) level_idc. Note that the sample entries 'avc1' and 'avc2' do not necessarily indicate that the media only contains AVC NAL units. In fact, the media may be encoded as an SVC or MVC profile and thus contain SVC or MVC NAL units. In order to be able to determine which codec is used further information is necessary (profile_idc). Note also that reserved_zero_2bits is required to be equal to 0 in [AVC], but other values for it may be specified in the future by ITU-T or ISO/IEC. This is as previously defined in the 3GPP File Format specification 3GPP TS 26.244 [3GPP-Formats], section A.2.2. When SVC or MVC content is coded in an AVC-compatible fashion, the sample description may include both an AVC configuration record and an SVC or MVC configuration record. Under those circumstances, it is recommended that the two configuration records both be reported as they may contain different AVC profile, level, and compatibility indicator values. Thus the codecs reported would include the sample description code (e.g. 'avc1') twice, with the values from one of the configuration records forming the 'avcoti' information in each. Gellens, et al. Expires October 20, 2011 [Page 11] Internet-Draft MIME codecs and profiles April 2011 3.4. ISO Syntax id-simple :=/ id-iso id-encoded :=/ id-iso id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc iso-gen := cpid *( element / encoded-elm ) ; used with ; used with ; ; Note that the BNF permits "." within ; and but "." is reserved as the ; hierarchy delimiter iso-mpega := mp4a "." oti [ "." aud-oti ] iso-mpegv := mp4v "." oti [ "." vid-pli ] iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ] cpid := 4(octet-simple / octet-fancy) ; used with ; used with mp4a := %x6d.70.34.61 ; 'mp4a' oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; leading "0x" omitted avc1 := %x61.76.63.31 ; 'avc1' avc2 := %x61.76.63.32 ; 'avc2' svc1 := %x73.76.63.31 ; 'svc1' mvc1 := %x6d.76.63.31 ; 'mvc1' mvc2 := %x6d.76.63.32 ; 'mvc2' avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; leading "0x" omitted aud-oti := 1*DIGIT mp4v := %x6d.70.34.76 ; 'mp4v' vid-pli := 1*DIGIT 3.5. Use in Additional Media Types This parameter MAY be specified for use with additional MIME media types. For ISO file formats where the name space as defined here is sufficient, all that needs to be done is to update the media type registration to specify the codecs parameter with a reference to this document. For existing media types, it is generally advisable for the parameter to be optional; for new media types, the parameter MAY be optional or required, as appropriate. For ISO file formats where the name space as defined here needs to be expanded, a new document MAY update this one by specifying the additional detail. Gellens, et al. Expires October 20, 2011 [Page 12] Internet-Draft MIME codecs and profiles April 2011 For non-ISO formats, a new document MAY update this one by specifying the name space for the media type(s). 3.6. Examples Content-Type: video/3gpp2; codecs="sevc, s263" (EVRC audio plus H.263 video) Content-Type: audio/3gpp; codecs=samr (AMR audio) Content-Type: video/3gpp; codecs="s263, samr" (H.263 video plus AMR audio) Content-Type: audio/3gpp2; codecs=mp4a.E1 (13k audio) Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1" (MPEG-4 Visual Simple Profile Level 0 plus 13K voice) Content-Type: video/mp4; codecs="avc1.640028" (H.264/AVC video, High Profile, Level 40, e.g. DVB 720p 50Hz HDTV) Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E" (SVC video, Scalable High Profile, Level 30, with a Main Profile AVC base layer, e.g. DVB 25 Hz SDTV) Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030" (MVC video, Stereo High Profile, Level 42, with a High Profile base layer, e.g. as adopted in Blu-ray) Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated Amendment(s) and Corrigendum(a). The actual object types are defined in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in [MP4V], Annex K." (references adjusted). 3.7. Additional Media Feature Details It is sometimes helpful to provide additional details for a media element (e.g., the number of X and Y pixels, the color depth, etc.). These details are sometimes called "media features" or "media characteristics". When such additional features are included, the content-features [RFC2912] header provides a handy way to do so. Gellens, et al. Expires October 20, 2011 [Page 13] Internet-Draft MIME codecs and profiles April 2011 4. The Profiles Parameter 4.1. Introduction Just as some codecs have a variety of profiles (subsets of their functionality within which a bitstream can be coded), so also some media files can be profiled, and be associated with one or more profile identifiers of the profiles to which they conform. These profiles can indicate features of the file format itself, which codecs may be present, the profiles of those codecs, and so on. It can be advantageous to a receiving system to know the overall file profile(s) of a file; indeed, under these circumstances it may not be necessary to know the codecs themselves if they are implied by the profile. 4.2. Formal Declaration This section adds a parameter to allow unambiguous specification of the profiles to which a file claims conformance. This parameter is optional in all current types to which it is added. This parameter applies to: 1. Box-structured (also known as atom-structured) files that have an initial box containing compatibility brands, as registered at the MP4 Registration Authority [MP4RA], such as a filetype or segment-type box. This includes principally files in the family based on the ISO Base Media File Format [ISO14496-12]. 2. The QuickTime file format, owned by Apple Inc. This includes the media types: 1. audio/3gpp, video/3gpp 2. audio/3gpp2, video/3gpp2 3. audio/mp4, video/mp4 4. video/quicktime 5. application/mp21 Parameter name: profiles Parameter value: A single value, or a comma-separated list of values identifying the profiles(s) to which the file claims conformance. Gellens, et al. Expires October 20, 2011 [Page 14] Internet-Draft MIME codecs and profiles April 2011 The name space is determined by the MIME type. Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value be enclosed in quotes. An element MAY include an octet that [RFC2045] REQUIRES to be encoded. In this case, [RFC2231] is used: an asterisk ("*") is placed at the end of the parameter name (becoming "profiles*" instead of "profiles"), the parameter value usually starts with two single quote ("'") characters(indicating that neither character set nor language is specified), and each octet that requires encoding is represented as a percent sign ("%") followed by two hexadecimal digits. When the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be encoded. Examples of Generic Syntax: profiles="isom,mp41,qvXt" profiles*="''%25%20xz, gork" 4.3. Profiles Parameter Definition The 'profiles' parameter is an optional parameter that indicates one or more profiles to which the file claims conformance. Like the 'codecs' parameter described above, it may occur as either 'profiles' or 'profiles*', with the same encoding rules. The value is, as for the codecs parameter, a comma-separated list of profile identifiers. 4.4. Profiles for files carrying registered brands For any file format carrying a brand registered at the MP4 Registration Authority [MP4RA], notably files based on the ISO Base Media File Format ISO/IEC 14496-12 [ISO14496-12] and QuickTime movie files, the profiles parameter MUST list exactly the major brand, followed by the compatible-brands, as listed in the filetype box ('ftyp') or segment-type box ('styp'). The major-brand MUST be first, and MAY be removed from the compatible-brands list. (The file format requires that it be repeated in the compatible brands, but this requirement is relaxed here for compactness.) An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4 version 1 is the major brand and preferred use, that the file is compatible with the version of the base file format identified by 'isom', and that it is also compatible with the specification/profile 'qvXt' (whatever that may be). Gellens, et al. Expires October 20, 2011 [Page 15] Internet-Draft MIME codecs and profiles April 2011 4.5. Profiles Parameter BNF Definition profil := pro-simple / pro-fancy pro-simple := "profiles" "=" unencodedv ; Within a codecs parameter value, "." is reserved ; as a hierarchy delimiter pro-fancy := "profiles*" ":=" encodedv Gellens, et al. Expires October 20, 2011 [Page 16] Internet-Draft MIME codecs and profiles April 2011 5. IANA Considerations The IANA has added "codecs" and "profiles" as optional parameters to the media types as listed in Sections 3 and 4, with a reference to this document. Gellens, et al. Expires October 20, 2011 [Page 17] Internet-Draft MIME codecs and profiles April 2011 6. Registration The MPEG4 Registration Authority can be consulted for the most up-to- date registration of sub-parameters for the codecs type, for specific codecs. Gellens, et al. Expires October 20, 2011 [Page 18] Internet-Draft MIME codecs and profiles April 2011 7. Security Considerations The codecs parameter itself does not alter the security considerations of any of the media types with which it is used. Each audio and video media type has its own set of security considerations that continue to apply, regardless of the use of the codecs parameter. An incorrect codecs parameter might cause media content to be received by a device that is not capable of rendering it, or might cause media content to not be sent to a device that is capable of receiving it. An incorrect codecs parameter is therefore capable of some types of denial-of-service attacks. However, this is most likely to arise by accident, as an attacker capable of altering media data in transit could cause more harm by altering the media format itself, or even the content type header, rather than just the codecs parameter of the content type header. Gellens, et al. Expires October 20, 2011 [Page 19] Internet-Draft MIME codecs and profiles April 2011 8. Acknowledgements Harinath Garudadri provided a great deal of help, which is very much appreciated. Mary Barnes and Bruce Lilly provided detailed and helpful comments. Reviews and comments by Sam Hartman, Russ Housley, and Bert Wijnen were much appreciated. Chris Newman carefully reviewed and improved the BNF. Christian Timmerer helped with the MPEG-21 material, and Thomas Schierl and Yago Sanchez helped with SVC and MVC. Gellens, et al. Expires October 20, 2011 [Page 20] Internet-Draft MIME codecs and profiles April 2011 9. References 9.1. Normative References [3GPP-Formats] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244. [AVC] "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, ISO/IEC 14496-10:2009. [AVC-Formats] "Information technology -- Coding of audio-visual objects -- Part 15: Advanced Video Coding (AVC) file format", ISO/ IEC 14496-15:2010. [ISO14496-12] "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/ IEC 14496-12:2008. [MP4RA] "MP4REG, The MPEG-4 Registration Authority", . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2912] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000. 9.2. Informative References [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 File Formats for Multimedia Service", . Gellens, et al. Expires October 20, 2011 [Page 21] Internet-Draft MIME codecs and profiles April 2011 [MP41] "Information technology--Coding of audio-visual objects-- Part 1: Systems", ISO/IEC 14496-1:2010. [MP4A] "Information technology--Coding of audio-visual objects--3: Audio", ISO/IEC 14496-3:2009. [MP4V] "Information technology--Coding of audio-visual objects-- Part 2: Visual", ISO/IEC 14496-2:2004. [RFC3625] Gellens, R. and H. Garudadri, "The QCP File Format and Media Types for Speech Data", RFC 3625, September 2003. Gellens, et al. Expires October 20, 2011 [Page 22] Internet-Draft MIME codecs and profiles April 2011 Authors' Addresses Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 US Email: randy@qualcomm.com David Singer Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US Phone: +1 408 996 1010 Email: singer@apple.com Per Frojdh Ericsson Research Multimedia Technologies SE-164 Stockholm 80 Sweden Phone: +46 8 7190000 Email: Per.Frojdh@ericsson.com Gellens, et al. Expires October 20, 2011 [Page 23] --Boundary_(ID_Mmgfj2177wQsPQR0h9rPCQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > >> >> In Section 4.2: >> >> "An element MAY include an octet that must be encoded in order to >> comply with [RFC2045]" >> >> I suggest capitalizing the "must". > > I suggest using the wording from above: > > An element MAY include an octet that [RFC2045] REQUIRES to be > encoded. In this case, [RFC2231] is used: > >> >> "Note that, when the [RFC2231] form is used, >> the percent sign, asterisk, and single quote characters have special >> meaning and so must themselves be encoded." >> >> I suggest capitalizing the "must". > > I agree. > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > He who would travel happily must travel light. --Antoine St. Exuperey David Singer Multimedia and Software Standards, Apple Inc. --Boundary_(ID_Mmgfj2177wQsPQR0h9rPCQ)-- From tbray@textuality.com Tue Apr 19 10:42:13 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D926E071E for ; Tue, 19 Apr 2011 10:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM2ZcWZAGneM for ; Tue, 19 Apr 2011 10:42:12 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9B424E069C for ; Tue, 19 Apr 2011 10:42:12 -0700 (PDT) Received: by pwi5 with SMTP id 5so3803028pwi.31 for ; Tue, 19 Apr 2011 10:42:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.104 with SMTP id j8mr9005462pbh.448.1303234931841; Tue, 19 Apr 2011 10:42:11 -0700 (PDT) Received: by 10.68.60.193 with HTTP; Tue, 19 Apr 2011 10:42:11 -0700 (PDT) X-Originating-IP: [216.239.45.130] In-Reply-To: <58E207308662A748A4AC1ECB4E88561408142CB8CA@ESESSCMS0355.eemea.ericsson.se> References: <58E207308662A748A4AC1ECB4E88561408142CB8CA@ESESSCMS0355.eemea.ericsson.se> Date: Tue, 19 Apr 2011 10:42:11 -0700 Message-ID: From: Tim Bray To: Oscar Novo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dave.Morgan@fmr.com" , "apps-discuss@ietf.org" , S Moonesamy , Gonzalo Camarillo , "jari.urpalainen@nokia.com" , "alan.b.johnston@gmail.com" Subject: Re: [apps-discuss] Apps-team review of draft-ietf-xcon-common-data-model-25.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:42:13 -0000 Looks good. Follow up: On Tue, Apr 19, 2011 at 5:16 AM, Oscar Novo wrote= : > General issue: There is much discussion of the values of various elements= . =A0There seems little discussion of whether exact case matching is requir= ed, whether white-space on either side of the designated values is allowed,= and so on. =A0Is this obvious from the context of the other SIP RFCs? =A0I= t would trouble me as an implementor. > =A0There are a couple of nits below where I've called this out. > > [ON] The RELAX NG shema is defining the syntactic of the elements. That's= why the text is not giving any clear guidance about it. The implementor ju= st has to follow the RELAX NG schema defined in this document. So I think you need a paragraph in your introduction saying that the syntax of element values is constrained by the provided RNG grammar, which is normative; the text in the main body of the specification is explanatory, but implementation MUST generate and parse content conforming to the schema. > 4.4.1 "The element represents a boo= lean action. " - should 'action' be 'value'? (this idiom also appears sever= al more times in the draft) > > [ON] I would say it's right. The element represents a boolean action. Tha= t's mean, the action can only take two boolean values. The term "boolean" has well-defined semantics in math and in computer language type theory. It is not applicable to an "action" in either of these senses. But I don't care, it's obvious what you mean. From jyee@afilias.info Tue Apr 19 10:54:00 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8192BE07DF for ; Tue, 19 Apr 2011 10:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3y9TR+ouWvd for ; Tue, 19 Apr 2011 10:53:59 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfc.amsl.com (Postfix) with ESMTP id 60CFBE0702 for ; Tue, 19 Apr 2011 10:53:59 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QCF7e-0005dH-62 for Apps-Discuss@ietf.org; Tue, 19 Apr 2011 17:53:58 +0000 Received: from mail-gy0-f178.google.com ([209.85.160.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QCF7e-0001US-5L for Apps-Discuss@ietf.org; Tue, 19 Apr 2011 17:53:58 +0000 Received: by gyd12 with SMTP id 12so5840515gyd.9 for ; Tue, 19 Apr 2011 10:53:58 -0700 (PDT) Received: by 10.150.74.13 with SMTP id w13mr5929045yba.313.1303235637869; Tue, 19 Apr 2011 10:53:57 -0700 (PDT) Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id x4sm321746ybl.8.2011.04.19.10.53.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 10:53:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: Date: Tue, 19 Apr 2011 13:53:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30217A32-0BCF-4074-BA49-AB87E57C7655@afilias.info> References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1082) Cc: klaus.darilion@nic.at, ed guy , Jason Livingood , Apps-Discuss@ietf.org Subject: Re: [apps-discuss] Apps-Review Team Review: draft-ietf-enum-iax-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:54:00 -0000 Hi Bernie, On 2011-04-19, at 6:22 AM, Bernie Hoeneisen wrote: > Hi Joseph >=20 > Thanks for your review and feedback on draft-ietf-enum-iax-10. > My comments inline. >=20 >=20 > On Tue, 19 Apr 2011, Joseph Yee wrote: >=20 >> Nits: >> (1) >> In Section 5, IANA Considerations, words suggested to make = registration type more specific >>=20 >> Original >> This document requests registration of the 'iax' Enumservice >> according.... >>=20 >> Suggestion >> This document requests registration of the Enumservice >> Type 'iax' according..... >=20 > Could be changed, although IMHO not really needed. No concern if not changed. >=20 >=20 >> (2) >> In Section 5, IANA Considerations, specifications reference should = include RFC6116 >>=20 >> Original >> according to the guidelines and specifications in [RFC6117] >> and the definitions in Section 2 in this document. >>=20 >> Suggestion >> according to the guidelines and specifications in [RFC6117], >> [RFC6116] and the definitions in Section 2 in this document. >=20 >=20 > Adding a reference to RFC 6116 just confuses the reader, as RFC 6116 = does not contain any specifications concerning IANA registration. When = we revised RFC 3761, we purposly made a split between ENUM (as protocol) = and the Enumservices (IANA registration, process). > (A reader who tries to find IANA Enumservices related content in RFC = 6116 due to such a reference will be disappointed, as all he finds is a = reference to RFC 6117.) >=20 > Therefore, a reference to RFC 6116 to the IANA considerations section = of draft-ietf-enum-iax should not be added. Thanks for clarifying terms. I read more in depth of both RFC6116 and = RFC6117 on referencing, and agreed it's not necessary. Best, Joseph >=20 > cheers, > Bernie (document shephard of draft-ietf-enum-iax & author of RFC 6117) >=20 > PS: I added Jason (the designated Expert for this document) to the Cc. >=20 > -- >=20 > http://ucom.ch/ > Tech Consulting for Internet Standardization > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From barryleiba.mailing.lists@gmail.com Tue Apr 19 11:40:22 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D709DE0664 for ; Tue, 19 Apr 2011 11:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.526 X-Spam-Level: X-Spam-Status: No, score=-103.526 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVW9CZlcgKlr for ; Tue, 19 Apr 2011 11:40:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 48154E0685 for ; Tue, 19 Apr 2011 11:40:21 -0700 (PDT) Received: by wwa36 with SMTP id 36so4905924wwa.13 for ; Tue, 19 Apr 2011 11:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qusT7ZSIW0FssuOh4Hc4kAHJrpChzUzZ8b6vyJ0Fuug=; b=fqVWQRuD0GblcLblOor+vx5CDr0+VUDN0HJyDCEHDhnNed1+GleHWMFc1CSfYgptPU 9g3btim5H8XAirdFzLXoJtdZEM10wFd70OrvtCwa7yqBb7JfFGR8PvQpUl+8kcYUjlpc RgEir0cUjbb+1E2OkX7gWaQDA9tqpi173oXBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=B3NWRVr+pzZiVQll38qORcLBupVNZHFnuexsJFWF7CGbjXHsVj8v3mp8tgPW2KJyni LxpJkHly1vXs9KQrlg8nZCJN5WikjTcyPR3gjujuNYpRZrs9P1mEpJaKguMWXpMecVrn 2IrZHrLeQv/ISa9MvmfQ3Fp1LQugkbMqBFEjE= MIME-Version: 1.0 Received: by 10.216.136.89 with SMTP id v67mr1672856wei.47.1303238420576; Tue, 19 Apr 2011 11:40:20 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.216.242.71 with HTTP; Tue, 19 Apr 2011 11:40:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2011 14:40:20 -0400 X-Google-Sender-Auth: RBUEy8Vf8zfWrLGTAp0omY-MR6M Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf-822@imc.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:40:23 -0000 On reading all the comments about this, and thinking about it myself, I'm of a very mixed mind. First: I have no sympathy for the comments that we should fix this stuff in 5322, and not in some "add-on". This is *not* "fixing" anything. This is *not* saying that any of the "malformed" messages are now valid. This is not changing anything at all in 5322. What this is doing is acknowledging that senders often violate 5322, and that those violations are *wrong*. What it adds is that it also acknowledges the reality that, as Nathaniel and others have said, we can't just throw those wrong messages away, and there's some value in agreeing how to handle them. This document -- or its final version -- is an attempt to document that agreement. Agents along the way -- MSAs, MTAs, MDAs, and MUAs -- will make their guesses and fix-ups, and I do think it's in the best interest of everyone for us to document less-harmful avenues to take, as well as roads to hell. So I support this document for that reason. On the other hand, Ned's right that the "best" (or least bad, or whatever) way to handle each situation *is* likely to change over time, so locking the advice into a BCP might not work well. It's also clear that some malformations will do best with complicated heuristics beyond what'll be recommended here. The appearance of a non-header line in a message header is a perfect example of that. Consider these two fragments: 1: Date: xxx Subject: this is a badly continued header line MIME-Version: 1.0 This is the body of the message. 2: Date: xxx MIME-Version: 1.0 Subject: this is the subject I've improperly terminated the header here. This is the rest of the body. The right answer for the two is different. In (1), we don't want to assume the "continued header line" is the beginning of the body, and in (2) we don't want to try to treat the "I've improperly" line as a continuation of the subject. A better answer will be to look ahead a bit to try to re-establish context and make a better guess than can be done simply by applying a rule. And yet number three here will break that too: 3: Date: xxx MIME-Version: 1.0 Subject: this is the subject I've improperly terminated the header here. Look: You know it's complicated. This is rest of the body. On the other hand, we know that some of these issues are straightforward. Why make everyone figure it all out from scratch? In the end, the best we can do is to make recommendations to try to get some consistency. I think it's worth doing a document like this, but it's not at all straightforward, and we'll have to be very careful at every step to make a few things clear: 1. The appearance of these broken messages is BAD, and the BEST thing is to fix the software that's generating them. 2. Sometimes, it really IS the right thing to reject/refuse/bounce/whatever-you-want-to-call-it the message. 3. We do or don't have a sense of a reasonably safe guess to make for this particular malformation. 4. When we do have a reasonably safe guess, here's what it is. Barry From oscar.novo@ericsson.com Wed Apr 20 01:23:52 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A12AEE0796 for ; Wed, 20 Apr 2011 01:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xczKbnCQGMP for ; Wed, 20 Apr 2011 01:23:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id A782CE0791 for ; Wed, 20 Apr 2011 01:23:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-55-4dae9816aaa4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E4.83.11171.6189EAD4; Wed, 20 Apr 2011 10:23:51 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.138]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 20 Apr 2011 10:23:50 +0200 From: Oscar Novo To: Tim Bray Date: Wed, 20 Apr 2011 10:23:49 +0200 Thread-Topic: Apps-team review of draft-ietf-xcon-common-data-model-25.txt Thread-Index: Acv+uR7GNEOyA2B+R6KH0b+M5XvAzgAeoBEg Message-ID: <58E207308662A748A4AC1ECB4E88561408142CBBE6@ESESSCMS0355.eemea.ericsson.se> References: <58E207308662A748A4AC1ECB4E88561408142CB8CA@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 20 Apr 2011 08:10:49 -0700 Cc: "Dave.Morgan@fmr.com" , "apps-discuss@ietf.org" , S Moonesamy , Gonzalo Camarillo , "jari.urpalainen@nokia.com" , "alan.b.johnston@gmail.com" Subject: Re: [apps-discuss] Apps-team review of draft-ietf-xcon-common-data-model-25.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:23:52 -0000 Hi, Thanks for your feedback. Section "3.1 Data Model Format" already take care= of explaining your suggestion:=20 "A conference object document is an XML [W3C.REC-xml-20001006] document that MUST be well formed and SHOULD be valid. Conference object documents MUST be based on Extensible Markup Language (XML) 1.0 and SHOULD be encoded using UTF-8."=20 Cheers, Oscar -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com]=20 Sent: 19. huhtikuuta 2011 20:42 To: Oscar Novo Cc: apps-discuss@ietf.org; S Moonesamy; alan.b.johnston@gmail.com; Gonzalo = Camarillo; Dave.Morgan@fmr.com; jari.urpalainen@nokia.com Subject: Re: Apps-team review of draft-ietf-xcon-common-data-model-25.txt Looks good. Follow up: On Tue, Apr 19, 2011 at 5:16 AM, Oscar Novo wrote= : > General issue: There is much discussion of the values of various elements= . =A0There seems little discussion of whether exact case matching is requir= ed, whether white-space on either side of the designated values is allowed,= and so on. =A0Is this obvious from the context of the other SIP RFCs? =A0I= t would trouble me as an implementor. > =A0There are a couple of nits below where I've called this out. > > [ON] The RELAX NG shema is defining the syntactic of the elements. That's= why the text is not giving any clear guidance about it. The implementor ju= st has to follow the RELAX NG schema defined in this document. So I think you need a paragraph in your introduction saying that the syntax= of element values is constrained by the provided RNG grammar, which is nor= mative; the text in the main body of the specification is explanatory, but = implementation MUST generate and parse content conforming to the schema. > 4.4.1 "The element represents a=20 > boolean action. " - should 'action' be 'value'? (this idiom also=20 > appears several more times in the draft) > > [ON] I would say it's right. The element represents a boolean action. Tha= t's mean, the action can only take two boolean values. The term "boolean" has well-defined semantics in math and in computer langu= age type theory. It is not applicable to an "action" in either of these se= nses. But I don't care, it's obvious what you mean. From alexey.melnikov@isode.com Wed Apr 20 14:39:20 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 58D4CE075D for ; Wed, 20 Apr 2011 14:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMcOVwpQSfhy for ; Wed, 20 Apr 2011 14:39:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id 38035E06DE for ; Wed, 20 Apr 2011 14:39:19 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Apr 2011 22:39:18 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DAF5256.2040303@isode.com> Date: Wed, 20 Apr 2011 22:38:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:39:20 -0000 Dear APPSAWG participants, There has been an active discussion about the document this week. Given that, I would like to ask the following questions: 1). Who is willing to review and post comments on the document if the WG accepts this document as a WG document? 2). Are there any objections to accepting this document as a WG document? If you have an objection, please be explicit about the nature of the objection (for example, if you think the document is harmful and shouldn't be worked on). Note that just saying that you don't like the document is not a good enough reason without further explanation. Explicit statements in favor of accepting are welcomed as well. But please also respond if you find objections by others to be objectionable ;-). You can send both objections and your statements of support directly to me (if you wish) or to the mailing list. Please send your responses by the end of April 29th. Alexey, as an APPSAWG co-chair -- Internet Messaging Team Lead, JID: same as my email address twitter: aamelnikov From barryleiba@computer.org Wed Apr 20 15:52:06 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1E23E0791; Wed, 20 Apr 2011 15:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6tQwaqEuGiz; Wed, 20 Apr 2011 15:52:06 -0700 (PDT) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by ietfc.amsl.com (Postfix) with ESMTP id 0ED9BE0765; Wed, 20 Apr 2011 15:52:02 -0700 (PDT) Received: from [192.168.0.2] (ool-457c2d3b.dyn.optonline.net [69.124.45.59]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0LJZ005AM3IOVEL0@mta2.srv.hcvlny.cv.net>; Wed, 20 Apr 2011 18:52:02 -0400 (EDT) Date: Wed, 20 Apr 2011 18:51:59 -0400 From: Barry Leiba To: apps-discuss@ietf.org Message-id: <7000F5E5D27FA961BE7D9EC6@uranus> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline Cc: public-iri@w3.org, draft-hoffman-rfc3536bis@tools.ietf.org, ima@ietf.org, idna-update@alvestrand.no, precis@ietf.org Subject: [apps-discuss] Call for adoption of draft-hoffman-rfc3536bis as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "apps-discuss@ietf.org" <> List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:52:06 -0000 Paul Hoffman and John Klensin have undertaken to update RFC 3536, which specified terminology for use in internationalization-related documents and discussions. The editors, appsawg chairs, and Applications Area directors think the document needs broad review, and propose to make it an appsawg document. You can find the document here: http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ The editors will soon submit an updated version, and await a decision on accepting the document into appsawg before doing that. We ask that anyone with a stake in internationalization review the current version and state any objections to making this an appsawg document by 29 April. You may, or course, also send comments on the document at this point to the editors and/or the apps-discuss list. Remember that there are changes queued, so you might bring up points that they're already planning to change/correct. The reply-to on this message is set to the apps-discuss list . Please put all responses and discussion there. Barry, appsawg chair From duerst@it.aoyama.ac.jp Wed Apr 20 16:54:02 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8F0B1E06E2 for ; Wed, 20 Apr 2011 16:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.965 X-Spam-Level: X-Spam-Status: No, score=-100.965 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoJfptnqnQTD for ; Wed, 20 Apr 2011 16:54:02 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfc.amsl.com (Postfix) with ESMTP id 7EFC5E0673 for ; Wed, 20 Apr 2011 16:54:00 -0700 (PDT) Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p3KNrs1s002164 for ; Thu, 21 Apr 2011 08:53:54 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 0a58_5764_72c70650_6ba9_11e0_8ecd_001d096c5b62; Thu, 21 Apr 2011 08:53:54 +0900 Received: from [IPv6:::1] ([133.2.210.5]:48727) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 21 Apr 2011 08:53:51 +0900 Message-ID: <4DAF71FE.8080103@it.aoyama.ac.jp> Date: Thu, 21 Apr 2011 08:53:34 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <7000F5E5D27FA961BE7D9EC6@uranus> In-Reply-To: <7000F5E5D27FA961BE7D9EC6@uranus> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-hoffman-rfc3536bis@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Call for adoption of draft-hoffman-rfc3536bis as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:54:02 -0000 [I significantly cut down the cc list] I have not yet read the current document (sorry, no time just now), but I have read RFC 3536, and I think this document should be adopted as a WG draft. Regards, Martin. On 2011/04/21 7:51, Barry Leiba wrote: > Paul Hoffman and John Klensin have undertaken to update RFC 3536, which > specified terminology for use in internationalization-related documents > and discussions. The editors, appsawg chairs, and Applications Area > directors think the document needs broad review, and propose to make it > an appsawg document. > > You can find the document here: > http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ > > The editors will soon submit an updated version, and await a decision on > accepting the document into appsawg before doing that. We ask that > anyone with a stake in internationalization review the current version > and state any objections to making this an appsawg document by 29 April. > > You may, or course, also send comments on the document at this point to > the editors and/or the apps-discuss list. Remember that there are > changes queued, so you might bring up points that they're already > planning to change/correct. > > The reply-to on this message is set to the apps-discuss list > . Please put all responses and discussion there. > > Barry, appsawg chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From jefsey@jefsey.com Thu Apr 21 04:49:23 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D253EE06CF; Thu, 21 Apr 2011 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkygD8apeAcd; Thu, 21 Apr 2011 04:49:22 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfc.amsl.com (Postfix) with ESMTP id 945B0E0698; Thu, 21 Apr 2011 04:49:22 -0700 (PDT) Received: from 18.109-227-89.dsl.completel.net ([89.227.109.18]:60868 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QCsNr-0004v5-LK; Thu, 21 Apr 2011 04:49:20 -0700 Message-Id: <7.0.1.0.2.20110421111550.059fe118@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 21 Apr 2011 13:49:31 +0200 To: iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: apps-discuss@ietf.org, precis@ietf.org, public-iri@w3.org, idna-update@alvestrand.no, ima@ietf.org, draft-hoffman-rfc3536bis@tools.ietf.org Subject: [apps-discuss] terminology X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:49:24 -0000 Dear IUsers, Barry Leiba, WG/APPSAWG Chair has sent the following most important mail for us: >"Paul Hoffman and John Klensin have undertaken to update RFC 3536, >which specified terminology for use in internationalization-related >documents and discussions. The editors, appsawg chairs, and >Applications Area directors think the document needs broad review, >and propose to make it an appsawg document. >You can find the document here: >http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ >The editors will soon submit an updated version, and await a >decision on accepting the document into appsawg before doing >that. We ask that anyone with a stake in internationalization >review the current version and state any objections to making this >an appsawg document by 29 April. >You may, or course, also send comments on the document at this point >to the editors and/or the apps-discuss list. Remember that there >are changes queued, so you might bring up points that they're >already planning to change/correct. >The reply-to on this message is set to the apps-discuss list >. Please put all responses and discussion there. This terminology is obviously going to be the mutual understanding bridge between the IETF and the IUTF communities. http://iucg.org/wiki/Wiki_RFC_3536bis is the traditional wiki working transcript (unfinished as yet) of the proposed draft. This is in line with my own I_D on orthotypography: http://tools.ietf.org/html/draft-iucg-idna2008-orthotypography-00 I suggest thet our target should be : 1. to make sure RFC 3536bis by APPSAWG is in line with our own understanding of the terms in our own working contexts (IDNA2008, ML-DNS, IUI, EST). 2. to build our own Internet extension section to document in a similar manner the emergent IUse terminology. This section should not document any concept than the way we read and use the existing "Internal Internet" technology (i.e. no bit change). 3. to continue building in contnuity our own dictionnary of the new IUI and Intersem (semiotic/semantic Intercomprehension network) stratum. Best. jfc NB: due to personal constraints that should now progressively reduce I was not able to sustain my post-IDNA2008 endeavour as I planned it. Some terminology used in this mail is not therefore as common and supported by operational prototypes as our little group hoped. Thank you to read the used acronyms/terms as follows: - IDNA2008: as documented by RFC 5890 to 5895 - ML-DNS: multilayer DNS (of which layer 1 is the Internal Internet DNS, layer 2 is IDNA2008). - IUI: Intelligent Use Interface (Internet Use Interface from an Internet perspective). i.e. a generalization of principle introduced by Paul Hoffman and Pete Resnick in RFC 5895 and a stable optional response to problems discussed by the IAB in RFC 6055 - IUse: an emergent community interested in an open general Intelligent Use of the world digital ecosystem (whatever the multitechnological convergence). - EST: Extended System Theory, a glogalization of the General System Theory which includes networking and interfaces and is necessary to better read the IETF RFCs in an IUse perspective. - IUTF: Intelligent Use Task Force, TF under formation further to the responses to the appeals to IESG and IAB following the successfull, but not documented yet as such, introduction of the principle of subsidiarity (IDNA2008) as the third internet architectural principle (RFC 1958: principle of permanent change, RFC 3439: principle of simplicity). I note that subsidiairity should come with suppleance (I did not found so far an English equivalent for the core to support peripheral difficulties) and precaution. - Dictionnary (http://iucg.org/wiki/Dictionnary): this IUCG project to integrate digital ecosystem convergence and ALFA (Free Acrchitecture) words. From paul.hoffman@vpnc.org Thu Apr 21 13:54:36 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35832E0722; Thu, 21 Apr 2011 13:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.054 X-Spam-Level: X-Spam-Status: No, score=-102.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG8TrwXdJuTJ; Thu, 21 Apr 2011 13:54:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 7F754E06B9; Thu, 21 Apr 2011 13:54:35 -0700 (PDT) Received: from sn80.proper.com (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3LKsSV9015073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Apr 2011 13:54:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7000F5E5D27FA961BE7D9EC6@uranus> Date: Thu, 21 Apr 2011 13:54:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B50401F-D2C9-42F1-9D61-D4B9A836DBEF@vpnc.org> References: <7000F5E5D27FA961BE7D9EC6@uranus> To: Apps Discuss X-Mailer: Apple Mail (2.1084) Cc: public-iri@w3.org, precis@ietf.org, draft-hoffman-rfc3536bis@tools.ietf.org, ima@ietf.org, idna-update@alvestrand.no Subject: Re: [apps-discuss] Call for adoption of draft-hoffman-rfc3536bis as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:54:36 -0000 On a related note, John and I have issued the -02 with a few fixes, = including a discussion of the always-popular "variant". See = . --Paul Hoffman= From ted.ietf@gmail.com Thu Apr 21 15:47:26 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45F59E06A4; Thu, 21 Apr 2011 15:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdItD-gT3+U9; Thu, 21 Apr 2011 15:47:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 8D24EE00BE; Thu, 21 Apr 2011 15:47:24 -0700 (PDT) Received: by pwi5 with SMTP id 5so122954pwi.31 for ; Thu, 21 Apr 2011 15:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ijXM5AnWpYtOhb7JI+/QNPrwr/goj0xHgUROi1JhhgA=; b=ICcUyGdOtSGH5ympjqsph2KEUm97FZE35SM8+bY5Eyft0oeEadG2YXHFm2vh0F91jl UE0/2h10zLYOJSEyJkEz+Zt/MUxXneV+yyd1le3vaQ+m5g2uXEjt9/OJISlyPX8UGETf G8juRidJLr71adu8c+HuLnfq8JkypE/7Dd/3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XGA1eGpQhKhQ1KBTlHdqcEKzb6bSgsJ5ytz6MhXiqUsqEh4QDljSYffxA5vsCllCmD 567WYForGl7pQt4VuLj7HQf1GzvP8gz1Ts4uOslBoNT9gN1FfeJKxferHomMfCvK+6Cm mfb1m3JtM+ZOCyqbD7zCT0GZUc2QQVAETL1xk= MIME-Version: 1.0 Received: by 10.68.49.136 with SMTP id u8mr646309pbn.170.1303426043999; Thu, 21 Apr 2011 15:47:23 -0700 (PDT) Received: by 10.68.48.33 with HTTP; Thu, 21 Apr 2011 15:47:23 -0700 (PDT) Date: Thu, 21 Apr 2011 15:47:23 -0700 Message-ID: From: Ted Hardie To: sandra.murphy@sparta.com, draft-ietf-sidr-rpki-manifests@tools.ietf.org, IESG , Apps Discuss Content-Type: multipart/alternative; boundary=bcaec544e98a57f5d904a17586d7 Subject: [apps-discuss] Applications Area Review of draft-ietf-sidr-rpki-manifests-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:47:26 -0000 --bcaec544e98a57f5d904a17586d7 Content-Type: text/plain; charset=ISO-8859-1 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-rpki-manifests-10 Title: Manifests for the Resource Public Key Infrastructure Reviewer: Ted Hardie Review Date: April 21, 2011 Summary: This draft is almost ready for publication as a Proposed Standard, but I believe it would benefit from restructuring to highlight the operational requirements for correct use. Issues: It's always difficult to review one piece of a document set that clearly depends on a much broader context, because some of the backstory is scattered in other documents. My primary concern with this document is not that it is incomplete, but that some of the operationally critical pieces may be too buried for the user community not immersed in the development of the protocol. The document introduction describes the baseline need for the protocol with this text: However, digital signatures provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not expired, but have since been superseded) or attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, the RPKI repository system can make use of a signed object called a "manifest". and the model for the response as: Manifests are modeled on CRLs, as the issues involved in detecting stale manifests, and detection of potential attacks using manifest replays, etc are similar to those for CRLs. The syntax of the manifest payload differs from CRLs, since RPKI repositories contain objects not covered by CRLs,e.g., digitally signed objects, such as Route Origination Authorizations (ROAs) The risk here appears to be exactly the same as that of CRL that is unexpired but superseded--if a manifest has not reached its "nextUpdate" time but has been superseded, it provides protection only if the relying partying can detect that the manifest has changed. An early pointer to the operational implications in this specific context would be valuable for the naive reader. It would be especially useful to describe how and when relying parties should check for updated manifests, when this is not simply a new retrieval at nextUpdate time. Some other aspects of the operational considerations that are present appear to be a bit buried. For example, this text in the definition of the nextUpdate field ties the nextUpdate time for the manifest to that of an encompassed CRL: If the authority alters any of the items that it has published in the repository publication point, then the authority MUST issue a new manifest before the nextUpdate time. If a manifest encompasses a CRL, the nextUpdate field of the manifest MUST match that of the CRL's nextUpdate field, as the manifest will be re- issued when a new CRL is published. The implications to me are that whoever controls the issuance of the manifest must also control the issuance of the CRL, so that the CRL's nextUpdate field can take into account any *other* changes that it might need to make that would cause it to issue a new manifest. (Alternatively, it might be permitted to issue a manifest with a nextUpdate time that was before the CRL's nextUpdate time.) It also seems difficult to include more than one CRL in the repository, since they would all be tied to the same timing. Making this impact explicit, rather than implicit would be valuable. I was also concerned by the apparent conflicts occasionally caused by the discussion of key rollover. In section 5.2, for example, the document says: Since the manifest object URL is included in the SIA of issued Certificates, a new manifest MUST NOT invalidate the manifest object URL of previously issued certificates. This implies that the manifest's publication name in the repository, in the form of an object URL, is unchanged across manifest generation cycles. When a CA entity is performing a key rollover, the entity MAY chose to have two CAs instances simultaneously publishing into the same repository publication point. In this case there will be one manifest associated with each active CA instance that is publishing into the common repository publication point (directory). The impact of the second paragraph seems to be that in the case where two CA instances are publishing simultaneously, each manifest must have a different object URL. Describing how a relying party determines that it should shift to the new instance (and thus new object URL) would be very useful. If these operational considerations are in other documents, more explicit pointers to the those documents would be fine. If they are not, I believe it might be useful to both expand and bring forward sections 5.2 and 6. (but not the subsequent 6.1-6). If those occurred as operational context after Manifest Scope, I believe that the document would be easier to follow and the manifests thus easier to use correctly. regards, Ted Hardie Nits: --bcaec544e98a57f5d904a17586d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Review Team reviewer for this= draft (for background on apps-review, please see http://www.apps.ietf.org/co= ntent/applications-area-review-team). Please resolve these comments alo= ng with any other Last Call comments=20 you may receive. Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft.

Document: draft-ietf-sidr-rpki-manifests-10
Title:=A0 Manifests for the Resource Public Key Infrastructure
Reviewer: Ted Hardie
Review Date: April 21, 2011

Summary:=A0 This draft is=20 almost ready for publication as a Proposed Standard, but I believe it would= benefit from restructuring to highlight the operational requirements for c= orrect use.

Issues:

It's always difficult to review one piece of a document= set that clearly depends on a much broader context, because some of the ba= ckstory is scattered in other documents.=A0 My primary concern with this do= cument is not that it is incomplete, but that some of the operationally cri= tical pieces may be too buried for the user community not immersed in the d= evelopment of the protocol.

The document introduction describes the baseline need for the protocol = with this text:

   However, digital signature=
s provide no protection
   against attacks that substitute "stale&q=
uot; versions of signed objects

   (i.e., objects that were valid and have not expired, but have since
 =
  been superseded) or attacks that remove an object that should be
   pr=
esent in the repository.  To assist in the detection of such
   attacks,=
 the RPKI repository system can make use of a signed object

   called a "manifest".
and the model for the response a= s:

   Manifests are modeled on CRLs, as the i=
ssues involved in detecting
   stale manifests, and detection of potenti=
al attacks using manifest

   replays, etc are similar to those for CRLs.  The syntax of the
   man=
ifest payload differs from CRLs, since RPKI repositories contain
   obje=
cts not covered by CRLs,e.g., digitally signed objects, such as
   Route=
 Origination Authorizations (ROAs)
The risk here appears to be exactly the same as that of CRL that is u= nexpired but superseded--if a manifest has not reached its "nextUpdate= " time but has been superseded, it provides protection only if the rel= ying partying can detect that the manifest has changed.=A0=A0 An early poin= ter to the operational implications in this specific context would be valua= ble for the naive reader. It would be especially useful to describe how and= when relying parties should check for updated manifests, when this is not = simply a new retrieval at nextUpdate time.

Some other aspects of the operational considerations that are present a= ppear to be a bit buried.=A0 For example, this text in the definition of th= e nextUpdate field ties the nextUpdate time for the manifest to that of an = encompassed CRL:

     If the authority alters any of the items th=
at it has published in
      the repository publication point, then the =
authority MUST issue a
      new manifest before the nextUpdate time.  I=
f a manifest

      encompasses a CRL, the nextUpdate field of the manifest MUST match      that of the CRL's nextUpdate field, as the manifest will be re-<=
br>      issued when a new CRL is published.
The implications to me a= re that whoever controls the issuance of the manifest must also control the= issuance of the CRL, so that the CRL's nextUpdate field can take into = account any *other* changes that it might need to make that would cause it = to issue a new manifest. (Alternatively, it might be permitted to issue a m= anifest with a nextUpdate time that was before the CRL's nextUpdate tim= e.)=A0 It also seems difficult to include more than one CRL in the reposito= ry, since they would all be tied to the same timing.=A0 Making this impact = explicit, rather than implicit would be valuable.

I was also concerned by the apparent conflicts occasionally caused by t= he discussion of key rollover.=A0=A0 In section 5.2, for example, the docum= ent says:

   Since the manifest object URL is=
 included in the SIA of issued

   Certificates, a new manifest MUST NOT invalidate the manifest object
=
   URL of previously issued certificates.  This implies that the
   mani=
fest's publication name in the repository, in the form of an
   obje=
ct URL, is unchanged across manifest generation cycles.


   When a CA entity is performing a key rollover, the entity MAY chose<=
br>   to have two CAs instances simultaneously publishing into the same
=
   repository publication point.  In this case there will be one
   mani=
fest associated with each active CA instance that is publishing

   into the common repository publication point (directory).
The i= mpact of the second paragraph seems to be that in the case where two CA ins= tances are publishing simultaneously, each manifest must have a different o= bject URL.=A0 Describing how a relying party determines that it should shif= t to the new instance (and thus new object URL) would be very useful.

If these operational considerations are in other documents, more explic= it pointers to the those documents would be fine.=A0 If they are not, I bel= ieve it might be useful to both expand and bring forward sections 5.2 and 6= . (but not the subsequent=A0 6.1-6).=A0 If those occurred as operational co= ntext after Manifest Scope, I believe that the document would be easier to = follow and the manifests thus easier to use correctly.

regards,

Ted Hardie



Nits:



--bcaec544e98a57f5d904a17586d7-- From vumip1@gmail.com Fri Apr 22 00:55:32 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFD5DE069C for ; Fri, 22 Apr 2011 00:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15GB0GpJLJVD for ; Fri, 22 Apr 2011 00:55:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5D23CE0679 for ; Fri, 22 Apr 2011 00:55:32 -0700 (PDT) Received: by yxk30 with SMTP id 30so139297yxk.31 for ; Fri, 22 Apr 2011 00:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xo4UG3Rl292C3foyc4IlZsu7knheRb3LGPCe59Y4uik=; b=m6gwOlDQf91cEZOKaUqVMkUZhyIbJxDDxVvNfjNdE/7bSee654jfqqvi89dfwehd6N WgjzZ7P/B8ZXULFUaGph5+1XTiwgRerYFc7V67sClNzHVFh2eQiNUCw04kKYISeSq/U5 OmRHuuht9AyHVO2mteyAhz5lhGoRlLvYrP6F0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k2Fpy9gh+R++C3iJ8HAowywcCyL/p8BDID24VPD92gmQtlVlvDsH7MMXN/N0UyqdZV cOL19UzKCIYQSwG+QuaEAJjXCx6Jb4kfnE9xynzwAzR10dSh/wYcEzyUBWzD1mXu8jiK 94Zz+GpjfOaLVKaF0DZ3jmtMr7Aq1Lv5A1d2E= MIME-Version: 1.0 Received: by 10.236.192.197 with SMTP id i45mr904184yhn.63.1303458932137; Fri, 22 Apr 2011 00:55:32 -0700 (PDT) Received: by 10.236.111.20 with HTTP; Fri, 22 Apr 2011 00:55:32 -0700 (PDT) Date: Fri, 22 Apr 2011 03:55:32 -0400 Message-ID: From: Bhumip Khasnabish To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=20cf30564307a11e9c04a17d2e32 Subject: [apps-discuss] Conf call to discuss virtual desktop infrastructure (VDI) works X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 07:55:33 -0000 --20cf30564307a11e9c04a17d2e32 Content-Type: text/plain; charset=ISO-8859-1 Based on our previous discussion on virtual desktop infrastructure (VDI) in this list (see e.g., http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02310.html), subsequent presentation during IETF-80 ( http://www.ietf.org/proceedings/80/minutes/apparea.txt), and discussion over lunch on Monday-28March2011, we are planning to continue work on developing the required architecture and requirements for VDI protocol and API. We are also looking for reports on VDI implementation experiences. *Start Time:* 10 AM ET (NY/USA time), Friday 22 April 2011 *Conf bridge:* US Toll-free +1-866-710-5490 If the toll-free number does not work, pls use +001-203-875-8973, *Passcode:* 204 1744# General Agenda VDI topics: - Protocol requirements, and APIs - Others: Architecture, Security framework, ... Note: All of the drafts and presentations are available at the following Website: http://trac.tools.ietf.org/area/app/trac/wiki/Clouds --20cf30564307a11e9c04a17d2e32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Based on our
previous discussion on virtual desktop infrastructure (VDI) i= n this list
(see e.g., = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02310.html),subsequent presentation during IETF-80 (http://www.ietf.org/proceedings/80/minutes/apparea.txt<= /a>),= =A0 and
discussion over lunch on Monday-28March2011, we are planning = to continue work on
developing the required architecture and requirements for VDI= protocol and API.
We are also looking for reports on VDI implementation experie= nces.

=A0

Start Time:<= /u> 10 AM ET (NY/USA time), Friday 22 April 20= 11

Conf bridge:= US Toll-free +1-866-710-5490

If the toll-free number does not work, pls use +001-203-875-89= 73,

Passcode: 204 1744#

=A0

General Agenda

VDI topics:

- Protocol requirements, and APIs

- Others: Architecture, Security framework, ...

=A0

Note: All of the drafts and presentations are available at the= following Website:

http://trac.tools.ietf.org/area/app/trac/wiki/Clouds

--20cf30564307a11e9c04a17d2e32-- From singer@apple.com Thu Apr 21 17:47:33 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A523E06F2 for ; Thu, 21 Apr 2011 17:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV1KuZz+98pa for ; Thu, 21 Apr 2011 17:47:29 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 43A3EE0673 for ; Thu, 21 Apr 2011 17:47:29 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GAp2xYHHXEW1Lp9OPfscKw)" Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK100BTJ3J43021@mail-out.apple.com> for apps-discuss@ietf.org; Thu, 21 Apr 2011 17:47:28 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-af-4db0d01f4c02 Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay11.apple.com (Apple SCV relay) with SMTP id A4.1A.23242.F10D0BD4; Thu, 21 Apr 2011 17:47:27 -0700 (PDT) From: David Singer In-reply-to: <6.2.5.6.2.20110419000054.055c8c10@elandnews.com> Date: Thu, 21 Apr 2011 17:47:27 -0700 Message-id: <8AAEA3D2-F482-4700-A846-83C8A4B10992@apple.com> References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> <6.2.5.6.2.20110419000054.055c8c10@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 22 Apr 2011 08:12:54 -0700 Cc: Randall Gellens , Per Frojdh , apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 00:47:33 -0000 --Boundary_(ID_GAp2xYHHXEW1Lp9OPfscKw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT OK I put back the "Note that" --Boundary_(ID_GAp2xYHHXEW1Lp9OPfscKw) Content-type: text/plain; x-unix-mode=0644; name=draft-gellens-mime-bucket-bis-04.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-gellens-mime-bucket-bis-04.txt Network Working Group R. Gellens Internet-Draft QUALCOMM Incorporated Obsoletes: 4281 (if approved) D. Singer Intended status: Standards Track Apple Inc. Expires: October 23, 2011 P. Frojdh Ericsson Research April 21, 2011 The Codecs and Profiles Parameters for "Bucket" Media Types draft-gellens-mime-bucket-bis-04.txt Abstract Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered. This document specifies two parameters, "codecs" and "profiles", which are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs and/or profiles employed by the media formats contained within. This document obsoletes RFC 4281; RFC 4281 defines the "codecs" parameter, which this document retains in a backwards compatible manner with minor clarifications; the "profiles" parameter is added by this document. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Gellens, et al. Expires October 23, 2011 [Page 1] Internet-Draft MIME codecs and profiles April 2011 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 23, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gellens, et al. Expires October 23, 2011 [Page 2] Internet-Draft MIME codecs and profiles April 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . . 7 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . 9 3.3. ISO File Format Name Space . . . . . . . . . . . . . . . . 10 3.4. ISO Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Use in Additional Media Types . . . . . . . . . . . . . . 12 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Additional Media Feature Details . . . . . . . . . . . . . 13 4. The Profiles Parameter . . . . . . . . . . . . . . . . . . . . 14 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Formal Declaration . . . . . . . . . . . . . . . . . . . . 14 4.3. Profiles Parameter Definition . . . . . . . . . . . . . . 15 4.4. Profiles for files carrying registered brands . . . . . . 15 4.5. Profiles Parameter BNF Definition . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Gellens, et al. Expires October 23, 2011 [Page 3] Internet-Draft MIME codecs and profiles April 2011 1. Introduction One of the original motivations for MIME is the ability to identify the specific media type of a message part. However, due to various factors, it is not always possible from looking at the MIME type and subtype to know which specific media formats are contained in the body part, or which codecs are indicated in order to render the content. There are several media type/subtypes (either currently registered or deployed with registration pending) that contain codecs chosen from a set. In the absence of the parameters described here, it is necessary to examine each media element in order to determine the codecs or other features required to render the content. For example, video/3gpp may contain any of the video formats H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate - WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or Enhanced aacPlus, as specified in [3GPP-Formats]. In some cases, the specific codecs can be determined by examining the header information of the media content. While this isn't as bad as examining the entire content, it still requires specialized knowledge of each format and is resource consumptive. This ambiguity can be a problem for various clients and servers. For example, it presents a significant burden to Multimedia Messaging (MMS) servers, which must examine the media sent in each message in order to determine which codecs are required to render the content. Only then can such a server determine if the content requires transcoding or specialized handling prior to being transmitted to the handset. Additionally, it presents a challenge to smart clients on devices with constrained memory, processing power, or transmission bandwidth (such as cellular telephones and PDAs). Such clients often need to determine in advance if they are currently capable of rendering the content contained in an MMS or email message. Ambiguity: o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or Enhanced aacPlus contents as specified in [3GPP-Formats]. o audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), Enhanced Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or VMR-WB, as specified in [3GPP2-Formats]. Gellens, et al. Expires October 23, 2011 [Page 4] Internet-Draft MIME codecs and profiles April 2011 o video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC, or Enhanced aacPlus, as specified in [3GPP-Formats]. o video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [RFC3625]), EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats]. o audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 or registered at the MP4 registration authority [MP4RA]. o video/mp4 has the same issues as audio/mp4, and in addition many video codecs, and especially the MPEG codecs, have a variety of profiles and levels, not all of which are supported by every implementation. Note that there are additional media types that are ambiguous, but are outside the scope of this document, including: o video/mpeg4-generic, which can contain anything allowed by the MPEG-4 specification, or any codec registered with the MP4 registration authority [MP4RA]; With each "bucket" type, a receiving agent only knows that it has a container format. It doesn't even know whether content labeled video/3gpp or video/3gpp2 contains video; it might be audio only, audio and video, or video only. A solution that permits a receiving agent to determine the specific codecs or profiles required to render media content would help provide efficient and scalable servers, especially for Multimedia Messaging (MMS), and aid the growth of multimedia services in wireless networks. Gellens, et al. Expires October 23, 2011 [Page 5] Internet-Draft MIME codecs and profiles April 2011 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] . The syntax in this document uses the BNF rules specified in [RFC2045] and [RFC2231]. Gellens, et al. Expires October 23, 2011 [Page 6] Internet-Draft MIME codecs and profiles April 2011 3. The Codecs Parameter 3.1. Introduction This section adds a parameter to allow unambiguous specification of all codecs indicated to render the content in the MIME part. This parameter is optional in all current types to which it is added. Future types that contain ambiguity are strongly encouraged to include this parameter. This parameter applies to: 1. Files in the family based on the ISO Base Media File Format [ISO14496-12]. 2. The QuickTime file format, owned by Apple Inc. This includes the media types: 1. audio/3gpp, video/3gpp 2. audio/3gpp2, video/3gpp2 3. audio/mp4, video/mp4, application/mp4 4. video/quicktime 5. application/mp21 (see note below) Note that MPEG-21 files under the type application/mp21 may, but are not required to, contain a top-level 'moov' atom providing a timed, coded, resource. The codecs parameter SHOULD only be used for MPEG-21 files when this timed material is also present in the file. Parameter name: codecs Parameter value: A single value, or a comma-separated list of values identifying the codec(s) indicated to render the content in the body part. Each value consists of one or more dot-separated elements. The name space for the first element is determined by the MIME type. The name space for each subsequent element is determined by the preceding element. The precise syntax is given below in the Generic Syntax (Section 3.2). Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value Gellens, et al. Expires October 23, 2011 [Page 7] Internet-Draft MIME codecs and profiles April 2011 be enclosed in quotes. An element MAY include an octet that [RFC2045] REQUIRES to be encoded. In this case, [RFC2231] is used: an asterisk ("*") is placed at the end of the parameter name (becoming "codecs*" instead of "codecs"), the parameter value usually starts with two single quote ("'") characters (indicating that neither character set nor language is specified), and each octet that requires encoding is represented as a percent sign ("%") followed by two hexadecimal digits. Note that, when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be encoded. Examples of Generic Syntax: codecs=a.bb.ccc.d codecs="a.bb.ccc.d, e.fff" codecs*=''fo%2e codecs*="''%25%20xz, gork" When the codecs parameter is used, it MUST contain all codecs indicated by the content present in the body part. The codecs parameter MUST NOT include any codecs that are not indicated by any media elements in the body part. In some cases, not all indicated codecs are absolutely required in order to render the content. Therefore, when a receiver does not support all listed codecs, special handling MAY be required. For example, the media element(s) MAY need to be examined in order to determine if an unsupported codec is actually required (e.g., there may be alternative tracks (such as English and Spanish audio), there may be timed text that can be dropped, etc.) NOTE: Although the parameter value MUST be complete and accurate in 'breadth' (that is, it MUST report all four-character codes used in all tracks for ISO-family files, for example) systems MUST NOT rely on it being complete in 'depth'. If the hierarchical rules for a given code (e.g., 'qvxy') were written after a server was implemented, for example, that server will not know what elements to place after 'qvxy'. If a receiver encounters a body part whose codecs parameter contains codecs that are not indicated by any media elements, then the receiver SHOULD process the body part by discarding the information in the codecs parameter. If a receiver encounters a body part whose codecs parameter does not contain all codecs indicated by the media elements, then the receiver Gellens, et al. Expires October 23, 2011 [Page 8] Internet-Draft MIME codecs and profiles April 2011 MAY process the body part by discarding the information in the codecs parameter. 3.2. Generic Syntax The codecs parameter takes either of two forms. The first form is used when the value does not contain any octets that require encoding. The second form uses [RFC2231] to allow arbitrary octets to be encoded. With either form, quotes allow for commas and other characters in (quotes MAY be used even when not required). This BNF uses the rules specified in [RFC2045] and [RFC2231] . Implementations MUST NOT add CFWS between the tokens except after ",". TOKEN is defined in [RFC2045], and and are defined in [RFC2231]. The BNF syntax is as follows: codecs := cod-simple / cod-fancy cod-simple := "codecs" "=" unencodedv unencodedv := id-simple / simp-list simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE id-simple := element ; "." reserved as hierarchy delimiter element := 1*octet-sim octet-sim := ; Within a codecs parameter value, "." is reserved ; as a hierarchy delimiter cod-fancy := "codecs*" ":=" encodedv encodedv := fancy-sing / fancy-list fancy-sing := [charset] "'" [language] "'" id-encoded ; Parsers MAY ignore ; Parsers MAY support only US-ASCII and UTF-8 fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE ; Parsers MAY ignore ; Parsers MAY support only US-ASCII and UTF-8 id-list := id-encoded *( "," id-encoded ) id-encoded := encoded-elm *( "." encoded-elm ) ; "." reserved as hierarchy delimiter encoded-elm := 1*octet-fancy octet-fancy := ext-octet / attribute-char DQUOTE := %x22 ; " (double quote) Gellens, et al. Expires October 23, 2011 [Page 9] Internet-Draft MIME codecs and profiles April 2011 Initial name space: This document only defines values for files in the ISO Base Media File Format, and QuickTime, families. Other file formats may also define codec naming. 3.3. ISO File Format Name Space For the ISO Base Media File Format, and the QuickTime movie file format, the first element of a codecs parameter value is a sample description entry four-character code as registered by the MP4 Registration Authority [MP4RA]. Values are case sensitive. Note that there are potentially multiple tracks in a file, each potentially carrying multiple sample entries (some but not all uses of the ISO File Format restrict the number of sample entries in a track to one). When the first element of a value is 'mp4a' (indicating some kind of MPEG-4 audio), or 'mp4v' (indicating some kind of MPEG-4 part-2 video), or 'mp4s' (indicating some kind of MPEG-4 Systems streams such as MPEG-4 BIFS), the second element is the hexadecimal representation of the MP4 Registration Authority ObjectTypeIndication (OTI), as specified in [MP4RA] and [MP41] (including amendments). Note that [MP4RA] uses a leading "0x" with these values, which is omitted here and hence implied. One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio). For this value, the third element identifies the audio ObjectTypeIndication (OTI) as defined in [MP4A] (including amendments), expressed as a decimal number. For example, AAC low complexity has the value 2, so a complete string for AAC-LC would be "mp4a.40.2". One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2 video). For this value, the third element identifies the video ProfileLevelIndication as defined in [MP4V] (including amendments), expressed as a decimal number. For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so a complete string for MPEG-4 Visual Simple Profile Level 0 would be "mp4v.20.9". When the first element of a value is a code indicating a codec from the Advanced Video Coding specification [AVC], specifically one of the sample entries defined in [AVC-Formats] (such as 'avc1', 'avc2', 'svc1', 'mvc1' and 'mvc2') - indicating AVC (H.264), Scalable Video Coding (SVC) or Multiview Video Coding (MVC), the second element (referred to as 'avcoti' in the formal syntax) is the hexadecimal Gellens, et al. Expires October 23, 2011 [Page 10] Internet-Draft MIME codecs and profiles April 2011 representation of the following three bytes in the (subset) sequence parameter set NAL unit specified in [AVC]: (1) profile_idc, (2) the byte containing the constraint_set flags (currently constraint_set0_flag through constraint_set5_flag, and the reserved_zero_2bits) and (3) level_idc. Note that the sample entries 'avc1' and 'avc2' do not necessarily indicate that the media only contains AVC NAL units. In fact, the media may be encoded as an SVC or MVC profile and thus contain SVC or MVC NAL units. In order to be able to determine which codec is used further information is necessary (profile_idc). Note also that reserved_zero_2bits is required to be equal to 0 in [AVC], but other values for it may be specified in the future by ITU-T or ISO/IEC. This is as previously defined in the 3GPP File Format specification 3GPP TS 26.244 [3GPP-Formats], section A.2.2. When SVC or MVC content is coded in an AVC-compatible fashion, the sample description may include both an AVC configuration record and an SVC or MVC configuration record. Under those circumstances, it is recommended that the two configuration records both be reported as they may contain different AVC profile, level, and compatibility indicator values. Thus the codecs reported would include the sample description code (e.g. 'avc1') twice, with the values from one of the configuration records forming the 'avcoti' information in each. Gellens, et al. Expires October 23, 2011 [Page 11] Internet-Draft MIME codecs and profiles April 2011 3.4. ISO Syntax id-simple :=/ id-iso id-encoded :=/ id-iso id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc iso-gen := cpid *( element / encoded-elm ) ; used with ; used with ; ; Note that the BNF permits "." within ; and but "." is reserved as the ; hierarchy delimiter iso-mpega := mp4a "." oti [ "." aud-oti ] iso-mpegv := mp4v "." oti [ "." vid-pli ] iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ] cpid := 4(octet-simple / octet-fancy) ; used with ; used with mp4a := %x6d.70.34.61 ; 'mp4a' oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; leading "0x" omitted avc1 := %x61.76.63.31 ; 'avc1' avc2 := %x61.76.63.32 ; 'avc2' svc1 := %x73.76.63.31 ; 'svc1' mvc1 := %x6d.76.63.31 ; 'mvc1' mvc2 := %x6d.76.63.32 ; 'mvc2' avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; leading "0x" omitted aud-oti := 1*DIGIT mp4v := %x6d.70.34.76 ; 'mp4v' vid-pli := 1*DIGIT 3.5. Use in Additional Media Types This parameter MAY be specified for use with additional MIME media types. For ISO file formats where the name space as defined here is sufficient, all that needs to be done is to update the media type registration to specify the codecs parameter with a reference to this document. For existing media types, it is generally advisable for the parameter to be optional; for new media types, the parameter MAY be optional or required, as appropriate. For ISO file formats where the name space as defined here needs to be expanded, a new document MAY update this one by specifying the additional detail. Gellens, et al. Expires October 23, 2011 [Page 12] Internet-Draft MIME codecs and profiles April 2011 For non-ISO formats, a new document MAY update this one by specifying the name space for the media type(s). 3.6. Examples Content-Type: video/3gpp2; codecs="sevc, s263" (EVRC audio plus H.263 video) Content-Type: audio/3gpp; codecs=samr (AMR audio) Content-Type: video/3gpp; codecs="s263, samr" (H.263 video plus AMR audio) Content-Type: audio/3gpp2; codecs=mp4a.E1 (13k audio) Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1" (MPEG-4 Visual Simple Profile Level 0 plus 13K voice) Content-Type: video/mp4; codecs="avc1.640028" (H.264/AVC video, High Profile, Level 40, e.g. DVB 720p 50Hz HDTV) Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E" (SVC video, Scalable High Profile, Level 30, with a Main Profile AVC base layer, e.g. DVB 25 Hz SDTV) Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030" (MVC video, Stereo High Profile, Level 42, with a High Profile base layer, e.g. as adopted in Blu-ray) Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated Amendment(s) and Corrigendum(a). The actual object types are defined in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in [MP4V], Annex K." (references adjusted). 3.7. Additional Media Feature Details It is sometimes helpful to provide additional details for a media element (e.g., the number of X and Y pixels, the color depth, etc.). These details are sometimes called "media features" or "media characteristics". When such additional features are included, the content-features [RFC2912] header provides a handy way to do so. Gellens, et al. Expires October 23, 2011 [Page 13] Internet-Draft MIME codecs and profiles April 2011 4. The Profiles Parameter 4.1. Introduction Just as some codecs have a variety of profiles (subsets of their functionality within which a bitstream can be coded), so also some media files can be profiled, and be associated with one or more profile identifiers of the profiles to which they conform. These profiles can indicate features of the file format itself, which codecs may be present, the profiles of those codecs, and so on. It can be advantageous to a receiving system to know the overall file profile(s) of a file; indeed, under these circumstances it may not be necessary to know the codecs themselves if they are implied by the profile. 4.2. Formal Declaration This section adds a parameter to allow unambiguous specification of the profiles to which a file claims conformance. This parameter is optional in all current types to which it is added. This parameter applies to: 1. Box-structured (also known as atom-structured) files that have an initial box containing compatibility brands, as registered at the MP4 Registration Authority [MP4RA], such as a filetype or segment-type box. This includes principally files in the family based on the ISO Base Media File Format [ISO14496-12]. 2. The QuickTime file format, owned by Apple Inc. This includes the media types: 1. audio/3gpp, video/3gpp 2. audio/3gpp2, video/3gpp2 3. audio/mp4, video/mp4 4. video/quicktime 5. application/mp21 Parameter name: profiles Parameter value: A single value, or a comma-separated list of values identifying the profiles(s) to which the file claims conformance. Gellens, et al. Expires October 23, 2011 [Page 14] Internet-Draft MIME codecs and profiles April 2011 The name space is determined by the MIME type. Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value be enclosed in quotes. An element MAY include an octet that [RFC2045] REQUIRES to be encoded. In this case, [RFC2231] is used: an asterisk ("*") is placed at the end of the parameter name (becoming "profiles*" instead of "profiles"), the parameter value usually starts with two single quote ("'") characters(indicating that neither character set nor language is specified), and each octet that requires encoding is represented as a percent sign ("%") followed by two hexadecimal digits. Note that, when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be encoded. Examples of Generic Syntax: profiles="isom,mp41,qvXt" profiles*="''%25%20xz, gork" 4.3. Profiles Parameter Definition The 'profiles' parameter is an optional parameter that indicates one or more profiles to which the file claims conformance. Like the 'codecs' parameter described above, it may occur as either 'profiles' or 'profiles*', with the same encoding rules. The value is, as for the codecs parameter, a comma-separated list of profile identifiers. 4.4. Profiles for files carrying registered brands For any file format carrying a brand registered at the MP4 Registration Authority [MP4RA], notably files based on the ISO Base Media File Format ISO/IEC 14496-12 [ISO14496-12] and QuickTime movie files, the profiles parameter MUST list exactly the major brand, followed by the compatible-brands, as listed in the filetype box ('ftyp') or segment-type box ('styp'). The major-brand MUST be first, and MAY be removed from the compatible-brands list. (The file format requires that it be repeated in the compatible brands, but this requirement is relaxed here for compactness.) An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4 version 1 is the major brand and preferred use, that the file is compatible with the version of the base file format identified by 'isom', and that it is also compatible with the specification/profile 'qvXt' (whatever that may be). Gellens, et al. Expires October 23, 2011 [Page 15] Internet-Draft MIME codecs and profiles April 2011 4.5. Profiles Parameter BNF Definition profil := pro-simple / pro-fancy pro-simple := "profiles" "=" unencodedv ; Within a codecs parameter value, "." is reserved ; as a hierarchy delimiter pro-fancy := "profiles*" ":=" encodedv Gellens, et al. Expires October 23, 2011 [Page 16] Internet-Draft MIME codecs and profiles April 2011 5. IANA Considerations The IANA has added "codecs" and "profiles" as optional parameters to the media types as listed in Sections 3 and 4, with a reference to this document. Gellens, et al. Expires October 23, 2011 [Page 17] Internet-Draft MIME codecs and profiles April 2011 6. Registration The MPEG4 Registration Authority can be consulted for the most up-to- date registration of sub-parameters for the codecs type, for specific codecs. Gellens, et al. Expires October 23, 2011 [Page 18] Internet-Draft MIME codecs and profiles April 2011 7. Security Considerations The codecs parameter itself does not alter the security considerations of any of the media types with which it is used. Each audio and video media type has its own set of security considerations that continue to apply, regardless of the use of the codecs parameter. An incorrect codecs parameter might cause media content to be received by a device that is not capable of rendering it, or might cause media content to not be sent to a device that is capable of receiving it. An incorrect codecs parameter is therefore capable of some types of denial-of-service attacks. However, this is most likely to arise by accident, as an attacker capable of altering media data in transit could cause more harm by altering the media format itself, or even the content type header, rather than just the codecs parameter of the content type header. Gellens, et al. Expires October 23, 2011 [Page 19] Internet-Draft MIME codecs and profiles April 2011 8. Acknowledgements Harinath Garudadri provided a great deal of help, which is very much appreciated. Mary Barnes and Bruce Lilly provided detailed and helpful comments. Reviews and comments by Sam Hartman, Russ Housley, and Bert Wijnen were much appreciated. Chris Newman carefully reviewed and improved the BNF. Christian Timmerer helped with the MPEG-21 material, and Thomas Schierl and Yago Sanchez helped with SVC and MVC. Gellens, et al. Expires October 23, 2011 [Page 20] Internet-Draft MIME codecs and profiles April 2011 9. References 9.1. Normative References [3GPP-Formats] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244. [AVC] "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, ISO/IEC 14496-10:2009. [AVC-Formats] "Information technology -- Coding of audio-visual objects -- Part 15: Advanced Video Coding (AVC) file format", ISO/ IEC 14496-15:2010. [ISO14496-12] "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/ IEC 14496-12:2008. [MP4RA] "MP4REG, The MPEG-4 Registration Authority", . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2912] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000. 9.2. Informative References [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 File Formats for Multimedia Service", . Gellens, et al. Expires October 23, 2011 [Page 21] Internet-Draft MIME codecs and profiles April 2011 [MP41] "Information technology--Coding of audio-visual objects-- Part 1: Systems", ISO/IEC 14496-1:2010. [MP4A] "Information technology--Coding of audio-visual objects--3: Audio", ISO/IEC 14496-3:2009. [MP4V] "Information technology--Coding of audio-visual objects-- Part 2: Visual", ISO/IEC 14496-2:2004. [RFC3625] Gellens, R. and H. Garudadri, "The QCP File Format and Media Types for Speech Data", RFC 3625, September 2003. Gellens, et al. Expires October 23, 2011 [Page 22] Internet-Draft MIME codecs and profiles April 2011 Authors' Addresses Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 US Email: randy@qualcomm.com David Singer Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US Phone: +1 408 996 1010 Email: singer@apple.com Per Frojdh Ericsson Research Multimedia Technologies SE-164 Stockholm 80 Sweden Phone: +46 8 7190000 Email: Per.Frojdh@ericsson.com Gellens, et al. Expires October 23, 2011 [Page 23] --Boundary_(ID_GAp2xYHHXEW1Lp9OPfscKw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Apr 19, 2011, at 0:41 , S Moonesamy wrote: > Hi David, > At 11:36 18-04-2011, David Singer wrote: >> I agree, I think it best if capitalized verbs are used for requirements expressed in the document. So I would not capitalize 'requires' in this case, but it's OK by me. > > Randy commented on this in another message. The "requires" should be clear enough. > >> Existing text from 4281. Can I have MUST in a 'Note' sentence? Most bodies don't allow that. I think that the 'Note that,' should go: >> When the [RFC2231] form is used, the percent >> sign, asterisk, and single quote characters have special meaning and >> so MUST themselves be encoded. > > I have seen "MUST" used in "Note" sentences in other RFCs. You already had similar text in the RFC published in 2005. As it hasn't been a problem, I don't see why it should be a problem now. > > By the way, I gave an "almost ready for publication" rating as the document state is "Publication Requested" and the authors already know how to address editorial nits. > > Regards, > S. Moonesamy David Singer Multimedia and Software Standards, Apple Inc. --Boundary_(ID_GAp2xYHHXEW1Lp9OPfscKw)-- From yaojk@cnnic.cn Sat Apr 23 09:25:38 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6C15E070E for ; Sat, 23 Apr 2011 09:25:38 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -97.467 X-Spam-Level: X-Spam-Status: No, score=-97.467 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE1FOQytLgjz for ; Sat, 23 Apr 2011 09:25:38 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 4D7A0E06CD for ; Sat, 23 Apr 2011 09:25:36 -0700 (PDT) Received: (eyou send program); Sun, 24 Apr 2011 00:25:32 +0800 Message-ID: <503575932.12389@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaogcd67c8424b) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 24 Apr 2011 00:25:32 +0800 Message-ID: <562E1E79BF22413CB20836BD5753DAB5@yaogcd67c8424b> From: "Jiankang Yao" To: Date: Sun, 24 Apr 2011 00:25:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CC0216.1AE93950" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: idna-update@alvestrand.no Subject: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 16:25:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01CC0216.1AE93950 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBjb2xsZWFndWVzLA0KDQpUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgdHdvLXdlZWsgV0dMQyBv biB0aGUgZHJhZnQNCmRyYWZ0LWZhbHRzdHJvbS01ODkyYmlzLTA0LnR4dC4gIFdlIGRpZCBmb3Jt YWxseQ0KYWRvcHQgdGhpcyBJLUQgYXMgYSBXRyBkb2N1bWVudCBhIGZldyBtb250aHMgYWdvLg0K VGhlcmUgaGFzIGEgbG90IG9mIGRpc2N1c3Npb24gYW5kIGFuIGluZm9ybWFsIGxhc3QgY2FsbCBm b3IgY29tbWVudHMgYWJvdXQNCnRoaXMgZHJhZnQgaW4gdGhlIElETkFiaXMgbGlzdCBpZG5hLXVw ZGF0ZUBhbHZlc3RyYW5kLm5vLiAgDQpUaGUgZWRpdG9ycy9hdXRob3JzIG9mIHRoaXMgZHJhZnQg YmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQgaGFzIGJlZW4gaW4gYSB2ZXJ5IGdvb2Qgc2hhcGUuDQoN ClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0LiAgSWYgeW91IHN1cHBvcnQgcHVibGljYXRpb24sIHBs ZWFzZSBzdGF0ZSBhcw0KbXVjaCBvbiB0aGUgbGlzdC4gIElmIHlvdSBhcmUgb3Bwb3NlZCB0byBw dWJsaWNhdGlvbiwgcGxlYXNlIHN0YXRlDQp0aGF0IG9uIHRoZSBsaXN0IGFzIHdlbGwuICBJdCBp cyBtb3JlL29ubHkgaGVscGZ1bCBpZiB5b3UgZ2l2ZSB5b3VyIHJlYXNvbnMgZm9yDQp5b3VyIHBv c2l0aW9uIGFzIHBhcnQgb2YgeW91ciBzdGF0ZW1lbnQuICANCg0KU2luY2UgdGhpcyBkcmFmdCBp cyB0aGUgV0cgaXRlbSBvZiBBUFBTQVdHLCB3ZSBmYXZvciB0aGF0IHRoZSBjb21tZW50cyB0byB0 aGlzIGRyYWZ0IGFyZSBzZW50IHRvIHRoZSBsaXN0IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZy4gDQoN ClRoZSBXR0xDIHdpbGwgZW5kIG9uIE1heSAwOCwgMjAxMSBhdCAyMzowMCBVVEMuDQoNCk5vdGU6 IFRoaXMgZHJhZnQgaXMgYSBkb2N1bWVudCB0aGF0IHVwZGF0ZXMgYW4gZWFybGllciBSRkMgYnkg c3RhdGluZyBub3RoaW5nIGlzIHRvIGJlIHVwZGF0ZWQuIA0KDQoNCkJlc3QgcmVnYXJkcywNCkpp YW5rYW5nIFlhbyhhcyBhIGNvLWNoYWlyIG9mIEFQUFNBV0cpDQo= ------=_NextPart_000_0024_01CC0216.1AE93950 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MDQ2Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIHNp emU9Mj4NCjxESVY+PEZPTlQgc2l6ZT0zPkRlYXIgY29sbGVhZ3Vlcyw8QlI+PEJSPlRoaXMgbWVz c2FnZSBzdGFydHMgYSB0d28td2VlayBXR0xDIG9uIA0KdGhlIGRyYWZ0PEJSPmRyYWZ0LWZhbHRz dHJvbS01ODkyYmlzLTA0LnR4dC4mbmJzcDsmbmJzcDtXZSANCmRpZCZuYnNwO2Zvcm1hbGx5PEJS PmFkb3B0IHRoaXMgSS1EIGFzIGEgV0cgZG9jdW1lbnQgYSBmZXcgbW9udGhzIA0KYWdvLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0zPlRoZXJlIGhhcyBhIGxvdCBvZiBkaXNjdXNzaW9u IGFuZCBhbiBpbmZvcm1hbCBsYXN0IGNhbGwgZm9yIA0KY29tbWVudHMgYWJvdXQ8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mz50aGlzIGRyYWZ0IGluIHRoZSBJRE5BYmlzIGxpc3QgPC9G T05UPjxBIGhyZWY9IiIgDQptb3otZG8tbm90LXNlbmQ9InRydWUiPjxGT05UIHNpemU9Mz5pZG5h LXVwZGF0ZUBhbHZlc3RyYW5kLm5vPC9GT05UPjwvQT48Rk9OVCANCnNpemU9Mz4uJm5ic3A7IDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0zPlRoZSBlZGl0b3JzL2F1dGhvcnMgb2YgdGhp cyBkcmFmdCBiZWxpZXZlIHRoYXQgdGhpcyZuYnNwO2RyYWZ0IA0KaGFzIGJlZW4gaW4gYSB2ZXJ5 IGdvb2Qgc2hhcGUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTM+PEJSPlBsZWFzZSBy ZXZpZXcgdGhlIGRyYWZ0LiZuYnNwOyBJZiB5b3Ugc3VwcG9ydCBwdWJsaWNhdGlvbiwgDQpwbGVh c2Ugc3RhdGUgYXM8QlI+bXVjaCBvbiB0aGUgbGlzdC4mbmJzcDsgSWYgeW91IGFyZSBvcHBvc2Vk IHRvIHB1YmxpY2F0aW9uLCANCnBsZWFzZSBzdGF0ZTxCUj50aGF0IG9uIHRoZSBsaXN0IGFzIHdl bGwuJm5ic3A7IEl0IGlzIG1vcmUvb25seSBoZWxwZnVsJm5ic3A7aWYgDQp5b3UgZ2l2ZSZuYnNw O3lvdXIgcmVhc29ucyBmb3I8QlI+eW91ciBwb3NpdGlvbiBhcyBwYXJ0IG9mIHlvdXIgc3RhdGVt ZW50LiZuYnNwOyANCjxCUj48QlI+U2luY2UgdGhpcyBkcmFmdCBpcyB0aGUgV0cgaXRlbSBvZiBB UFBTQVdHLCB3ZSBmYXZvciB0aGF0IHRoZSBjb21tZW50cyANCnRvIHRoaXMgZHJhZnQmbmJzcDth cmUgc2VudCB0byB0aGUgbGlzdCA8L0ZPTlQ+PEEgaHJlZj0iIiANCm1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+PEZPTlQgc2l6ZT0zPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvRk9OVD48L0E+PEZPTlQg DQpzaXplPTM+LiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEJSPjxGT05UIHNpemU9Mz5UaGUg V0dMQyB3aWxsIGVuZCBvbiBNYXkgMDgsIDIwMTEgYXQgMjM6MDAgDQpVVEMuPC9GT05UPjwvRElW PjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9O VCBzaXplPTM+Tm90ZTombmJzcDtUaGlzIGRyYWZ0Jm5ic3A7aXMgYSBkb2N1bWVudCB0aGF0IA0K dXBkYXRlcyBhbiBlYXJsaWVyIFJGQyBieSBzdGF0aW5nIG5vdGhpbmcgaXMgdG8gYmUgdXBkYXRl ZC4gPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mz48 QlI+PEJSPkJlc3QgcmVnYXJkcyw8QlI+SmlhbmthbmcgWWFvKGFzIGEgDQpjby1jaGFpciBvZiBB UFBTQVdHKTxCUj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_000_0024_01CC0216.1AE93950-- From alexey.melnikov@isode.com Sun Apr 24 03:38:12 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B27C5E0697; Sun, 24 Apr 2011 03:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1QQZKRX1au6; Sun, 24 Apr 2011 03:38:12 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id 022ABE064E; Sun, 24 Apr 2011 03:38:12 -0700 (PDT) Received: from [188.28.175.146] (188.28.175.146.threembb.co.uk [188.28.175.146]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 24 Apr 2011 11:38:09 +0100 Message-ID: <4DB3FD7E.2030800@isode.com> Date: Sun, 24 Apr 2011 11:37:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: draft-ietf-sidr-roa-format.all@tools.ietf.org, IESG , Apps Discuss MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070803080608060505040100" Cc: sandra.murphy@sparta.com Subject: [apps-discuss] Applications Area Review of draft-ietf-sidr-roa-format-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 10:38:12 -0000 This is a multi-part message in MIME format. --------------070803080608060505040100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-roa-format-10 Title: A Profile for Route Origin Authorizations (ROAs) Reviewer: Alexey Melnikov Review Date: April 24, 2011 Summary: ready for publication Issues: none I have mostly a curiosity question: APPENDIX A: ASN.1 Module ROAIPAddressFamily ::= SEQUENCE { addressFamily OCTET STRING (SIZE (2..3)), What is the point of allowing size 3? addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress } Best Regards, Alexey --------------070803080608060505040100 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/MAIN/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/MAIN/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --------------070803080608060505040100-- From jefsey@jefsey.com Sun Apr 24 06:54:33 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 986BCE06A9; Sun, 24 Apr 2011 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.882 X-Spam-Level: X-Spam-Status: No, score=-100.882 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9ZYpi0gYtN7; Sun, 24 Apr 2011 06:54:33 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfc.amsl.com (Postfix) with ESMTP id 29E7FE0696; Sun, 24 Apr 2011 06:54:33 -0700 (PDT) Received: from 142.183-227-89.dsl.completel.net ([89.227.183.142]:57501 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QDzlf-0003HG-C1; Sun, 24 Apr 2011 06:54:31 -0700 Message-Id: <7.0.1.0.2.20110424020635.05d8a470@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 24 Apr 2011 15:55:00 +0200 To: From: JFC Morfin In-Reply-To: <503575932.12389@cnnic.cn> References: <503575932.12389@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 13:54:33 -0000 This draft is worded in a way I, and I suppose other IUCG Members, can accept. However, the need to publish it underlines that Unicode is not the most appropriate Internet oriented solution to support IDNs, the multilingual internet, and further on the Intersem (semiotic/semantic Internet). For example, I underlines once more that IDNA2008 using Unicode does not support the French (and many other languages) orthotypography. jfc morfin IUCG Facilitator From turners@ieca.com Sun Apr 24 06:57:41 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B5D62E074E for ; Sun, 24 Apr 2011 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX0v1kz9OMWU for ; Sun, 24 Apr 2011 06:57:41 -0700 (PDT) Received: from nm9.bullet.mail.ac4.yahoo.com (nm9.bullet.mail.ac4.yahoo.com [98.139.52.206]) by ietfc.amsl.com (Postfix) with SMTP id 22FADE06C1 for ; Sun, 24 Apr 2011 06:57:40 -0700 (PDT) Received: from [98.139.52.196] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 24 Apr 2011 13:57:40 -0000 Received: from [98.139.52.167] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 24 Apr 2011 13:57:40 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 24 Apr 2011 13:57:40 -0000 X-Yahoo-Newman-Id: 509183.72782.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 46896 invoked from network); 24 Apr 2011 13:57:40 -0000 Received: from thunderfish.local (turners@71.191.0.196 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 24 Apr 2011 06:57:39 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: z1OY7T4VM1mhD_cBO5BYcZSxOj6_rnB0BQdgDLBig94Q2Se 3u8HEunwnTul_z9qsaLuKBlxOMGjp5KI3epBdcLTP.qEyLsRZx3orJt.2HBC X3nHaPLVm72KVBpB2tPNv08NgW7RZnKrvlK5aHLbUMgTCQhf2yZhOvKmoKHy kmebE0_Nj2TsDHog1SmrEl1Zx6FB5Pu9sjg40rjhk4y0uCkA5y2LrzY4hSSg cJQIqf.i9.M82.3sfPwwY6ZjjinqteuEaJdKu7GbAc2Yj8HOrn8msl29cIRw 1BivY6OuKjSjZT5T6FJzgGnNemy4QNyBxEQrl19fGlj3YUsG3I0YmC5lAMhH GNdFI2SzQXYgd6AW8cHfEQQL7QsqbxjD8_JywZ4E6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB42C51.8020806@ieca.com> Date: Sun, 24 Apr 2011 09:57:37 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexey Melnikov References: <4DB3FD7E.2030800@isode.com> In-Reply-To: <4DB3FD7E.2030800@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 24 Apr 2011 08:19:13 -0700 Cc: sandra.murphy@sparta.com, draft-ietf-sidr-roa-format.all@tools.ietf.org, Apps Discuss , IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-sidr-roa-format-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 13:57:41 -0000 Alexey, See the following thread: http://www.ietf.org/mail-archive/web/sidr/current/msg02621.html spt On 4/24/11 6:37 AM, Alexey Melnikov wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). Please > resolve these comments along with any other Last Call comments you may > receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-sidr-roa-format-10 > Title: A Profile for Route Origin Authorizations (ROAs) > Reviewer: Alexey Melnikov > Review Date: April 24, 2011 > > Summary: ready for publication > > Issues: none > > I have mostly a curiosity question: > > > APPENDIX A: ASN.1 Module > > ROAIPAddressFamily ::= SEQUENCE { > addressFamily OCTET STRING (SIZE (2..3)), > > What is the point of allowing size 3? > > addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress } > > Best Regards, > Alexey > From jyee@afilias.info Sun Apr 24 09:29:00 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8FAEE05F5 for ; Sun, 24 Apr 2011 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPr1xUkFlGcw for ; Sun, 24 Apr 2011 09:29:00 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfc.amsl.com (Postfix) with ESMTP id 01360E062B for ; Sun, 24 Apr 2011 09:28:59 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QE2B6-0007eL-3e for Apps-Discuss@ietf.org; Sun, 24 Apr 2011 16:28:56 +0000 Received: from mail-iw0-f178.google.com ([209.85.214.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QE2B5-0008Ga-6B for Apps-Discuss@ietf.org; Sun, 24 Apr 2011 16:28:55 +0000 Received: by iwn9 with SMTP id 9so1537506iwn.9 for ; Sun, 24 Apr 2011 09:28:55 -0700 (PDT) Received: by 10.42.75.65 with SMTP id z1mr3580378icj.132.1303662533840; Sun, 24 Apr 2011 09:28:53 -0700 (PDT) Received: from [192.168.1.104] (69-196-182-49.dsl.teksavvy.com [69.196.182.49]) by mx.google.com with ESMTPS id t1sm1906133ibm.38.2011.04.24.09.28.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Apr 2011 09:28:52 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Apr 2011 12:28:50 -0400 Message-Id: To: Apps-Discuss@ietf.org, mark@azu.ca, jouni.nospam@gmail.com, lionel.morand@orange-fpgroup.com Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [apps-discuss] Apps-team review of draft-ietf-dime-extended-naptr-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 16:29:01 -0000 We have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please=20 seehttp://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-ietf-dime-extended-naptr-06 Title: Diameter S-NAPTR Usage Reviewers: Julian Reschke, Joseph Yee Review Date: April 23, 2011 Summary: This draft is almost ready for publication as Standard Track = RFC but has a few issues that should be fixed before publication Major Issues:=20 "app-protocol" is defined optional rather mandatory in current = draft =20 This draft adopts the model from RFC3958, where app-protocol is = optional. Not a Diameter myself, but I am under impression that this = draft intends to make app-protocol mandatory. The previous model = (RFC3588) always advertise the transport protocol (D2S or D2T). If = app-protocol is mandatory, add text (to Section 3, IMHO) to ensure it to = readers. If app-protocol is optional, please disregard this issue, but = I would suggest to expand Section 5 (query procedure steps). Minor Issues:=20 Section 3: iana-registered-service =3D aaa-service / ALPHA *31ALPHANUMSYM aaa-service =3D "aaa+ap" appln-id appln-id =3D DIGIT *DIGIT ; Application identifier expressed as a ; decimal integer. 1) Is "aaa+ap" case-insensitive? (That's the ABNF default for string = literals) 2) Maybe "1*DIGIT" instead of "DIGIT *DIGIT"? iana-registered-protocol =3D aaa-protocol / ALPHA *31ALPHANUMSYM aaa-protocol =3D "diameter." aaa-transport aaa-transport =3D "tcp" / "sctp" / "tls.tcp" Nits: None= From john-ietf@jck.com Sun Apr 24 10:42:26 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E4ABE06BD for ; Sun, 24 Apr 2011 10:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mal3YupWQt-B for ; Sun, 24 Apr 2011 10:42:25 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 9A313E05F5 for ; Sun, 24 Apr 2011 10:42:25 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QE3KB-0005iI-Sm; Sun, 24 Apr 2011 13:42:24 -0400 X-Vipre-Scanned: 021A3A22002393021A3B6F-TDI Date: Sun, 24 Apr 2011 13:42:23 -0400 From: John C Klensin To: Jiankang Yao , apps-discuss@ietf.org Message-ID: <7FE9748079E870860D590EF0@[192.168.1.128]> In-Reply-To: <503575932.12389@cnnic.cn>, <562E1E79BF22413CB20836BD5753DAB5@yaogcd67c8424b> References: <503575932.12389@cnnic.cn>, <562E1E79BF22413CB20836BD5753DAB5@yaogcd67c8424b> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 17:42:26 -0000 --On Sunday, April 24, 2011 00:25 +0800 Jiankang Yao wrote: > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-faltstrom-5892bis-04.txt. We did formally > adopt this I-D as a WG document a few months ago. > There has a lot of discussion and an informal last call for > comments about this draft in the IDNAbis list > idna-update@alvestrand.no. The editors/authors of this draft > believe that this draft has been in a very good shape. > > Please review the draft. If you support publication, please > state as much on the list. If you are opposed to publication, >... I think it is time to approve this and move on. To review, the issue here was caused by some corrections of properties between Unicode 5.2 and Unicode 6.0. There is no debate about the corrections being appropriate. The question is whether it is more important to maintain strict backward compatibility (by making the characters exceptions in IDNA to preserve the status given to them by the Unicode 5.2 properties) or to maintain consistency with Unicode properties going forward. The latter avoids having to actually create an exception table at this stage and avoids what many of us think of as a fork from Unicode conformance and libraries into more separate IDNA ones. In any event, we have been through the discussion several times, no one is changing their minds, and just about everyone seems to be in agreement that the odds of these particular characters ever being an actual issue (other than as a matter of principle) are quite low. My main concern at this stage is that the exception procedure in IDNA2008 assumes that there will be very few property changes between Unicode versions and we can react fairly quickly when they occur. Whether the "few" criterion is being met (i.e., whether the implicit promises made about it) depends on one one's point of view. Seen as a percentage of the total number of characters in Unicode, the number of changes is miniscule. Seen as a cause of disruption and uncertainty, they may be more of a problem. And, while the IDNABIS WG anticipated that the first few Unicode releases after IDNA2008 was adopted would take extra time as we examined procedures and precedents, we are certainly not managing "fairly quickly" when it takes this many months to publish a document whose essence is "we have agreed to do nothing". In the short term, I think that suggests we need to approve it now rather than wasting more time. In the longer term, we may need to think about more efficient ways to handle this sort of thing. john From barryleiba.mailing.lists@gmail.com Sun Apr 24 14:20:34 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87154E067F for ; Sun, 24 Apr 2011 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7d1pjD5xz-7 for ; Sun, 24 Apr 2011 14:20:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id 1E08AE0613 for ; Sun, 24 Apr 2011 14:20:34 -0700 (PDT) Received: by yxk30 with SMTP id 30so643881yxk.31 for ; Sun, 24 Apr 2011 14:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=skadlKNssQ/YZGEen7SPy3wtlbq3GinpZKAE27+qDZ8=; b=AgO46eYsWjQLwLT29C2yE5dmPb+QOstHmlJanYLo72QuEEFzCHDmiFdwMfa0CCcKZ5 //xpOcfrTOIL/nIpnNKoy3qdYAOLOoU2C12o2l7MNB79WmXFvbF8RSjvJpgs09ZwRTBD zzTuhPS/VpN1lzFF4vR9KRGf8GnhYnCNRGbuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=dHc4v6ol0HTej2XvMD1dyvxO4rgBeoN6LqT8/iBNajf1Ia0RvDIyq7Puy/eLBjB8Kj nRR/PK3SXnkp08ekgEqmALyPCt3IqslPqnKRaEQza4Xl+CltyXlG5b5JFVg4iB6W+B5Q 5nK/z/z82PXPqvjzd75vZ/IDyaPD4a55kE4kQ= MIME-Version: 1.0 Received: by 10.147.23.14 with SMTP id a14mr2265815yaj.38.1303680033853; Sun, 24 Apr 2011 14:20:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.10 with HTTP; Sun, 24 Apr 2011 14:20:33 -0700 (PDT) In-Reply-To: <7FE9748079E870860D590EF0@192.168.1.128> References: <503575932.12389@cnnic.cn> <562E1E79BF22413CB20836BD5753DAB5@yaogcd67c8424b> <7FE9748079E870860D590EF0@192.168.1.128> Date: Sun, 24 Apr 2011 17:20:33 -0400 X-Google-Sender-Auth: yXFBgvdHMeumjI16_hQvmAKcjhA Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 21:20:34 -0000 On Sun, Apr 24, 2011 at 1:42 PM, John C Klensin wrote: > My main concern at this stage is that the exception procedure in > IDNA2008 assumes that there will be very few property changes > between Unicode versions and we can react fairly quickly when > they occur. ... > In the short term, I think that suggests we need to approve it > now rather than wasting more time. =A0In the longer term, we may > need to think about more efficient ways to handle this sort of > thing. I agree. Barry, as participant From ajs@shinkuro.com Mon Apr 25 04:13:49 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B32DE06A4 for ; Mon, 25 Apr 2011 04:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj2kZM55n39c for ; Mon, 25 Apr 2011 04:13:49 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 00277E06A1 for ; Mon, 25 Apr 2011 04:13:48 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6C19E1ECB41D for ; Mon, 25 Apr 2011 11:13:47 +0000 (UTC) Date: Mon, 25 Apr 2011 07:13:43 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110425111342.GB400@crankycanuck.ca> References: <562E1E79BF22413CB20836BD5753DAB5@yaogcd67c8424b> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562E1E79BF22413CB20836BD5753DAB5@yaogcd67c8424b> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 11:13:49 -0000 Dear colleagues, On Sun, Apr 24, 2011 at 12:25:25AM +0800, Jiankang Yao wrote: > This message starts a two-week WGLC on the draft > draft-faltstrom-5892bis-04.txt. We did formally > adopt this I-D as a WG document a few months ago. > Please review the draft. If you support publication, please state as > much on the list. I have read this document. I support its publication. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From evnikita2@gmail.com Mon Apr 25 09:08:53 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE61CE06CC for ; Mon, 25 Apr 2011 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y97HJVTjfcJ for ; Mon, 25 Apr 2011 09:08:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 84D0AE06C7 for ; Mon, 25 Apr 2011 09:08:52 -0700 (PDT) Received: by fxm15 with SMTP id 15so1708612fxm.31 for ; Mon, 25 Apr 2011 09:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=odajxZk75zNaanwOUanpbOHlo/FEqHLiWotgOZfBD3s=; b=HWj3FUO+CUDWGnEaLfWasmQ8BJTBRSVt5BixDWBeBmYclw74vihBMeq4LkMAiXdkID dn/LzslZWFL36JfPFXKZFMLCSySbUeiHGiKtfjkykIMrElf1bQMN1Keash5yG7Hlmh2v stZKM/aXop/qXhNhvuWhQBBZQTQlUxgVvLoHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=ktVTesm+I6kIGom5yeL9hQgooAyHNYvc15+RN0/3+9hQbBClP0bZ6NmOYb+7/aD/+G qU7PonPUWeeeRdihivlw2P6aq4hT6Lb+NYZOZJEPlU2A94jmHd2jRtexhY1ZGirf5tQq moHm1/YoL+tDQPdQVhU+NV4FTOozXlogfNHeM= Received: by 10.223.15.72 with SMTP id j8mr41329faa.69.1303747731457; Mon, 25 Apr 2011 09:08:51 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 23sm1727906fay.4.2011.04.25.09.08.49 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 09:08:50 -0700 (PDT) Message-ID: <4DB59CBC.6060908@gmail.com> Date: Mon, 25 Apr 2011 19:09:32 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang Yao References: <503575932.12389@cnnic.cn> In-Reply-To: <503575932.12389@cnnic.cn> Content-Type: multipart/alternative; boundary="------------080006090408020806060901" Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:08:54 -0000 This is a multi-part message in MIME format. --------------080006090408020806060901 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit 23.04.2011 19:25, Jiankang Yao wrote: > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-faltstrom-5892bis-04.txt. [ . . . ] > > Please review the draft. If you support publication, please state as > much on the list. Making some, maybe very scanty, contribution to further existence of this document... :-) As a minor proposal. I think some sentences or a paragraph regarding the IDNs and the Unicode should be added to the draft, for the convenience of the readers, who are not deeply familiar with these topics. I think a link to http://www.unicode.org/versions/Unicode6.0.0/ should also go in the [Unicode6] citation. Mykyta Yevstifeyev > [ . . . ] > Best regards, > Jiankang Yao(as a co-chair of APPSAWG) > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------080006090408020806060901 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit 23.04.2011 19:25, Jiankang Yao wrote:
Dear colleagues,

This message starts a two-week WGLC on the draft
draft-faltstrom-5892bis-04.txt.  [ . . . ]

Please review the draft.  If you support publication, please state as
much on the list.
Making some, maybe very scanty, contribution to further existence of this document... :-)

As a minor proposal.  I think some sentences or a paragraph regarding the IDNs and the Unicode should be added to the draft, for the convenience of the readers, who are not deeply familiar with these topics.

I think a link to http://www.unicode.org/versions/Unicode6.0.0/ should also go in the [Unicode6] citation.

Mykyta Yevstifeyev
[ . . . ]
Best regards,
Jiankang Yao(as a co-chair of APPSAWG)

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--------------080006090408020806060901-- From patrik@frobbit.se Mon Apr 25 21:47:57 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D76E06E4 for ; Mon, 25 Apr 2011 21:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kozHShpZg9GN for ; Mon, 25 Apr 2011 21:47:57 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id A45ABE0669 for ; Mon, 25 Apr 2011 21:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B8CC51090BF7C; Tue, 26 Apr 2011 06:47:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFa0fPF9oEO2; Tue, 26 Apr 2011 06:47:52 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6691E1090BF75; Tue, 26 Apr 2011 06:47:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4DB59CBC.6060908@gmail.com> Date: Tue, 26 Apr 2011 06:47:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8870FAB4-50D1-44F4-BC45-86A887B31186@frobbit.se> References: <503575932.12389@cnnic.cn> <4DB59CBC.6060908@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:47:57 -0000 On 25 apr 2011, at 18.09, Mykyta Yevstifeyev wrote: > As a minor proposal. I think some sentences or a paragraph regarding the > IDNs and the Unicode should be added to the draft, for the convenience > of the readers, who are not deeply familiar with these topics. > > I think a link to http://www.unicode.org/versions/Unicode6.0.0/ should > also go in the [Unicode6] citation. Please send proposed text. Patrik - editor From stpeter@stpeter.im Tue Apr 26 10:12:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27FDE07A0 for ; Tue, 26 Apr 2011 10:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Skpg1yRFvvHd for ; Tue, 26 Apr 2011 10:12:06 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfa.amsl.com (Postfix) with ESMTP id 664F9E076A for ; Tue, 26 Apr 2011 10:12:06 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E47A40022; Tue, 26 Apr 2011 11:16:16 -0600 (MDT) Message-ID: <4DB6FCE2.6080903@stpeter.im> Date: Tue, 26 Apr 2011 11:12:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080604050101010009010106" Cc: Sean Turner Subject: [apps-discuss] Position Paper for W3C Identity in the Browser Workshop X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:12:09 -0000 This is a cryptographically signed message in MIME format. --------------ms080604050101010009010106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, over on the SAAG list, Sean Turner and Stephen Farrell have posted a draft position paper for the upcoming W3C Workshop on Identity in the Browser: http://www.ietf.org/mail-archive/web/saag/current/msg03201.html http://www.w3.org/2011/identity-ws/ Because neither Sean nor Stephen will be able to attend the workshop, I offered to help them by co-authoring the position paper and presenting about the topic if the proposal is accepted. Since this proposal straddles the line between apps and security, I figured it would be good to get feedback from the AppsArea community before we submit the proposal (the deadline is tomorrow, sorry about the late notice). Your feedback is welcome. Thanks! Peter ### Submitters Sean Turner Stephen Farrell Peter Saint-Andre Abstract This position paper advocates an Application Programming Interface (API) that will enable developers access to cryptographic algorithms already present in today's web browsers. Motivations More and more applications are moving to the "web" (e.g., http://app.example.com:80 and https://app.example.com:443). Developers are working within the confines of various browsers to secure these applications, and most use Secure Sockets Layer (SSL)/Transport Security Layer (TLS) to do so. This reliance is not sub-optimal for applications whose architectures are not strictly client-server (e.g., IM and VoIP). As a workaround, developers are currently investigating the creation of new Javascript-based cryptography libraries, along with new formats for signed and encrypted objects based on JavaScript Object Notation (JSON). Use of JSON makes some sense in an application layer security protocol. However, it makes less sense for developers to roll (and deliver) their own cryptographic algorithms -- it's not only wasteful, it's also dangerous when the browser's security "goodies" (i.e., the cryptographic algorithms) are just an API away. Downloading cryptographic algorithms is wasteful in terms of bandwidth used. Application and browser developers are both very interested in ensuring their applications are speedy in the eyes of users; nobody wants to lose a speed war on CNET. If web developers end up rolling their own cryptographic algorithms to support a JSON application layer security protocol, then the code may end up being downloaded during application initialization. Such cryptographic code could include message digest/hash algorithms, digital signature algorithms, content encryption algorithms, key wrap algorithms, and keyed-Hash Message Authentication Code (HMAC) algorithms. This kind of code is typically not small because of the significant math involved in producing strong security. However, the greatest danger here is not a waste of bandwidth, but possible security breaches. Obviously, downloading cryptographic algorithms is an easy attack vector if not done over SSL/TLS. But the real challenge is that security is hard. As Steve Bellovin pointed out in RFC 5406, the design of security protocols is a subtle and difficult art. In fact, coding security protocols is even more subtle and difficult than designing security protocols. There is no doubt that some developers will get it right the first time, but there is also no doubt that some will get it wrong. Given that cryptographic algorithms alread coded into browsers (and that some of them have already been evaluated by the U.S. National Institute of Standards and Technology (NIST) for compliance with Federal Information Processing Publication (FIPS PUB) 140), it seems unnecessarily risky to not make use of the cryptographic algorithms already present in the browser. A consistent API for access to those algorithms would provide a strong foundation for securing the web. Goals We propose that a consistent web security API would support the following algorithms and functions: o Hash/message digest algorithms (e.g., SHA-256) o Digital signatures algorithms (e.g., RSA PKCS#1 v1.5, ECDSA) o Confidentiality algorithms (e.g., AES) o Key transport/agreement algorithms (e.g., RSA PKCS#1 v1.5, ECDH) o HMAC algorithms (e.g., HMAC-SHA1, HMAC-SHA256) o Methods for extracting keys from TLS sessions (e.g., using RFC 5176) o Methods for PKI path validation (e.g., input/output of base64 certificate/CRL blobs) o Methods for generating and processing Cryptographic Message Syntax (CMS= ) ### --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080604050101010009010106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQy NjE3MTIwMlowIwYJKoZIhvcNAQkEMRYEFAaLnLA9VgNITD6Mwv7x68nlWIAuMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAyYzWA+05O8A6Wo3k8Gu/pVgG/P1RPj+YPERIkFsYHpxCSk427fx32U+/5 2YzEfKWr5ffBnhDMsS01iANk++aLcXhDsTNmCE1VxoxBXUDMqP7xzTvN1r0HGLWPQKbhHTbM wb69vMGiJeWjHtSbMqVhxx1pLXrHhCOXO1EW5eTPKZDCSPerBTAK5xgHAZ2ImGAppOPKAZ/T gBpIcci/iSmG1lAxYhJF0ylENjhO5riyjl0s08Kry58/af1kX3NBLgWN8bPzyWer+ZdKY/iJ QKPyKH88SuKvn6oml3WEeuFEszCSKW+MXQxIhOffOEoItsh1jibe3oStagnR+D2bqeroAAAA AAAA --------------ms080604050101010009010106-- From evnikita2@gmail.com Tue Apr 26 10:28:00 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70B7E0816 for ; Tue, 26 Apr 2011 10:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1U6HeiJC1qT for ; Tue, 26 Apr 2011 10:27:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2FCE0812 for ; Tue, 26 Apr 2011 10:27:59 -0700 (PDT) Received: by fxm15 with SMTP id 15so698468fxm.31 for ; Tue, 26 Apr 2011 10:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RcRL4m4RhGG3zcEa+aCqvsnf/Zt+jFHr1GfkJNpYeAE=; b=axF6KiUaG5Z2V9cS4FCA7c8HWCwjmc0hvrNRoLKD5QdmEHF6LhBAmfrPymc/oi1h9H FZ92jeuBLZAbHw2hZv0SJNgxXkdYzdgCzwUFVL+S7qJkUYpHC+2+6BRigahueILQFndH grAQLeclNsiNhdWDRNa4mPXpSkxXMT9ItfmfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jMZOc6KSPjiWRiR03UZIkfpcKfBI6iyUr5g54+ps4HAgpPx0sI2E9KI+1WRRw9GHnF AFe/DcOkf/voFB77EOx9n0ZIp999FsHfF8QBVBy/TaGhoiEx4zE/JCv4Y9b/Byt7qwts jH+H14lGrA9YmkTclhjL/Jtk4uyVa6T8m3DFo= Received: by 10.223.23.212 with SMTP id s20mr1129470fab.120.1303838878625; Tue, 26 Apr 2011 10:27:58 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id j12sm2065314fax.33.2011.04.26.10.27.56 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 10:27:57 -0700 (PDT) Message-ID: <4DB700C8.4080606@gmail.com> Date: Tue, 26 Apr 2011 20:28:40 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <503575932.12389@cnnic.cn> <4DB59CBC.6060908@gmail.com> <8870FAB4-50D1-44F4-BC45-86A887B31186@frobbit.se> In-Reply-To: <8870FAB4-50D1-44F4-BC45-86A887B31186@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:28:00 -0000 26.04.2011 7:47, Patrik Fältström wrote: > On 25 apr 2011, at 18.09, Mykyta Yevstifeyev wrote: > >> As a minor proposal. I think some sentences or a paragraph regarding the >> IDNs and the Unicode should be added to the draft, for the convenience >> of the readers, who are not deeply familiar with these topics. >> >> I think a link to http://www.unicode.org/versions/Unicode6.0.0/ should >> also go in the [Unicode6] citation. > Please send proposed text. Patrik, I am not a great expert in these topics. So, to be frank, I do not think I can be useful as a contributor to this draft. Mykyta Yevstifeyev > Patrik - editor > > From simon@josefsson.org Tue Apr 26 13:29:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ABDE07A3 for ; Tue, 26 Apr 2011 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOcUW6uDVtKc for ; Tue, 26 Apr 2011 13:29:09 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id AC36BE06A6 for ; Tue, 26 Apr 2011 13:29:08 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3QKSnfS000863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Apr 2011 22:28:51 +0200 From: Simon Josefsson To: "Jiankang Yao" References: <503575932.12389@cnnic.cn> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110426:yaojk@cnnic.cn::thSggWDWKwCoE0zp:2yYn X-Hashcash: 1:22:110426:apps-discuss@ietf.org::BMSGvRMlbpwsLym/:3Hqa X-Hashcash: 1:22:110426:idna-update@alvestrand.no::YnIgyb830AqgQUOw:TRlo Date: Tue, 26 Apr 2011 22:28:49 +0200 In-Reply-To: <503575932.12389@cnnic.cn> (Jiankang Yao's message of "Sun, 24 Apr 2011 00:25:25 +0800") Message-ID: <87mxjc21vi.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:29:10 -0000 "Jiankang Yao" writes: > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-faltstrom-5892bis-04.txt. All, I support publication of a document to clarify IDNA2008's relationship to Unicode 6.0 but I believe the content of the above document causes an instability for U+19DA which can be avoided. From my implementer's point of view, it seems better to add U+19DA as PVALID in the BackwardCompatible (G) category so that we have the property that IDNA2008-Unicode5.2(X) = IDNA2008-Unicode6.0(X) for all strings X that were permitted by IDNA2008-Unicode5.2. The above document effectively forbids some strings that were permitted before. I believe this causes a perception of instability in the algorithm. It seems that permitting strings with this code point would not cause any problem in practice. To me that is a strong argument that good algorithmical/implementation properties are more important than any consideration for this particular code point. If U+19DA would cause operational difficulties, I would be more inclined towards forbidding strings that contains it, but I haven't seen those arguments. This has been brought up before by others, and I have merely been convinced by that discussion. I'm not trying to state this point as anything original. In particular, here are pointers to where Mark Davis explains the point: http://article.gmane.org/gmane.ietf.idnabis/6910 http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html > Note: This draft is a document that updates an earlier RFC by stating > nothing is to be updated. That seems wrong. Technically the document does not claim to update any earlier RFC according to the document content (there is no 'Updates:' header). Could you clarify what you mean here? Is the intention that the document will be marked as Updating any earlier RFC or not? /Simon From lee@cnnic.cn Wed Apr 27 06:54:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8EE0717 for ; Wed, 27 Apr 2011 06:54:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaQfvVf0petz for ; Wed, 27 Apr 2011 06:54:39 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D3682E074B for ; Wed, 27 Apr 2011 06:54:38 -0700 (PDT) Received: (eyou send program); Wed, 27 Apr 2011 21:54:33 +0800 Message-ID: <503912473.01951@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [192.168.16.40]) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 27 Apr 2011 21:54:33 +0800 Message-ID: <4DB82017.1010303@cnnic.cn> Date: Wed, 27 Apr 2011 21:54:31 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-mif-current-practices@tools.ietf.org, iesg@ietf.org, denghui02@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] apps-team review of draft-ietf-mif-current-practices-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: lee@cnnic.cn List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:54:42 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mif-current-practices-11 Title: Current Practices for Multiple Interface Hosts Reviewer: Xiaodong Lee Review Date: April 26, 2011 Review Summary: This draft is almost ready for publication as an Informational RFC but has a few issues that suggested to be fixed before publication. Major Issues: This draft gives the introduction about the multiple-interface solutions implemented in some widely used operating systems. It seems that this draft just simply introduces or lists every example. The author might consider the following suggestions: - Do some simple analysis of pros and cons of every implementation or solution; - Compare different solutions and make some possible suggestions. Since this draft aims for an informational RFC, doing some analysis and comparison will be helpful for the readers. Minor issues: - Both the "multiple-interface" and the "multi-interface" are used in this document with the same meaning. - Term "PEERDNS" might have reference. Nits: - In Section 3.2.2.3, second paragraph, third sentence: "become" should be "becomes" here. Regards, -- -- Xiaodong Lee, VP&CTO, CNNIC Professor, Chinese Academy of Sciences From ajs@shinkuro.com Wed Apr 27 07:06:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C00E06EC for ; Wed, 27 Apr 2011 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzAJzciNhDJZ for ; Wed, 27 Apr 2011 07:06:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4D37CE0781 for ; Wed, 27 Apr 2011 07:06:48 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AABCD1ECB41D; Wed, 27 Apr 2011 14:06:46 +0000 (UTC) Date: Wed, 27 Apr 2011 10:06:44 -0400 From: Andrew Sullivan To: Vint Cerf Message-ID: <20110427140644.GH7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Simon Josefsson , idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:06:48 -0000 On Wed, Apr 27, 2011 at 09:28:25AM -0400, Vint Cerf wrote: > algorithms for PVALID, etc. Does anyone know whether U+19DA has > actually been used in any domain names? Short of scanning the entire DNS of the entire Internet (presumably including split-brain cases where the name is not visible in the public tree), non-evidence of use doesn't show very much. But it seems a very unlikely character. Implicit in the decision in the past about these sorts of cases was that we'd treat them case by case. The reason to do that was that some (potential) incompatibilities are more serious than others. IF we were changing the rules around (say) the character "0", I'm quite sure that the reaction would be different. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Wed Apr 27 07:58:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A17E07AD; Wed, 27 Apr 2011 07:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHxRfTe70iNt; Wed, 27 Apr 2011 07:58:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE0E0721; Wed, 27 Apr 2011 07:58:03 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6A7A31ECB41D; Wed, 27 Apr 2011 14:58:02 +0000 (UTC) Date: Wed, 27 Apr 2011 10:58:00 -0400 From: Andrew Sullivan To: =?utf-8?B?U3TDqXBoYW5l?= Lancel Message-ID: <20110427145800.GI7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idna-update@alvestrand.no, internet users contributing group , apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:58:04 -0000 [cc:s trimmed] On Wed, Apr 27, 2011 at 04:49:18PM +0200, Stéphane Lancel wrote: > I am sorry because I am not really expert in PVALID issues (changes, etc.), > but I understood that PVALID once, PVALID for ever. I realize with this > Draft that this means at character level not at codepoint level. Or am I > wrong? I think you're wrong in two ways. First, it's true that the idea in IDNA2008 was that once something would be PVALID, it would be PVALID forever. But IDNA2008 depends on Unicode and its properties. If Unicode changes properties such that something moves from PVALID to something else, then the desired state is not achieved. Now, one could just make a rule, "once PVALID then always PVALID." But this is tantamount to sticking IDNA2008 to the Unicode version that was around at the time of IDNA2008 publication. We wanted to be Unicode-version independent, and so that strategy doesn't meet the goal. Second, I don't think "at character level not at codepoint level" is right. We're dealing in code points. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jmabdp@gmail.com Tue Apr 26 17:51:29 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DACE081F; Tue, 26 Apr 2011 17:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZXIpdIwlmne; Tue, 26 Apr 2011 17:51:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC296E0680; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) Received: by vws12 with SMTP id 12so1039315vws.31 for ; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zDAe3rTIT4WmQn2/riOAicZfzBboAi6kZx3OVbYHwh0=; b=GBRKG6Oy5z9khbnX7TZJc2lrE5Jndask7xDcfiPydkOqa2tbdtWYrdx0IG/NtNiu4D pUOCPV+FHe0eI+PRg/XWso8KwgPpIzTdxt6Ypcv9/A4tqyZ2ehLkot9RtIdhB+PEFi4N ojBMOZnjLlkPq7TTChhN21xImsnsbgVQRNi4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jUhqCGeou2rQYLH/V2Fc/Gkgkxv6+RWeMCk673Ymx7hvZQtiKmxbSI2FRE6H2iSpqB 3XYOgBjqFsAHXrYoLBNiTDV8jZNO/vW4HKzMnDdkV9vqKvp0AFz9aNhvEtrdRTbE4bo5 yBX3qGrCyLsv8LZwBVpXLYsQsqRj5WDFsVTsE= MIME-Version: 1.0 Received: by 10.52.172.2 with SMTP id ay2mr553328vdc.50.1303865488033; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) Received: by 10.52.111.162 with HTTP; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) In-Reply-To: <87mxjc21vi.fsf@latte.josefsson.org> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> Date: Wed, 27 Apr 2011 02:51:28 +0200 Message-ID: From: jean-michel bernier de portzamparc To: Simon Josefsson , internet users contributing group Content-Type: multipart/alternative; boundary=bcaec53f2ae73fc74b04a1dbd742 X-Mailman-Approved-At: Wed, 27 Apr 2011 08:02:17 -0700 Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 00:51:30 -0000 --bcaec53f2ae73fc74b04a1dbd742 Content-Type: text/plain; charset=ISO-8859-1 However I support JFC's position on the long range, I disagree that IUCG should support the Draft until the points well made by Simon Josefsson are addressed. Even if we can introduce a better network suited approach than Unicode we will still have to interface the Unicode codepoints for a very long time. Portzamparc 2011/4/26 Simon Josefsson > "Jiankang Yao" writes: > > > Dear colleagues, > > > > This message starts a two-week WGLC on the draft > > draft-faltstrom-5892bis-04.txt. > > All, > > I support publication of a document to clarify IDNA2008's relationship > to Unicode 6.0 but I believe the content of the above document causes an > instability for U+19DA which can be avoided. From my implementer's > point of view, it seems better to add U+19DA as PVALID in the > BackwardCompatible (G) category so that we have the property that > IDNA2008-Unicode5.2(X) = IDNA2008-Unicode6.0(X) for all strings X that > were permitted by IDNA2008-Unicode5.2. > > The above document effectively forbids some strings that were permitted > before. I believe this causes a perception of instability in the > algorithm. It seems that permitting strings with this code point would > not cause any problem in practice. To me that is a strong argument that > good algorithmical/implementation properties are more important than any > consideration for this particular code point. If U+19DA would cause > operational difficulties, I would be more inclined towards forbidding > strings that contains it, but I haven't seen those arguments. > > This has been brought up before by others, and I have merely been > convinced by that discussion. I'm not trying to state this point as > anything original. In particular, here are pointers to where Mark Davis > explains the point: > > http://article.gmane.org/gmane.ietf.idnabis/6910 > http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html > > > Note: This draft is a document that updates an earlier RFC by stating > > nothing is to be updated. > > That seems wrong. Technically the document does not claim to update any > earlier RFC according to the document content (there is no 'Updates:' > header). Could you clarify what you mean here? Is the intention that > the document will be marked as Updating any earlier RFC or not? > > /Simon > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --bcaec53f2ae73fc74b04a1dbd742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable However I support JFC's position on the long range, I disagree that IUC= G should support the Draft until the points well made by Simon Josefsson ar= e addressed. Even if we can introduce a better network suited approach than= Unicode we will still have to interface the Unicode codepoints for a very = long time.
Portzamparc


2011/4/26 Simon Josefsson= <simon@josefss= on.org>
"Jiankang Yao" <yaojk@cnnic.cn> writes:

> Dear colleagues,
>
> This message starts a two-week WGLC on the draft
> draft-faltstrom-5892bis-04.txt.

All,

I support publication of a document to clarify IDNA2008's relationship<= br> to Unicode 6.0 but I believe the content of the above document causes an instability for U+19DA which can be avoided. =A0From my implementer's point of view, it seems better to add U+19DA as PVALID in the
BackwardCompatible (G) category so that we have the property that
IDNA2008-Unicode5.2(X) =3D IDNA2008-Unicode6.0(X) for all strings X that were permitted by IDNA2008-Unicode5.2.

The above document effectively forbids some strings that were permitted
before. =A0I believe this causes a perception of instability in the
algorithm. =A0It seems that permitting strings with this code point would not cause any problem in practice. =A0To me that is a strong argument that<= br> good algorithmical/implementation properties are more important than any consideration for this particular code point. =A0If U+19DA would cause
operational difficulties, I would be more inclined towards forbidding
strings that contains it, but I haven't seen those arguments.

This has been brought up before by others, and I have merely been
convinced by that discussion. =A0I'm not trying to state this point as<= br> anything original. =A0In particular, here are pointers to where Mark Davis<= br> explains the point:

http://article.gmane.org/gmane.ietf.idnabis/6910
http://www.alvestrand.no/pipermail/idna-update/2= 010-October/006742.html

> Note: This draft is a document that updates an earlier RFC by stating<= br> > nothing is to be updated.

That seems wrong. =A0Technically the document does not claim to updat= e any
earlier RFC according to the document content (there is no 'Updates:= 9;
header). =A0Could you clarify what you mean here? =A0Is the intention that<= br> the document will be marked as Updating any earlier RFC or not?

/Simon
__________________________________= _____________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--bcaec53f2ae73fc74b04a1dbd742-- From pierrick.seite@orange-ftgroup.com Wed Apr 27 07:06:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF94E069F; Wed, 27 Apr 2011 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDIEQGyG9j5s; Wed, 27 Apr 2011 07:06:44 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3C775E06EC; Wed, 27 Apr 2011 07:06:44 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 716FF8B8014; Wed, 27 Apr 2011 16:05:55 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D11A09B0005; Wed, 27 Apr 2011 16:03:43 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 16:00:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Apr 2011 16:00:06 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A8EE0B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4DB82017.1010303@cnnic.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: apps-team review of draft-ietf-mif-current-practices-11 Thread-Index: AcwE4q+8gO8RgRe7Sy6sXEEtEgbnzQAAEujg References: <4DB82017.1010303@cnnic.cn> From: To: , , , , X-OriginalArrivalTime: 27 Apr 2011 14:00:07.0814 (UTC) FILETIME=[6A85C260:01CC04E3] X-Mailman-Approved-At: Wed, 27 Apr 2011 08:02:21 -0700 Subject: Re: [apps-discuss] apps-team review of draft-ietf-mif-current-practices-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:06:48 -0000 Thanks for the review. Please see inline > -----Message d'origine----- > De=A0: Xiaodong Lee [mailto:lee@cnnic.cn] > Envoy=E9=A0: mercredi 27 avril 2011 15:55 > =C0=A0: apps-discuss@ietf.org; draft-ietf-mif-current- > practices@tools.ietf.org; iesg@ietf.org; denghui02@gmail.com > Objet=A0: apps-team review of draft-ietf-mif-current-practices-11 >=20 > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-mif-current-practices-11 > Title: Current Practices for Multiple Interface Hosts > Reviewer: Xiaodong Lee >=20 > Review Date: April 26, 2011 >=20 > Review Summary: > This draft is almost ready for publication as an Informational RFC but > has a few issues that suggested to be fixed before publication. >=20 > Major Issues: > This draft gives the introduction about the multiple-interface = solutions > implemented in some widely used operating systems. It seems that this > draft just simply introduces or lists every example. The author might > consider the following suggestions: > - Do some simple analysis of pros and cons of every = implementation > or solution; > - Compare different solutions and make some possible suggestions. > Since this draft aims for an informational RFC, doing some analysis = and > comparison will be helpful for the readers. >=20 Another document that analyzes current practice is chartered. This = document will address above points. > Minor issues: > - Both the "multiple-interface" and the "multi-interface" are used in > this document with the same meaning. > - Term "PEERDNS" might have reference. >=20 Ok >=20 > Nits: > - In Section 3.2.2.3, second paragraph, third sentence: > "become" should be "becomes" here. Ok >=20 > Regards, >=20 > -- > -- > Xiaodong Lee, > VP&CTO, CNNIC > Professor, Chinese Academy of Sciences From stelancel@gmail.com Wed Apr 27 07:49:26 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35816E07BC; Wed, 27 Apr 2011 07:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI7vO0gKgOW9; Wed, 27 Apr 2011 07:49:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8C4E0778; Wed, 27 Apr 2011 07:49:21 -0700 (PDT) Received: by fxm15 with SMTP id 15so1384071fxm.31 for ; Wed, 27 Apr 2011 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nxT1O2X27sFrcQU2lpZZ7iQ2CkZK6HHHZUUk1w4XTKo=; b=I8UksyoD0Dju9c3LIgVzE3IAv0c6OEArNWPTCmTmR8uJ5XqZRrYR7REW6mfSDaakYE KT4vi6dol7fWuGYrE7aak8rDCibiK8grOfGWoFbb6FIh7dYb7DNkpom9SCKvm+2YpFmE uzd+I0f+f/EqiFXVKG7Sj3K3keFKmxqjebOoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lje7A355Mxzp5iJ7ZT1a0ZXLPHaNtw19okjPiLj24mIguNBYXWPUi/DHp/IWrwxbnP AA5HXCgRyc+2Vw48pNHD/aydy3p9cnzC0xWfGpwVSDPASRXl3X1qMrYqWU85vdsuCfzp 7Cllb6YvgOUz6jqNaaQtyHVS59aPtcBeHGPwA= MIME-Version: 1.0 Received: by 10.223.160.8 with SMTP id l8mr2511441fax.114.1303915758592; Wed, 27 Apr 2011 07:49:18 -0700 (PDT) Received: by 10.223.105.145 with HTTP; Wed, 27 Apr 2011 07:49:18 -0700 (PDT) In-Reply-To: <20110427140644.GH7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> Date: Wed, 27 Apr 2011 16:49:18 +0200 Message-ID: From: =?ISO-8859-1?Q?St=E9phane_Lancel?= To: Andrew Sullivan , Vint Cerf Content-Type: multipart/alternative; boundary=0023542750009d133b04a1e78bf0 X-Mailman-Approved-At: Wed, 27 Apr 2011 08:02:25 -0700 Cc: Simon Josefsson , idna-update@alvestrand.no, internet users contributing group , apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:49:26 -0000 --0023542750009d133b04a1e78bf0 Content-Type: text/plain; charset=ISO-8859-1 This worries me: "implicit in the decision on the past". In RFC everything MUST be explicit. (my interest lies in non registered sub-domain names used to deliver an information to the other end). I am sorry because I am not really expert in PVALID issues (changes, etc.), but I understood that PVALID once, PVALID for ever. I realize with this Draft that this means at character level not at codepoint level. Or am I wrong? What about the applications using hard-coded code points names, or crypted domain names or subnames based upon an algorythm among PVALID code points (I understood that ".su" permitted that).. Another point is that this Draft is precisely to show that IDNA2008 is stable. Simon and Andrew show that this may not be the case, even when IETF says it is? How could the IDNS be stable if it uses a non-stable element (Unicode) ? 2011/4/27 Andrew Sullivan > On Wed, Apr 27, 2011 at 09:28:25AM -0400, Vint Cerf wrote: > > algorithms for PVALID, etc. Does anyone know whether U+19DA has > > actually been used in any domain names? > > Short of scanning the entire DNS of the entire Internet (presumably > including split-brain cases where the name is not visible in the > public tree), non-evidence of use doesn't show very much. But it > seems a very unlikely character. > > Implicit in the decision in the past about these sorts of cases was > that we'd treat them case by case. The reason to do that was that > some (potential) incompatibilities are more serious than others. IF > we were changing the rules around (say) the character "0", I'm quite > sure that the reaction would be different. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --0023542750009d133b04a1e78bf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This worries me: "implicit in the decision on the past". In RFC e= verything MUST be explicit. (my interest lies in non registered sub-domain = names used to deliver an information to the other end).

I am sorry b= ecause I am not really expert in PVALID issues (changes, etc.), but I under= stood that PVALID once, PVALID for ever. I realize with this Draft that thi= s means at character level not at codepoint level. Or am I wrong?

What about the applications using hard-coded code points names, or cryp= ted domain names or subnames based upon an algorythm among PVALID=A0 code p= oints (I understood that ".su" permitted that)..

Another p= oint is that this Draft is precisely to show that IDNA2008 is stable. Simon= and Andrew show that this may not be the case, even when IETF says it is? = How could the IDNS be stable if it uses a non-stable element (Unicode) ?
2011/4/27 Andrew Sullivan = <ajs@shinkuro.com>
=
On Wed, Apr 27, 2011 at 09:28:25AM -0400, Vint Cerf wrote= :
> algorithms for PVALID, etc. Does anyone know whether U+19DA has
> actually been used in any domain names?

Short of scanning the entire DNS of the entire Internet (presumably including split-brain cases where the name is not visible in the
public tree), non-evidence of use doesn't show very much. =A0But it
seems a very unlikely character.

Implicit in the decision in the past about these sorts of cases was
that we'd treat them case by case. =A0The reason to do that was that some (potential) incompatibilities are more serious than others. =A0IF
we were changing the rules around (say) the character "0", I'= m quite
sure that the reaction would be different.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
__________________________________= _____________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--0023542750009d133b04a1e78bf0-- From vint@google.com Wed Apr 27 06:28:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2210AE06DD for ; Wed, 27 Apr 2011 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORzXZSkhRifK for ; Wed, 27 Apr 2011 06:28:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id DA13DE069F for ; Wed, 27 Apr 2011 06:28:28 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p3RDSR32005026 for ; Wed, 27 Apr 2011 06:28:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303910908; bh=QVKXe7Jmb6dyLAMmhWmWVEu8lGI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ObFq2HAWjzG+TZ2s2uLuLyA2eAv2pP9AhM9IpqvV9TKvexctzB/72/BSPFtiGFESW +UvJ7zzXXXYguZO2eCtig== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by kpbe15.cbf.corp.google.com with ESMTP id p3RDRptZ024620 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 27 Apr 2011 06:28:26 -0700 Received: by qwe5 with SMTP id 5so799998qwe.9 for ; Wed, 27 Apr 2011 06:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fwvc5TUqy9cY/Y0m6hmdn0tthF2y7oAkVY1cg7x1Du4=; b=e55DWgRtkyTmitaF8Y8174rZ8rpmd4U6VfC9epZf5jmtbjJ17tQDawazD7MqE1L1Fi i/pcfUBxkIYGyxIVQ2Cw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FtY8mhNnf/el/hp9/vXtR+O7fw9QVLhQnYj/IRUY+fITi5xHNgxD0jtrSH9aBCcoCb W4/NTuEr2tO61Zm4eNsA== MIME-Version: 1.0 Received: by 10.229.206.42 with SMTP id fs42mr1715876qcb.150.1303910905561; Wed, 27 Apr 2011 06:28:25 -0700 (PDT) Received: by 10.229.141.135 with HTTP; Wed, 27 Apr 2011 06:28:25 -0700 (PDT) In-Reply-To: <87mxjc21vi.fsf@latte.josefsson.org> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> Date: Wed, 27 Apr 2011 09:28:25 -0400 Message-ID: From: Vint Cerf To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Wed, 27 Apr 2011 08:02:33 -0700 Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:28:34 -0000 Simon, point taken - the other side of the equation is to try to get the UNICODE property values to produce stable results using the IDNA2008 algorithms for PVALID, etc. Does anyone know whether U+19DA has actually been used in any domain names? v On Tue, Apr 26, 2011 at 4:28 PM, Simon Josefsson wrot= e: > "Jiankang Yao" writes: > >> Dear colleagues, >> >> This message starts a two-week WGLC on the draft >> draft-faltstrom-5892bis-04.txt. > > All, > > I support publication of a document to clarify IDNA2008's relationship > to Unicode 6.0 but I believe the content of the above document causes an > instability for U+19DA which can be avoided. =A0From my implementer's > point of view, it seems better to add U+19DA as PVALID in the > BackwardCompatible (G) category so that we have the property that > IDNA2008-Unicode5.2(X) =3D IDNA2008-Unicode6.0(X) for all strings X that > were permitted by IDNA2008-Unicode5.2. > > The above document effectively forbids some strings that were permitted > before. =A0I believe this causes a perception of instability in the > algorithm. =A0It seems that permitting strings with this code point would > not cause any problem in practice. =A0To me that is a strong argument tha= t > good algorithmical/implementation properties are more important than any > consideration for this particular code point. =A0If U+19DA would cause > operational difficulties, I would be more inclined towards forbidding > strings that contains it, but I haven't seen those arguments. > > This has been brought up before by others, and I have merely been > convinced by that discussion. =A0I'm not trying to state this point as > anything original. =A0In particular, here are pointers to where Mark Davi= s > explains the point: > > http://article.gmane.org/gmane.ietf.idnabis/6910 > http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html > >> Note: This draft is a document that updates an earlier RFC by stating >> nothing is to be updated. > > That seems wrong. =A0Technically the document does not claim to update an= y > earlier RFC according to the document content (there is no 'Updates:' > header). =A0Could you clarify what you mean here? =A0Is the intention tha= t > the document will be marked as Updating any earlier RFC or not? > > /Simon > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > From ajs@shinkuro.com Wed Apr 27 09:05:51 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73083E082E; Wed, 27 Apr 2011 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7twcukHmP5X7; Wed, 27 Apr 2011 09:05:51 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EB7ECE07F8; Wed, 27 Apr 2011 09:05:50 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2684E1ECB41D; Wed, 27 Apr 2011 16:05:50 +0000 (UTC) Date: Wed, 27 Apr 2011 12:05:48 -0400 From: Andrew Sullivan To: =?utf-8?B?U3TDqXBoYW5l?= Lancel Message-ID: <20110427160548.GJ7329@shinkuro.com> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> <20110427145800.GI7329@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idna-update@alvestrand.no, iucg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:05:51 -0000 On Wed, Apr 27, 2011 at 05:56:15PM +0200, Stéphane Lancel wrote: > " But IDNA2008 depends on Unicode and its properties. If Unicode changes > properties such that something moves from PVALID to something else", > > is that not a change in Unicode, i.e. a new version ? It is. That's what the issue is in this case: there's a new Unicode version, and a code point's properties changed from one version to another, such that the derived category in IDNA2008 changes from PVALID to something else. Have you read the draft? This is called out quite explicitly in section 1. > Yes, and their properties change for the same character ? Please don't bring characters into this. We are talking about code points, and we don't need to muddy the waters. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From stelancel@gmail.com Wed Apr 27 08:56:17 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7262E07B0; Wed, 27 Apr 2011 08:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzmDDQWeFucC; Wed, 27 Apr 2011 08:56:17 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFA49E070E; Wed, 27 Apr 2011 08:56:16 -0700 (PDT) Received: by fxm15 with SMTP id 15so1436622fxm.31 for ; Wed, 27 Apr 2011 08:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V5KTDzf4WCPc/Eq/+Cum1FiWcic8FpgNvyDZwoOCWpc=; b=YTJhvM1AHdoPHbbARO2+meWrVSzqGoBT5bugsrIl5Wa+f4SrcyPm6XX3CH6TFnLZ05 Pa6dsDsjvyTPQUbhYi8OG3oQ5zdw6A3eOvkdwXal1QsdTcy9ZZRRp6+VOWEDFRXRJ3Es k7BCmMR7jwAgdsC15zjoI290E0viDFHNSVEOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ln3O6wM6t7KIjIIyj8f0QjvaUA1RLcSKLrX8rOdphchaIAb2vZX2ptOsL4QwCtLxOp jbKi+oLgblyuIM1IzrY+R1JRzLKojT/ZG3x9Dy5wTurkJBD3wlLAFyESlvrnfQRSK6RI Dkh3DzcFokb0LeSwjSZLrVIaFRGhh3VF2qSH4= MIME-Version: 1.0 Received: by 10.223.94.129 with SMTP id z1mr2604741fam.144.1303919775910; Wed, 27 Apr 2011 08:56:15 -0700 (PDT) Received: by 10.223.105.145 with HTTP; Wed, 27 Apr 2011 08:56:15 -0700 (PDT) In-Reply-To: <20110427145800.GI7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> <20110427145800.GI7329@crankycanuck.ca> Date: Wed, 27 Apr 2011 17:56:15 +0200 Message-ID: From: =?ISO-8859-1?Q?St=E9phane_Lancel?= To: Andrew Sullivan Content-Type: multipart/alternative; boundary=000e0ce0b1160f61e904a1e87b69 X-Mailman-Approved-At: Wed, 27 Apr 2011 09:41:35 -0700 Cc: idna-update@alvestrand.no, internet users contributing group , apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:56:17 -0000 --000e0ce0b1160f61e904a1e87b69 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 27 avril 2011 16:58, Andrew Sullivan a =E9crit : > I think you're wrong in two ways. > No problem. I try to understand. " But IDNA2008 depends on Unicode and its properties. If Unicode change= s properties such that something moves from PVALID to something else", is that not a change in Unicode, i.e. a new version ? > We wanted to be Unicode-version independent, and so that strategy doesn't > meet the goal. > Here I am lost. > Second, I don't think "at character level not at codepoint level" is righ= t. > We're dealing in code points. > Yes, and their properties change for the same character ? Best S. Lancel --000e0ce0b1160f61e904a1e87b69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Le 27 avril 2011 16:58, Andrew Sullivan = <ajs@shinkuro.com<= /a>> a =E9crit :
I think you're wrong in two ways.

No problem. = I try to understand.
=A0
=A0=A0 " But IDNA2008 dep= ends on Unicode and its properties. =A0If Unicode changes properties such t= hat something moves from PVALID to something else",

is that not a change in Unicode, i.e. a new version ?
=A0
=
We wanted to be U= nicode-version independent, and so that strategy doesn't meet the goal.=

Here I am lost.

=A0
Second, I don't think "at character level not at codepoint level&q= uot; is right. =A0We're dealing in code points.
Yes, and their properties change for the same character ?

Best
S. Lancel
=A0

--000e0ce0b1160f61e904a1e87b69-- From simon@josefsson.org Wed Apr 27 10:36:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ACAE07ED for ; Wed, 27 Apr 2011 10:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovcwwXbwyvSE for ; Wed, 27 Apr 2011 10:36:07 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 00620E07E6 for ; Wed, 27 Apr 2011 10:36:06 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3RHZqYZ030079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Apr 2011 19:35:54 +0200 From: Simon Josefsson To: =?iso-8859-1?Q?St=E9phane?= Lancel References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110427:vint@google.com::CfLRT1OVR4Z8YckS:496z X-Hashcash: 1:22:110427:idna-update@alvestrand.no::ftSjRfMnyXfolBUc:6cO+ X-Hashcash: 1:22:110427:stelancel@gmail.com::Wq8QmED502UnF/Y0:D19s X-Hashcash: 1:22:110427:apps-discuss@ietf.org::t/xwJAsCN8H6gKId:Bojc X-Hashcash: 1:22:110427:ajs@shinkuro.com::kCJoDoN9jJJ+iva7:S9zO X-Hashcash: 1:22:110427:iucg@ietf.org::lCiNo9BoWYvgVtJV:WbIr X-Hashcash: 1:22:110427:yaojk@cnnic.cn::RWCjVsMiQTS3NI/K:blA+ Date: Wed, 27 Apr 2011 19:35:52 +0200 In-Reply-To: (=?iso-8859-1?Q?=22St=E9phane?= Lancel"'s message of "Wed, 27 Apr 2011 16:49:18 +0200") Message-ID: <87pqo7zjev.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 17:36:08 -0000 (I'm limiting the cc list to just idna-update and apps-discuss.) Stéphane Lancel writes: > I am sorry because I am not really expert in PVALID issues (changes, etc.), > but I understood that PVALID once, PVALID for ever. I realize with this > Draft that this means at character level not at codepoint level. Or am I > wrong? The "PVALID once PVALID forever" invariant will not be true if this draft is approved. However I'm not saying that should be an absolute axiom. There could be cases where we want to disallow some strings that used to be permitted because they cause significant problems (for similar reasons some code points are disallowed today). I would prefer case-by-case decisions. What I'm not seeing here is an explanation why this code point is so problematic that we must disallow it. The code point doesn't even seem to be used in IDNs. /Simon From klensin@jck.com Wed Apr 27 11:58:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D350E078B for ; Wed, 27 Apr 2011 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJCp1tVMyJZJ for ; Wed, 27 Apr 2011 11:58:33 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 388CBE0769 for ; Wed, 27 Apr 2011 11:58:33 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QF9wA-0006MB-4k; Wed, 27 Apr 2011 14:58:10 -0400 Date: Wed, 27 Apr 2011 14:58:08 -0400 From: John C Klensin To: Andrew Sullivan , Vint Cerf Message-ID: <4A02D767834082FBD0D4E7A8@PST.JCK.COM> In-Reply-To: <20110427140644.GH7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Simon Josefsson , idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:58:34 -0000 --On Wednesday, April 27, 2011 10:06 -0400 Andrew Sullivan wrote: >... > Implicit in the decision in the past about these sorts of > cases was that we'd treat them case by case. The reason to do > that was that some (potential) incompatibilities are more > serious than others. We have been over this before, but there is another reason that keeps getting lost when someone says "it is incompatible". There really isn't ever going to be a choice between "incompatibility" and "no incompatibility". It is a tradeoff between two different choices of incompatibility: * We preserve the earlier interpretation of a character. That requires compensating for a change in Unicode properties by putting the character into a table of exceptions (a table that we have not yet actually had to create and start putting entries into). * We preserve the alignment between IDNA2008 and evolving-version Unicode properties by letting the character's interpretation change if its Unicode properties are changed. That is the "do nothing" option as far as IDNA2008 (and RFC 5892 in particular) are concerned -- IDNA2008's rules and tables are unchanged, but the character status changes. That distinction is important because the underlying design model for IDNA2008 is that it is a specification of rules about property values (with exceptions as absolutely needed), not a table of characters and their interpretations (the latter was the model with Stringprep and Nameprep). While I assume that others may understand things differently than I do, that implies to me that the "normal" (and stable) action for new versions of Unicode is simply to run the existing rules against the Unicode-updated character and property list. If Unicode decides that a property was sufficiently in error that they should reclassify the character despite whatever disruptions that would have (to our work or that of anyone else), then the IETF/IDNA default, IMO, should be that we don't second-guess that choice or its importance, _especially_ in an environment in which, however many labels appear in the DNS today for a previously PVALID character (or that might have appeared if the character were previously DISALLOWED), there will be more on the future, just because of the growth in registrations. Remember too that the WG's decision (which I hope we don't need to reopen) was that, all things being equal, a change from DISALLOWED to PVALID is no less problematic than a change from PVALID to DISALLOWED. That is at least partially because, if someone wants to register a label that would naturally include a DISALLOWED character, people will make compromises and register whatever they consider as similar as possible. If the character is later reclassified to PVALID, while there is no issue with a label becoming invalid, we end up with the same problem we are now facing with Sharp S, Final Sigma, and the previously "mapped to nothing" joiner characters (and had some years ago with the introduction of decorated Latin characters): there is no way to know whether previous registrations were intended as compromises with what was possible or were intended to be in that form, creating a need for either special registration models (e.g., sunrise reservations), alias registrations in some form, or both. The reality is that any change in properties and therefore IDNA classification of a code point between versions of Unicode is going to be disruptive. I think we need to assume (and hope) that Unicode will not make such changes unless they are really necessary and justified and will exert appropriate caution in adding characters to make the odds of needing to reclassify them very low. But, if they do make such a change and we continue to believe in the "Unicode version independent" model of IDNA2008, our default, IMO, needs to be "follow Unicode" in the absence of strong and material evidence that the change would be unusually and unacceptably disruptive to IDNA. Otherwise, it seems to me that we lose that model and, instead, replace the IDNA2003 model of "Unicode 3.2 forever" with one that uses rolling snapshots of Unicode based on each version's property lists, i.e., that we effectively hold properties immutable that the Unicode Consortium, in its wisdom, feels free to change. IF we were changing the rules around > (say) the character "0", I'm quite sure that the reaction > would be different. Indeed. john From sm@elandnews.com Wed Apr 27 13:21:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA0DE0803; Wed, 27 Apr 2011 13:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slZqN6rZCaHZ; Wed, 27 Apr 2011 13:21:09 -0700 (PDT) Received: from mail.elandnews.com (mail.elandnews.com [208.69.177.124]) by ietfa.amsl.com (Postfix) with ESMTP id 4A581E07F1; Wed, 27 Apr 2011 13:21:04 -0700 (PDT) Received: from subman.elandnews.com ([41.136.232.81]) (authenticated bits=0) by mail.elandnews.com (8.13.8/8.13.8) with ESMTP id p3RKI59W019056; Wed, 27 Apr 2011 13:18:10 -0700 Message-Id: <6.2.5.6.2.20110427131513.04936810@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Apr 2011 13:17:54 -0700 To: apps-discuss@ietf.org From: Dave CROCKER (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Terry Manderson , iesg@ietf.org, dcrocker@bbiw.net Subject: [apps-discuss] Apps Area Review of: draft-ietf-grow-geomrt-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:42:55 -0000 Howdy. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-grow-geomrt-01 Title: MRT BGP routing information export format with geo-location extensions Reviewer: D. Crocker Review Date: 27 April 2011 Summary: This document provides a focused enhancement to an existing data specification for exchanges reports about BGP activity externally. It adds geo-location information to the tables. Major Issues: 0) The specification generally appears reasonable and concise. The enhancement seems intuitively useful, although I strongly suggest the document make the types of utility explicit. Why is it good to add this information to the table? 1) The document presumes extensive background by the reader. Instead it needs a bit of tutorial and it needs to define every term -- acronym or core vocabulary -- it uses, either directly or by citation 2) The GEO_PEER_TABLE needs a column with text defining the meaning of each value, rather than relying on the labels' being intuitive. Detailed comment: > MRT BGP routing information export format with geo-location extensions > draft-ietf-grow-geomrt-01.txt > >Abstract > > This document extends the Border Gateway Protocol (BGP) MRT export > format for routing information to include terrestrial coordinates. Expand MRT so that the Abstract requires less background to understand and gives a basic sense of the purpose/benefit of this work. >2. Introduction > > Research is underway that analyzes the network behavior of routing > protocol transactions from routing information base snapshots in > relation to geographical coordinates. Specifically the BGP routing The first sentence is confusing. Although I could make guess, I don't really know what it means. I suggest less redundant vocabulary and possibly two sentences and probably more active sentence form. In contrast, I find draft-ietf-grow-mrt's related sentence: "Researchers and engineers often wish to analyze network behavior by studying routing protocol transactions and routing information base snapshots." to be reasonably clear. > protocol is the subject of study and the analysis has been > significantly aided by the availability and extension of the "MRT > format" [I-D.ietf-grow-mrt] originally defined in the MRT > Programmer's Guide [MRT PROG GUIDE]. > > This memo documents an extension to the "MRT format" > [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT > Subtype field. Lots of acronym repetition, without any acronym definition. >3. Geo-location aware MRT Routing Information Subtype > > The additional Subtype is defined for the TABLE_DUMP_v format, which > extends the TABLE_DUMP_V2 type. > >3.1. GEO_PEER_TABLE > > The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include > Geo-location information in the form of WGS84 [WGS 84] formatted > coordinates. The MRT subtypes would be as follows. > > 1 PEER_INDEX_TABLE > 2 RIB_IPV4_UNICAST > 3 RIB_IPV4_MULTICAST > 4 RIB_IPV6_UNICAST > 5 RIB_IPV6_MULTICAST > 6 RIB_GENERIC > 7 GEO_PEER_TABLE What does each of these value mean? The labels might seem intuitive, but there should be explicit text defining their meaning. > The GEO_PEER_TABLE MRT record provides the BGP ID of the collector, > Its latitude and longitude in WGS84 [WGS 84] format, and a list of > indexed peers. I'm guessing this is the single most important text in the document, since it specifies exactly what location info is being provided. I suggest the Abstract and Introduction summarize this, along the lines of: ...to include terrestrial coordinates of the BGP collector. On the other hand, I can't find a definition of what a BGP Collector is, in this or related documents. (It's not in RFC 4271, for example.) In looking over the vocabulary from RFC 4271, it does appear that there is no term for the system that receives BGP reports. Clearly one is needed, but it needs to be defined explicitly, so please either provide definition text or cite it.0 In fact, it's probably a good idea to explain why this particular bit of information is useful. A small segment of tutorial text would go a long way. Depending on what the definition of a BGP Collector is, the usefulness might or might note be obvious, but it shouldn't be left to chance. > The format and function of the Collector BGP ID, Peer Count are as > defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format. > [I-D.ietf-grow-mrt]. > > The Collector Latitude and Collector Longitude are the geographical > coordinates of the collector in WGS84 [WGS 84] datum decimal degrees > format stored as a single precision float in the 32 bits allocated to > the Collector Latitude and Collector Longitude. The latitude and > longitude may be a Not A Number (NAN) for situations where the geo- It's not required, but common practice is to capitalize normative terms, like MAY. > location of the collector is considered private. The Collector > Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84] > datum coordinate and NAN values. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Collector BGP ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Collector Latitude | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Collector Longitude | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Peer Count | Peer entries (variable) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The format of the peer entries is shown below. The Peer Type and the > Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT > [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer > entries in GEO_PEER_TABLE MUST match the order and number as existing > in the PEER_INDEX_TABLE. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Peer Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Peer BGP ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Peer Latitude | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Peer Longitude | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The Peer Latitude and Peer Longitude are the geographical coordinates > of the peer in WGS84 [WGS 84] datum decimal degrees format stored as > a single precision float in the 32 bits allocated to the Peer > Latitude and Peer Longitude. The latitude and longitude may be a Not MAY -- Dave Crocker Brandenburg InternetWorking bbiw.net From jfc@morfin.org Wed Apr 27 14:42:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7954E0873 for ; Wed, 27 Apr 2011 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev8JNiTdEzon for ; Wed, 27 Apr 2011 14:42:52 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 452C2E086C for ; Wed, 27 Apr 2011 14:42:52 -0700 (PDT) Received: from 124.250-227-89.dsl.completel.net ([89.227.250.124]:50297 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QFCV1-0000fu-5k; Wed, 27 Apr 2011 14:42:19 -0700 Message-Id: <7.0.1.0.2.20110427230849.059f2780@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 27 Apr 2011 23:43:02 +0200 To: John C Klensin ,Andrew Sullivan , Vint Cerf From: "J-F C. Morfin" In-Reply-To: <4A02D767834082FBD0D4E7A8@PST.JCK.COM> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> <4A02D767834082FBD0D4E7A8@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Wed, 27 Apr 2011 20:32:15 -0700 Cc: Simon Josefsson , idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:42:52 -0000 At 20:58 27/04/2011, John C Klensin wrote: >That is at least partially because, if someone wants to register a >label that would naturally include a DISALLOWED character, people >will make compromises and register whatever they consider as >similar as possible. John, this is what, I believe, makes Stephane differentiating characters and code points. Characters are what people consider. Code points and their properties what Unicode considers. Characters exist before Unicode code points. Unicode changes at this stage are to better match characters. The way people have used code points to support a character may be the same or different from the way Unicode will do it in its new version: this is something a registry can easily address through a policy statement and in validating domain names using the new Unicode approach to replace the people compromise. Also, remember that if IDNA2008 is Unicode-version independent, it means that it is necessarily UCS system independent. I consider that Unicode is inappropriate to network semiotics support but that IDNA2008 does a good job to support Unicode and pave the way for new kind of supports. This means that U-labels and A-labels may go for ever, but N-labels (from an UCS network oriented system?) could be introduced and supported [that internally may very well use ISO 10646 tables or not]. At this stage, IDNA2008, on the machine side uses Unicode which is a computer oriented (hence code point) system, while people use signs (i.e. when scripting, characters). The whole issue is to make them better and better correspond. However, IMHO we are reaching the limits of the Unicode kind of typographic oriented system (ex. lack of French majuscules support, but also logos, gestures, sounds, thoughts, etc. new signs for new kind of communication system. etc.) jfc From dhc@dcrocker.net Wed Apr 27 22:05:22 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2AE081D; Wed, 27 Apr 2011 22:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BR5I6+DdV2w; Wed, 27 Apr 2011 22:05:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC8E0685; Wed, 27 Apr 2011 22:05:20 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3S55Adq020939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 22:05:15 -0700 Message-ID: <4DB8F586.10201@dcrocker.net> Date: Wed, 27 Apr 2011 22:05:10 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 27 Apr 2011 22:05:16 -0700 (PDT) Cc: Christopher Morrow , Apps Review , "iesg@ietf.org" , "apps-discuss@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [apps-discuss] Apps Area Review of: draft-ietf-grow-geomrt-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 05:05:22 -0000 On 4/27/2011 9:51 PM, Terry Manderson wrote: > A rfcdiff is attached for the new -02 from -01. Do these adequately address > the issues you raise? From a quick read of the diffs, the changes appear to be thorough and complete, nevermind the lightning speed with which they were produced. Nice job. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From terry.manderson@icann.org Wed Apr 27 21:51:26 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D8DE081D; Wed, 27 Apr 2011 21:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ4kS8Cu1qGZ; Wed, 27 Apr 2011 21:51:25 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id C5580E0685; Wed, 27 Apr 2011 21:51:25 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 27 Apr 2011 21:51:24 -0700 From: Terry Manderson To: Dave CROCKER , "apps-discuss@ietf.org" Date: Wed, 27 Apr 2011 21:51:11 -0700 Thread-Topic: Apps Area Review of: draft-ietf-grow-geomrt-01 Thread-Index: AcwFHYVRJhlHwhNgScmiylEQGpIj3AAQl+92 Message-ID: In-Reply-To: <6.2.5.6.2.20110427131513.04936810@elandnews.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_C9DF2F6011ECDterrymandersonicannorg_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Apr 2011 08:27:48 -0700 Cc: Christopher Morrow , Apps Review , "iesg@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [apps-discuss] Apps Area Review of: draft-ietf-grow-geomrt-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 04:51:26 -0000 --_002_C9DF2F6011ECDterrymandersonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your careful review. On 28/04/11 6:17 AM, "Dave CROCKER" wrote: >=20 >=20 > Document: draft-ietf-grow-geomrt-01 >=20 >=20 >=20 > Major Issues: >=20 > 0) The specification generally appears reasonable and concise. > The enhancement seems intuitively useful, although I strongly suggest > the document make the types of utility explicit. Why is it good to > add this information to the table? I have added a paragraph describing the utility to the introduction. >=20 > 1) The document presumes extensive background by the > reader. Instead it needs a bit of tutorial and it needs to define > every term -- acronym or core vocabulary -- it uses, either directly > or by citation I have added a definitions section. >=20 > 2) The GEO_PEER_TABLE needs a column with text defining the > meaning of each value, rather than relying on the labels' being intuitive= . >=20 I have added a small table following the GEO_PEER_TABLE and peer entries defining the label definitions. >=20 >=20 > Detailed comment: >=20 >=20 >> MRT BGP routing information export format with geo-location extensions >> draft-ietf-grow-geomrt-01.txt >>=20 >> Abstract >>=20 >> This document extends the Border Gateway Protocol (BGP) MRT export >> format for routing information to include terrestrial coordinates. >=20 > Expand MRT so that the Abstract requires less background to > understand and gives a basic sense of the purpose/benefit of this work. done. >=20 >=20 >> 2. Introduction >>=20 >> Research is underway that analyzes the network behavior of routing >> protocol transactions from routing information base snapshots in >> relation to geographical coordinates. Specifically the BGP routing >=20 > The first sentence is confusing. Although I could make guess, I > don't really know what it means. I suggest less redundant vocabulary > and possibly two sentences and probably more active sentence form. >=20 > In contrast, I find draft-ietf-grow-mrt's related sentence: >=20 > "Researchers and engineers often wish to analyze network behavior b= y > studying routing protocol transactions and routing information base > snapshots." >=20 > to be reasonably clear. Updated. >=20 >=20 >> protocol is the subject of study and the analysis has been >> significantly aided by the availability and extension of the "MRT >> format" [I-D.ietf-grow-mrt] originally defined in the MRT >> Programmer's Guide [MRT PROG GUIDE]. >>=20 >> This memo documents an extension to the "MRT format" >> [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT >> Subtype field. >=20 > Lots of acronym repetition, without any acronym definition. expanded acronyms. >=20 >=20 >> 3. Geo-location aware MRT Routing Information Subtype >>=20 >> The additional Subtype is defined for the TABLE_DUMP_v format, which >> extends the TABLE_DUMP_V2 type. >>=20 >> 3.1. GEO_PEER_TABLE >>=20 >> The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include >> Geo-location information in the form of WGS84 [WGS 84] formatted >> coordinates. The MRT subtypes would be as follows. >>=20 >> 1 PEER_INDEX_TABLE >> 2 RIB_IPV4_UNICAST >> 3 RIB_IPV4_MULTICAST >> 4 RIB_IPV6_UNICAST >> 5 RIB_IPV6_MULTICAST >> 6 RIB_GENERIC >> 7 GEO_PEER_TABLE >=20 > What does each of these value mean? It's actually superfluous to list types 1-6. I have updated the table to be just Subtype 7 with a header that explains that the number is a subtype number and the text is a subtype name. >=20 > The labels might seem intuitive, but there should be explicit text > defining their meaning. They are just the Subtype number and name in the export format. They hold n= o special meaning. >=20 >=20 >> The GEO_PEER_TABLE MRT record provides the BGP ID of the collector, >> Its latitude and longitude in WGS84 [WGS 84] format, and a list of >> indexed peers. >=20 > I'm guessing this is the single most important text in the document, > since it specifies exactly what location info is being provided. I > suggest the Abstract and Introduction summarize this, along the lines of: >=20 > ...to include terrestrial coordinates of the BGP collector. Have updated the intro and abstract. >=20 > On the other hand, I can't find a definition of what a BGP Collector > is, in this or related documents. (It's not in RFC 4271, for > example.) In looking over the vocabulary from RFC 4271, it does > appear that there is no term for the system that receives BGP > reports. Clearly one is needed, but it needs to be defined > explicitly, so please either provide definition text or cite it.0 Indeed no documentation exists describing a BGP collector. I have added a definition for BGP Collector. >=20 > In fact, it's probably a good idea to explain why this particular bit > of information is useful. A small segment of tutorial text would go > a long way. >=20 > Depending on what the definition of a BGP Collector is, the > usefulness might or might note be obvious, but it shouldn't be left to ch= ance. I've provided some expanded information on a BGP Collector in its own section. >=20 >=20 >> The format and function of the Collector BGP ID, Peer Count are as >> defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format. >> [I-D.ietf-grow-mrt]. >>=20 >> The Collector Latitude and Collector Longitude are the geographical >> coordinates of the collector in WGS84 [WGS 84] datum decimal degrees >> format stored as a single precision float in the 32 bits allocated to >> the Collector Latitude and Collector Longitude. The latitude and >> longitude may be a Not A Number (NAN) for situations where the geo- >=20 > It's not required, but common practice is to capitalize normative > terms, like MAY. Fixed. >=20 >=20 >> location of the collector is considered private. The Collector >> Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84] >> datum coordinate and NAN values. >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Collector BGP ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Collector Latitude | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Collector Longitude | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Peer Count | Peer entries (variable) >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >>=20 >> The format of the peer entries is shown below. The Peer Type and the >> Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT >> [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer >> entries in GEO_PEER_TABLE MUST match the order and number as existing >> in the PEER_INDEX_TABLE. >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Peer Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Peer BGP ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Peer Latitude | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Peer Longitude | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> The Peer Latitude and Peer Longitude are the geographical coordinates >> of the peer in WGS84 [WGS 84] datum decimal degrees format stored as >> a single precision float in the 32 bits allocated to the Peer >> Latitude and Peer Longitude. The latitude and longitude may be a Not >=20 > MAY fixed A rfcdiff is attached for the new -02 from -01. Do these adequately address the issues you raise? (also noting the removal of the IANA considerations section as the primary MRT draft no longer calls for an IANA registry, thus geomrt shouldn't either.) And I'm awaiting the shepherd's ack to post. Cheers Terry --_002_C9DF2F6011ECDterrymandersonicannorg_ Content-Type: application/octet-stream; name="draft-ietf-grow-geomrt-02-from-1.diff.html" Content-Description: draft-ietf-grow-geomrt-02-from-1.diff.html Content-Disposition: attachment; filename="draft-ietf-grow-geomrt-02-from-1.diff.html"; size=80923; creation-date="Wed, 27 Apr 2011 21:51:24 GMT"; modification-date="Wed, 27 Apr 2011 21:51:24 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQxOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogRGFyd2luIHRlcnJ5LW1hbmRlcnNvbnMtbWFjYm9vay5s b2NhbCAxMC43LjAgRGFyd2luIEtlcm5lbCBWZXJzaW9uIDEwLjcuMDogU2F0IEphbiAyOSAxNTox NzoxNiBQU1QgMjAxMTsgcm9vdDp4bnUtMTUwNC45LjM3fjEvUkVMRUFTRV9JMzg2IGkzODYgLS0+ IAo8IS0tIFVzaW5nIGF3azogL29wdC9sb2NhbC9iaW4vZ2F3azogR05VIEF3ayAzLjEuOCAtLT4g CjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1dGlscykgMi44 LjEgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvb3B0L2xvY2FsL2Jpbi93ZGlmZjogd2RpZmYgKEdO VSB3ZGlmZikgMC42LjMgLS0+IAo8aHRtbD4gCjxoZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJD b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiAvPiAK ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3Nz IiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1ncm93LWdlb21ydC0wMS50eHQgLSBkcmFm dC1pZXRmLWdyb3ctZ2VvbXJ0LTAyLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2Nz cyI+IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAK ICAgIHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFt aWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30g CiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1z aXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNF RUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZm ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQt Y29sb3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAK ICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJh Y2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjog I0ZGQjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxp bmViciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJl ZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjog cmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6 ICNBQUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAg ICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAu Y29udCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFj a2dyb3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7 IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjog I0VFRTsgcGFkZGluZzogMnB4IDA7IH0gCiAgPC9zdHlsZT4gCjwvaGVhZD4gCjxib2R5ID4gCiAg PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRy IGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPiZuYnNwO2RyYWZ0LWlldGYtZ3Jvdy1nZW9t cnQtMDEudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwO2RyYWZ0LWlldGYtZ3Jvdy1n ZW9tcnQtMDIudHh0Jm5ic3A7PC90aD48dGg+PC90aD48L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj5HbG9iYWwgUm91dGluZyBPcGVyYXRpb25zIFdvcmtpbmcgICAgICAgICAgICAg ICAgICAgICAgICAgICBULiBNYW5kZXJzb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+R2xvYmFsIFJvdXRpbmcgT3BlcmF0aW9ucyBXb3JraW5nIDxzcGFuIGNsYXNzPSJpbnNlcnQi Pkdyb3VwPC9zcGFuPiAgICAgICAgICAgICAgICAgICAgIFQuIE1hbmRlcnNvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPkdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBJQ0FOTjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPklDQU5OPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBj bGFzcz0iZGVsZXRlIj5EZWNlbWJlciAxNCwgMjAxMDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+SW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFwcmlsIDI4LCAyMDExPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PY3RvYmVyIDMwLDwvc3Bhbj4g MjAxMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJkZWxldGUiPkp1bmUgMTcsPC9zcGFuPiAyMDExPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+IE1SVCBCR1Agcm91dGluZyBpbmZvcm1hdGlvbiBleHBvcnQgZm9ybWF0IHdpdGggZ2VvLWxv Y2F0aW9uIGV4dGVuc2lvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gTVJUIEJH UCByb3V0aW5nIGluZm9ybWF0aW9uIGV4cG9ydCBmb3JtYXQgd2l0aCBnZW8tbG9jYXRpb24gZXh0 ZW5zaW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDIiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWdyb3ctZ2VvbXJ0LTA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4xPC9zcGFuPi50eHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1ncm93LWdlb21ydC0wPHNwYW4gY2xhc3M9Imluc2Vy dCI+Mjwvc3Bhbj4udHh0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDMiIC8+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChCR1Ap IDxzcGFuIGNsYXNzPSJkZWxldGUiPk1SVDwvc3Bhbj4gZXhwb3J0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgQm9yZGVyIEdhdGV3 YXkgUHJvdG9jb2wgKEJHUCkgPHNwYW4gY2xhc3M9Imluc2VydCI+TXVsdGktPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGZv cm1hdCBmb3Igcm91dGluZyBpbmZvcm1hdGlvbiB0byBpbmNsdWRlIHRlcnJlc3RyaWFsIDxzcGFu IGNsYXNzPSJkZWxldGUiPmNvb3JkaW5hdGVzLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhyZWFkZWQgUm91dGluZyBUb29s a2l0IChNUlQpPC9zcGFuPiBleHBvcnQgZm9ybWF0IGZvciByb3V0aW5nIGluZm9ybWF0aW9uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRvIGluY2x1ZGUgdGVycmVzdHJpYWwg PHNwYW4gY2xhc3M9Imluc2VydCI+Y29vcmRpbmF0ZXMgb2YgYSBCR1AgQ29sbGVjdG9yIGFuZCBp dHMgQkdQPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICBQZWVycy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5T dGF0dXMgb2YgdGhpcyBNZW1vPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+U3RhdHVz IG9mIHRoaXMgTWVtbzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5l dC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0 dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm92aXNpb25zIG9m IEJDUCA3OCBhbmQgQkNQIDc5LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJp bmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJl IHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNl IChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt RHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVw ZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIg dGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPkp1bmUgMTc8 L3NwYW4+LCAyMDExLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk9jdG9iZXIg MzA8L3NwYW4+LCAyMDExLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5v dGljZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNSIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIENvcHlyaWdodCAoYykgMjAxPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ MDwvc3Bhbj4gSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQ29weXJpZ2h0IChjKSAyMDE8c3BhbiBj bGFzcz0iaW5zZXJ0Ij4xPC9zcGFuPiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlm aWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVU RiBEb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25z IFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNl IHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1 bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmlj dGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2Fy ZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0 aCByZXNwZWN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZy b20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg dG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRv Y3VtZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg aW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNC5lIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0 aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBU cnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBh czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgMS4gIFJlcXVpcmVtZW50cyBub3RhdGlvbiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgMS4gIFJlcXVpcmVtZW50cyBub3RhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIDIuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAzLiAgR2VvLWxvY2F0aW9uIGF3YXJlIE1SVCBSb3V0aW5nIEluZm9y bWF0aW9uIFN1YnR5cGUgLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjU8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDMuICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5EZWZpbml0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgIDMuMS48L3NwYW4+ ICBHRU9fUEVFUl9UQUJMRSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICA0Ljwvc3Bhbj4gIEdlby1sb2NhdGlv biBhd2FyZSBNUlQgUm91dGluZyBJbmZvcm1hdGlvbiBTdWJ0eXBlIC4gLiAuIC4gLiAuICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIDQuPC9zcGFu PiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgNC4xLjwvc3Bhbj4gIEdF T19QRUVSX1RBQkxFIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgNS48 L3NwYW4+ICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICA0LjIuICBHRU9f UEVFUl9UQUJMRSBhbmQgcGVlciBlbnRyeSB2YWx1ZXMuICAuIC4gLiAuIC4gLiAuIC4gLiAuICA3 PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIDYuPC9zcGFuPiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNs YXNzPSJkZWxldGUiPjk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIDUuICBCR1AgQ29sbGVjdG9yIENvbnN0cnVjdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICA3Ljwvc3Bhbj4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjEwPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICA2 Ljwvc3Bhbj4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEwPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgICAgNy4xLjwvc3Bhbj4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIDcuPC9zcGFuPiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MTE8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ICAgICA3LjIuPC9zcGFuPiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4x MDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgOC48L3NwYW4+ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIDkuPC9zcGFuPiAgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MTM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgOS4xLjwvc3Bhbj4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4g Y2xhc3M9Imluc2VydCI+MTM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgOS4yLjwvc3Bhbj4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imlu c2VydCI+MTM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEF1dGhv cidzIEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjEuICBSZXF1aXJlbWVudHMgbm90YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4xLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNI QUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhl IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5k ICJPUFRJT05BTCIgaW4gdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4g W1JGQzIxMTldLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+Mi4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjIuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAwNyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPlJlc2VhcmNoIGlzIHVuZGVyd2F5IHRoYXQgYW5hbHl6ZXMgdGhlPC9zcGFu PiBuZXR3b3JrIGJlaGF2aW9yIDxzcGFuIGNsYXNzPSJkZWxldGUiPm9mPC9zcGFuPiByb3V0aW5n PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQi PlJlc2VhcmNoZXJzIGFuZCBlbmdpbmVlcnMgb2Z0ZW4gd2lzaCB0byBhbmFseXplPC9zcGFuPiBu ZXR3b3JrIGJlaGF2aW9yIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmJ5PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHByb3RvY29s IHRyYW5zYWN0aW9ucyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5mcm9tPC9zcGFuPiByb3V0aW5nIGlu Zm9ybWF0aW9uIGJhc2Ugc25hcHNob3RzIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN0dWR5aW5nPC9zcGFuPiByb3V0aW5nIHByb3Rv Y29sIHRyYW5zYWN0aW9ucyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbmQ8L3NwYW4+IHJvdXRpbmcg aW5mb3JtYXRpb24gYmFzZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIHJlbGF0aW9uIHRvIGdlb2dyYXBoaWNhbCA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5jb29yZGluYXRlcy4gIFNwZWNpZmljYWxseTwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNz PSJkZWxldGUiPkJHUCByb3V0aW5nPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBzbmFwc2hvdHMgaW4gcmVsYXRpb24gdG8gZ2VvZ3JhcGhpY2FsIDxzcGFuIGNsYXNz PSJpbnNlcnQiPnRvcG9sb2dpZXMuICBVc3VhbGx5PC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9Imlu c2VydCI+Qm9yZGVyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHByb3RvY29sPC9zcGFu PiBpcyB0aGUgc3ViamVjdCBvZiBzdHVkeSBhbmQgdGhlIGFuYWx5c2lzIDxzcGFuIGNsYXNzPSJk ZWxldGUiPmhhcyBiZWVuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBHYXRld2F5IFByb3RvY29sIFtSRkM0MjcxXTwvc3Bhbj4g aXMgdGhlIHN1YmplY3Qgb2Ygc3R1ZHkgYW5kIHRoZSBhbmFseXNpczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHNpZ25pZmljYW50bHkg YWlkZWQgYnkgdGhlIGF2YWlsYWJpbGl0eSBhbmQgZXh0ZW5zaW9uIG9mIHRoZSA8c3BhbiBjbGFz cz0iZGVsZXRlIj4iTVJUPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5jYW4gYmU8L3NwYW4+IHNpZ25pZmljYW50bHkgYWlkZWQg YnkgdGhlIGF2YWlsYWJpbGl0eSBhbmQgZXh0ZW5zaW9uIG9mIHRoZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGZvcm1hdCIgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+W0ktRC5pZXRmLWdyb3ctbXJ0XTwvc3Bhbj4gb3JpZ2luYWxseSBkZWZp bmVkIGluIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5NUlQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPiJNdWx0aS10aHJlYWRl ZCBSb3V0aW5nIFRvb2xraXQgKE1SVCk8L3NwYW4+IGZvcm1hdCIgPHNwYW4gY2xhc3M9Imluc2Vy dCI+W0ktRC5pZXRmLWdyb3ctbXJ0XS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgUHJvZ3JhbW1lcidzIEd1aWRlIDxzcGFu IGNsYXNzPSJkZWxldGUiPltNUlQgUFJPRyBHVUlERV0uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBUaGUgTVJUIGZvcm1hdCB3 YXM8L3NwYW4+IG9yaWdpbmFsbHkgZGVmaW5lZCBpbiB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+ TXVsdGktdGhyZWFkZWQgUm91dGluZzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgVG9vbGtpdDwvc3Bhbj4gUHJvZ3JhbW1lcidz IEd1aWRlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPltNUlQtR1VJREVdLjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBUaGUg YWRkaXRpb24gb2YgZ2VvLWxvY2F0aW9uIGNvb3JkaW5hdGVzIChsb25naXR1ZGUgYW5kIGxhdGl0 dWRlKTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgcGVydGFpbmluZyB0byB0aGUgZ2VvZ3JhcGhpY2FsIGxvY2F0aW9uIG9mIGJv dGggdGhlIEJHUCBjb2xsZWN0b3IgYW5kPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBpdHMgQkdQIHBlZXJzIHRvIEJHUCBleHBv cnQgZGF0YSBlbmFibGVzIGEgcmVzZWFyY2hlciBvciBlbnF1aXJpbmc8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGluZGl2aWR1 YWwgdG8gZ2FpbiBhIHRlcmVyZXN0cmlhbCBpbnNpZ2h0IHRvIHRoZSByb3V0ZXMgc2VlbiBieSBh IEJHUDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgc3BlYWtlci4gIFN1Y2ggZGF0YSBtYXkgdWx0aW1hdGVseSBhaWRlIHJlc2Vy YWNoZXJzIGluIHVuZGVyc3RhbmRpbmc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGFueSBkaXNwYXJpdHkgYmV0d2VlbiB0aGUg Z2VvZ3JhcGhpY2FsIGxvY2F0aW9uIG9mIG5ldHdvcmtzIGFuZCB0aGU8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRvcG9sb2dp Y2FsIGxvY2F0aW9uIG9mIG5ldHdvcmtzIGluIGFkZGl0aW9uIHRvIHRoZSByZWxhdGlvbnNoaXBz PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICBiZXR3ZWVuIGdlb2dyYXBoaWNhbCBwb3NpdGlvbiBhbmQgcm91dGluZyBhbm9tb2xp ZXMuICBTdWNoIGluc2lnaHQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGNvdWxkIHByb3ZpZGUgZnV0dXJlIGlucHV0IGludG8g bmV0d29yayBkZXNpZ24gb3IgbmV0d29yayBzZWN1cml0eS48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGlzIG1lbW8gZG9jdW1lbnRzIGFuIGV4dGVuc2lvbiB0byB0aGUg Ik1SVCBmb3JtYXQiPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBtZW1v IGRvY3VtZW50cyBhbiBleHRlbnNpb24gdG8gdGhlICJNUlQgZm9ybWF0IjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtZ3Jv dy1tcnRdIGFuZCBpbnRyb2R1Y2VzIGFuIGFkZGl0aW9uYWwgZGVmaW5pdGlvbiBvZiBhIE1SVDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1ncm93LW1ydF0gYW5k IGludHJvZHVjZXMgYW4gYWRkaXRpb25hbCBkZWZpbml0aW9uIG9mIGEgTVJUPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAwOCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUi PlN1YnR5cGUgZmllbGQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zdWJ0eXBlIGZpZWxkIHRoYXQgaW5jbHVkZXMgdGhlIHRl cmVzdHJpYWwgY29vcmRpbmF0ZXMgb2YgYSBCR1A8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIENvbGxlY3RvciBhbmQgaXRzIEJH UCBQZWVycy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwMDkiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4zLiAgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+R2VvLWxvY2F0aW9uIGF3YXJlIE1SVCBSb3V0aW5nIEluZm9ybWF0aW9uIFN1YnR5cGU8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjMuICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5EZWZpbml0aW9uczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAxMCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJkZWxldGUiPlRoZSBhZGRpdGlvbmFsIFN1YnR5cGUgaXMgZGVmaW5lZCBmb3I8L3NwYW4+IHRo ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UQUJMRV9EVU1QX3YgZm9ybWF0LCB3aGljaDwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ Q29vcmRpbmF0ZXM6IEEgc2V0IG9mIGdlb2dyYXBoaWMgbGF0aXR1ZGUgYW5kIGxvbmdpdHVkZSBz cGVjaWZ5aW5nIGE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgZXh0ZW5kcyB0aGUgVEFC TEVfRFVNUF9WMiB0eXBlLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbG9jYXRpb24gb248L3NwYW4+IHRoZSA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5FYXJ0aC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMTEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4zLjEuPC9zcGFuPiAgR0VPX1BFRVJfVEFCTEU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+QkdQIFNwZWFrZXI6IEEgbmV0d29y ayBkZXZpY2Ugd2hpY2ggZXhjaGFuZ2VzIG5ldHdvcmsgcm91dGluZzwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaW5mb3JtYXRp b24gdXNpbmcgQkdQLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBHZW8tbG9jYXRpb246IEFzc2lnbmluZyBhIHNldCBv ZiBjb29yZGluYXRlcyB0byBhIHNwZWNpZmljIGFydGlmYWN0LDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaW4gdGhpcyBjYXNl IGEgQkdQIHNwZWFrZXIuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEJHUCBDb2xsZWN0b3I6IEEgQkdQIHNwZWFrZXIg KHVzdWFsbHkgcGFzc2l2ZSkgdGhhdCBzdG9yZXMgYW5kPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhcmNoaXZlcyBCR1Agcm91 dGluZyBkYXRhIGZyb20gYWN0aXZlIEJHUCBwZWVycyBmb3IgYW5hbHlzaXMuPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IEJHUCBQZWVyOiBFaXRoZXIgYW4gaW50ZXJuYWwgb3IgZXh0ZXJuYWwgQkdQIHBlZXIgW1JGQzQy NzFdLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBOb3QgQSBOdW1iZXIgKE5BTik6IG51bWVyaWMgZGF0YSB0eXBlIHJl cHJlc2VudGluZyBhbiB1bmRlZmluZWQgb3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHVucmVwcmVzZW50YWJsZSB2YWx1ZS4g IEFzIGRlZmluZWQgaW4gSUVFRSBTdGFuZGFyZCBmb3IgRmxvYXRpbmctPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBQb2ludCBB cml0aG1ldGljIFtJRUVFNzU0XS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+NC4gIEdlby1sb2NhdGlvbiBhd2FyZSBNUlQg Um91dGluZyBJbmZvcm1hdGlvbiBTdWJ0eXBlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEFuIGFkZGl0aW9uYWwgc3Vi dHlwZSAoR0VPX1BFRVJfVEFCTEUpIGlzIGRlZmluZWQgZm9yIHRoZTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgVEFCTEVfRFVN UF92MiBmb3JtYXQsIGV4dGVuZGluZyBUQUJMRV9EVU1QX1YyIFR5cGUuPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjQuMS48 L3NwYW4+ICBHRU9fUEVFUl9UQUJMRTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IEdFT19QRUVSX1RBQkxFIFN1YnR5cGUgdXBkYXRlcyB0aGUgVEFCTEVfRFVNUF92MiBUeXBlcyB0 byBpbmNsdWRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEdFT19QRUVS X1RBQkxFIFN1YnR5cGUgdXBkYXRlcyB0aGUgVEFCTEVfRFVNUF92MiBUeXBlcyB0byBpbmNsdWRl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAxMiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEdlby1sb2Nh dGlvbiBpbmZvcm1hdGlvbiBpbiB0aGUgZm9ybSBvZiBXR1M4NCA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5bV0dTIDg0XTwvc3Bhbj4gZm9ybWF0dGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIEdlby1sb2NhdGlvbiBpbmZvcm1hdGlvbiBpbiB0aGUgZm9ybSBvZiBXR1M4NCA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5bV0dTLTg0XTwvc3Bhbj4gZm9ybWF0dGVkPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY29vcmRpbmF0ZXMu ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGUgTVJUIHN1YnR5cGVzIHdvdWxkIGJlIGFzIGZvbGxv d3MuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjb29yZGluYXRl cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxMyIg Lz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xICAgIFBF RVJfSU5ERVhfVEFCTEU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoZSBkb2N1bWVudCBhZGRzIHRoZSA3dGggc3VidHlwZSBu dW1iZXIgYW5kIG5hbWUgYmVsb3cuICBUaGUgZmlyc3Q8L3NwYW4+IDY8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICAgICAgMiAgICBSSUJfSVBWNF9VTklDQVNUPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zdWJ0eXBlcyBhcmUgZGVm aW5lZCBieSB0aGUgIk1SVCBmb3JtYXQiIFtJLUQuaWV0Zi1ncm93LW1ydF0uPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPiAgICAgICAzICAgIFJJQl9JUFY0X01VTFRJQ0FTVDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICA0ICAgIFJJQl9JUFY2X1VOSUNBU1Q8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IFN1YnR5cGUgTnVtYmVyICAgICAgIFN1YnR5cGUgTmFtZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICAgICAgNSAgICBSSUJfSVBWNl9NVUxUSUNBU1Q8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIDYgICAgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+UklCX0dFTkVSSUM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICA3ICAgICAgICAgICAgICAgR0VPX1BFRVJfVEFCTEU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgNyAgICBHRU9fUEVFUl9U QUJMRTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFRoZSBHRU9fUEVFUl9UQUJMRSBNUlQgcmVjb3JkIHByb3ZpZGVzIHRoZSBC R1AgSUQgb2YgdGhlIGNvbGxlY3Rvciw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUaGUgR0VPX1BFRVJfVEFCTEUgTVJUIHJlY29yZCBwcm92aWRlcyB0aGUgQkdQIElEIG9mIHRo ZSBjb2xsZWN0b3IsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNCIgLz48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkl0czwvc3Bhbj4gbGF0aXR1ZGUgYW5kIGxvbmdpdHVk ZSBpbiBXR1M4NCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bV0dTIDg0XTwvc3Bhbj4gZm9ybWF0LCBh bmQgYSBsaXN0IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNs YXNzPSJpbnNlcnQiPml0czwvc3Bhbj4gbGF0aXR1ZGUgYW5kIGxvbmdpdHVkZSBpbiBXR1M4NCA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bV0dTLTg0XTwvc3Bhbj4gZm9ybWF0LCBhbmQgYSBsaXN0IG9m PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgaW5kZXhlZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5wZWVycy48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGluZGV4ZWQgPHNwYW4gY2xhc3M9Imluc2VydCI+cGVl cnMgYW5kIHRoZWlyIHJlc3BlY3RpdmUgbGF0aXR1ZGVzIGFuZCBsb25naXR1ZGVzIGluIFdHUzg0 PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICBbV0dTLTg0XSBmb3JtYXQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVGhlIGZvcm1hdCBhbmQgZnVuY3Rpb24gb2YgdGhlIENvbGxlY3RvciBCR1AgSUQsIFBl ZXIgQ291bnQgYXJlIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGZv cm1hdCBhbmQgZnVuY3Rpb24gb2YgdGhlIENvbGxlY3RvciBCR1AgSUQsIFBlZXIgQ291bnQgYXJl IGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGRlZmlu ZWQgYnkgdGhlIFRBQkxFX0RVTVBfVjIgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TVJUIDwvc3Bhbj5Q RUVSX0lOREVYX1RBQkxFIGZvcm1hdC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgZGVmaW5lZCBieSB0aGUgVEFCTEVfRFVNUF9WMiBQRUVSX0lOREVYX1RBQkxFIGZvcm1hdC48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg W0ktRC5pZXRmLWdyb3ctbXJ0XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb SS1ELmlldGYtZ3Jvdy1tcnRdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIENv bGxlY3RvciBMYXRpdHVkZSBhbmQgQ29sbGVjdG9yIExvbmdpdHVkZSBhcmUgdGhlIGdlb2dyYXBo aWNhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBDb2xsZWN0b3IgTGF0 aXR1ZGUgYW5kIENvbGxlY3RvciBMb25naXR1ZGUgYXJlIHRoZSBnZW9ncmFwaGljYWw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDE2IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY29vcmRpbmF0ZXMgb2Yg dGhlIGNvbGxlY3RvciBpbiBXR1M4NCBbV0dTPHNwYW4gY2xhc3M9ImRlbGV0ZSI+IDwvc3Bhbj44 NF0gZGF0dW0gZGVjaW1hbCBkZWdyZWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGNvb3JkaW5hdGVzIG9mIHRoZSBjb2xsZWN0b3IgaW4gV0dTODQgW1dHUzxzcGFuIGNsYXNz PSJpbnNlcnQiPi08L3NwYW4+ODRdIGRhdHVtIGRlY2ltYWwgZGVncmVlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3JtYXQgc3RvcmVk IGFzIGEgc2luZ2xlIHByZWNpc2lvbiBmbG9hdCBpbiB0aGUgMzIgYml0cyBhbGxvY2F0ZWQgdG88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3JtYXQgc3RvcmVkIGFzIGEgc2lu Z2xlIHByZWNpc2lvbiBmbG9hdCBpbiB0aGUgMzIgYml0cyBhbGxvY2F0ZWQgdG88L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIENvbGxl Y3RvciBMYXRpdHVkZSBhbmQgQ29sbGVjdG9yIExvbmdpdHVkZS4gIFRoZSBsYXRpdHVkZSBhbmQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgQ29sbGVjdG9yIExhdGl0dWRl IGFuZCBDb2xsZWN0b3IgTG9uZ2l0dWRlLiAgVGhlIGxhdGl0dWRlIGFuZDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMTciIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBsb25naXR1ZGUgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+bWF5PC9zcGFuPiBiZSBhIE5vdCBBIE51bWJlciAoTkFOKSBmb3Igc2l0dWF0aW9u cyB3aGVyZSB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Z2VvLTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbG9uZ2l0dWRlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk1B WTwvc3Bhbj4gYmUgYSBOb3QgQSBOdW1iZXIgKE5BTikgPHNwYW4gY2xhc3M9Imluc2VydCI+W0lF RUU3NTRdPC9zcGFuPiBmb3Igc2l0dWF0aW9ucyB3aGVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAg IGxvY2F0aW9uPC9zcGFuPiBvZiB0aGUgY29sbGVjdG9yIGlzIGNvbnNpZGVyZWQgcHJpdmF0ZS4g IFRoZSBDb2xsZWN0b3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhlIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmdlby1sb2NhdGlvbjwvc3Bhbj4gb2YgdGhlIGNvbGxlY3RvciBp cyBjb25zaWRlcmVkIHByaXZhdGUuICBUaGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBMYXRpdHVkZSBhbmQgQ29sbGVjdG9yIExvbmdp dHVkZSBNVVNUIE5PVCBiZSBhIG1peCBvZiBXR1M4NCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bV0dT IDg0XTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQ29sbGVjdG9y IExhdGl0dWRlIGFuZCBDb2xsZWN0b3IgTG9uZ2l0dWRlIE1VU1QgTk9UIGJlIGEgbWl4IG9mIFdH Uzg0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgZGF0dW0gY29vcmRpbmF0ZSBhbmQgTkFOIHZhbHVlcy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W1dHUy04NF08L3NwYW4+IGRh dHVtIGNvb3JkaW5hdGUgYW5kIE5BTiB2YWx1ZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgICAgICAgICAg ICAgICAgQ29sbGVjdG9yIEJHUCBJRCAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgICAgICAgICAgICAgICBDb2xsZWN0 b3IgQkdQIElEICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgIENv bGxlY3RvciBMYXRpdHVkZSAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICAgICAgICAgICAgICAgICAgQ29sbGVjdG9yIExhdGl0 dWRlICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICAgICAgICAgICAgICAgICBDb2xsZWN0b3Ig TG9uZ2l0dWRlICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgIENvbGxlY3RvciBMb25naXR1ZGUgICAg ICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHwgICAgICAgICAgUGVlciBDb3VudCAgICAgICAgICAgfCAgUGVlciBl bnRyaWVzICh2YXJpYWJsZSk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAg ICAgICAgIFBlZXIgQ291bnQgICAgICAgICAgIHwgIFBlZXIgZW50cmllcyAodmFyaWFibGUpPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDE5IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+Rm9ybWF0IG9mIHRoZSBHRU9fUEVFUl9UQUJMRTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZm9ybWF0IG9mIHRoZSBwZWVyIGVu dHJpZXMgaXMgc2hvd24gYmVsb3cuICBUaGUgUGVlciBUeXBlIGFuZCB0aGU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZm9ybWF0IG9mIHRoZSBwZWVyIGVudHJpZXMgaXMg c2hvd24gYmVsb3cuICBUaGUgUGVlciBUeXBlIGFuZCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUGVlciBCR1AgSUQgaXMgYXMgZGVm aW5lZCBpbiB0aGUgVEFCTEVfRFVNUF9WMiBNUlQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBQZWVyIEJHUCBJRCBpcyBhcyBkZWZpbmVkIGluIHRoZSBUQUJMRV9EVU1QX1YyIE1S VDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBbSS1ELmlldGYtZ3Jvdy1tcnRdIFBFRVJfSU5ERVhfVEFCTEUgZm9ybWF0LiAgVGhlIG9yZGVy IG9mIHRoZSBQZWVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRm LWdyb3ctbXJ0XSBQRUVSX0lOREVYX1RBQkxFIGZvcm1hdC4gIFRoZSBvcmRlciBvZiB0aGUgUGVl cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBlbnRyaWVzIGluIEdFT19QRUVSX1RBQkxFIE1VU1QgbWF0Y2ggdGhlIG9yZGVyIGFuZCBudW1i ZXIgYXMgZXhpc3Rpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBlbnRyaWVz IGluIEdFT19QRUVSX1RBQkxFIE1VU1QgbWF0Y2ggdGhlIG9yZGVyIGFuZCBudW1iZXIgYXMgZXhp c3Rpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgaW4gdGhlIFBFRVJfSU5ERVhfVEFCTEUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgaW4gdGhlIFBFRVJfSU5ERVhfVEFCTEUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjAiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAw ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAg ICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgUGVlciBUeXBlICAgfDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHwgICBQZWVyIFR5cGUgICB8PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICBQZWVyIEJHUCBJRCAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAg ICAgIFBlZXIgQkdQIElEICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgUGVlciBMYXRpdHVkZSAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBQZWVy IExhdGl0dWRlICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgICAg IFBlZXIgTG9uZ2l0dWRlICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgUGVlciBMb25naXR1 ZGUgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAyMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPkZvcm1hdCBvZiBwZWVyIGVudHJpZXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIFBlZXIgTGF0aXR1ZGUgYW5kIFBl ZXIgTG9uZ2l0dWRlIGFyZSB0aGUgZ2VvZ3JhcGhpY2FsIGNvb3JkaW5hdGVzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIFBlZXIgTGF0aXR1ZGUgYW5kIFBlZXIgTG9uZ2l0 dWRlIGFyZSB0aGUgZ2VvZ3JhcGhpY2FsIGNvb3JkaW5hdGVzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAy MiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG9mIHRoZSBwZWVyIGluIFdHUzg0IFtXR1M8c3Bh biBjbGFzcz0iZGVsZXRlIj4gPC9zcGFuPjg0XSBkYXR1bSBkZWNpbWFsIGRlZ3JlZXMgZm9ybWF0 IHN0b3JlZCBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBvZiB0aGUgcGVl ciBpbiBXR1M4NCBbV0dTPHNwYW4gY2xhc3M9Imluc2VydCI+LTwvc3Bhbj44NF0gZGF0dW0gZGVj aW1hbCBkZWdyZWVzIGZvcm1hdCBzdG9yZWQgYXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYSBzaW5nbGUgcHJlY2lzaW9uIGZsb2F0IGlu IHRoZSAzMiBiaXRzIGFsbG9jYXRlZCB0byB0aGUgUGVlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGEgc2luZ2xlIHByZWNpc2lvbiBmbG9hdCBpbiB0aGUgMzIgYml0cyBhbGxv Y2F0ZWQgdG8gdGhlIFBlZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDIzIiAvPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgTGF0aXR1ZGUgYW5kIFBlZXIgTG9uZ2l0dWRlLiAgVGhlIGxhdGl0dWRlIGFuZCBs b25naXR1ZGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bWF5PC9zcGFuPiBiZSBhIE5vdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBMYXRpdHVkZSBhbmQgUGVlciBMb25naXR1ZGUu ICBUaGUgbGF0aXR1ZGUgYW5kIGxvbmdpdHVkZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5NQVk8L3Nw YW4+IGJlIGEgTm90PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgQSBOdW1iZXIgKE5BTikgZm9yIHNpdHVhdGlvbnMgd2hlcmUgdGhlIGdl by1sb2NhdGlvbiBvZiB0aGUgcGVlciBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBBIE51bWJlciAoTkFOKSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bSUVFRTc1NF08L3NwYW4+ IGZvciBzaXR1YXRpb25zIHdoZXJlIHRoZSBnZW8tbG9jYXRpb24gb2YgdGhlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY29uc2lkZXJl ZCBwcml2YXRlLiAgVGhlIFBlZXIgTGF0aXR1ZGUgYW5kIFBlZXIgTG9uZ2l0dWRlIE1VU1QgTk9U IGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHBlZXIgaXMgY29uc2lkZXJl ZCBwcml2YXRlLiAgVGhlIFBlZXIgTGF0aXR1ZGUgYW5kIFBlZXIgTG9uZ2l0dWRlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYSBtaXgg b2YgV0dTODQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+W1dHUyA4NF08L3NwYW4+IGRhdHVtIGNvb3Jk aW5hdGUgYW5kIE5BTiB2YWx1ZXMgZm9yIGEgc2luZ2xlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIE1VU1QgTk9UIGJlIGEgbWl4IG9mIFdHUzg0IDxzcGFuIGNsYXNzPSJpbnNl cnQiPltXR1MtODRdPC9zcGFuPiBkYXR1bSBjb29yZGluYXRlIGFuZCBOQU4gdmFsdWVzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgUGVl ci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZm9yIGEgc2luZ2xlIFBlZXIu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjQiIC8+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj40Ljwvc3Bhbj4gIEFja25v d2xlZGdlbWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+NC4yLiAgR0VPX1BFRVJfVEFCTEUgYW5kIHBlZXIgZW50cnkgdmFsdWVzLjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICBDb2xsZWN0b3IgQkdQIElEOiBEZWZpbmVkIGluIHRoZSBNUlQgZm9ybWF0IFtJLUQu aWV0Zi1ncm93LW1ydF08L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgQ29sbGVjdG9yIExhdGl0dWRlOiBHZW9ncmFwaGlj IGxhdGl0dWRlIG9mIHRoZSBCR1AgY29sbGVjdG9yIGluIFdHUzg0PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBbV0dTLTg0XSBk YXR1bSBkZWNpbWFsIGRlZ3JlZXMgZm9ybWF0IHN0b3JlZCBhcyBhIHNpbmdsZSBwcmVjaXNpb248 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGZsb2F0Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBDb2xsZWN0b3IgTG9uZ2l0dWRlOiBHZW9ncmFwaGlj IExvbmdpdHVkZSBvZiB0aGUgQkdQIGNvbGxlY3RvciBpbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgV0dTODQgW1dHUy04NF0g ZGF0dW0gZGVjaW1hbCBkZWdyZWVzIGZvcm1hdCBzdG9yZWQgYXMgYSBzaW5nbGU8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHBy ZWNpc2lvbiBmbG9hdC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgUGVlciBDb3VudDogRGVmaW5lZCBpbiB0aGUgTVJU IGZvcm1hdCBbSS1ELmlldGYtZ3Jvdy1tcnRdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFBlZXIgZW50cmllczogRGVm aW5lZCBpbiB0aGUgTVJUIGZvcm1hdCBbSS1ELmlldGYtZ3Jvdy1tcnRdPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBQZWVyIFR5 cGU6IERlZmluZWQgaW4gdGhlIE1SVCBmb3JtYXQgW0ktRC5pZXRmLWdyb3ctbXJ0XTwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICBQZWVyIEJHUCBJRDogRGVmaW5lZCBpbiB0aGUgTVJUIGZvcm1hdCBbSS1ELmlldGYtZ3Jv dy1tcnRdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIFBlZXIgTGF0aXR1ZGU6IEdlb2dyYXBoaWMgbGF0aXR1ZGUgb2Yg dGhlIEJHUCBwZWVyIGluIFdHUzg0IFtXR1MtODRdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBkYXR1bSBkZWNpbWFsIGRlZ3Jl ZXMgZm9ybWF0IHN0b3JlZCBhcyBhIHNpbmdsZSBwcmVjaXNpb24gZmxvYXQuPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IFBlZXIgTG9uZ2l0dWRlOiBHZW9ncmFwaGljIExvbmdpdHVkZSBvZiB0aGUgQkdQIHBlZXIgaW4g V0dTODQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIFtXR1MtODRdIGRhdHVtIGRlY2ltYWwgZGVncmVlcyBmb3JtYXQgc3RvcmVk IGFzIGEgc2luZ2xlIHByZWNpc2lvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZmxvYXQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjUuICBCR1AgQ29s bGVjdG9yIENvbnN0cnVjdGlvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBUaGlzIHNlY3Rpb24gaXMgdG8gYWlkZSB0 aGUgcmVhZGVyIGluIHVuZGVyc3RhbmRpbmcgdGhlIGZ1bmN0aW9uIG9mIGE8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEJHUCBj b2xsZWN0b3IuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoZSBCR1AgQ29sbGVjdG9yIGlzIGEgZGV2aWNlIChoYXJk d2FyZSBvciBzb2Z0d2FyZSBiYXNlZCkgd2hpY2g8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHNwZWFrcyB0aGUgQm9yZGVyIEdh dGV3YXkgUHJvdG9jb2wgYW5kIGl0cyBpbnRlbmRlZCBmdW5jdGlvbiBpcyB0bzwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgc3Rv cmUgKGFuZCBhcmNoaXZlKSB0aGUgQkdQIHJvdXRpbmcgZGF0YSBpdCByZWNlaXZlcyBmcm9tIG90 aGVyIEJHUDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgc3BlYWtlcnMgaXQgaGFzIHBlZXJpbmcgcmVsYXRpb25zaGlwcyB3aXRo LCBwcm92aWRpbmcgZGF0YSBmb3IgbGF0ZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGFuYWx5c2lzLiAgVGhlIGdlbmVyYWwg bmF0dXJlIG9mIGEgQkdQIENvbGxlY3RvciBpcyB0aGF0IGl0IGlzIGE8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHBhc3NpdmUg ZGV2aWNlIGluIHRoYXQgaXQgbGlzdGVucyB0byByb3V0ZSB1cGRhdGVzLCBhbmQgZG9lcyBub3Q8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGFubm91bmNlIG5vciBwcm9wYWdhdGUgYW55IGluZm9ybWF0aW9uIGl0IGtub3dzIG9y IHJlY2VpdmVzLiAgSXQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIHNob3VsZCBiZSBub3RlZCB0aGF0IHRoaXMgaXMgbm90IGFs d2F5cyB0aGUgY2FzZSwgbmV0d29yayBvcGVyYXRvcnM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHNvbWV0aW1lcyBlbmFibGUg dGhlIGNvbGxlY3Rpb24gb2YgQkdQIHJvdXRpbmcgZGF0YSBvbiBhY3RpdmUgQkdQPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBz cGVha2VycyB0byBvYnRhaW4gYSBzaXR1YXRpb25hbCB2aWV3IG9mIHRoZSByb3V0aW5nIHN5c3Rl bSBhcyB0aGV5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBzZWUgaXQgYXQgYSBwYXJ0aWN1bGFyIHBvaW50IGluIHRpbWUuPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIEFzIGEgZnVsbHkgZmxlZGdlZCBCR1Agc3BlYWtlciB0aGUgQkdQIENvbGxlY3Rv ciBjYW4gZml0IGludG8gYW55IEJHUDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdG9wb2xvZ3kgaW5jbHVkaW5nIGlCR1AsIGVC R1AsIGFuZCBzbyBvbi4gIFRoZSBpbXBsZW1lbnRhdGlvbiBvZiBhPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBCR1AgY29sbGVj dG9yIGluIGEgbmV0d29yayB0b3BvbG9neSBpcyB0aGVyZWZvcmUgbGltaXRlZCBieSB0aGF0PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICBuZXR3b3JrJ3MgdXNlIG9mIEJHUC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+Ni48L3NwYW4+ICBBY2tub3dsZWRn ZW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGFua3MgdG8gQW5kcmV3IENs YXJrLCBFcm5lc3QgRm9vLCBEYXZlIE1leWVyLCBMYXJyeSBCbHVjaywgUmljaGFyZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoYW5rcyB0byBBbmRyZXcgQ2xhcmssIEVybmVz dCBGb28sIERhdmUgTWV5ZXIsIExhcnJ5IEJsdWNrLCBSaWNoYXJkPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJhcm5lcywgYW5kIEplZmZy ZXkgSGFhcyBmb3IgcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgQmFybmVzLCBhbmQgSmVmZnJleSBIYWFzIGZvciByZXZpZXdpbmcgdGhp cyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgc21hbGwgcG9ydGlvbiBvZiB0aGUgcmVzZWFyY2ggdG93YXJkcyB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IHNtYWxsIHBvcnRpb24gb2YgdGhlIHJlc2VhcmNoIHRvd2FyZHMgdGhlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhvcidzIFBoRC48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdXRob3IncyBQaEQuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjUiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj41Ljwvc3Bhbj4gIElBTkEgQ29uc2lkZXJh dGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+Ny48L3NwYW4+ICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGlzIHNl Y3Rpb24gcmVxdWVzdHMgdGhlIEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IChJ QU5BKTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgcmVnaXN0ZXIgdGhlIGFkZGl0aW9uYWwgU3VidHlwZSBjb2RlIHZhbHVlIGFz Ojwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICAgICAgNyAgICBHRU9fUEVFUl9UQUJMRTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMjYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5pbiB0aGUgIk1SVCBmb3JtYXQiIFtJLUQuaWV0Zi1ncm93LW1ydF0gYW5kIFN1YnR5 cGUgY29kZSB2YWx1ZXM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gcmVxdWVzdDwvc3Bh bj4gdG8gPHNwYW4gY2xhc3M9Imluc2VydCI+SUFOQTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICByZWxhdGVkPC9zcGFuPiB0byA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGUgVEFCTEVfRFVN UF92MiB0eXBlIGluIHRoZSBNUlQgbmFtZXNwYWNlLCBpbiBhY2NvcmRhbmNlPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICB3aXRo IEJDUCAyNiwgUkZDIDUyMjYgW1JGQzUyMjZdLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMjciIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9z cGFuPi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZXh0ZW5zaW9uIHRvIHRo ZSAiTVJUIGZvcm1hdCIgW0ktRC5pZXRmLWdyb3ctbXJ0XSBkZWZpbmVzIGZpZWxkczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZXh0ZW5zaW9uIHRvIHRoZSAiTVJUIGZv cm1hdCIgW0ktRC5pZXRmLWdyb3ctbXJ0XSBkZWZpbmVzIGZpZWxkczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0IGFyZSBvZiBhIGRl c2NyaXB0aXZlIG5hdHVyZSBhbmQgcHJvdmlkZSBpbmZvcm1hdGlvbiB0aGF0IGlzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhhdCBhcmUgb2YgYSBkZXNjcmlwdGl2ZSBuYXR1 cmUgYW5kIHByb3ZpZGUgaW5mb3JtYXRpb24gdGhhdCBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2VmdWwgaW4gdGhlIGFuYWx5c2lz IG9mIHJvdXRpbmcgc3lzdGVtcy4gIEFzIHN1Y2gsIHRoZSBhdXRob3I8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB1c2VmdWwgaW4gdGhlIGFuYWx5c2lzIG9mIHJvdXRpbmcgc3lz dGVtcy4gIEFzIHN1Y2gsIHRoZSBhdXRob3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmVsaWV2ZXMgdGhhdCB0aGV5IGRvIG5vdCBjb25z dGl0dXRlIGFuIGFkZGl0aW9uYWwgc2VjdXJpdHkgcmlzay4gIEl0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgYmVsaWV2ZXMgdGhhdCB0aGV5IGRvIG5vdCBjb25zdGl0dXRlIGFu IGFkZGl0aW9uYWwgc2VjdXJpdHkgcmlzay4gIEl0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyOCIgLz48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIG9wZXJhdG9ycyBv ZiB0aGUgQkdQIGNvbGxlY3RvciBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+UDwvc3Bhbj5lZXJz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGlzIHJlY29tbWVuZGVkIHRoYXQg dGhlIG9wZXJhdG9ycyBvZiB0aGUgQkdQIGNvbGxlY3RvciBhbmQgPHNwYW4gY2xhc3M9Imluc2Vy dCI+QkdQIHA8L3NwYW4+ZWVyczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25zaWRlciB0aGVpciBvd24gcHJpdmFjeSBjb25jZXJucyBi ZWZvcmUgc3VwcGx5aW5nIGdlb2dyYXBoaWNhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGNvbnNpZGVyIHRoZWlyIG93biBwcml2YWN5IGNvbmNlcm5zIGJlZm9yZSBzdXBwbHlp bmcgZ2VvZ3JhcGhpY2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyOSIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGNvb3JkaW5hdGVzIDxzcGFuIGNsYXNzPSJkZWxldGUiPmluIE1SVCBkdW1wPC9zcGFu PnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGNvb3JkaW5hdGVzIDxzcGFu IGNsYXNzPSJpbnNlcnQiPnRvIEJHUCBkYXRhIGNvbGxlY3Rpb24gc3lzdGVtPC9zcGFuPnMuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzAiIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj43PC9zcGFuPi4gIFJlZmVyZW5j ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ OTwvc3Bhbj4uICBSZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMzEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj43PC9zcGFuPi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj4uMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtZ3Jv dy1tcnRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWdyb3ct bXJ0XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgIEJsdW5rLCBMLiwgS2FyaXIsIE0uLCBhbmQgQy4gTGFib3ZpdHosICJN UlQgcm91dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg Qmx1bmssIEwuLCBLYXJpciwgTS4sIGFuZCBDLiBMYWJvdml0eiwgIk1SVCByb3V0aW5nPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAzMiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgaW5m b3JtYXRpb24gZXhwb3J0IGZvcm1hdCIsIDxzcGFuIGNsYXNzPSJkZWxldGUiPmRyYWZ0LWlldGYt Z3Jvdy1tcnQtMTM8L3NwYW4+ICh3b3JrPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgICAgICAgICAgaW5mb3JtYXRpb24gZXhwb3J0IGZvcm1hdCIsIDxzcGFuIGNsYXNzPSJp bnNlcnQiPmRyYWZ0LWlldGYtZ3Jvdy1tcnQtMTQ8L3NwYW4+ICh3b3JrPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBp biBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJkZWxldGUiPlNlcHRlbWJlciAyMDEwLjwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICBpbiBwcm9ncmVz cyksIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFwcmlsIDIwMTEuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3Ig dXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJ bmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks IE1hcmNoIDE5OTcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzQyNzFdICBSZWtodGVyLCBZLiwgTGksIFQu LCBhbmQgUy4gSGFyZXMsICJBIEJvcmRlciBHYXRld2F5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgW1JGQzQyNzFdICBSZWtodGVyLCBZLiwgTGksIFQuLCBhbmQgUy4gSGFyZXMs ICJBIEJvcmRlciBHYXRld2F5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUHJvdG9jb2wgNCAoQkdQLTQpIiwgUkZDIDQy NzEsIEphbnVhcnkgMjAwNi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgIFByb3RvY29sIDQgKEJHUC00KSIsIFJGQyA0MjcxLCBKYW51YXJ5IDIwMDYuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzMiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bUkZDNDc2MF0gIEJhdGVzLCBU LiwgQ2hhbmRyYSwgUi4sIEthdHosIEQuLCBhbmQgWS4gUmVraHRlciw8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjkuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAg ICAiTXVsdGlwcm90b2NvbCBFeHRlbnNpb25zIGZvciBCR1AtNCIsIFJGQyA0NzYwLDwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg ICAgICAgICAgICBKYW51YXJ5IDIwMDcuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFtSRkM1MjI2XSAgTmFydGVuLCBU LiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW48L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAg ICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJG QyA1MjI2LDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICBNYXkgMjAwOC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDM0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+Ny4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W0lFRUU3NTRdICBJRUVFLCAi SUVFRSBTdGFuZGFyZCBmb3IgRmxvYXRpbmctUG9pbnQgQXJpdGhtZXRpYyIsPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAg ICAgICAgIEF1Z3VzdCAyMDA4LDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL2llZWV4cGxv cmUuaWVlZS5vcmcvc2VydmxldC88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgb3BhYz9wdW51bWJlcj00NjEw OTMzJmd0Oy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwMzUiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBbTVJUPHNwYW4gY2xhc3M9ImRl bGV0ZSI+IFBST0cgPC9zcGFuPkdVSURFXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBbTVJUPHNwYW4gY2xhc3M9Imluc2VydCI+LTwvc3Bhbj5HVUlERV08L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBM YWJvdml0eiwgQy4sICJNUlQgUHJvZ3JhbW1lcidzIEd1aWRlIiwgTm92ZW1iZXIgMTk5OSw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIExhYm92aXR6LCBDLiwg Ik1SVCBQcm9ncmFtbWVyJ3MgR3VpZGUiLCBOb3ZlbWJlciAxOTk5LDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICZsdDto dHRwOi8vd3d3Lm1lcml0LmVkdS9uZXR3b3JrcmVzZWFyY2gvbXJ0cHJvZ3JhbW1lci5wZGYmZ3Q7 LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgJmx0O2h0dHA6 Ly93d3cubWVyaXQuZWR1L25ldHdvcmtyZXNlYXJjaC9tcnRwcm9ncmFtbWVyLnBkZiZndDsuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzYiIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBbV0dTPHNwYW4gY2xhc3M9ImRlbGV0ZSI+IDwvc3Bhbj44NF0g ICBHZW9kZXN5IGFuZCBHZW9waHlzaWNzIERlcGFydG1lbnQsIERvRC4sICJXb3JsZCBHZW9kZXRp YzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBbV0dTPHNwYW4gY2xhc3M9Imlu c2VydCI+LTwvc3Bhbj44NF0gICBHZW9kZXN5IGFuZCBHZW9waHlzaWNzIERlcGFydG1lbnQsIERv RC4sICJXb3JsZCBHZW9kZXRpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIFN5c3RlbSAxOTg0IiwgSmFudWFyeSAyMDAw LCAmbHQ7aHR0cDovL2VhcnRoLWluZm8ubmdhLm1pbC88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgIFN5c3RlbSAxOTg0IiwgSmFudWFyeSAyMDAwLCAmbHQ7aHR0 cDovL2VhcnRoLWluZm8ubmdhLm1pbC88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBHYW5kRy9wdWJsaWNhdGlvbnMvdHI4 MzUwLjIvd2dzODRmaW4ucGRmJmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgIEdhbmRHL3B1YmxpY2F0aW9ucy90cjgzNTAuMi93Z3M4NGZpbi5wZGYmZ3Q7 LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QXV0aG9yJ3MgQWRkcmVzczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkF1dGhvcidzIEFkZHJlc3M8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFRlcnJ5IE1hbmRlcnNvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRlcnJ5IE1hbmRlcnNvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJQ0FOTjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIElDQU5OPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFbWFpbDogdGVycnku bWFuZGVyc29uQGljYW5uLm9yZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVt YWlsOiB0ZXJyeS5tYW5kZXJzb25AaWNhbm4ub3JnPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAg IDx0ciBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+PGEgbmFt ZT0iZW5kIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMzYgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8L2E+ PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT44NSBsaW5l cyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48aT4xNjMg bGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0 ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1s IGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS40MS4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMv cmZjZGlmZi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+ PC90cj4KICAgPC90YWJsZT4KICAgPC9ib2R5PgogICA8L2h0bWw+Cg== --_002_C9DF2F6011ECDterrymandersonicannorg_--