From nobody Tue May 2 11:16:32 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB635129C04 for ; Tue, 2 May 2017 11:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV9vX3VwyAE2 for ; Tue, 2 May 2017 11:16:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF23129C15 for ; Tue, 2 May 2017 11:13:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3C6083004FE for ; Tue, 2 May 2017 14:13:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f75FPC9QFMKU for ; Tue, 2 May 2017 14:13:38 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D8DED3004B6 for ; Tue, 2 May 2017 14:13:38 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> Date: Tue, 2 May 2017 14:13:38 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:16:30 -0000 Tools Call Agenda -- 9 May 2017 at 1:00 Eastern JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=3Dm440dd848726339c03e605b9956e38bac= Meeting number (access code): 640 103 570 Meeting password: tools JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada)=20 1-650-479-3208 Call-in toll number (US/Canada) Meeting number (access code): 640 103 570 Meeting password: tools 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - Volunteer Enhancements -- Submit an I-D directly from GitHub -- Unknown -- Integrate downref registry with IETF Last Call -- Russ - Contracts for Datatracker Enhancements -- Robert -- Author Statistics 2. Community & Other Projects - Improvements to the mail archive application -- Robert and Ryan - IETF Website Makeover -- Greg and Russ 3. RFC Services Projects - RFC Format Contracts -- Heather and Robert -- IDnits -- Publication Formatter -- RFClint -- SVGcheck -- Text Submission -- XMLdiff 4. Server Infrastructure - IESG discussions of DMARC -- Robert and Alexey -- Mailman upgrade -- Impact on Internet-Draft-specific mail aliases - Libraries for HTML of I-Ds -- Henrik 5. Parking Lot - Migrate to Django 1.11 when it is released -- Henrik - Migrate from Python 2.7 to Pyton 3 - CDN support for HTML and PDF I-Ds -- Henrik - Migrate from MySQL to PostgreSQL -- Henrik - Discontinue MonArch email archives -- Robert - Improve infrastructure for finding and fetching artifacts -- Robert - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Performance improvements and transition to Postgres -- Henrik - VM Architecture for Servers -- Robert - Add view of recent ballots by telechat to - Allow meetecho to associate recordings with sessions as they become = available - Mailman support for internationalized email addresses -- Requires Mailman 3.1, which is expected in early 2017 - Meeting registration support for internationalized email addresses -- Mailman must be done first; user is added to meeting mail lists 6. AOB From nobody Sun May 7 05:08:03 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3A127058 for ; Sun, 7 May 2017 05:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=N5lLh1th; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E10zFHyc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl3M5Ey_QxNW for ; Sun, 7 May 2017 05:07:59 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDFA12420B for ; Sun, 7 May 2017 05:07:59 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 03ED1208A9 for ; Sun, 7 May 2017 08:07:59 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Sun, 07 May 2017 08:07:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=SeumVXULRFMu3aGEiJTzL5mFQokwFxiYOvKEtVOvFW4=; b=N5lLh1th az7HpBFXB362eKpTDu2ricKr+yjJ+yOMQJfHtb/IQXxVh74aoRLqjTJ2P6iXmm3l UpEAPAmRjNLhjSRi1PmFauDHnqxQxIksgWHpl8Tyi2bh6fqsxDx7sYSG7x4yUGvs 9KQoMs4Z3kuYO/pirDgBzosgNsYt1mYmEl1lQWQEsnM1QFWNx9z4exYq0C3tHpou 0xr6gTRpgP9Cfzvm8McWQH07RWn1v0eLz5gRLRI56fDKyDY2cjIfiK0nLY/lrv/r 3+ZcgXmT+FhcqB/hmaeZisHUS38utjDhWKmFXJGZHWSHZI3c97sLjrlKqPiUKGIW X1q5qJGb3G1SXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=SeumVXULRFMu3aGEiJTzL5mFQokwF xiYOvKEtVOvFW4=; b=E10zFHycG3BKsBKbGqG4cEEYmuZcMvtxGGqtCOVFSIYNx R+wAXY2hcfcA/0TVoYM8+IV4X9TIwj9C2SVnVT7y+rMrb4wby2C/E3uwhyXJl9IG N3OmIRtQYA7HGcQ8zBXA7FIpgI9F6FTpKzw08zF7z4GyYDcYZG80yu+TG8whgaon APKCclTUX2hRKX9mDrYk4ULSOnoRd1QFGHszhKxhN1kkGeCVxsrdBtfwa3NgdZ/X Hj+DTRNHEvL8umowRlfginbJHfvBfmWln7EPCkWXaAoxZ9BvwvBuDhaB60lmABhl n4bkKod2aFm9yxGBsDwnzVPsD2cFjc13bTWFQ/bFQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CF14A62704; Sun, 7 May 2017 08:07:58 -0400 (EDT) Message-Id: <1494158878.2009619.968436408.566F6F8B@webmail.messagingengine.com> From: Alexey Melnikov To: tools-development@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 Date: Sun, 07 May 2017 13:07:58 +0100 Archived-At: Subject: [TOOLS-DEVELOPMENT] WG mailing lists that agreed to test DMARC work-arounds X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 12:08:02 -0000 Hi everyone, WG chairs of the following mailing lists agreed to participate in DMARC workaround testing: id-events pals dmarc quic Suggestions on which mailing list we should or should not use for testing of From header field rewriting are welcome. Thank you, Alexey From nobody Mon May 8 11:07:46 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB36C12896F for ; Mon, 8 May 2017 11:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-5rWML7gV-T for ; Mon, 8 May 2017 11:07:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FC9128796 for ; Mon, 8 May 2017 11:07:43 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v48I7gTV008074 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 8 May 2017 13:07:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: tools-development@ietf.org References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> From: Robert Sparks Message-ID: <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> Date: Mon, 8 May 2017 13:07:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:07:45 -0000 Notes for tomorrow's call On 5/2/17 1:13 PM, Russ Housley wrote: > Tools Call Agenda -- 9 May 2017 at 1:00 Eastern > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m440dd848726339c03e605b9956e38bac > Meeting number (access code): 640 103 570 > Meeting password: tools > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Meeting number (access code): 640 103 570 > Meeting password: tools > > > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan > - Volunteer Enhancements > -- Submit an I-D directly from GitHub -- Unknown Henrik and I can talk to this going forward. The status right now is that it's waiting for cycles - Henrik and I need to have a design conversation, and then follow up with Martin to make sure where we're going to go matches expectations. > -- Integrate downref registry with IETF Last Call -- Russ > - Contracts for Datatracker Enhancements -- Robert > -- Author Statistics The remaining meeting statistics portion has been added. I expect we will merge and deploy this soon. Note that early testing highlights again that our older documentauthor information is often wrong. I've been working towards improving that for RFCs. What I'm learning there will inform how we try to make things better for older drafts. > > 2. Community & Other Projects > - Improvements to the mail archive application -- Robert and Ryan The project for this round of improvements is complete. Ryan has demonstrated that the URL redirection code (for when we are eventually able to move away from mhonarc) is functioning correctly using the testlist. > - IETF Website Makeover -- Greg and Russ > > 3. RFC Services Projects > - RFC Format Contracts -- Heather and Robert > -- IDnits > -- Publication Formatter > -- RFClint > -- SVGcheck > -- Text Submission > -- XMLdiff The first deliverable for the text submission conversion tool is very close to ready to test. Work on SVGcheck is still just beginning. > > 4. Server Infrastructure > - IESG discussions of DMARC -- Robert and Alexey > -- Mailman upgrade > -- Impact on Internet-Draft-specific mail aliases This is nearing the head of Henrik's queue. > - Libraries for HTML of I-Ds -- Henrik > > 5. Parking Lot > - Migrate to Django 1.11 when it is released -- Henrik > - Migrate from Python 2.7 to Pyton 3 > - CDN support for HTML and PDF I-Ds -- Henrik > - Migrate from MySQL to PostgreSQL -- Henrik > - Discontinue MonArch email archives -- Robert > - Improve infrastructure for finding and fetching artifacts -- Robert > - Author information for very old I-Ds in the datatracker -- Robert > - Replace I-Ds in proceedings with links to archive copy? > - Performance improvements and transition to Postgres -- Henrik > - VM Architecture for Servers -- Robert > - Add view of recent ballots by telechat to > - Allow meetecho to associate recordings with sessions as they become available > - Mailman support for internationalized email addresses > -- Requires Mailman 3.1, which is expected in early 2017 > - Meeting registration support for internationalized email addresses > -- Mailman must be done first; user is added to meeting mail lists > > 6. AOB > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon May 8 11:48:00 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87DF128CDB for ; Mon, 8 May 2017 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfc_EY1SKS2V for ; Mon, 8 May 2017 11:47:57 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E4E128B51 for ; Mon, 8 May 2017 11:47:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 82E821CA0FC for ; Mon, 8 May 2017 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzK9l6JSqmV9 for ; Mon, 8 May 2017 11:47:44 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (c-50-159-75-65.hsd1.wa.comcast.net [50.159.75.65]) by c8a.amsl.com (Postfix) with ESMTPSA id 572491CA0FA for ; Mon, 8 May 2017 11:47:44 -0700 (PDT) To: tools-development@ietf.org References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> From: "Heather Flanagan (RFC Series Editor)" Message-ID: <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> Date: Mon, 8 May 2017 11:47:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> Content-Type: multipart/alternative; boundary="------------48D503C73AD6D6E5A0C4C2A5" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:47:59 -0000 This is a multi-part message in MIME format. --------------48D503C73AD6D6E5A0C4C2A5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/8/17 11:07 AM, Robert Sparks wrote: >> >> 3. RFC Services Projects >> - RFC Format Contracts -- Heather and Robert >> -- IDnits >> -- Publication Formatter >> -- RFClint >> -- SVGcheck >> -- Text Submission >> -- XMLdiff > The first deliverable for the text submission conversion tool is very > close to ready to test. > Work on SVGcheck is still just beginning. I've also asked Sandy to report on the call what she's discovered so far wrt testing non-ASCII characters in the existing environment. -Heather --------------48D503C73AD6D6E5A0C4C2A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/8/17 11:07 AM, Robert Sparks wrote:

3. RFC Services Projects
    - RFC Format Contracts -- Heather and Robert
      -- IDnits
      -- Publication Formatter
      -- RFClint
      -- SVGcheck
      -- Text Submission
      -- XMLdiff
The first deliverable for the text submission conversion tool is very close to ready to test.
Work on SVGcheck is still just beginning.


I've also asked Sandy to report on the call what she's discovered so far wrt testing non-ASCII characters in the existing environment.


-Heather

--------------48D503C73AD6D6E5A0C4C2A5-- From nobody Tue May 9 09:40:50 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0655129B3F for ; Tue, 9 May 2017 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CtFaJpF4wiv for ; Tue, 9 May 2017 09:40:48 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409721279EB for ; Tue, 9 May 2017 09:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 35E6D1CA0B4; Tue, 9 May 2017 09:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G69Rcz_yGuP3; Tue, 9 May 2017 09:40:34 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id 0994A1CA0A7; Tue, 9 May 2017 09:40:34 -0700 (PDT) From: Sandy Ginoza Message-Id: <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8CEE5E72-1633-4458-A659-2BADAE7B34EE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 09:40:46 -0700 In-Reply-To: <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> Cc: tools-development@ietf.org To: "Heather Flanagan (RFC Series Editor)" References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:40:50 -0000 --Apple-Mail=_8CEE5E72-1633-4458-A659-2BADAE7B34EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On May 8, 2017, at 11:47 AM, Heather Flanagan (RFC Series Editor) = wrote: >=20 > On 5/8/17 11:07 AM, Robert Sparks wrote: >>>=20 >>> 3. RFC Services Projects=20 >>> - RFC Format Contracts -- Heather and Robert=20 >>> -- IDnits=20 >>> -- Publication Formatter=20 >>> -- RFClint=20 >>> -- SVGcheck=20 >>> -- Text Submission=20 >>> -- XMLdiff=20 >> The first deliverable for the text submission conversion tool is very = close to ready to test.=20 >> Work on SVGcheck is still just beginning. >=20 > I've also asked Sandy to report on the call what she's discovered so = far wrt testing non-ASCII characters in the existing environment. >=20 The nroff program (make file) we use reads the user's environment. When = the variable LANGUAGE is set to utf-8, nroff converts the ' and - = characters (and probably some others) to their 'pretty' utf-8 = equivalents. This is the default behavior for nroff when the LANGUAGE = variable is set. Some browsers are OK with the resulting text file, as = they assume utf-8 encoding when they see extended characters without = explicit encoding (i.e. Google Chrome). Other browsers assume that .txt = files will be encoded with ASCII and print odd characters when they hit = non-ASCII characters in a .txt file (i.e, Safari). To continue with testing we have created a copy of our make file that = produces ASCII only when the LANGUAGE variable is set to UTF-8. I need = to do more testing and understand whether it=E2=80=99s possible (with = our current tools) to create a .txt file with UTF-8 that does not = automatically convert the =E2=80=98 and - characters to their UTF-8 = forms (because UTF-8 chars are only supposed to appear where needed). = I also need to see what the output looks like using the sed command = Henrik provided that adds the BOM. Talk to you all soon. Sandy >=20 > -Heather > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_8CEE5E72-1633-4458-A659-2BADAE7B34EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

On May 8, 2017, at 11:47 AM, Heather Flanagan = (RFC Series Editor) <rse@rfc-editor.org> wrote:

=20 =20
On 5/8/17 11:07 AM, Robert Sparks wrote:

3. RFC Services Projects
    - RFC Format Contracts -- Heather and Robert
      -- IDnits
      -- Publication Formatter
      -- RFClint
      -- SVGcheck
      -- Text Submission
      -- XMLdiff
The first deliverable for the text submission conversion tool is very close to ready to test.
Work on SVGcheck is still just beginning.


I've also asked Sandy to report on the call what = she's discovered so far wrt testing non-ASCII characters in the existing environment.

The = nroff program (make file) we use reads the user's environment. =  When the variable LANGUAGE is set to utf-8, nroff converts the ' = and - characters (and probably some others) to their 'pretty' utf-8 = equivalents.  This is the default behavior for nroff when the = LANGUAGE variable is set.  Some browsers are OK with the resulting = text file, as they assume utf-8 encoding when they see extended = characters without explicit encoding (i.e. Google Chrome).  Other = browsers assume that .txt files will be encoded with ASCII and print odd = characters when they hit non-ASCII characters in a .txt file (i.e, = Safari).

To = continue with testing we have created a copy of our make file that = produces ASCII only when the LANGUAGE variable is set to UTF-8.  I = need to do more testing and understand whether it=E2=80=99s possible = (with our current tools) to create a .txt file with UTF-8 that does not = automatically convert the =E2=80=98 and - characters to their UTF-8 = forms (because UTF-8 chars are only supposed to appear where needed). =   I also need to see what the output looks like using the sed = command Henrik provided that adds the BOM.

Talk to you all soon.

Sandy



-Heather

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

= --Apple-Mail=_8CEE5E72-1633-4458-A659-2BADAE7B34EE-- From nobody Tue May 9 10:59:33 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAA312AF77 for ; Tue, 9 May 2017 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjas6nET8pjF for ; Tue, 9 May 2017 10:59:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7C6129524 for ; Tue, 9 May 2017 10:59:30 -0700 (PDT) Received: from [192.168.178.20] ([93.217.101.68]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MPlY2-1d3DSk2HWU-0052bt; Tue, 09 May 2017 19:59:12 +0200 To: Sandy Ginoza , "Heather Flanagan (RFC Series Editor)" References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> Cc: tools-development@ietf.org From: Julian Reschke Message-ID: <27e59d14-7aa9-876a-e628-2fd175f8338a@gmx.de> Date: Tue, 9 May 2017 19:59:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:6K4sz0fE4+S5rMKjf7LmscDwYHL9RRKl9YRkI1vsUJyLX3krNuD 3uE/kcTAImiIfMnurI02jo5L36xqJLNtdkHWbdEaDQwFfJ/xjdOfSguvz6ZCdhbF8H2QL00 8Eo0JSS57UhUgwljoSlnBWcMFbvHSVEgrvxIv7dNgoaPZ4cJHRTC7xM1Bk9M8o0SOi0llRb XYyNNEjbv8hYGoXNb1A0w== X-UI-Out-Filterresults: notjunk:1;V01:K0:OukT4uteAXI=:7X+GCbhTH78nGAL2S8/6n5 95ZJ6xe+3e9WdrOQ8OUoS1IZ5eilo7j/yorLvnqYJJGBZvuiTM7PtXyFFaUt+wAGVWbvmfxnl w9G3VFKtYJzElsRM4z6ZEjF4GvD22SjbyAXwXy8rEULC0QjhMZdABg4A7z3qsclTqLdeav1qW zjSyyIqfGjWK7Vft/uL57wR/ezdwg+7iZY43dO7j3G9b+KkkmrxoX5CZGvEMhlYAwkMhc+xiv tTC7DWJICfH2riiUxrGKXAXLPwqvuQaVwCbOT0NVQhNebdAdXLNi4ySUHKVxImmHt02SLB6iy wGSTyCNCfZZj7xZXfaMn58/eqxrcm13+NwEbIVuk8oxbIHKnoZJK2WEb/lMNZ4ES466xwOluK +fnfwbw6UD2yDGq61SBeevHJMVYjtuSsUpuusz7Qu2erkRBGLIcTVH5YDcRPrBSPPYTKaUStX MYE1hQiF1x3Lccy+rmQy5BF/2TVK3HGuccJdICX2JsF5910AN1zDxg5A2Yh/vOU+AqwoU+9AO Go74NNmqZRmOlKU3NDXVe+LWTbSt5wWzFpN5QuwA15B8OimjbYQQK7E+i/ybP+8yZ3GDcgKrR 6z9T4HsLX24ij9uHo8tE0ZaM0rZ0YqSrkMVbEOEYcXGuAvFC+DfAcV3AUCLrdujVmR631BjYR XDAj4/Qhz/WCs5kKsV+Czu0OxWFO7u4WOzY/LVmCayOxVCXpOmZHyovqhQZci82puA9IGoItt ej5z7rYQjLMsRNGkGZR4WYcCVhmgNeZvWPmiwmJdrs2zhoTJJaWZI92dD7SsG1yf7E1acFnYM d3MMQ2f Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:59:32 -0000 On 2017-05-09 18:40, Sandy Ginoza wrote: > ... > To continue with testing we have created a copy of our make file that > produces ASCII only when the LANGUAGE variable is set to UTF-8. I need > to do more testing and understand whether it’s possible (with our > current tools) to create a .txt file with UTF-8 that does not > automatically convert the ‘ and - characters to their UTF-8 forms > (because UTF-8 chars are only supposed to appear where needed). I also > need to see what the output looks like using the sed command Henrik > provided that adds the BOM. > > Talk to you all soon. > ... This: https://github.com/fish-shell/fish-shell/issues/2673#issuecomment-254925374 might be related... From nobody Tue May 9 11:17:54 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA83129537 for ; Tue, 9 May 2017 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV28k24dL6mz for ; Tue, 9 May 2017 11:17:52 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0584A129535 for ; Tue, 9 May 2017 11:17:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D90E61CA0B5; Tue, 9 May 2017 11:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGywtvh-CIJd; Tue, 9 May 2017 11:17:37 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id AC4181C1B55; Tue, 9 May 2017 11:17:37 -0700 (PDT) From: Sandy Ginoza Message-Id: <31C69CE8-F80C-4AE1-A34B-F8D12F309E3F@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A2442F85-4CF3-496B-8CDB-DD0934110520" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 11:17:51 -0700 In-Reply-To: <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> Cc: tools-development@ietf.org To: "Heather Flanagan (RFC Series Editor)" References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:17:53 -0000 --Apple-Mail=_A2442F85-4CF3-496B-8CDB-DD0934110520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again, > On May 9, 2017, at 9:40 AM, Sandy Ginoza wrote: >=20 > I also need to see what the output looks like using the sed command = Henrik provided that adds the BOM. >=20 Just a few additional comments on this one, as I realize that my = explanation on the call may not have answered the question. The BOM is separate from the issue regarding the make file converting = characters to UTF-8. It is related to this item in that it is a new = step for us and needs to be tested before we can publish files that = include UTF-8. Thanks for the suggestion regarding having a script that converts = specific UTF-8 characters back to ASCII. The obvious ones so far have = been =E2=80=98 (single quote), =E2=80=9C (double quote), and - (hyphen). = I=E2=80=99ll do some more testing to see if other characters are = impacted by this conversion as well, but that may work.=20 Thanks, Sandy= --Apple-Mail=_A2442F85-4CF3-496B-8CDB-DD0934110520 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi again,


On May 9, 2017, at 9:40 AM, = Sandy Ginoza <sginoza@amsl.com> wrote:

I also need = to see what the output looks like using the sed command Henrik provided = that adds the BOM.


Just a few additional comments on this = one, as I realize that my explanation on the call may not have answered = the question.

The BOM is separate from the issue regarding the make file = converting characters to UTF-8.  It is related to this item in that = it is a new step for us and needs to be tested before we can publish = files that include UTF-8.

Thanks for = the suggestion regarding having a script that converts specific UTF-8 = characters back to ASCII.  The obvious ones so far have been =E2=80=98= (single quote), =E2=80=9C (double quote), and - (hyphen).   I=E2=80=99= ll do some more testing to see if other characters are impacted by this = conversion as well, but that may work. 

Thanks,
Sandy
= --Apple-Mail=_A2442F85-4CF3-496B-8CDB-DD0934110520-- From nobody Tue May 9 11:21:31 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3301A12954D for ; Tue, 9 May 2017 11:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xiKUdDEz2W0 for ; Tue, 9 May 2017 11:21:29 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2CB126FDC for ; Tue, 9 May 2017 11:21:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0DE941CA0B5; Tue, 9 May 2017 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaLwN_91qz8G; Tue, 9 May 2017 11:21:14 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id D5E161C1B55; Tue, 9 May 2017 11:21:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sandy Ginoza In-Reply-To: <27e59d14-7aa9-876a-e628-2fd175f8338a@gmx.de> Date: Tue, 9 May 2017 11:21:28 -0700 Cc: "Heather Flanagan (RFC Series Editor)" , tools-development@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6EEEECBA-B52D-47B1-A671-60209BEC77E1@amsl.com> References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> <27e59d14-7aa9-876a-e628-2fd175f8338a@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:21:30 -0000 Thanks Julian - we=E2=80=99ll look into this!=20 > On May 9, 2017, at 10:59 AM, Julian Reschke = wrote: >=20 > On 2017-05-09 18:40, Sandy Ginoza wrote: >> ... >> To continue with testing we have created a copy of our make file that >> produces ASCII only when the LANGUAGE variable is set to UTF-8. I = need >> to do more testing and understand whether it=E2=80=99s possible (with = our >> current tools) to create a .txt file with UTF-8 that does not >> automatically convert the =E2=80=98 and - characters to their UTF-8 = forms >> (because UTF-8 chars are only supposed to appear where needed). I = also >> need to see what the output looks like using the sed command Henrik >> provided that adds the BOM. >>=20 >> Talk to you all soon. >> ... >=20 > This: >=20 > = https://github.com/fish-shell/fish-shell/issues/2673#issuecomment-25492537= 4 >=20 >=20 > might be related... >=20 From nobody Tue May 9 13:38:04 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35007128D64 for ; Tue, 9 May 2017 13:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK9addgGd-I4 for ; Tue, 9 May 2017 13:38:00 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F84F1286AB for ; Tue, 9 May 2017 13:38:00 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v49IYvIP026508; Tue, 9 May 2017 14:42:53 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2abfsjdhu0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 May 2017 14:42:52 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v49Igo47007144; Tue, 9 May 2017 14:42:51 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v49IgfRs006765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 14:42:46 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 9 May 2017 18:42:26 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.29]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0319.002; Tue, 9 May 2017 14:42:25 -0400 From: "HANSEN, TONY L" To: Sandy Ginoza CC: "tools-development@ietf.org" Thread-Topic: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern Thread-Index: AQHSyPCR/5Bf+KPdgE2s8CIT3IFwyqHsVh4A Date: Tue, 9 May 2017 18:42:25 +0000 Message-ID: <8D1560E3-272C-478A-9322-948398F04F95@att.com> References: <721020DC-C2C3-4A02-BF05-8110FD29313B@vigilsec.com> <394145a5-209b-1d1c-e4d9-3db5ef329a22@nostrum.com> <68e1bc97-b719-1448-be74-7d639da40516@rfc-editor.org> <24ADF220-51C4-40B1-9A43-2C5BDA3C660F@amsl.com> <31C69CE8-F80C-4AE1-A34B-F8D12F309E3F@amsl.com> In-Reply-To: <31C69CE8-F80C-4AE1-A34B-F8D12F309E3F@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.241.200] Content-Type: multipart/alternative; boundary="_000_8D1560E3272C478A9322948398F04F95attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090102 Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 9 May 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 20:38:02 -0000 --_000_8D1560E3272C478A9322948398F04F95attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSB0aGUgcGFnZSBKdWxpYW4gcG9zdGVkLCBpdCBsb29rcyBsaWtlIGAgKGdyYXZlIGFjY2Vu dCkgbWlnaHQgYWxzbyBiZSBhZmZlY3RlZC4NClJ1biBhIHRlc3Qgd2l0aCB0aGUgOTUgcHJpbnRh YmxlIGNoYXJhY3RlcnMgaW4gaXQgYW5kIHNlZSB3aGF0IGdldHMgbWFuZ2xlZC4NCg0KICAgICAg ICAgICAgICAgIFRvbnkNCg0KRnJvbTogVE9PTFMtREVWRUxPUE1FTlQgPHRvb2xzLWRldmVsb3Bt ZW50LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTYW5keSBHaW5vemEgPHNnaW5vemFA YW1zbC5jb20+DQpEYXRlOiBUdWVzZGF5LCBNYXkgOSwgMjAxNyBhdCAyOjE3IFBNDQpUbzogIkhl YXRoZXIgRmxhbmFnYW4gKFJGQyBTZXJpZXMgRWRpdG9yKSIgPHJzZUByZmMtZWRpdG9yLm9yZz4N CkNjOiAidG9vbHMtZGV2ZWxvcG1lbnRAaWV0Zi5vcmciIDx0b29scy1kZXZlbG9wbWVudEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbVE9PTFMtREVWRUxPUE1FTlRdIFRvb2xzIENhbGwgQWdlbmRh IC0tIDkgTWF5IDIwMTcgYXQgMTowMCBFYXN0ZXJuDQoNCkhpIGFnYWluLA0KDQoNCk9uIE1heSA5 LCAyMDE3LCBhdCA5OjQwIEFNLCBTYW5keSBHaW5vemEgPHNnaW5vemFAYW1zbC5jb208bWFpbHRv OnNnaW5vemFAYW1zbC5jb20+PiB3cm90ZToNCg0KSSBhbHNvIG5lZWQgdG8gc2VlIHdoYXQgdGhl IG91dHB1dCBsb29rcyBsaWtlIHVzaW5nIHRoZSBzZWQgY29tbWFuZCBIZW5yaWsgcHJvdmlkZWQg dGhhdCBhZGRzIHRoZSBCT00uDQoNCg0KSnVzdCBhIGZldyBhZGRpdGlvbmFsIGNvbW1lbnRzIG9u IHRoaXMgb25lLCBhcyBJIHJlYWxpemUgdGhhdCBteSBleHBsYW5hdGlvbiBvbiB0aGUgY2FsbCBt YXkgbm90IGhhdmUgYW5zd2VyZWQgdGhlIHF1ZXN0aW9uLg0KDQpUaGUgQk9NIGlzIHNlcGFyYXRl IGZyb20gdGhlIGlzc3VlIHJlZ2FyZGluZyB0aGUgbWFrZSBmaWxlIGNvbnZlcnRpbmcgY2hhcmFj dGVycyB0byBVVEYtOC4gIEl0IGlzIHJlbGF0ZWQgdG8gdGhpcyBpdGVtIGluIHRoYXQgaXQgaXMg YSBuZXcgc3RlcCBmb3IgdXMgYW5kIG5lZWRzIHRvIGJlIHRlc3RlZCBiZWZvcmUgd2UgY2FuIHB1 Ymxpc2ggZmlsZXMgdGhhdCBpbmNsdWRlIFVURi04Lg0KDQpUaGFua3MgZm9yIHRoZSBzdWdnZXN0 aW9uIHJlZ2FyZGluZyBoYXZpbmcgYSBzY3JpcHQgdGhhdCBjb252ZXJ0cyBzcGVjaWZpYyBVVEYt OCBjaGFyYWN0ZXJzIGJhY2sgdG8gQVNDSUkuICBUaGUgb2J2aW91cyBvbmVzIHNvIGZhciBoYXZl IGJlZW4g4oCYIChzaW5nbGUgcXVvdGUpLCDigJwgKGRvdWJsZSBxdW90ZSksIGFuZCAtIChoeXBo ZW4pLiAgIEnigJlsbCBkbyBzb21lIG1vcmUgdGVzdGluZyB0byBzZWUgaWYgb3RoZXIgY2hhcmFj dGVycyBhcmUgaW1wYWN0ZWQgYnkgdGhpcyBjb252ZXJzaW9uIGFzIHdlbGwsIGJ1dCB0aGF0IG1h eSB3b3JrLg0KDQpUaGFua3MsDQpTYW5keQ0K --_000_8D1560E3272C478A9322948398F04F95attcom_ Content-Type: text/html; charset="utf-8" Content-ID: <33F72E1016BD3B4782EEDD425A568EB5@LOCAL> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPkZyb20gdGhlIHBhZ2UgSnVsaWFuIHBvc3RlZCwgaXQgbG9va3MgbGlrZSBgIChn cmF2ZSBhY2NlbnQpIG1pZ2h0IGFsc28gYmUgYWZmZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+UnVuIGEgdGVzdCB3aXRoIHRoZSA5NSBwcmludGFibGUgY2hhcmFj dGVycyBpbiBpdCBhbmQgc2VlIHdoYXQgZ2V0cyBtYW5nbGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb255PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+VE9PTFMtREVW RUxPUE1FTlQgJmx0O3Rvb2xzLWRldmVsb3BtZW50LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJl aGFsZiBvZiBTYW5keSBHaW5vemEgJmx0O3NnaW5vemFAYW1zbC5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlR1ZXNkYXksIE1heSA5LCAyMDE3IGF0IDI6MTcgUE08YnI+DQo8Yj5UbzogPC9iPiZx dW90O0hlYXRoZXIgRmxhbmFnYW4gKFJGQyBTZXJpZXMgRWRpdG9yKSZxdW90OyAmbHQ7cnNlQHJm Yy1lZGl0b3Iub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7dG9vbHMtZGV2ZWxvcG1lbnRA aWV0Zi5vcmcmcXVvdDsgJmx0O3Rvb2xzLWRldmVsb3BtZW50QGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW1RPT0xTLURFVkVMT1BNRU5UXSBUb29scyBDYWxsIEFnZW5kYSAt LSA5IE1heSAyMDE3IGF0IDE6MDAgRWFzdGVybjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhZ2FpbiwgPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgOSwgMjAx NywgYXQgOTo0MCBBTSwgU2FuZHkgR2lub3phICZsdDs8YSBocmVmPSJtYWlsdG86c2dpbm96YUBh bXNsLmNvbSI+c2dpbm96YUBhbXNsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpDb3VyaWVyIj5JIGFsc28gbmVlZCB0byBzZWUgd2hhdCB0aGUgb3V0cHV0 IGxvb2tzIGxpa2UgdXNpbmcgdGhlIHNlZCBjb21tYW5kIEhlbnJpayBwcm92aWRlZCB0aGF0IGFk ZHMgdGhlIEJPTS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBhIGZldyBhZGRpdGlvbmFsIGNvbW1lbnRz IG9uIHRoaXMgb25lLCBhcyBJIHJlYWxpemUgdGhhdCBteSBleHBsYW5hdGlvbiBvbiB0aGUgY2Fs bCBtYXkgbm90IGhhdmUgYW5zd2VyZWQgdGhlIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgQk9NIGlzIHNlcGFyYXRlIGZy b20gdGhlIGlzc3VlIHJlZ2FyZGluZyB0aGUgbWFrZSBmaWxlIGNvbnZlcnRpbmcgY2hhcmFjdGVy cyB0byBVVEYtOC4gJm5ic3A7SXQgaXMgcmVsYXRlZCB0byB0aGlzIGl0ZW0gaW4gdGhhdCBpdCBp cyBhIG5ldyBzdGVwIGZvciB1cyBhbmQgbmVlZHMgdG8gYmUgdGVzdGVkIGJlZm9yZSB3ZSBjYW4g cHVibGlzaCBmaWxlcyB0aGF0IGluY2x1ZGUgVVRGLTguPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGFua3MgZm9yIHRoZSBzdWdnZXN0 aW9uIHJlZ2FyZGluZyBoYXZpbmcgYSBzY3JpcHQgdGhhdCBjb252ZXJ0cyBzcGVjaWZpYyBVVEYt OCBjaGFyYWN0ZXJzIGJhY2sgdG8gQVNDSUkuICZuYnNwO1RoZSBvYnZpb3VzIG9uZXMgc28gZmFy IGhhdmUgYmVlbiDigJggKHNpbmdsZSBxdW90ZSksIOKAnCAoZG91YmxlIHF1b3RlKSwgYW5kIC0g KGh5cGhlbikuICZuYnNwOyBJ4oCZbGwgZG8gc29tZSBtb3JlIHRlc3RpbmcgdG8gc2VlIGlmIG90 aGVyIGNoYXJhY3RlcnMgYXJlIGltcGFjdGVkDQogYnkgdGhpcyBjb252ZXJzaW9uIGFzIHdlbGws IGJ1dCB0aGF0IG1heSB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8D1560E3272C478A9322948398F04F95attcom_-- From nobody Tue May 9 14:42:49 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0391D12945E for ; Tue, 9 May 2017 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3Gd85vHgqOR for ; Tue, 9 May 2017 14:42:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE294127977 for ; Tue, 9 May 2017 14:42:45 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v49Lgik0081215 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 9 May 2017 16:42:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: tools-development@ietf.org From: Robert Sparks Message-ID: <7f4917f1-8e85-2499-1cb4-5f0ac834b65b@nostrum.com> Date: Tue, 9 May 2017 16:42:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] Observations from trying to improve the document authors captured for RFCs in the datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 21:42:48 -0000 I spent more time than I planned seeing if we could improve the tracker's notion of who the authors of any given RFC were before we release the authorstats project. Here's a short dump of a few things I learned in the process before I lose track of them: We currently model documentauthors using email addresses (the Email objects point to Person objects). This doesn't work when we don't have an email address for an author. We have begun discussing changing that to have it link to Person objects, with possibly an Email reference when it's available. The RFC Editor's database has a few aspects that make it difficult to use as a source of authority (these are not requests for change, just observations on what's there) - The columns holding author names and author addresses are each single text fields. Each row contains a comma separated string in each field. - There are many RFCs where the author addresses in that database are incomplete (often because the author didn't supply an email address in that RFC). Sometimes, but not always, this is captured as a "none". - There are several records where the order of names and the order of addresses don't line up (in cases like the previous bullet, the _number_ of names and addresses don't agree). The RFC Editor's database (and the documents themselves) are very inconsistent on who to list as authors when a document comes out of the IAB or the IESG. The datatracker currently does not recalculate authors when an RFC is published - what it has (until the migrations I just committed are applied to production) as the documentauthor set for any given RFC are what it had for the last revision of the Internet-Draft that led to it. New code needs to be created that updates authors when and RFC is published. The datatracker doesn't know many of the email addresses that have been used in RFCs (until those migrations run again), or who they should be associated with. The migrations add about 850 addresses for People the tracker already knew, and addresses and Person records for another 220 that the tracker didn't know yet. The datatracker still has quite a number of duplicate Person records. As part of preparing this set of migrations we cleaned up 50ish cases of that. Some examples (already fixed) to show how sometimes this is easy, and sometimes it's hard : (format: [ (person name,person primary key),(person name, person primary key)] rfc_number ) [(, 108522L), (, 22971L)] 4918 [(, 110964L), (, 2455L)] 3342 [(, 119947L), (, 100887L)] 7652 [(, 120586L), (, 6526L)] 1823 The draft parser has a hard job to do. There are many RFCs where authors have been "clever" or don't follow the one-author-per-address convention. Good examples of hard problems: RFC2016 and RFC2198. (In particular, things like "EMail: {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.uk" defeat the parser.) Applying what I just did to Internet-Drafts in general won't work as well as it did for drafts that have become RFCs. Factors contributing to that are: - Things that become RFCs have some pressure to become more regular, hence parsable (even very old RFCs) - The addresses used by folks in RFCs are relatively easy to map to People than the general case (fewer instances of inscrutable@ to deal with). - Associating an address the tracker hasn't seen before with the right person will be particularly hard to automate. The probability of creating new Duplicate Person records will be very high. Be sure to note that what we can do in the future to improve the quality of the data we capture as new Internet-Drafts are submitted is an entirely different problem/solution space to explore than trying to improve what we have for old I-Ds. RjS From nobody Mon May 15 04:03:43 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6211286D6 for ; Mon, 15 May 2017 04:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.821 X-Spam-Level: * X-Spam-Status: No, score=1.821 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tRw5hbBTCsx for ; Mon, 15 May 2017 04:03:41 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C691294B8 for ; Mon, 15 May 2017 04:00:08 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:53144 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dADjT-00043S-Q4 for tools-development@ietf.org; Mon, 15 May 2017 04:00:08 -0700 From: Henrik Levkowetz Cc: IETF Tools Development Message-ID: <59198A25.9010206@levkowetz.com> Date: Mon, 15 May 2017 12:59:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D1j1XbcdBwV8xcOMubJ8dKK5UCwgGwM4g" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 11:03:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D1j1XbcdBwV8xcOMubJ8dKK5UCwgGwM4g Content-Type: multipart/mixed; boundary="8mxD4mEWNxW2ax8F2fj1INIC8pMmLbkM5"; protected-headers="v1" From: Henrik Levkowetz Cc: IETF Tools Development Message-ID: <59198A25.9010206@levkowetz.com> Subject: Preview release of Text Submission Converter, id2xml --8mxD4mEWNxW2ax8F2fj1INIC8pMmLbkM5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've just uploaded the third preview release (0.9.2) of 'id2xml', the text-submission converter tool: https://pypi.python.org/pypi/id2xml You should be able to install it with: $ pip install id2xml All feedback is very welcome. =46rom the README file: This tool, 'id2xml', is intended for use by the RFC-Editor staff, in orde= r to produce a first xml2rfc-compatible XML version from text-only Internet-Dr= aft submissions. id2xml may also be useful for Internet-Draft authors who wish to start wo= rking on a new version of an older draft or RFC, for which no xml2rfc-compatibl= e XML source is available. The releases of the 0.9.x release series are preview releases, with a num= ber of known deficiencies. They are released in order that potential users m= ay provide feedback on the most desired improvements ahead of a 1.0.0 releas= e. Version 0.9.0 can process the drafts specified in the development Stateme= nt of Work to XML files acceptable to xml2rfc, and can also process a number of= other test files to acceptable XML. However, adding new drafts to the te= st set still reveals weaknesses in many cases, so trouble-free processing of= any arbitrary draft should not be expected from the 0.9.x series. The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of the to= ol, and will follow RFC 7991 [2]_ in version 2.x, which will be released = once support is available to process XML sources which follows the RFC 7991 vocabulary. =2E. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI= 10.17487/RFC7749, February 2016, . =2E. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI= 10.17487/RFC7991, December 2016, http://www.rfc-editor.org/info/rfc799= 1>. Best regards, Henrik --8mxD4mEWNxW2ax8F2fj1INIC8pMmLbkM5-- --D1j1XbcdBwV8xcOMubJ8dKK5UCwgGwM4g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZGYovAAoJEE6bV0uPuxcaZ9IQAM0mAn/DpOO5BmPkzuN6tseu MPw11caP8Q/kbU+nHcfPyKQ5uliFXz5raTzqiLGWZ+XE3u7WAwAgAHFAcKJPNGK7 i5pZKo01IJdkxZEhbGQSBrs7F6sD1ezXlLaxvvwR1z1Xu3cQ+ewagBtC4I7uXiJt /B7PNvO9qpRGZ+JmMffYP89RKsuMWpSBo/51CTEYuAnyvG8oNqxCTrWBqNlbEEBL yalXThKzZltoa4IoIARnR6Q2xls/pvbi+jy3JDHC01kNDZi141YLzAIlJsCeYtz7 joXLQPM5nmIfPs56PnRtT9YUC4Ch+kjHNj8+RHF+zfaW5U4iznN3XwLVEAIz4jOq WX49D9Nibg/ZLw9Va9lOgporMdJR9O+mEOYMnociaQLB+Fdmni40uhpofNvqpgfF 6iIOG2gb3zeS0nlf1zRDMfknd+Qvodr4zMjJwwzO68GMOTl9k1CH9naDutHMLdli MMa7iAtpmNqu9aKbU54Yg7cusBy1GUoopiM7aUBpgMFVSMoCot9DNFKApfQsD6pP xYkVKm3R5HAKCYvv9ELqN/n7Stvw1MsgiyijjKN7rtSkWp4xPpTREj+fO/M5fWXX sT/eWj6H2KlS71A5EuY/6NFXSIjkk7pKo0sdIlStS6O+NkcDNgHU4PjiyT3prypO eS2akwvZqOy/O/OdBANc =2/Un -----END PGP SIGNATURE----- --D1j1XbcdBwV8xcOMubJ8dKK5UCwgGwM4g-- From nobody Mon May 15 12:56:13 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF116129C3B for ; Mon, 15 May 2017 12:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTtHrmn9ThiA for ; Mon, 15 May 2017 12:56:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D6B1286AB for ; Mon, 15 May 2017 12:52:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3C907300538 for ; Mon, 15 May 2017 15:52:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UTcvCBoMgWic for ; Mon, 15 May 2017 15:52:56 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BFCFD3000FF; Mon, 15 May 2017 15:52:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <59198A25.9010206@levkowetz.com> Date: Mon, 15 May 2017 15:53:00 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> References: <59198A25.9010206@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 19:56:12 -0000 Henrik: After $ pip install id2xml, what is the command line to produce a .xml = form a .txt that contains an RFC or Internet-Draft? Russ > On May 15, 2017, at 6:59 AM, Henrik Levkowetz = wrote: >=20 > Hi, >=20 > I've just uploaded the third preview release (0.9.2) of 'id2xml', the > text-submission converter tool: >=20 > https://pypi.python.org/pypi/id2xml >=20 > You should be able to install it with: >=20 > $ pip install id2xml >=20 > All feedback is very welcome. >=20 >=20 > =46rom the README file: >=20 > This tool, 'id2xml', is intended for use by the RFC-Editor staff, in = order to > produce a first xml2rfc-compatible XML version from text-only = Internet-Draft > submissions. >=20 > id2xml may also be useful for Internet-Draft authors who wish to start = working > on a new version of an older draft or RFC, for which no = xml2rfc-compatible XML > source is available. >=20 > The releases of the 0.9.x release series are preview releases, with a = number > of known deficiencies. They are released in order that potential = users may > provide feedback on the most desired improvements ahead of a 1.0.0 = release. >=20 > Version 0.9.0 can process the drafts specified in the development = Statement of > Work to XML files acceptable to xml2rfc, and can also process a number = of > other test files to acceptable XML. However, adding new drafts to the = test > set still reveals weaknesses in many cases, so trouble-free processing = of any > arbitrary draft should not be expected from the 0.9.x series. >=20 > The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of the = tool, and will follow RFC 7991 [2]_ in version 2.x, which will be = released once > support is available to process XML sources which follows the RFC 7991 > vocabulary. >=20 >=20 > .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, = DOI > 10.17487/RFC7749, February 2016, = . >=20 > .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, = DOI > 10.17487/RFC7991, December 2016, = http://www.rfc-editor.org/info/rfc7991>. >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon May 15 13:15:27 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B899912EB06 for ; Mon, 15 May 2017 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnGO2lBN-IjX for ; Mon, 15 May 2017 13:15:23 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D8F12EB14 for ; Mon, 15 May 2017 13:11:29 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:65091 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dAML1-0007bW-Jz; Mon, 15 May 2017 13:11:29 -0700 To: Russ Housley References: <59198A25.9010206@levkowetz.com> <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> Cc: IETF Tools Development From: Henrik Levkowetz Message-ID: <591A0B67.4050401@levkowetz.com> Date: Mon, 15 May 2017 22:11:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="febPAObFmXjgmIIhGbCD7ohBnkeSMj4Cm" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, housley@vigilsec.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 20:15:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --febPAObFmXjgmIIhGbCD7ohBnkeSMj4Cm Content-Type: multipart/mixed; boundary="hlEAU5NWj16KmruD4XGd8qD2cbhn9Nvmb"; protected-headers="v1" From: Henrik Levkowetz To: Russ Housley Cc: IETF Tools Development Message-ID: <591A0B67.4050401@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <59198A25.9010206@levkowetz.com> <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> In-Reply-To: <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> --hlEAU5NWj16KmruD4XGd8qD2cbhn9Nvmb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, On 2017-05-15 21:53, Russ Housley wrote: > Henrik: >=20 > After $ pip install id2xml, what is the command line to produce a .xml= form a .txt that contains an RFC or Internet-Draft? Something like $ id2xml draft-old-foo-bar.txt -o draft-new-foo-bar.xml or $ id2xml draft-foo-bar.txt -p ~/workdir/ should do it. On first invocation, id2xml will produce an .xml file also if you don't give an explicit output file or output path, if there isn't already an xml file with the inferred name; but to avoid possibly overwriting an original xml source, it won't do any overwrites unless given an explicit target name or path. If $ id2xml --help doesn't work, there's probably an issue with your defa= ult pip and your default python not agreeing on installation directories. Write me off-list if you run into indications that that's the case. Best regards, Henrik > Russ >=20 >=20 >=20 >> On May 15, 2017, at 6:59 AM, Henrik Levkowetz w= rote: >>=20 >> Hi, >>=20 >> I've just uploaded the third preview release (0.9.2) of 'id2xml', the >> text-submission converter tool: >>=20 >> https://pypi.python.org/pypi/id2xml >>=20 >> You should be able to install it with: >>=20 >> $ pip install id2xml >>=20 >> All feedback is very welcome. >>=20 >>=20 >> From the README file: >>=20 >> This tool, 'id2xml', is intended for use by the RFC-Editor staff, in o= rder to >> produce a first xml2rfc-compatible XML version from text-only Internet= -Draft >> submissions. >>=20 >> id2xml may also be useful for Internet-Draft authors who wish to start= working >> on a new version of an older draft or RFC, for which no xml2rfc-compat= ible XML >> source is available. >>=20 >> The releases of the 0.9.x release series are preview releases, with a = number >> of known deficiencies. They are released in order that potential user= s may >> provide feedback on the most desired improvements ahead of a 1.0.0 rel= ease. >>=20 >> Version 0.9.0 can process the drafts specified in the development Stat= ement of >> Work to XML files acceptable to xml2rfc, and can also process a number= of >> other test files to acceptable XML. However, adding new drafts to the= test >> set still reveals weaknesses in many cases, so trouble-free processing= of any >> arbitrary draft should not be expected from the 0.9.x series. >>=20 >> The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of the= tool, and will follow RFC 7991 [2]_ in version 2.x, which will be releas= ed once >> support is available to process XML sources which follows the RFC 7991= >> vocabulary. >>=20 >>=20 >> .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DO= I >> 10.17487/RFC7749, February 2016, . >>=20 >> .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DO= I >> 10.17487/RFC7991, December 2016, http://www.rfc-editor.org/info/rfc7= 991>. >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 >=20 --hlEAU5NWj16KmruD4XGd8qD2cbhn9Nvmb-- --febPAObFmXjgmIIhGbCD7ohBnkeSMj4Cm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZGgtoAAoJEE6bV0uPuxcaYtIP/3WiG7URd/h/Yl2TEJcR6NKg spH8ly2YByWe+nWbJCLrKOnSf28CvONcNFEBPZwll9N3+qanWLI4rpAex5PbcVqY CRR6NlggfXvDA2hVs02VdmSdf5h4yjxoBiidTRWSnP2YWJseogIrj6sGoRth24Ap uJ0wVxQWjm7ZmOElBOqNmhv5U4KLWgUvEfQ4aeu3k+Z6WMYayceTRamx+FMrmMDi 38npnyEFROzy8mr5MyCfWqL7+/ZUR+C85okN91yqgfleVnQrMimszDdPW4yPu7AR 2EhwXXgdpHoKkwVcSAnGvo+THsC35FW6E9wFoHUAWiwhVM2J+wimyBv8K47f/mw9 AlzNRixl1UPYjTf5Hzs6P9nb55W5gbE4q2iu0xfJ5TlzLh722fw6tZhleeQVnzTw x8U6m5ARBrBAZibLk3X139a3JPNpmT3gidQa9bW/pXmLEHe1zgxElYiJ6i8JTUQk USnWl4HL7dPrZ8ONKH79RYkXm/k6yUBKtRXqc5a3B0j3Jucl9aXpmNRSiVzPdAk9 R+nCudSotne/yAEg9BFPZl0ne44pOdgTx7CQL1eg3xbnYNJgFbwTmQopp2NJgqt4 GeglP5/uoVWNBc+JUAuyOfAo7tT4FH0daur7DvW1kAanVFTDk5E2M09VdMu8mVjQ rWvqVI3Xxb0CRwa7MLla =Op0q -----END PGP SIGNATURE----- --febPAObFmXjgmIIhGbCD7ohBnkeSMj4Cm-- From nobody Mon May 15 13:19:09 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAEF124C27 for ; Mon, 15 May 2017 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzFb0XwIK5zq for ; Mon, 15 May 2017 13:19:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC2312778D for ; Mon, 15 May 2017 13:15:55 -0700 (PDT) Received: from unescapeable.local (marriott-chateau-champlain-montreal.sites.intello.com [66.171.169.34]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4FKFq6h096408 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 15 May 2017 15:15:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host marriott-chateau-champlain-montreal.sites.intello.com [66.171.169.34] claimed to be unescapeable.local To: tools-development@ietf.org References: <59198A25.9010206@levkowetz.com> <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> From: Robert Sparks Message-ID: <3e742421-2c31-3327-9551-0725252f45c8@nostrum.com> Date: Mon, 15 May 2017 16:15:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 20:19:08 -0000 On 5/15/17 3:53 PM, Russ Housley wrote: > Henrik: > > After $ pip install id2xml, what is the command line to produce a .xml form a .txt that contains an RFC or Internet-Draft? id2xml draft-whatever.txt id2xml --help shows a lot of options > > Russ > > > >> On May 15, 2017, at 6:59 AM, Henrik Levkowetz wrote: >> >> Hi, >> >> I've just uploaded the third preview release (0.9.2) of 'id2xml', the >> text-submission converter tool: >> >> https://pypi.python.org/pypi/id2xml >> >> You should be able to install it with: >> >> $ pip install id2xml >> >> All feedback is very welcome. >> >> >> From the README file: >> >> This tool, 'id2xml', is intended for use by the RFC-Editor staff, in order to >> produce a first xml2rfc-compatible XML version from text-only Internet-Draft >> submissions. >> >> id2xml may also be useful for Internet-Draft authors who wish to start working >> on a new version of an older draft or RFC, for which no xml2rfc-compatible XML >> source is available. >> >> The releases of the 0.9.x release series are preview releases, with a number >> of known deficiencies. They are released in order that potential users may >> provide feedback on the most desired improvements ahead of a 1.0.0 release. >> >> Version 0.9.0 can process the drafts specified in the development Statement of >> Work to XML files acceptable to xml2rfc, and can also process a number of >> other test files to acceptable XML. However, adding new drafts to the test >> set still reveals weaknesses in many cases, so trouble-free processing of any >> arbitrary draft should not be expected from the 0.9.x series. >> >> The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of the tool, and will follow RFC 7991 [2]_ in version 2.x, which will be released once >> support is available to process XML sources which follows the RFC 7991 >> vocabulary. >> >> >> .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI >> 10.17487/RFC7749, February 2016, . >> >> .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI >> 10.17487/RFC7991, December 2016, http://www.rfc-editor.org/info/rfc7991>. >> >> >> Best regards, >> >> Henrik >> >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon May 15 13:41:11 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6C21241FC for ; Mon, 15 May 2017 13:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBsLWk_spzRG for ; Mon, 15 May 2017 13:41:07 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFB2124BFA for ; Mon, 15 May 2017 13:38:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7BB851C5A6F; Mon, 15 May 2017 13:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qx5xZLVDmDa; Mon, 15 May 2017 13:38:41 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id 339B51C362A; Mon, 15 May 2017 13:38:41 -0700 (PDT) From: Sandy Ginoza Message-Id: <2CFEC0BB-D0AE-4391-9E0B-AA170874F914@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8C2AF5B1-89AD-4BFE-82FA-007A7C7DDA7A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 15 May 2017 13:38:42 -0700 In-Reply-To: <3e742421-2c31-3327-9551-0725252f45c8@nostrum.com> Cc: Megan Ferguson , IETF Tools Development , Henrik Levkowetz To: Robert Sparks References: <59198A25.9010206@levkowetz.com> <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> <3e742421-2c31-3327-9551-0725252f45c8@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 20:41:10 -0000 --Apple-Mail=_8C2AF5B1-89AD-4BFE-82FA-007A7C7DDA7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Please note that I=E2=80=99ve added Megan Ferguson to the thread, as she = is the lead for testing v3-related tools for the RPC. =20 We haven=E2=80=99t been able to successfully run id2xml yet. Matt = installed the updated version for us this morning to see if that helped, = but we=E2=80=99re still getting the same errors and we=E2=80=99re unable = to view output of "id2xml =E2=80=94help" Are we missing something? Some of the error messages are below. Thanks! Sandy > > id2xml draft-ietf-rtgwg-yang-key-chain-24test.txt > Traceback (most recent call last): > File "/usr/bin/id2xml", line 9, in > load_entry_point('id2xml=3D=3D0.9.1', 'console_scripts', = 'id2xml')() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 558, in load_entry_point > return get_distribution(dist).load_entry_point(group, name) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2682, in load_entry_point > return ep.load() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2355, in load > return self.resolve() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2361, in resolve > module =3D __import__(self.module_name, fromlist=3D['__name__'], = level=3D0) > File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 43, in = > from __init__ import __version__ > ImportError: No module named =E2=80=98__init__' > id2xml draft-ietf-sidr-rpki-oob-setup-09.txt > = draft-ietf-sidr-rpki-oob-setup-test.xml Traceback (most recent call last): File "/usr/bin/id2xml", line 9, in load_entry_point('id2xml=3D=3D0.9.1', 'console_scripts', 'id2xml')() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 558, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2682, in load_entry_point return ep.load() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2355, in load return self.resolve() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2361, in resolve module =3D __import__(self.module_name, fromlist=3D['__name__'], = level=3D0) File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 43, in = from __init__ import __version__ ImportError: No module named =E2=80=98__init__' > id2xml draft-ietf-sidr-rpki-oob-setup-09.txt | = draft-ietf-sidr-rpki-oob-setup-test.xml If 'draft-ietf-sidr-rpki-oob-setup-test.xml' is not a typo you can use = command-not-found to lookup the package that contains it, like this: cnf draft-ietf-sidr-rpki-oob-setup-test.xml Traceback (most recent call last): File "/usr/bin/id2xml", line 9, in load_entry_point('id2xml=3D=3D0.9.2', 'console_scripts', 'id2xml')() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 558, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2682, in load_entry_point return ep.load() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2355, in load return self.resolve() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2361, in resolve module =3D __import__(self.module_name, fromlist=3D['__name__'], = level=3D0) File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 44, in = from __init__ import __version__ ImportError: No module named =E2=80=98__init__' > id2xml --help Traceback (most recent call last): File "/usr/bin/id2xml", line 9, in load_entry_point('id2xml=3D=3D0.9.2', 'console_scripts', 'id2xml')() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 558, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2682, in load_entry_point return ep.load() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2355, in load return self.resolve() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", = line 2361, in resolve module =3D __import__(self.module_name, fromlist=3D['__name__'], = level=3D0) File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 44, in = from __init__ import __version__ ImportError: No module named '__init__' > On May 15, 2017, at 1:15 PM, Robert Sparks = wrote: >=20 >=20 >=20 > On 5/15/17 3:53 PM, Russ Housley wrote: >> Henrik: >>=20 >> After $ pip install id2xml, what is the command line to produce a = .xml form a .txt that contains an RFC or Internet-Draft? > id2xml draft-whatever.txt >=20 > id2xml --help shows a lot of options >>=20 >> Russ >>=20 >>=20 >>=20 >>> On May 15, 2017, at 6:59 AM, Henrik Levkowetz = wrote: >>>=20 >>> Hi, >>>=20 >>> I've just uploaded the third preview release (0.9.2) of 'id2xml', = the >>> text-submission converter tool: >>>=20 >>> https://pypi.python.org/pypi/id2xml >>>=20 >>> You should be able to install it with: >>>=20 >>> $ pip install id2xml >>>=20 >>> All feedback is very welcome. >>>=20 >>>=20 >>> =46rom the README file: >>>=20 >>> This tool, 'id2xml', is intended for use by the RFC-Editor staff, in = order to >>> produce a first xml2rfc-compatible XML version from text-only = Internet-Draft >>> submissions. >>>=20 >>> id2xml may also be useful for Internet-Draft authors who wish to = start working >>> on a new version of an older draft or RFC, for which no = xml2rfc-compatible XML >>> source is available. >>>=20 >>> The releases of the 0.9.x release series are preview releases, with = a number >>> of known deficiencies. They are released in order that potential = users may >>> provide feedback on the most desired improvements ahead of a 1.0.0 = release. >>>=20 >>> Version 0.9.0 can process the drafts specified in the development = Statement of >>> Work to XML files acceptable to xml2rfc, and can also process a = number of >>> other test files to acceptable XML. However, adding new drafts to = the test >>> set still reveals weaknesses in many cases, so trouble-free = processing of any >>> arbitrary draft should not be expected from the 0.9.x series. >>>=20 >>> The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of = the tool, and will follow RFC 7991 [2]_ in version 2.x, which will be = released once >>> support is available to process XML sources which follows the RFC = 7991 >>> vocabulary. >>>=20 >>>=20 >>> .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, = DOI >>> 10.17487/RFC7749, February 2016, = . >>>=20 >>> .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, = DOI >>> 10.17487/RFC7991, December 2016, = http://www.rfc-editor.org/info/rfc7991>. >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Henrik >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --Apple-Mail=_8C2AF5B1-89AD-4BFE-82FA-007A7C7DDA7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

Please note that I=E2=80=99ve added = Megan Ferguson to the thread, as she is the lead for testing v3-related = tools for the RPC.  

We haven=E2=80=99t been able to successfully run id2xml yet. =  Matt installed the updated version for us this morning to see if = that helped, but we=E2=80=99re still getting the same errors and we=E2=80=99= re unable to view output of "id2xml =E2=80=94help"

Are we missing = something?  Some of the error messages are below.

Thanks!
Sandy

> id2xml draft-ietf-rtgwg-yang-key-chain-24test.txt
Traceback (most recent call last):
 File = "/usr/bin/id2xml", line 9, in <module>
   load_entry_point('id2xml=3D=3D0.9.1', = 'console_scripts', 'id2xml')()
 File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 558, = in load_entry_point
   return = get_distribution(dist).load_entry_point(group, name)
 File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2682, = in load_entry_point
   return ep.load()
 File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2355, = in load
   return self.resolve()
 File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2361, = in resolve
   module =3D = __import__(self.module_name, fromlist=3D['__name__'], level=3D0)
 File = "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 43, in = <module>
   from __init__ import = __version__
ImportError: No module named = =E2=80=98__init__'

> id2xml draft-ietf-sidr-rpki-oob-setup-09.txt = > draft-ietf-sidr-rpki-oob-setup-test.xml
Traceback (most = recent call last):
  File = "/usr/bin/id2xml", line 9, in <module>
    = load_entry_point('id2xml=3D=3D0.9.1', 'console_scripts', = 'id2xml')()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 558, = in load_entry_point
    = return get_distribution(dist).load_entry_point(group, = name)
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2682, = in load_entry_point
    = return ep.load()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2355, = in load
    return = self.resolve()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2361, = in resolve
    module =3D = __import__(self.module_name, fromlist=3D['__name__'], = level=3D0)
  File = "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 43, in = <module>
    = from __init__ import __version__
ImportError: No = module named =E2=80=98__init__'


> = id2xml draft-ietf-sidr-rpki-oob-setup-09.txt | = draft-ietf-sidr-rpki-oob-setup-test.xml
If = 'draft-ietf-sidr-rpki-oob-setup-test.xml' is not a typo you can use = command-not-found to lookup the package that contains it, like = this:
    cnf = draft-ietf-sidr-rpki-oob-setup-test.xml
Traceback= (most recent call last):
  File "/usr/bin/id2xml", line 9, = in <module>
    = load_entry_point('id2xml=3D=3D0.9.2', 'console_scripts', = 'id2xml')()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 558, = in load_entry_point
    return = get_distribution(dist).load_entry_point(group, name)
  = File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line = 2682, in load_entry_point
    return = ep.load()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2355, = in load
    return self.resolve()
  = File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line = 2361, in resolve
    module =3D = __import__(self.module_name, fromlist=3D['__name__'], = level=3D0)
  File = "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 44, in = <module>
    from __init__ import = __version__
ImportError: No module named =E2=80=98__init__'


> = id2xml --help
Traceback (most recent call = last):
  File "/usr/bin/id2xml", line 9, = in <module>
    = load_entry_point('id2xml=3D=3D0.9.2', 'console_scripts', = 'id2xml')()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 558, = in load_entry_point
    return = get_distribution(dist).load_entry_point(group, name)
  = File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line = 2682, in load_entry_point
  =   return ep.load()
  = File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line = 2355, in load
    return = self.resolve()
  File = "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 2361, = in resolve
    module =3D = __import__(self.module_name, fromlist=3D['__name__'], = level=3D0)
  File = "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 44, in = <module>
    from __init__ import = __version__
ImportError: No module named = '__init__'




On May 15, 2017, at 1:15 PM, = Robert Sparks <rjsparks@nostrum.com> wrote:



On 5/15/17 3:53 PM, Russ Housley wrote:
Henrik:

After  $ pip install id2xml, what is the command line to = produce a .xml form a .txt that contains an RFC or Internet-Draft?
id2xml draft-whatever.txt

id2xml --help shows a lot of options

Russ



On May 15, 2017, at 6:59 AM, Henrik Levkowetz <henrik@levkowetz.com> wrote:

Hi,

I've just uploaded the third = preview release (0.9.2) of 'id2xml', the
text-submission = converter tool:

 https://pypi.python.org/pypi/id2xml

You should be able to install it with:

 $ pip install id2xml

All = feedback is very welcome.


= =46rom the README file:

This tool, = 'id2xml', is intended for use by the RFC-Editor staff, in order to
produce a first xml2rfc-compatible XML version from text-only = Internet-Draft
submissions.

id2xml may also be useful for Internet-Draft authors who wish = to start working
on a new version of an older draft or = RFC, for which no xml2rfc-compatible XML
source is = available.

The releases of the 0.9.x = release series are preview releases, with a number
of = known deficiencies.  They are released in order that potential = users may
provide feedback on the most desired = improvements ahead of a 1.0.0 release.

Version 0.9.0 can process the drafts specified in the = development Statement of
Work to XML files acceptable to = xml2rfc, and can also process a number of
other test files = to acceptable XML.  However, adding new drafts to the test
set still reveals weaknesses in many cases, so trouble-free = processing of any
arbitrary draft should not be expected = from the 0.9.x series.

The XML produced = follows RFC 7749 [1]_ in version 0.9.x and 1.x of the tool, and will = follow RFC 7991 [2]_ in version 2.x, which will be released once
support is available to process XML sources which follows the = RFC 7991
vocabulary.


.. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC = 7749, DOI
  10.17487/RFC7749, February 2016, = <http://www.rfc-editor.org/info/rfc7749>.

.. [2] Hoffman, P., "The "xml2rfc" Version 3 = Vocabulary", RFC 7991, DOI
  10.17487/RFC7991, = December 2016, http://www.rfc-editor.org/info/rfc7991>.


Best regards,

= Henrik



_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development
_______________________________________________TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development


= --Apple-Mail=_8C2AF5B1-89AD-4BFE-82FA-007A7C7DDA7A-- From nobody Mon May 15 14:05:17 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9F21243F3 for ; Mon, 15 May 2017 14:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyMyLpnWVkKv for ; Mon, 15 May 2017 14:05:14 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69683129562 for ; Mon, 15 May 2017 14:02:28 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:50032 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dAN8N-0002Gj-8Z; Mon, 15 May 2017 14:02:28 -0700 To: Sandy Ginoza , Robert Sparks References: <59198A25.9010206@levkowetz.com> <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> <3e742421-2c31-3327-9551-0725252f45c8@nostrum.com> <2CFEC0BB-D0AE-4391-9E0B-AA170874F914@amsl.com> Cc: Megan Ferguson , IETF Tools Development From: Henrik Levkowetz Message-ID: <591A175B.4020108@levkowetz.com> Date: Mon, 15 May 2017 23:02:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2CFEC0BB-D0AE-4391-9E0B-AA170874F914@amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="38a1Fgkj3tthVgfDusXPUIfnAKaBawksS" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.com, rjsparks@nostrum.com, sginoza@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 21:05:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --38a1Fgkj3tthVgfDusXPUIfnAKaBawksS Content-Type: multipart/mixed; boundary="rUNSFjdq5e5jhEBeG6uGkTwAer6JrSqeE"; protected-headers="v1" From: Henrik Levkowetz To: Sandy Ginoza , Robert Sparks Cc: Megan Ferguson , IETF Tools Development Message-ID: <591A175B.4020108@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <59198A25.9010206@levkowetz.com> <7B6CCAAC-766D-430B-B109-53EB327F3464@vigilsec.com> <3e742421-2c31-3327-9551-0725252f45c8@nostrum.com> <2CFEC0BB-D0AE-4391-9E0B-AA170874F914@amsl.com> In-Reply-To: <2CFEC0BB-D0AE-4391-9E0B-AA170874F914@amsl.com> --rUNSFjdq5e5jhEBeG6uGkTwAer6JrSqeE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sandy, Responding off list. Best, Henrik On 2017-05-15 22:38, Sandy Ginoza wrote: > Hi all, >=20 > Please note that I=E2=80=99ve added Megan Ferguson to the thread, as sh= e is the lead for testing v3-related tools for the RPC. =20 >=20 > We haven=E2=80=99t been able to successfully run id2xml yet. Matt inst= alled the updated version for us this morning to see if that helped, but = we=E2=80=99re still getting the same errors and we=E2=80=99re unable to v= iew output of "id2xml =E2=80=94help" >=20 > Are we missing something? Some of the error messages are below. >=20 > Thanks! > Sandy >=20 >> > id2xml draft-ietf-rtgwg-yang-key-chain-24test.txt >> Traceback (most recent call last): >> File "/usr/bin/id2xml", line 9, in >> load_entry_point('id2xml=3D=3D0.9.1', 'console_scripts', 'id2xml')(= ) >> File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 558, in load_entry_point >> return get_distribution(dist).load_entry_point(group, name) >> File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2682, in load_entry_point >> return ep.load() >> File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2355, in load >> return self.resolve() >> File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2361, in resolve >> module =3D __import__(self.module_name, fromlist=3D['__name__'], le= vel=3D0) >> File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 43, in= >> from __init__ import __version__ >> ImportError: No module named =E2=80=98__init__' >=20 >> id2xml draft-ietf-sidr-rpki-oob-setup-09.txt > draft-ietf-sidr-rpki-oo= b-setup-test.xml > Traceback (most recent call last): > File "/usr/bin/id2xml", line 9, in > load_entry_point('id2xml=3D=3D0.9.1', 'console_scripts', 'id2xml')(= ) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 558, in load_entry_point > return get_distribution(dist).load_entry_point(group, name) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2682, in load_entry_point > return ep.load() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2355, in load > return self.resolve() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2361, in resolve > module =3D __import__(self.module_name, fromlist=3D['__name__'], le= vel=3D0) > File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 43, in= > from __init__ import __version__ > ImportError: No module named =E2=80=98__init__' >=20 >=20 >> id2xml draft-ietf-sidr-rpki-oob-setup-09.txt | draft-ietf-sidr-rpki-oo= b-setup-test.xml > If 'draft-ietf-sidr-rpki-oob-setup-test.xml' is not a typo you can use = command-not-found to lookup the package that contains it, like this: > cnf draft-ietf-sidr-rpki-oob-setup-test.xml > Traceback (most recent call last): > File "/usr/bin/id2xml", line 9, in > load_entry_point('id2xml=3D=3D0.9.2', 'console_scripts', 'id2xml')(= ) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 558, in load_entry_point > return get_distribution(dist).load_entry_point(group, name) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2682, in load_entry_point > return ep.load() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2355, in load > return self.resolve() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2361, in resolve > module =3D __import__(self.module_name, fromlist=3D['__name__'], le= vel=3D0) > File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 44, in= > from __init__ import __version__ > ImportError: No module named =E2=80=98__init__' >=20 >=20 >> id2xml --help > Traceback (most recent call last): > File "/usr/bin/id2xml", line 9, in > load_entry_point('id2xml=3D=3D0.9.2', 'console_scripts', 'id2xml')(= ) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 558, in load_entry_point > return get_distribution(dist).load_entry_point(group, name) > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2682, in load_entry_point > return ep.load() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2355, in load > return self.resolve() > File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", li= ne 2361, in resolve > module =3D __import__(self.module_name, fromlist=3D['__name__'], le= vel=3D0) > File "/usr/lib/python3.4/site-packages/id2xml/parser.py", line 44, in= > from __init__ import __version__ > ImportError: No module named '__init__' >=20 >=20 >=20 >=20 >> On May 15, 2017, at 1:15 PM, Robert Sparks wrot= e: >>=20 >>=20 >>=20 >> On 5/15/17 3:53 PM, Russ Housley wrote: >>> Henrik: >>>=20 >>> After $ pip install id2xml, what is the command line to produce a .x= ml form a .txt that contains an RFC or Internet-Draft? >> id2xml draft-whatever.txt >>=20 >> id2xml --help shows a lot of options >>>=20 >>> Russ >>>=20 >>>=20 >>>=20 >>>> On May 15, 2017, at 6:59 AM, Henrik Levkowetz = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I've just uploaded the third preview release (0.9.2) of 'id2xml', th= e >>>> text-submission converter tool: >>>>=20 >>>> https://pypi.python.org/pypi/id2xml >>>>=20 >>>> You should be able to install it with: >>>>=20 >>>> $ pip install id2xml >>>>=20 >>>> All feedback is very welcome. >>>>=20 >>>>=20 >>>> From the README file: >>>>=20 >>>> This tool, 'id2xml', is intended for use by the RFC-Editor staff, in= order to >>>> produce a first xml2rfc-compatible XML version from text-only Intern= et-Draft >>>> submissions. >>>>=20 >>>> id2xml may also be useful for Internet-Draft authors who wish to sta= rt working >>>> on a new version of an older draft or RFC, for which no xml2rfc-comp= atible XML >>>> source is available. >>>>=20 >>>> The releases of the 0.9.x release series are preview releases, with = a number >>>> of known deficiencies. They are released in order that potential us= ers may >>>> provide feedback on the most desired improvements ahead of a 1.0.0 r= elease. >>>>=20 >>>> Version 0.9.0 can process the drafts specified in the development St= atement of >>>> Work to XML files acceptable to xml2rfc, and can also process a numb= er of >>>> other test files to acceptable XML. However, adding new drafts to t= he test >>>> set still reveals weaknesses in many cases, so trouble-free processi= ng of any >>>> arbitrary draft should not be expected from the 0.9.x series. >>>>=20 >>>> The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of t= he tool, and will follow RFC 7991 [2]_ in version 2.x, which will be rele= ased once >>>> support is available to process XML sources which follows the RFC 79= 91 >>>> vocabulary. >>>>=20 >>>>=20 >>>> .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, = DOI >>>> 10.17487/RFC7749, February 2016, . >>>>=20 >>>> .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, = DOI >>>> 10.17487/RFC7991, December 2016, http://www.rfc-editor.org/info/rf= c7991>. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Henrik >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TOOLS-DEVELOPMENT mailing list >>>> TOOLS-DEVELOPMENT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tools-development >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >=20 >=20 --rUNSFjdq5e5jhEBeG6uGkTwAer6JrSqeE-- --38a1Fgkj3tthVgfDusXPUIfnAKaBawksS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZGhdbAAoJEE6bV0uPuxcaJk8QAJKjAv0xSBtAyrG6G8NVu9Nw ZkcZotJo6LicYHr2cOckJ/1V+m64HghzSJ1Gc9OcktzOwysjOhbIzq+ws88QJwg3 wZU+scCmnjD8CZY6dPXV6aMC5xZrEVkeLfp09Om4rkY/CJUZbAI18+wIzssDUpbQ OSjlH2vxJjB0qtt7r22iKCeiy5geS+147n1sMI2iFrktWi975QFJdrY+wgB+l518 lKMVKWnnAorGwNGWcA+UMXDkY0Vi0GBiOEnamYYWdGxkvrVD/Z6stPk0x3Mk05IJ rteN3+HQy7TrrfjbC9hGxiZ0BhdNjLlacZm9MJBCQEFq6gZxoqDr8aTnHWw2NM35 Zx9Qr25+HRMRJuDWNjtj4nlIrXLRVvcCfvHmzzTAAnsS5hv4nCE/e0Drj7MJbw6W RGtnMd3sS/R4w2uLWYGksAjxSJKmiVT5VAwLs/sny/NvjOiiEBgWhU+l4+0rZGCc +5wi+OllgIA12vtTTqTLamuaZ9tlZw5Js6OAFuuCLccXXLd00rCtwDCtphG22jUF p+Naif2tHiIWfZviqrLpFFNlltILgR23BWOWZ0LmMNZpQ0pWPfAFKIwpGlNlj36n tHeMpVOq7UN55heVEN8wbFzmHUW1xE99RdgHf9tPABJqf47JXXigvEc0cP4AcYmk 9adu9hE1veL9njQR3RP+ =9Cmb -----END PGP SIGNATURE----- --38a1Fgkj3tthVgfDusXPUIfnAKaBawksS-- From nobody Mon May 15 22:22:29 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCFA12EB3A for ; Mon, 15 May 2017 22:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7iYuaRmvDiu for ; Mon, 15 May 2017 22:22:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8F912957C for ; Mon, 15 May 2017 22:19:51 -0700 (PDT) Received: from [192.168.178.20] ([93.217.65.198]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lqn7e-1deceP3fOs-00eIR0; Tue, 16 May 2017 07:19:32 +0200 To: Henrik Levkowetz References: <59198A25.9010206@levkowetz.com> Cc: IETF Tools Development From: Julian Reschke Message-ID: <9cda6ddd-a31f-0123-1985-6d2edb7b1eaf@gmx.de> Date: Tue, 16 May 2017 07:19:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <59198A25.9010206@levkowetz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PqQWTt78ldU+0Y5vPNp35BJZrgig2LhrhJAoOzaceU1FwLqlcVJ 7BhQ3vdgrRZ7q/hbI+SW4ji2djLS7XWOVfNWK4sS84ejQx1QmMaXRI4/3k1T2iHy1pVfEsi wFOHsjd6osOjQEaFRVZReAp+hQ+4hH9vsZRdXvdFd3RUHM7uuYY+E9gED+FqquRl8A0ZQkA C2Kmyyy3uhqn1YtFFv0nA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2fuGOcAIDvw=:l3PXG00hi9+qPD7U/02rp9 P5lVQkUoiNm4dK1r3sYmeaWTwPribRzgrhiGAahOuEYXa7YPaxgvu42IAKbbl6vWyIpRatNVu P8MH2Q8KxeKiygIafTogmLhIZhZ2VvqJYwFOe128rn04yqF7iBw3SrLNvBAK4FYHS0V6HV0ms 3zAnGyv409jro2mHQLwtK6i7wRHscK/ltQ5IMl7aVHOXnPOLj60Gz7OakXID9vQivmUpGuoLN QXcuM15Ww5wnKIwBNviJLK71mWIaPEIH7H6uPx872SSa8nvCVXqR75HTf2C3CgsTUiOsRf1bf XfUlyKKiRsYyLQlTKUF+JaHPtXBBYBgLxlDCg2iQx/bgKfXgmUJ8KLeVIjNaEnglM64gcAWxz HNFmFS8jKtFOWlNDjy80VMx3/eLktLFBA+I4X2s6lijzkdB9azWImfnS+14HZXZvAhG41u7t+ dLu+i3jxCo2raJAyB8mT37CFL1KiiZ+LX26kgQADEiyTGdRkKpaL0dq9qCr66xJ5bYtcxZ1Qj zEsxUZMj4oJissmeaSCRC55r+D118cvZR2dtqE/7FV/dNX2sTFdCQATXfLLGlC9xrHWFZBqQ5 noOD6dbBkE+l6wUAONv5nPtVFciIBwdWqbbVsv6CW8W/Q/K6HTVrXDz5r/kG1r4+UQg+0OZ5z 48n2vzh+CGRzbMQviHJymhf/Wfab14euvnuzrlb8TQjPxR/3u7op+OxtIkfIrllttoytMAsD4 +jmyYBKKKNnaH/KMChNh9ZeTNAxz6//F20csp8DhdhPvog6SonpQH9CwUOG6VdnHGLEJeaCEi 2xhhjXO Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 05:22:28 -0000 On 2017-05-15 12:59, Henrik Levkowetz wrote: > Hi, > > I've just uploaded the third preview release (0.9.2) of 'id2xml', the > text-submission converter tool: > ... Looks promising. Did a test run with rfc7230.txt, and re-transformed it with rfc2629.xslt. Warnings/errors: > WARNING: @initials 'R. ': did you mean 'R.'? (at line 11) > WARNING: @initials 'J. ': did you mean 'J.'? (at line 23) > WARNING: front matter mentions RFC 2616 for which there is no reference element (at line 9) > WARNING: front matter mentions RFC 2818 for which there is no reference element (at line 9) > WARNING: @initials 'R. ': did you mean 'R.'? (at line 11) > WARNING: @initials 'J. ': did you mean 'J.'? (at line 23) > ERROR: no XSLT template for element 'list' (at line 1602) > ERROR: no XSLT template for element 'list' (at line 1605) > ERROR: no XSLT template for element 'list' (at line 1602) > ERROR: no XSLT template for element 'list' (at line 1605) > WARNING: excessive whitespace in street: 'San Jose, CA 95110' (at line 16) > WARNING: excessive whitespace in street: 'Muenster, NW 48155' (at line 28) The errors about "list" is because there's no style and no enclosing list (should be style='empty'). Best regards, Julian PS: will look at the output in detail soonish... From nobody Tue May 16 09:10:31 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB6129C06 for ; Tue, 16 May 2017 09:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs1S4xpGYdGa for ; Tue, 16 May 2017 09:10:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EB712EBEC for ; Tue, 16 May 2017 09:05:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 446E7300577 for ; Tue, 16 May 2017 12:05:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RKETBWBk-bmK for ; Tue, 16 May 2017 12:05:53 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 76FA1300096; Tue, 16 May 2017 12:05:53 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <59198A25.9010206@levkowetz.com> Date: Tue, 16 May 2017 12:05:53 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: <8279F426-97CE-40E9-9708-0A881E5348E2@vigilsec.com> References: <59198A25.9010206@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:10:29 -0000 Henrik: I used draft-ietf-curdle-cms-eddsa-signatures-05.txt as the input, and I = got a few surprises. I used xml2rfc to generate a text file from the = .xml that id2xml produced First, the heading on the title page. ORIGINAL Internet-Draft R. Housley Intended status: Standards Track Vigil Security Expires: 11 October 2017 11 April 2017 Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) NEW Internet-Draft R. Housley Internet-Draft Vigil Security Expires: October 13, 2017 April 11, 2017 Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) draft-ietf-curdle-cms-eddsa-signatures-05.txt Second, the top of each page. This can probably be resolved by only = using the Month and Year, but the result is a bit odd. ORIGINAL Internet-Draft 11 April 2017 NEW Internet-Draft 11 April 2017 Third, the NOTE format. ORIGINAL NOTE: Either id-sha512 or id-shake256 is used as part to the private key signing operation. However, the private key signing operation does not take a message digest computed with one of these algorithms as an input. NEW NOTE: Either id-sha512 or id-shake256 is used as part to the private key signing operation. However, the private key signing operation does not take a message digest computed with one of these algorithms as an input. Fourth, and indented quote. ORIGINAL The EdDSA specification [EDDSA] includes the following warning. It deserves highlighting, especially when signed-data is used without signed attributes and the content to be signed might be quite large: PureEdDSA requires two passes over the input. Many existing APIs, protocols, and environments assume digital signature algorithms only need one pass over the input, and may have API or bandwidth concerns supporting anything else. NEW The EdDSA specification [EDDSA] includes the following warning. It deserves highlighting, especially when signed-data is used without signed attributes and the content to be signed might be quite large: PureEdDSA requires two passes over the input. Many existing APIs, protocols, and environments assume digital signature algorithms only need one pass over the input, and may have API or bandwidth concerns supporting anything else. Thanks for the good work. I=E2=80=99m sure it will get better and = better. Russ > On May 15, 2017, at 6:59 AM, Henrik Levkowetz = wrote: >=20 > Hi, >=20 > I've just uploaded the third preview release (0.9.2) of 'id2xml', the > text-submission converter tool: >=20 > https://pypi.python.org/pypi/id2xml >=20 > You should be able to install it with: >=20 > $ pip install id2xml >=20 > All feedback is very welcome. >=20 >=20 > =46rom the README file: >=20 > This tool, 'id2xml', is intended for use by the RFC-Editor staff, in = order to > produce a first xml2rfc-compatible XML version from text-only = Internet-Draft > submissions. >=20 > id2xml may also be useful for Internet-Draft authors who wish to start = working > on a new version of an older draft or RFC, for which no = xml2rfc-compatible XML > source is available. >=20 > The releases of the 0.9.x release series are preview releases, with a = number > of known deficiencies. They are released in order that potential = users may > provide feedback on the most desired improvements ahead of a 1.0.0 = release. >=20 > Version 0.9.0 can process the drafts specified in the development = Statement of > Work to XML files acceptable to xml2rfc, and can also process a number = of > other test files to acceptable XML. However, adding new drafts to the = test > set still reveals weaknesses in many cases, so trouble-free processing = of any > arbitrary draft should not be expected from the 0.9.x series. >=20 > The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of the = tool, and will follow RFC 7991 [2]_ in version 2.x, which will be = released once > support is available to process XML sources which follows the RFC 7991 > vocabulary. >=20 >=20 > .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, = DOI > 10.17487/RFC7749, February 2016, = . >=20 > .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, = DOI > 10.17487/RFC7991, December 2016, = http://www.rfc-editor.org/info/rfc7991>. >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development _______________________________________________ TOOLS-DEVELOPMENT mailing list TOOLS-DEVELOPMENT@ietf.org https://www.ietf.org/mailman/listinfo/tools-development From nobody Tue May 16 16:42:44 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF97D1287A3 for ; Tue, 16 May 2017 16:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q85Pzcfz7QHW for ; Tue, 16 May 2017 16:42:40 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB07F1273B1 for ; Tue, 16 May 2017 16:38:58 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:62975 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dAm3N-0004Bj-Bt; Tue, 16 May 2017 16:38:58 -0700 To: Russ Housley References: <59198A25.9010206@levkowetz.com> <8279F426-97CE-40E9-9708-0A881E5348E2@vigilsec.com> Cc: IETF Tools Development From: Henrik Levkowetz Message-ID: <591B8D89.20108@levkowetz.com> Date: Wed, 17 May 2017 01:38:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8279F426-97CE-40E9-9708-0A881E5348E2@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rNCHFTILNLNpVcsplsSo7VVc0cNIJoehn" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, housley@vigilsec.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:42:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rNCHFTILNLNpVcsplsSo7VVc0cNIJoehn Content-Type: multipart/mixed; boundary="tKrEKjGM6sbP5MifVX8dFU0pm4tP2dw83"; protected-headers="v1" From: Henrik Levkowetz To: Russ Housley Cc: IETF Tools Development Message-ID: <591B8D89.20108@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <59198A25.9010206@levkowetz.com> <8279F426-97CE-40E9-9708-0A881E5348E2@vigilsec.com> In-Reply-To: <8279F426-97CE-40E9-9708-0A881E5348E2@vigilsec.com> --tKrEKjGM6sbP5MifVX8dFU0pm4tP2dw83 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, On 2017-05-16 18:05, Russ Housley wrote: > Henrik: >=20 > I used draft-ietf-curdle-cms-eddsa-signatures-05.txt as the input, > and I got a few surprises. I used xml2rfc to generate a text file > from the .xml that id2xml produced >=20 > First, the heading on the title page. >=20 > ORIGINAL >=20 > Internet-Draft R. Housle= y > Intended status: Standards Track Vigil Securit= y > Expires: 11 October 2017 11 April 201= 7 >=20 >=20 > Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) > >=20 >=20 > NEW >=20 > Internet-Draft R. Housle= y > Internet-Draft Vigil Securit= y > Expires: October 13, 2017 April 11, 201= 7 >=20 >=20 > Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) > draft-ietf-curdle-cms-eddsa-signatures-05.txt Yes. xml2rfc wants to put either a stream identifier, a WG name, or the traditional 'Network Working Group' as the first word of the lefhand column. It took 'Internet-Draft' to be the WG name; I've now told it to not do that (which results in 'Network Working Group' at the top left, and also in recognising the intended status). The date formatting is also as given by xml2rfc; we could change xml2rfc to produce the format you used if people would be happier with that for drafts. (It's more natural and readable for me, but I don't know if it's better in an English-language style sense.) The angle brackets around the filename are also given by xml2rfc. > Second, the top of each page. This can probably be resolved by only > using the Month and Year, but the result is a bit odd. >=20 > ORIGINAL >=20 > Internet-Draft 11 April 201= 7 >=20 > NEW >=20 > Internet-Draft 11 April 201= 7 Ugh. This is a bug. It should not be using '11' as short title. Now fixed in upcoming 0.9.4 > Third, the NOTE format. >=20 > ORIGINAL >=20 > NOTE: Either id-sha512 or id-shake256 is used as part to the > private key signing operation. However, the private key signing > operation does not take a message digest computed with one of > these algorithms as an input. >=20 > NEW >=20 > NOTE: Either id-sha512 or id-shake256 is used as part to the >=20 > private key signing operation. However, the private key signing > operation does not take a message digest computed with one of > these algorithms as an input. Yes. This is a recurring flaw. I'll see what I can do with it (but it's not as easy as it might seem, as I have to juggle list styles of nested lists to produce evenly indented paragraphs, and in this case I think the heuristics took the 'NOTE:' part as the start of a hanging list. > Fourth, and indented quote. >=20 > ORIGINAL >=20 > The EdDSA specification [EDDSA] includes the following warning. It > deserves highlighting, especially when signed-data is used without > signed attributes and the content to be signed might be quite large:= >=20 > PureEdDSA requires two passes over the input. Many existing APIs= , > protocols, and environments assume digital signature algorithms > only need one pass over the input, and may have API or bandwidth > concerns supporting anything else. >=20 > NEW >=20 > The EdDSA specification [EDDSA] includes the following warning. It > deserves highlighting, especially when signed-data is used without > signed attributes and the content to be signed might be quite large:= >=20 > PureEdDSA requires two passes over the input. Many existing APIs, >=20 > protocols, and environments assume digital signature algorithms > only need one pass over the input, and may have API or bandwidth > concerns supporting anything else. Yes. Same flaw as the third. I'll give this some attention. > Thanks for the good work. I=E2=80=99m sure it will get better and bett= er. Thank you for the feedback! Henrik > Russ >=20 >=20 >=20 >> On May 15, 2017, at 6:59 AM, Henrik Levkowetz w= rote: >>=20 >> Hi, >>=20 >> I've just uploaded the third preview release (0.9.2) of 'id2xml', the >> text-submission converter tool: >>=20 >> https://pypi.python.org/pypi/id2xml >>=20 >> You should be able to install it with: >>=20 >> $ pip install id2xml >>=20 >> All feedback is very welcome. >>=20 >>=20 >> From the README file: >>=20 >> This tool, 'id2xml', is intended for use by the RFC-Editor staff, in o= rder to >> produce a first xml2rfc-compatible XML version from text-only Internet= -Draft >> submissions. >>=20 >> id2xml may also be useful for Internet-Draft authors who wish to start= working >> on a new version of an older draft or RFC, for which no xml2rfc-compat= ible XML >> source is available. >>=20 >> The releases of the 0.9.x release series are preview releases, with a = number >> of known deficiencies. They are released in order that potential user= s may >> provide feedback on the most desired improvements ahead of a 1.0.0 rel= ease. >>=20 >> Version 0.9.0 can process the drafts specified in the development Stat= ement of >> Work to XML files acceptable to xml2rfc, and can also process a number= of >> other test files to acceptable XML. However, adding new drafts to the= test >> set still reveals weaknesses in many cases, so trouble-free processing= of any >> arbitrary draft should not be expected from the 0.9.x series. >>=20 >> The XML produced follows RFC 7749 [1]_ in version 0.9.x and 1.x of the= tool, and will follow RFC 7991 [2]_ in version 2.x, which will be releas= ed once >> support is available to process XML sources which follows the RFC 7991= >> vocabulary. >>=20 >>=20 >> .. [1] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DO= I >> 10.17487/RFC7749, February 2016, . >>=20 >> .. [2] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DO= I >> 10.17487/RFC7991, December 2016, http://www.rfc-editor.org/info/rfc79= 91>. >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --tKrEKjGM6sbP5MifVX8dFU0pm4tP2dw83-- --rNCHFTILNLNpVcsplsSo7VVc0cNIJoehn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZG42JAAoJEE6bV0uPuxca4uUP/i50C51oyNqNkcg07T2Y4RpR MwaEnCZ2JxZ0oSSdG39y4Wch+Ht2oUvGxJM9pqHC7Rbopz93eeBt7eFmVNT4x3ZD ETyX1jhu+WPzvNIdPavIq2fgN9RTiMtUqdBszeuosLxn4Vzf2tXJgYMyYwWH2PzD RTmflxLlahGuYR+xZsq+8WNLX6IDk4+aVWFTZDSczGdFrWZNS/qHQwi9dPzf6zwR vZazIbIoX55zcn+QSxf2Hp4ksnTdfDzEavti8xIIW45UvKChGafRzZRJ2hbEGsuW s/apLXv6VWERFj1IAqNtM2LuwL1GsjuxWfkuqK/PGZJnIPxBrBDYXMa9F+VhohFX PgaHe411wd2w1B61ybONSe9TlJw3K3Y1ZNBMTT6RvkY1EiaTuEgf+lWO8pygnE1h TpbZ3tLUJ0kTsp9LteLc2Gm/gRMdOpElmZreOM/64ZsdZmLM4fvBX0LwbUi5ErAR EAxhimhrqkEGFmDK2pNtrYaTrkwPdw+uywz/dBPyjKTAaM1BvkkY9x1unl4x6Wma G1jr7F+D7G5ZdlhHyb7wPRqVos9aQ/Eux7h5UHit8HztgTXHDGVF8nz8FRwxMWHS lyaVli2wUAmZlcFE6XTDXXN/UG1+L+30ze0dO9s5Fbha8bZowLfuhYAL9Vq+lJtS xex3i96/XXxSARrJOJxB =7Nk4 -----END PGP SIGNATURE----- --rNCHFTILNLNpVcsplsSo7VVc0cNIJoehn-- From nobody Thu May 18 16:10:50 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6464129B55 for ; Thu, 18 May 2017 16:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-HXUU-cWUt9 for ; Thu, 18 May 2017 16:10:45 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5DA129B29 for ; Thu, 18 May 2017 16:05:49 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:50285 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dBUUO-0007kt-F4; Thu, 18 May 2017 16:05:48 -0700 To: Julian Reschke References: <59198A25.9010206@levkowetz.com> <9cda6ddd-a31f-0123-1985-6d2edb7b1eaf@gmx.de> Cc: IETF Tools Development From: Henrik Levkowetz Message-ID: <591E28B6.90508@levkowetz.com> Date: Fri, 19 May 2017 01:05:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <9cda6ddd-a31f-0123-1985-6d2edb7b1eaf@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XvC5OQ67VqdeJHpDULI33TQq8qxVfHrqe" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 23:10:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XvC5OQ67VqdeJHpDULI33TQq8qxVfHrqe Content-Type: multipart/mixed; boundary="7jNRxGmGujXOkKMlM7PMlvbTmllk2kSEd"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke Cc: IETF Tools Development Message-ID: <591E28B6.90508@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <59198A25.9010206@levkowetz.com> <9cda6ddd-a31f-0123-1985-6d2edb7b1eaf@gmx.de> In-Reply-To: <9cda6ddd-a31f-0123-1985-6d2edb7b1eaf@gmx.de> --7jNRxGmGujXOkKMlM7PMlvbTmllk2kSEd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, All of the issues below which are due to the xml generation should be fixed in 0.9.3. I'm getting closer to releasing a 1.0.0-rc1; there are a lot of improvements since 0.9.3, so you may want to wait with looking at the generated xml in detail until that one is out. Best regards, Henrikma On 2017-05-16 07:19, Julian Reschke wrote: > On 2017-05-15 12:59, Henrik Levkowetz wrote: >> Hi, >> >> I've just uploaded the third preview release (0.9.2) of 'id2xml', the >> text-submission converter tool: >> ... >=20 > Looks promising. >=20 > Did a test run with rfc7230.txt, and re-transformed it with=20 > rfc2629.xslt. Warnings/errors: >=20 >> WARNING: @initials 'R. ': did you mean 'R.'? (at line 11) >> WARNING: @initials 'J. ': did you mean 'J.'? (at line 23) >> WARNING: front matter mentions RFC 2616 for which there is no referenc= e element (at line 9) >> WARNING: front matter mentions RFC 2818 for which there is no referenc= e element (at line 9) >> WARNING: @initials 'R. ': did you mean 'R.'? (at line 11) >> WARNING: @initials 'J. ': did you mean 'J.'? (at line 23) >> ERROR: no XSLT template for element 'list' (at line 1602) >> ERROR: no XSLT template for element 'list' (at line 1605) >> ERROR: no XSLT template for element 'list' (at line 1602) >> ERROR: no XSLT template for element 'list' (at line 1605) >> WARNING: excessive whitespace in street: 'San Jose, CA 95110' (at lin= e 16) >> WARNING: excessive whitespace in street: 'Muenster, NW 48155' (at lin= e 28) >=20 > The errors about "list" is because there's no style and no enclosing=20 > list (should be style=3D'empty'). >=20 > Best regards, Julian >=20 > PS: will look at the output in detail soonish... >=20 --7jNRxGmGujXOkKMlM7PMlvbTmllk2kSEd-- --XvC5OQ67VqdeJHpDULI33TQq8qxVfHrqe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZHijDAAoJEE6bV0uPuxcaUpkQAItLlKNlAQWz1Ry7TSa28dpe X2Qoak+/2DKABC0yObAiz1xJc4fmNq2sh/YHGIxB+XjPZmShEfN+RW+fwAmjXYN2 DSFDIpvtBPk3r6xnbLbCE2fCQhr/6DSNuWKumXVSugHTnsClQgyZ3JGD7+4g6twg ATxeWsqufx58QS/GK4ssVQ4Rvo/lJuLUp7VERIOJKbS16Wyl/fh1tpQ/pyi8aOEp MSIXYe2I7qhlxi9wCNwniXjl8VfvgAuyYQ26SP5O0UEHW5DZMl8VnYgmNTORBXOc ck+I0AwfU8CRoQjhIfVPv3sr7pHzb/bVclNyOq5v0GE+T0TpDohmyVGtPXd1jF6p Qr9WtOYeCeSONh0FoByS85c0f/9NLyVedRzH8fu4pHbbrOGYJ/FMM3GtWOAhnEVq OlJrDplEKATMYYSVt5ySDMHyK4XFqJA49bvl6A4VWlXjMMGmIKUXVsM0U4mjKNLt iIWo38TcYli4DzKBbey7mGv21a8ggKvSXRcxprZDmX8Qsv7n9pjyI4O6+dpT1Hiu CrZTeYwJKuJXNSX5NtDV4L/uqB1uyZMQLPaLKZ4SIe975wZ3tv8n6ko0wLFdWqCb 3sKaeAocPOS+jU18haRzdNd9PxmOnB1f6JrkPws1H+ag5jVbxCGMrv7mSDQ9Hro6 /2TIKgQLHNw7DhJ/RT8q =R3fD -----END PGP SIGNATURE----- --XvC5OQ67VqdeJHpDULI33TQq8qxVfHrqe-- From nobody Fri May 19 12:53:53 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D031296B3 for ; Fri, 19 May 2017 12:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE775TXGj_sT for ; Fri, 19 May 2017 12:53:50 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FBE129508 for ; Fri, 19 May 2017 12:53:50 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:57567 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dBny7-0002kI-61; Fri, 19 May 2017 12:53:49 -0700 From: Henrik Levkowetz Cc: IETF Tools Development To: RFC Editor Message-ID: <591F4D41.6050908@levkowetz.com> Date: Fri, 19 May 2017 21:53:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rp61dEoMPbqjF7FrdwPCIJKu8oUt9FGdm" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, rfc-editor@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 19:53:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rp61dEoMPbqjF7FrdwPCIJKu8oUt9FGdm Content-Type: multipart/mixed; boundary="4CoMcr73HIBt9MKXFsTukDr8SEMIRbr9u"; protected-headers="v1" From: Henrik Levkowetz To: RFC Editor Cc: IETF Tools Development Message-ID: <591F4D41.6050908@levkowetz.com> Subject: Preview release of Text Submission Converter, id2xml --4CoMcr73HIBt9MKXFsTukDr8SEMIRbr9u Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've just uploaded the first 1.0.0 release candidate of id2xml: 1.0.0-rc1= : https://pypi.python.org/pypi/id2xml This version processes all the files in the current test suite with only minor discrepancies between the original .txt files and those created by xml2rfc from the generated .xml files. There are still corner cases, but= I believe this version should be useful for the stated purpose. You should be able to install it with: $ pip install id2xml As before, feedback is very welcome. =46rom the changelog: * Improved the code recognition regex, in order to handle more code and= constants fragments as figures. * Added recognition and handling of and marks= =2E * Added recognition of reference text date strings containing days. * Added recognition of another usage of 'Work-in-progress' in reference= s. * Modified list handling to recognise lists in additional formats, and = to use to introduce line breaks and blank lines for some cases.= * Added recognition of reference quotes within list text. * Added 2 new ways to recognize text which needs to be captured as figu= res (based on recurring wide whitespace and on text not being paragraph f= illed). * Added better handling of draft references for the purpose of generati= ng proper entity definitions in the doctype declaration. * Refined the test suite to show percentages of lines which deviate bet= ween text master and the text generated from the generated xml, and to not= include differences in the ToC page numbers in the checked diff linecounts. * Added support for title abbreviation occuring in the footer, rather=20 than the header. Explicitly created a title abbreviation for long ti= tles=20 with no abbreviation available, rather than letting xml2rfc mangle th= e page=20 header. * Improved the debug trace facilities with --start-trace on a text match= , --stop-trace on a text match, and --trace one or more function names. * Tweaked the setup to make the local debug.py available. * Don't interpret 'Internet-Draft' at the top left of the first page as= a=20 workgroup name. Test case added. * Added list default style 'empty', based on an issue report from=20 julian.reschke@gmx.de. * Added stripping of leading/trailing blanks from author name component= s=20 (initials and surname), based on an issue report from julian.reschke@= gmx.de. * Renamed the subversion branch to match the selected tool name. -- Henrik Levkowetz 19 May 2017 20:32:32 +0200 Best regards, Henrik --4CoMcr73HIBt9MKXFsTukDr8SEMIRbr9u-- --rp61dEoMPbqjF7FrdwPCIJKu8oUt9FGdm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZH01BAAoJEE6bV0uPuxcawxoP/3dDwvYYChrEfWI199PduS/J VAcVuHFzYpqspLNTmHn30Kl7uCSwx8+93xyFTLY5JOg96paxymUCvNmqJYA8EKps r12yMw7Pi3czwWRCQFVM4vpSRCsYfZXoUgWw6nEBQ26e/dFzYsOEkIVVpByVaJma VfRgKFW5i4wm3xvcUO/r8A3vBWRTBaFdRteptkCXtdxEWc3CTaL+gMp1ecYfNqSu J5qBS1iTq95NbUl4ns+lkRWJ9i9fTmoTAYhVo4xCJIAstezgSBMiklu2vKXP2Bv+ X67xYwIyru1UtdCX3CoX4a2wQNEdKL/Qiqqbwye4hudJrra3Y5GABX1h5uqEese8 WRQAHXKQ72wBCFT02/x2I0FfVnlfmLIXurv9PiMD939Zqpi3TKQpgKaur1kzWPyh iOjkGzJY3y/rHfRwIVB9vhA8TEmbr9ZzuCoWvjfYQI0tvF5Iaj9cc9vMAugtYvPx R5Tu1dg46xc2JSeBMG3DvhnM6xEYbO+RkiLZ9cOFxjrqbm/rAp8psHG4xAzystnI 6if7qZHhWQWV3PfST7g+f0aEH7qYFsI0lOnlj17uyf6/zFh/cZT50y3RguFjpvao U4ZczW2LCye8yMQ78xcfObXCVBeX4RIpIJ7CeNOABnAAwAWi+HsQb2ZPABFxoLZa ptWHBrSKXpu3hkTHots5 =HRks -----END PGP SIGNATURE----- --rp61dEoMPbqjF7FrdwPCIJKu8oUt9FGdm-- From nobody Fri May 19 12:55:46 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF29129434 for ; Fri, 19 May 2017 12:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrqJdiyZ_qK7 for ; Fri, 19 May 2017 12:55:42 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46343120046 for ; Fri, 19 May 2017 12:55:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A68641C52E7; Fri, 19 May 2017 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssgst4cUs5z6; Fri, 19 May 2017 12:55:36 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 600161C5011; Fri, 19 May 2017 12:55:36 -0700 (PDT) From: Megan Ferguson Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 19 May 2017 12:55:42 -0700 Message-Id: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> Cc: tools-development@ietf.org To: henrik@levkowetz.com Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 19:55:45 -0000 Hi Henrik, Some notes on our initial test pass. Please let me know if you would = like any further information on any of the points below. Disclaimer: We understand that the editors will need to clean up the XML = when it=92s been converted from .txt to .xml. Please note that we are = reporting oddities without trying to figure out which ones could be = fixed (i.e., automated). =20 Thank you. Megan PIs, etc. =97=97 1) We were surprised to see symrefs set to no as most reference entries = we see use the RFC number as citation tag. 2) We see the encoding as utf-8. We were under the impression that = ascii would be the default unless utf-8 characters were included in the = file, which they were not in our test cases. Author elements =97=97=97=97=97=97=97=97 3) We see several differences in the use of the elements in the author=92s= postal address. v2: = Cisco Systems
821 Alder Drive Milpitas 95035 CA USA ginsberg@cisco.com
id2xml: Cisco Systems
821 Alder Drive Milpitas, CA 95035 USA ginsberg@cisco.com
Artwork tags vs. lists=20 =97=97=97=97=97=97=97 4) The following list was converted to a hanging list, which really = changed the output. =20 The author-submitted version had this list in artwork. Original text: An MI-RTR MUST NOT support [RFC5120] multi-topology within a non-zero instance when any non-zero ITID is supported. The following TLVs MUST NOT be sent in an LSP associated with a non-zero instance which supports a non-zero ITID and such an LSP MUST be ignored when received: TLV 222 - MT IS Neighbors TLV 235 - MT IP Reachability TLV 237 - MT IPv6 Reachability id2xml text output: An MI-RTR MUST NOT support [RFC5120] multi-topology within a non-zero instance when any non-zero ITID is supported. The following TLVs MUST NOT be sent in an LSP associated with a non-zero instance which supports a non-zero ITID and such an LSP MUST be ignored when received: TLV 222 - MT IS Neighbors TLV 235 - MT IP Reachability TLV 237 - MT IPv6 Reachability In v2 (as submitted by authors):
In id2xml: TLV 235 - MT IP Reachability TLV 237 - MT IPv6 Reachability Another related example: In the original text: Per [RFC6822], IANA has registered two EUI-48 multicast addresses from the IANA-managed EUI address space as specified in [RFC7042]. The addresses are as follows: 01-00-5E-90-00-02 AllL1MI-ISs 01-00-5E-90-00-03 AllL2MI-ISs All references to [RFC6822] in the IS-IS TLV Codepoints registry should be replaced by references to this document. In the id2xml text output: Per [RFC6822], IANA has registered two EUI-48 multicast addresses from the IANA-managed EUI address space as specified in [RFC7042]. The addresses are as follows: 01-00-5E-90-00-02 AllL1MI-ISs 01-00-5E-90-00-03 AllL2MI-ISs All references to [RFC6822] in the IS-IS TLV Codepoints registry should be replaced by references to this document. In v2 (as submitted by authors)
In id2xml: 01-00-5E-90-00-03 AllL2MI-ISs 5) The text following this figure was originally included in an = tag and appeared as slightly indented in the text. original text: Type: 7 Length: 2 - 254 Value: No. of octets +-------------------------+ | IID (0 - 65535) | 2 +-------------------------+ | Supported ITID | 2 +-------------------------+ : : +-------------------------+ | Supported ITID | 2 +-------------------------+ When the IID =3D 0, the list of supported ITIDs MUST NOT be = present. An IID-TLV with IID =3D 0 MUST NOT appear in an SNP or LSP. When the TLV appears (with a non-zero IID) in an SNP or LSP, exactly one ITID MUST be present indicating the instance-specific topology with which the PDU is associated. If no ITIDs or multiple ITIDs are present or the IID is zero, then the PDU MUST be ignored. When the IID is non-zero and the TLV appears in an IIH, the set of ITIDs supported on the circuit over which the IIH is sent is included. There MUST be at least one ITID present. ITID #0 is reserved for a specific use case as described later in this document. ITID #0 MUST NOT be supported in combination with any non-zero ITID. If multiple ITIDs are advertised in an IIH and one of the ITIDs is #0 then the PDU MUST be ignored. Multiple IID-TLVs MAY appear in IIHs. If multiple IID-TLVs are present and the IID value in all IID-TLVs is not the same, then the PDU MUST be ignored. A single IID-TLV will support advertisement of up to 126 ITIDs. If multiple IID-TLVs are present in an IIH PDU, the supported set of ITIDs is the union of all ITIDs present in all IID-TLVs. id2xml text output: Type: 7 Length: 2 - 254 Value: No. of octets +-------------------------+ | IID (0 - 65535) | 2 +-------------------------+ | Supported ITID | 2 +-------------------------+ : : +-------------------------+ | Supported ITID | 2 +-------------------------+ When the IID =3D 0, the list of supported ITIDs MUST NOT be present. An IID-TLV with IID =3D 0 MUST NOT appear in an SNP or LSP. When the TLV appears (with a non-zero IID) in an SNP or LSP, exactly one ITID MUST be present indicating the instance-specific topology with which the PDU is associated. If no ITIDs or multiple ITIDs are present or the IID is zero, then the PDU MUST be ignored. When the IID is non-zero and the TLV appears in an IIH, the set of ITIDs supported on the circuit over which the IIH is sent is included. There MUST be at least one ITID present. ITID #0 is reserved for a specific use case as described later in this document. ITID #0 MUST NOT be supported in combination with any non-zero ITID. If multiple ITIDs are advertised in an IIH and one of the ITIDs is #0 then the PDU MUST be ignored. Multiple IID-TLVs MAY appear in IIHs. If multiple IID-TLVs are present and the IID value in all IID-TLVs is not the same, then the PDU MUST be ignored. A single IID-TLV will support advertisement of up to 126 ITIDs. If multiple IID-TLVs are present in an IIH PDU, the supported set of ITIDs is the union of all ITIDs present in all IID-TLVs. In v2:
A single IID-TLV will support advertisement of up to 126 ITIDs. = If multiple IID-TLVs are present in an IIH PDU, the supported set of ITIDs is the union of all ITIDs present in all IID-TLVs. id2xml:
When the IID =3D 0, the list of supported = ITIDs MUST NOT be present.
the TLV appears (with a non-zero IID) in an SNP or LSP, exactly one ITID MUST be present indicating the instance-specific topology with which the PDU is associated. If no ITIDs or multiple ITIDs are present or the IID is zero, then the PDU MUST be ignored. of ITIDs supported on the circuit over which the IIH is sent is included. There MUST be at least one ITID present. in this document. ITID #0 MUST NOT be supported in combination with any non-zero ITID. If multiple ITIDs are advertised in an IIH and one of the ITIDs is #0 then the PDU MUST be = ignored. present and the IID value in all IID-TLVs is not the same, then the PDU MUST be ignored. A single IID-TLV will support advertisement of up to 126 ITIDs. If multiple IID-TLVs are present in an IIH PDU, the supported set of ITIDs is the union of all ITIDs present in all IID-TLVs. Citations throughout text =97=97=97=97=97=97=97=97=97 6) It appears that citations were not converted to xref tags throughout. = For example: v2:
Security concerns for IS-IS are addressed in [ISO10589, [RFC5304], and [RFC5310].
id2xml:
Security concerns for IS-IS are addressed in [ISO10589, [RFC5304], = and [RFC5310].
Reference Entries in the References section =97=97=97=97=97=97=97=97 7) We note that elements were not used and the references = section was created using a
element instead of = and appears in the as opposed to . =20 Is it possible to make these be includes (e.g., )? That way, the RPC will know the = entries are being pulled from the citation library and contain the = correct information. We understand that v3 will have to contain the = expanded references. =20 in v2: Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction = with the protocol for providing the connectionless-mode Network = Service (ISO 8473), ISO/IEC 10589:2002, Second Edition. in id2xml:
"Intermediate system to Intermediate system = intra-domain routeing information exchange protocol for use in = conjunction with the protocol for providing the connectionless-mode = Network Service (ISO 8473), ISO/IEC 10589:2002, Second Edition.", Nov = 2002.Bradner, S., "Key words for use in = RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: = Multi Topology (MT) Routing in Intermediate System to Intermediate = Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, .Katz, D., Saluja, R., and D. Eastlake 3rd, = "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, October 2008, .Li, T. and R. Atkinson, "IS-IS Cryptographic = Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, .Shand, M. and L. Ginsberg, "Restart Signaling for = IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, .Bhatia, M., Manral, V., Li, T., Atkinson, R., = White, R., and M. Fanto, "IS-IS Generic Cryptographic = Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, .Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled = TLV", RFC 6213, DOI 10.17487/RFC6213, April 2011, .Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, = "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, .Li, T. and L. Ginsberg, "IS-IS Registry Extension = for Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, .
. ]]>
Ginsberg, L., Previdi, S., and M. = Shand, "Advertising Generic Information in IS-IS", RFC 6823, DOI 10.17487/RFC6823, December 2012, .
Shen, N., Ed. and A. Zinin, Ed., = "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC = 5309, DOI 10.17487/RFC5309, October 2008, . Eastlake 3rd, D. and J. Abley, = "IANA Considerations and IETF Protocol and Documentation Usage for IEEE = 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, .
8) In v2, there is currently a setting to keep DOIs, draft strings, and = URLs on the same line (if possible for the latter). 9) We generally see a single space after the author initials instead of = two spaces there. original text: [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . id2xml text output: [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . From nobody Fri May 19 13:26:50 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C5512945A for ; Fri, 19 May 2017 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW4VbHw80wXr for ; Fri, 19 May 2017 13:26:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD97129440 for ; Fri, 19 May 2017 13:26:46 -0700 (PDT) Received: from [192.168.178.20] ([93.217.79.69]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MCxfb-1dJpDQ1lcx-009ft2; Fri, 19 May 2017 22:26:15 +0200 To: Megan Ferguson , henrik@levkowetz.com References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> Cc: tools-development@ietf.org From: Julian Reschke Message-ID: <46baaba1-07ef-5a77-845a-e03083aec97d@gmx.de> Date: Fri, 19 May 2017 22:26:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:kIPuh4+0R0qLou5D1YHx714wnEWFSClvgJmJtuXSmkaukgzKYBS k2a8mPatXaO1GuEYFDZrEiNwupG7OCvRN6LBvjsxdMl08CMZG+52Fn1Iq/6INuVldyXrL0E aiYOERPqPojBDM70Xwv/JaNEBsHkvTAs15Q0cJkY0kIZFbQLlVrSyC1UtSQQaTWLm5iiGnM MjDK3/WX9eX/RQgTEviVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:R50mFl+wpSw=:dqKedc9ptJ/6p4tKHBEd9m SzdBA3MaUPxIM8cB6NGpnA7YapVd7fMQqze9y3c8HpqpHZzSqvYXNFvGZHc13JOb/OmpLh5d/ QkhyzNzO/g6OJyLoheoAJZMXbio2W3mZyjCN6gTj0arks/lqNWSqRdQngu2dOYv1NabxYc5v6 b/TYOIqeT8wp4TJRmFN0WVCZTs9wDifToIIaWk1yEQk9u98AHkn0JrM9GiaF/QcNazPSN8/32 EQ19xanFnoKFHu4IH1LWF0acSeBdcZfoAQEsc3OJib09hMHftynepqbV6sMjCBDaibR9jusw2 httsQDdvvxKzoeDdfnzQ3XNksKYoJb6uNI4T2NhHDxUTOAxVqZiEtwQlHOi8mBoVF1FTu1R2j QkPdHF44g2eza0ZLDBY0HUY5X3K5jTSDLyuqXkuOAUmgGyTnAOI6MPLYdoEzG9+DHTG8FLzeE z4mNC9kVoQOb1b5fSw8OJfOs2czQxtdri4KMf9nrewS+P9kpt7xhv2YwzbkesA3mitHlndeXk lQyWpiWDXL+7TTxn46UqG9kpvC38XBkE0qQr6pfGat70SjMqs0Y4kIM8z+Jjh18JqPMfUPJyR iQn+BbYH4v3LJ2H58jFtSEBLfe4uWdFDN0TzV9UxGL0y1EroM0bvDbHabm03dCrUoiP3qQw3q DKOO2nFC6LiAOIolus+8joqY3N9GLlrW858AOJNZd47zoaze+nZD5CHyZQwmWl1UKPHM745zf bVyWeoFRE5WuszKelz16EECXQS2BS9JNRWw2okRSGU3dWEmWHZWFnzOUe+rnVgIcUm1ZLQi/E oEY4+ue Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 20:26:49 -0000 On 2017-05-19 21:55, Megan Ferguson wrote: > ... > 1) We were surprised to see symrefs set to no as most reference entries we see use the RFC number as citation tag. > ... +1 > 2) We see the encoding as utf-8. We were under the impression that ascii would be the default unless utf-8 characters were included in the file, which they were not in our test cases. How does that matter if the input is indeed all ASCII? > ... > Is it possible to make these be includes (e.g., )? That way, the RPC will know the entries are being pulled from the citation library and contain the correct information. We understand that v3 will have to contain the expanded references. > ... Why? Includes are not part of the xml2rfc vocabulary. Inline entries or external entity references () seem like a better choice. > ... Best regards, Julian From nobody Fri May 19 14:20:38 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C1128656 for ; Fri, 19 May 2017 14:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23XJDatRA8cK for ; Fri, 19 May 2017 14:20:35 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF38124BFA for ; Fri, 19 May 2017 14:20:35 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:59188 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dBpK5-0000zP-Aj; Fri, 19 May 2017 14:20:34 -0700 To: Megan Ferguson References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> Cc: tools-development@ietf.org From: Henrik Levkowetz Message-ID: <591F6199.60801@levkowetz.com> Date: Fri, 19 May 2017 23:20:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dxSvQLl5XRQjA6JaCfbWN63eUappFLxOP" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 21:20:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dxSvQLl5XRQjA6JaCfbWN63eUappFLxOP Content-Type: multipart/mixed; boundary="bgmM5fGBEtDunVPqaQr09XCuarVrstxga"; protected-headers="v1" From: Henrik Levkowetz To: Megan Ferguson Cc: tools-development@ietf.org Message-ID: <591F6199.60801@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> In-Reply-To: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> --bgmM5fGBEtDunVPqaQr09XCuarVrstxga Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Megan, On 2017-05-19 21:55, Megan Ferguson wrote: > Hi Henrik, >=20 > Some notes on our initial test pass. Please let me know if you would > like any further information on any of the points below. In general, I'd very much appreciate the relevant draft name when you point out an issue; that will let me use that in testing and fixing the issue. As you'll see below, I believe that many of the issues you mention below are fixed in the latest release (1.0.0-rc1), but there are some cases below where the draft name would be good to have. > Disclaimer: We understand that the editors will need to clean up the > XML when it=E2=80=99s been converted from .txt to .xml. Please note tha= t we > are reporting oddities without trying to figure out which ones could > be fixed (i.e., automated). Ack, understood. Thank you for the work in testing and writing up the issues :-) More inline: > Thank you. >=20 > Megan >=20 > PIs, etc. > =E2=80=94=E2=80=94 >=20 > 1) We were surprised to see symrefs set to no as most reference > entries we see use the RFC number as citation tag. The generated xml should reflect the symrefs setting appropriate for the input. If the input file uses symrefs=3D"no", the xml will try to detect that; and likewise for symrefs=3D"yes". Could you send me the input source which gave symrefs=3D"no" when you did not expect it, please= ? > 2) We see the encoding as utf-8. We were under the impression that > ascii would be the default unless utf-8 characters were included in > the file, which they were not in our test cases. utf-8 is the default encoding for XML; I have not made any effort to set a different encoding based on detecting ascii or not. Does this make a difference for you? If so, could you give more details so I understand better? In the past, using encoding=3D'ascii' would make sense, to enforce the ascii-only policy; however going forward, I expect utf-8 will be the norm, and once utf-8 becomes permitted in some elements, it's probably better to consistently use encoding=3D'utf-8' in the xml files, rather than have different settings depending on content. However, I am not the user here, and don't know all the wrinkles involved ,:-) > Author elements > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= >=20 > 3) We see several differences in the use of the elements in the author=E2= =80=99s postal address. >=20 > v2: > > Cisco Systems >=20 >
> > 821 Alder Drive > Milpitas > 95035 > CA > USA > >=20 > ginsberg@cisco.com >
> >=20 >=20 > id2xml: >=20 > > Cisco Systems >
> > 821 Alder Drive > Milpitas, CA 95035 > USA > > ginsberg@cisco.com >
> Yes. The v2 address elements will go away when we hit v3, which doesn't = try to squeeze addresses into a US-centric format. (For an example of how=20 completely different from the US address concept some other addresses are= , see https://en.wikipedia.org/wiki/Japanese_addressing_system) Trying to map an arbitrary address into a format which uses the v2 fields= correctly would be a major undertaking, and would be abandoned within a y= ear. I've chosen not to do so in id2xml, leaving the proper matching to a huma= n. > Artwork tags vs. lists=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > 4) The following list was converted to a hanging list, which really cha= nged the output. =20 > The author-submitted version had this list in artwork. >=20 >=20 > Original text: >=20 > An MI-RTR MUST NOT support [RFC5120] multi-topology within a non-zer= o > instance when any non-zero ITID is supported. The following TLVs > MUST NOT be sent in an LSP associated with a non-zero instance which= > supports a non-zero ITID and such an LSP MUST be ignored when > received: >=20 > TLV 222 - MT IS Neighbors > TLV 235 - MT IP Reachability > TLV 237 - MT IPv6 Reachability >=20 > id2xml text output: >=20 > An MI-RTR MUST NOT support [RFC5120] multi-topology within a non-zer= o > instance when any non-zero ITID is supported. The following TLVs > MUST NOT be sent in an LSP associated with a non-zero instance which= > supports a non-zero ITID and such an LSP MUST be ignored when > received: >=20 > TLV 222 - MT IS Neighbors >=20 > TLV 235 - MT IP Reachability TLV 237 - MT IPv6 Reachability Yes. A definite flaw. This is much improved in version 1.0.0-rc1, which= I just released. There will, however, still be cases where id2xml tries to make lists out of something that originally was artwork. This is for good reasons: Artwork is the last fallback if nothing else will fit, beca= use it doesn't map well to html elements -- it's just a fixed-width-font blob= =2E I'll snip the other examples you give -- please try v1.0.0-rc1 on the relevant documents, and see if it does better. I believe it will. If no= t, please let me know the document names I should use to reproduce the issue= =2E > 5) The text following this figure was originally included in an > tag and appeared as slightly indented in the text. >=20 > original text: =2E.. > id2xml text output: >=20 > Type: 7 > Length: 2 - 254 > Value: > No. of octets > +-------------------------+ > | IID (0 - 65535) | 2 > +-------------------------+ > | Supported ITID | 2 > +-------------------------+ > : : > +-------------------------+ > | Supported ITID | 2 > +-------------------------+ >=20 > When the IID =3D 0, the list of supported ITIDs MUST NOT be present.= >=20 > An IID-TLV with IID =3D 0 MUST NOT appear in an SNP or LSP. When >=20 > the TLV appears (with a non-zero IID) in an SNP or LSP, exactly > one ITID MUST be present indicating the instance-specific topolog= y > with which the PDU is associated. If no ITIDs or multiple ITIDs > are present or the IID is zero, then the PDU MUST be ignored. ( <> a number of similar cases ) Yes. This was a recurring phenomenon for some documents in 0.9.3. I believe it will be better handled by 1.0.0-rc1. Could you check? If not, could you please provide the name of the input document, so I can add it to my test suite and work in improving the handling? >=20 > Citations throughout text > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > 6) It appears that citations were not converted to xref tags > throughout. For example: This should also be much improved in 1.0.0-rc1. Still missing is conversion of citations within tables; I've found that the chances of messing up there are higher. I'll have a look at addressing that case, too. > Reference Entries in the References section > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= > 7) We note that elements were not used and the references > section was created using a
element instead of > and appears in the as opposed to . The detection of reference sections was very mixed in version 0.9.3. If the reference sections were numbered, they would be missed, if they were not, they would be processed. Version 1.0.0-rc1 attempts to recognize al= so numbered reference sections, and generate both inline entrie= s and entity definitions at the top. > Is it possible to make these be includes (e.g.,=20 > )? That way, the RPC will= know the > entries are being pulled from the citation library and contain the > correct information. We understand that v3 will have to contain the > expanded references. It is possible, but as you indicate, the construct i= s deprecated. The best (I believe) alternative when working with both v2 and v3 xml sources is to use entity definitions, and have those expanded = by xml2rfc (in v2) and by the preptool (in v3) during final processing. In order to make it easy to use entities, I insert entity definitions at the= start of the generated xml both in 0.9.3 and in 1.0.0-rc1. The choice of inserting both entity definitions at the start, and expande= d xml refereces in the sections was done to make it easier fo= r you to choose one or the other. If you'd rather I inserted the appropria= te entity at the point of reference, I could do so. You would then instead of: ... see: &RFC2119; &RFC5304; ... and it would pull the reference entries from the citation library in the same way as with the pi. > 8) In v2, there is currently a setting to keep DOIs, draft strings, > and URLs on the same line (if possible for the latter). Ok; which setting are you thinking of? I can certainly insert it if desired. > 9) We generally see a single space after the author initials instead > of two spaces there. > original text: >=20 > [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., > and M. Fanto, "IS-IS Generic Cryptographic > Authentication", RFC 5310, DOI 10.17487/RFC5310, February= > 2009, . >=20 > id2xml text output: >=20 > [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., > and M. Fanto, "IS-IS Generic Cryptographic > Authentication", RFC 5310, DOI 10.17487/RFC5310, February= > 2009, . There was an issue in 0.9.2 where extra spaces were not stripped from the= initials string; that was fixed in 0.9.3, and should also be fixed in=20 1.0.0-rc1. Please let me know if you find that it's not the case. Thank you so much for the feedback! Best regards, Henrik --bgmM5fGBEtDunVPqaQr09XCuarVrstxga-- --dxSvQLl5XRQjA6JaCfbWN63eUappFLxOP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZH2GZAAoJEE6bV0uPuxca5aAP/ikE86LEHGn4aCctyMOm9BJl BWG9E67jsmbO+YsS1ZX+CmfV9vnqZ9jr5Z6QxZ9xdgSXomImd9ys7ZmelMD+k0YG LHFQGqhaKMGmdrUuIvmC9ePYzM95PTjXkXXm6C20Wl9dP2txeRgZn1rz87KmnzPR enIfgZ9ncAbQjFK2zhHHE6vk4Swz2oAhlCWhtfuA5HKIb6e7sW630MH6k0DO0wgI 4GcnO8UmyT+uorP+YUUI/d1BloxuYrZliJVd9fxcSqXinPBPH1mXgionpAWXw1Ff G8N5/S8ZSccglQ9IU6hLh7HXe1b7bHJncl8Fz8JusUOasLniSJi9KRyRQugTV8I5 IVOOUkO8tug94BwejdWg3f1w2Qwsi5QoMy4C7DduJlYFHtPQZICYs98mZ0w8k1gT ncTTVS1GNsIvb/tmBKvRw/wbW6attheOvD7igK79YCqKgsx4BekbEWwlybPT+d8b kkehyG851Fx2VHva77/vbnFh6h7I/+VFPiR8fTj8lJsHheUTQoLw3/D9vN721ykk aSziwl4y+SoT6iWDtOAv+LCDk6UO1CjumziSjqSybLidvjd4SkYjiT94wcUPwIJr 6dIK4nd6BTeEoXxTL1IHVPie0CZI/L35CeS4kjhXPAVAjSq+mp5T2pz0597ZvlZr vcRfESj7+yCi5seZ0Y/Y =l3sZ -----END PGP SIGNATURE----- --dxSvQLl5XRQjA6JaCfbWN63eUappFLxOP-- From nobody Fri May 19 14:43:42 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4512717E for ; Fri, 19 May 2017 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrQLjW2hgbtp for ; Fri, 19 May 2017 14:43:39 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912901200F1 for ; Fri, 19 May 2017 14:43:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id DE2921C5A6F; Fri, 19 May 2017 14:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOrt4CRK7UBk; Fri, 19 May 2017 14:43:33 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id 9FAA21C2CBA; Fri, 19 May 2017 14:43:33 -0700 (PDT) From: Sandy Ginoza Message-Id: <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5FF46278-18D5-4F34-8EDF-852C2C85C6CA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 19 May 2017 14:43:37 -0700 In-Reply-To: <591F6199.60801@levkowetz.com> Cc: Megan Ferguson , tools-development@ietf.org To: Henrik Levkowetz References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 21:43:41 -0000 --Apple-Mail=_5FF46278-18D5-4F34-8EDF-852C2C85C6CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Henrik > On May 19, 2017, at 2:20 PM, Henrik Levkowetz = wrote: >=20 >> 2) We see the encoding as utf-8. We were under the impression that >> ascii would be the default unless utf-8 characters were included in >> the file, which they were not in our test cases. >=20 > utf-8 is the default encoding for XML; I have not made any effort to > set a different encoding based on detecting ascii or not. Does this > make a difference for you? If so, could you give more details so I > understand better? >=20 > In the past, using encoding=3D'ascii' would make sense, to enforce the > ascii-only policy; however going forward, I expect utf-8 will be the > norm, and once utf-8 becomes permitted in some elements, it's probably > better to consistently use encoding=3D'utf-8' in the xml files, rather > than have different settings depending on content. However, I am not > the user here, and don't know all the wrinkles involved ,:-) Ah, this may have been my misunderstanding. I thought the .txt files = would be output differently depending, perhaps, on how encoding was set = in the XML file. Is it correct that ALL .txt files will have a BOM, = regardless of whether the encoding is set to UTF-8 (I was thinking it = was only to be applied to those .txt files that contained UTF-8 to let = the reader know the file is not strictly ASCII)? =20 Thanks! Sandy= --Apple-Mail=_5FF46278-18D5-4F34-8EDF-852C2C85C6CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Henrik

On May 19, 2017, at 2:20 PM, = Henrik Levkowetz <henrik@levkowetz.com> wrote:

2) We see the encoding as = utf-8. We were under the impression that
ascii would be = the default unless utf-8 characters were included in
the = file, which they were not in our test cases.

utf-8 is the default encoding for XML; I = have not made any effort to
set a different encoding based = on detecting ascii or not.  Does this
make a difference for you? =  If so, could you give more details so I
understand better?

In the past, using encoding=3D'ascii' would make = sense, to enforce the
ascii-only policy; however going = forward, I expect utf-8 will be the
norm, and once utf-8 becomes = permitted in some elements, it's probably
better to consistently use = encoding=3D'utf-8' in the xml files, rather
than have different settings depending on = content.  However, I am not
the user here, and don't know = all the wrinkles involved = ,:-)

Ah, this may have been my = misunderstanding.  I thought the .txt files would be output = differently depending, perhaps, on how encoding was set in the XML file. =  Is it correct that ALL .txt files will have a BOM, regardless of = whether the encoding is set to UTF-8 (I was thinking it was only to be = applied to those .txt files that contained UTF-8 to let the reader know = the file is not strictly ASCII)?  


Thanks!

Sandy
= --Apple-Mail=_5FF46278-18D5-4F34-8EDF-852C2C85C6CA-- From nobody Sat May 20 02:32:09 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E51127333 for ; Sat, 20 May 2017 02:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10jGzMKZ-5YY for ; Sat, 20 May 2017 02:32:06 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CEA1200FC for ; Sat, 20 May 2017 02:32:06 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:56068 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dC0k1-0000Uu-K9; Sat, 20 May 2017 02:32:06 -0700 To: Sandy Ginoza References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> Cc: Megan Ferguson , tools-development@ietf.org From: Henrik Levkowetz Message-ID: <59200D03.60307@levkowetz.com> Date: Sat, 20 May 2017 11:31:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xe32Cj9xP1WjNJDltQc2QoodvOA6rwkq1" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.com, sginoza@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 09:32:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xe32Cj9xP1WjNJDltQc2QoodvOA6rwkq1 Content-Type: multipart/mixed; boundary="KQemx9Bnegg9xq4qNV6MthCh5LdAkS0Ov"; protected-headers="v1" From: Henrik Levkowetz To: Sandy Ginoza Cc: Megan Ferguson , tools-development@ietf.org Message-ID: <59200D03.60307@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> In-Reply-To: <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> --KQemx9Bnegg9xq4qNV6MthCh5LdAkS0Ov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sandy, On 2017-05-19 23:43, Sandy Ginoza wrote: > Hi Henrik >=20 >> On May 19, 2017, at 2:20 PM, Henrik Levkowetz w= rote: >>=20 >>> 2) We see the encoding as utf-8. We were under the impression that >>> ascii would be the default unless utf-8 characters were included in >>> the file, which they were not in our test cases. >>=20 >> utf-8 is the default encoding for XML; I have not made any effort to >> set a different encoding based on detecting ascii or not. Does this >> make a difference for you? If so, could you give more details so I >> understand better? >>=20 >> In the past, using encoding=3D'ascii' would make sense, to enforce the= >> ascii-only policy; however going forward, I expect utf-8 will be the >> norm, and once utf-8 becomes permitted in some elements, it's probably= >> better to consistently use encoding=3D'utf-8' in the xml files, rather= >> than have different settings depending on content. However, I am not >> the user here, and don't know all the wrinkles involved ,:-) >=20 >=20 > Ah, this may have been my misunderstanding. I thought the .txt files > would be output differently depending, perhaps, on how encoding was > set in the XML file. Aha. No, but in a limited sense. More below. > Is it correct that ALL .txt files will have a > BOM, regardless of whether the encoding is set to UTF-8 (I was > thinking it was only to be applied to those .txt files that contained > UTF-8 to let the reader know the file is not strictly ASCII)?>=20 The important thing here is that ASCII is a subset of UTF-8. Given that, it is equally correct to give an XML file with pure ASCII content the encoding=3D'utf-8' and to give it the encoding=3D'ascii', wit= h no change in the rest of the bytes in the file. And the same goes for the output; you can say that a file with pure ascii content is encoded as UTF-8, and be perfectly right; there is no difference in the encoding between ASCII and UTF-8 for pure-ASCII content. So returning briefly to the 'No' above: If the XML content is pure ASCII,= the output will be the same irrespective of whether the file states "encoding=3D'ascii'" or "encoding=3D'utf-8'". If the XML content is non-= ASCII UTF-8, and the file states "encoding=3D'ascii'", the file is invalid. For the XML files, I'd go with encoding=3D'utf-8' consistently. For the generated text files, my preference would be to only tag them with a BOM in contexts where no other way of signalling the encoding exists. But that may complicate your toolchain too much. So the choice is then between giving all .txt files a BOM, or giving only .txt files with non- ASCII content a BOM. Both will result in valid files, but the BOM will be completely unnecessary and unhelpful if the content is pure ASCII. So I would go with the concept you stated in your question above, of applying a BOM only to the text files which have non-ASCII content. You should be able to identify .txt output with non-ascii content by use of the 'file' command, e.g., "$ file --brief --mime-encoding rfcNNNN.txt"= -- this should output the encoding, in our case either 'utf-8' or 'us-asc= ii'. This turned out somewhat long-winded, but I hope it helps. Best regards, Henrik --KQemx9Bnegg9xq4qNV6MthCh5LdAkS0Ov-- --xe32Cj9xP1WjNJDltQc2QoodvOA6rwkq1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZIA0NAAoJEE6bV0uPuxcalw0P/1011zcqaeU/1dfYbGaWvntb QOp0e+czKrO6KuQPG1Ve0aCrIno/J1lfzPunG5OddXMYAWg1MercvEmpV/TowLIi CO0xndB7F6R8gougu4apgztOigswYR/HopLHKCPph15HwJiSIzKiSumSN7b2DQIH P9ak6INAORNUcr4GLFeSg+OEuFeEFjoH4ecja6AOZYAN/aqJ1xlaTr8TrhK5JJoz NZBIbmMB0XalSk56kKOWfQaCbHBNbsGL8AmcQOJLhmvoKlF1FBN9OkIOJDPtMxMa C79UefCsQTsyE81958QrxEID+qh3xBc/OCivNO3cflEUimqNbhmcNkU4DNVjDXMt HePXzWeDjY5DgSbM6hpIfROhTfLgbhLc9UHTGCBzuoUKOREKrUDINYht6az3otz2 T513Mpd21eLeRmBYF4BZEOfoEelnzpj3ylQ+HoLCKSWMHgjJvYsDJl//uigIxANv DVBlXbOFbdBsmtXntZmrfKdFEedS3Ci4ZxRXAIgdUxLqhwJRL86tkifa4AkF1w3/ M6LCE/fRcXSRPRy/g9oQgFfEYCpnSEZoeBvZ5UrS+VcEHOMNjjM/F7d5fdsc8/zu zWun0+KCbIgJcSHhZ/g0y6luDYasDzZ3XKcGufcHvIQ3Qc12t0l8LJcnsly1uGJK e471ZtOYKZ164XKjtOe/ =HTNF -----END PGP SIGNATURE----- --xe32Cj9xP1WjNJDltQc2QoodvOA6rwkq1-- From nobody Sat May 20 18:52:39 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDAF12948F for ; Sat, 20 May 2017 18:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3aIwgH7BYq6 for ; Sat, 20 May 2017 18:52:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D9C1252BA for ; Sat, 20 May 2017 18:52:36 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4L1jNl1006302 for ; Sat, 20 May 2017 21:52:33 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2ajf2a9tvh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 20 May 2017 21:52:33 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4L1qWOe021072 for ; Sat, 20 May 2017 21:52:32 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4L1qOeg021004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 20 May 2017 21:52:26 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Sun, 21 May 2017 01:52:11 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.110]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0319.002; Sat, 20 May 2017 21:52:10 -0400 From: "HANSEN, TONY L" CC: "tools-development@ietf.org" Thread-Topic: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml Thread-Index: AQHS0Nnl/h9+7187TkqLTmYjtrmU/6H8bNCAgAAGe4CAAMXcgIAAzqEA Date: Sun, 21 May 2017 01:52:10 +0000 Message-ID: References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> <59200D03.60307@levkowetz.com> In-Reply-To: <59200D03.60307@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.4.168.243] Content-Type: text/plain; charset="utf-8" Content-ID: <97721AE14233A842ACF5A5FAFAD7C313@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705210009 Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 01:52:38 -0000 TGV04oCZcyBqdXN0IHNheSB0aGF0IEnigJltIG5vdCBhIGZhbiBvZiBCT00gb24gVVRGLTggZmls ZXMsIGV2ZXIsIGFuZCBlbmNvZGluZz3igJlhc2NpaeKAmSBzaG91bGQganVzdCBkaXNhcHBlYXIu DQoNClNvbWUgd291bGQgc2F5IHRoYXTigJlzIHRvbyBleHRyZW1lIGEgc3RhbmNlLCBhbmQgb3Ro ZXJzIHRoYXQgaXTigJlzIGp1c3QgcmlnaHQuDQoNCglUb255DQoNCk9uIDUvMjAvMTcsIDU6MzEg QU0sICJUT09MUy1ERVZFTE9QTUVOVCBvbiBiZWhhbGYgb2YgSGVucmlrIExldmtvd2V0eiIgPHRv b2xzLWRldmVsb3BtZW50LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGhlbnJpa0BsZXZr b3dldHouY29tPiB3cm90ZToNCg0KICAgIEhpIFNhbmR5LA0KICAgIA0KICAgIE9uIDIwMTctMDUt MTkgMjM6NDMsIFNhbmR5IEdpbm96YSB3cm90ZToNCiAgICA+IEhpIEhlbnJpaw0KICAgID4gDQog ICAgPj4gT24gTWF5IDE5LCAyMDE3LCBhdCAyOjIwIFBNLCBIZW5yaWsgTGV2a293ZXR6IDxoZW5y aWtAbGV2a293ZXR6LmNvbT4gd3JvdGU6DQogICAgPj4gDQogICAgPj4+IDIpIFdlIHNlZSB0aGUg ZW5jb2RpbmcgYXMgdXRmLTguIFdlIHdlcmUgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdA0KICAg ID4+PiBhc2NpaSB3b3VsZCBiZSB0aGUgZGVmYXVsdCB1bmxlc3MgdXRmLTggY2hhcmFjdGVycyB3 ZXJlIGluY2x1ZGVkIGluDQogICAgPj4+IHRoZSBmaWxlLCB3aGljaCB0aGV5IHdlcmUgbm90IGlu IG91ciB0ZXN0IGNhc2VzLg0KICAgID4+IA0KICAgID4+IHV0Zi04IGlzIHRoZSBkZWZhdWx0IGVu Y29kaW5nIGZvciBYTUw7IEkgaGF2ZSBub3QgbWFkZSBhbnkgZWZmb3J0IHRvDQogICAgPj4gc2V0 IGEgZGlmZmVyZW50IGVuY29kaW5nIGJhc2VkIG9uIGRldGVjdGluZyBhc2NpaSBvciBub3QuICBE b2VzIHRoaXMNCiAgICA+PiBtYWtlIGEgZGlmZmVyZW5jZSBmb3IgeW91PyAgSWYgc28sIGNvdWxk IHlvdSBnaXZlIG1vcmUgZGV0YWlscyBzbyBJDQogICAgPj4gdW5kZXJzdGFuZCBiZXR0ZXI/DQog ICAgPj4gDQogICAgPj4gSW4gdGhlIHBhc3QsIHVzaW5nIGVuY29kaW5nPSdhc2NpaScgd291bGQg bWFrZSBzZW5zZSwgdG8gZW5mb3JjZSB0aGUNCiAgICA+PiBhc2NpaS1vbmx5IHBvbGljeTsgaG93 ZXZlciBnb2luZyBmb3J3YXJkLCBJIGV4cGVjdCB1dGYtOCB3aWxsIGJlIHRoZQ0KICAgID4+IG5v cm0sIGFuZCBvbmNlIHV0Zi04IGJlY29tZXMgcGVybWl0dGVkIGluIHNvbWUgZWxlbWVudHMsIGl0 J3MgcHJvYmFibHkNCiAgICA+PiBiZXR0ZXIgdG8gY29uc2lzdGVudGx5IHVzZSBlbmNvZGluZz0n dXRmLTgnIGluIHRoZSB4bWwgZmlsZXMsIHJhdGhlcg0KICAgID4+IHRoYW4gaGF2ZSBkaWZmZXJl bnQgc2V0dGluZ3MgZGVwZW5kaW5nIG9uIGNvbnRlbnQuICBIb3dldmVyLCBJIGFtIG5vdA0KICAg ID4+IHRoZSB1c2VyIGhlcmUsIGFuZCBkb24ndCBrbm93IGFsbCB0aGUgd3JpbmtsZXMgaW52b2x2 ZWQgLDotKQ0KICAgID4gDQogICAgPiANCiAgICA+IEFoLCB0aGlzIG1heSBoYXZlIGJlZW4gbXkg bWlzdW5kZXJzdGFuZGluZy4gSSB0aG91Z2h0IHRoZSAudHh0IGZpbGVzDQogICAgPiB3b3VsZCBi ZSBvdXRwdXQgZGlmZmVyZW50bHkgZGVwZW5kaW5nLCBwZXJoYXBzLCBvbiBob3cgZW5jb2Rpbmcg d2FzDQogICAgPiBzZXQgaW4gdGhlIFhNTCBmaWxlLg0KICAgIA0KICAgIEFoYS4gTm8sIGJ1dCBp biBhIGxpbWl0ZWQgc2Vuc2UuICBNb3JlIGJlbG93Lg0KICAgIA0KICAgID4gSXMgaXQgY29ycmVj dCB0aGF0IEFMTCAudHh0IGZpbGVzIHdpbGwgaGF2ZSBhDQogICAgPiBCT00sIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlciB0aGUgZW5jb2RpbmcgaXMgc2V0IHRvIFVURi04IChJIHdhcw0KICAgID4gdGhp bmtpbmcgaXQgd2FzIG9ubHkgdG8gYmUgYXBwbGllZCB0byB0aG9zZSAudHh0IGZpbGVzIHRoYXQg Y29udGFpbmVkDQogICAgPiBVVEYtOCB0byBsZXQgdGhlIHJlYWRlciBrbm93IHRoZSBmaWxlIGlz IG5vdCBzdHJpY3RseSBBU0NJSSk/PiANCiAgICANCiAgICBUaGUgaW1wb3J0YW50IHRoaW5nIGhl cmUgaXMgdGhhdCBBU0NJSSBpcyBhIHN1YnNldCBvZiBVVEYtOC4NCiAgICANCiAgICBHaXZlbiB0 aGF0LCBpdCBpcyBlcXVhbGx5IGNvcnJlY3QgdG8gZ2l2ZSBhbiBYTUwgZmlsZSB3aXRoIHB1cmUg QVNDSUkNCiAgICBjb250ZW50IHRoZSBlbmNvZGluZz0ndXRmLTgnIGFuZCB0byBnaXZlIGl0IHRo ZSBlbmNvZGluZz0nYXNjaWknLCB3aXRoDQogICAgbm8gY2hhbmdlIGluIHRoZSByZXN0IG9mIHRo ZSBieXRlcyBpbiB0aGUgZmlsZS4gIEFuZCB0aGUgc2FtZSBnb2VzIGZvcg0KICAgIHRoZSBvdXRw dXQ7IHlvdSBjYW4gc2F5IHRoYXQgYSBmaWxlIHdpdGggcHVyZSBhc2NpaSBjb250ZW50IGlzIGVu Y29kZWQNCiAgICBhcyBVVEYtOCwgYW5kIGJlIHBlcmZlY3RseSByaWdodDsgdGhlcmUgaXMgbm8g ZGlmZmVyZW5jZSBpbiB0aGUgZW5jb2RpbmcNCiAgICBiZXR3ZWVuIEFTQ0lJIGFuZCBVVEYtOCBm b3IgcHVyZS1BU0NJSSBjb250ZW50Lg0KICAgIA0KICAgIFNvIHJldHVybmluZyBicmllZmx5IHRv IHRoZSAnTm8nIGFib3ZlOiBJZiB0aGUgWE1MIGNvbnRlbnQgaXMgcHVyZSBBU0NJSSwNCiAgICB0 aGUgb3V0cHV0IHdpbGwgYmUgdGhlIHNhbWUgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgdGhlIGZp bGUgc3RhdGVzDQogICAgImVuY29kaW5nPSdhc2NpaSciIG9yICJlbmNvZGluZz0ndXRmLTgnIi4g IElmIHRoZSBYTUwgY29udGVudCBpcyBub24tQVNDSUkNCiAgICBVVEYtOCwgYW5kIHRoZSBmaWxl IHN0YXRlcyAiZW5jb2Rpbmc9J2FzY2lpJyIsIHRoZSBmaWxlIGlzIGludmFsaWQuDQogICAgDQog ICAgRm9yIHRoZSBYTUwgZmlsZXMsIEknZCBnbyB3aXRoIGVuY29kaW5nPSd1dGYtOCcgY29uc2lz dGVudGx5LiAgRm9yIHRoZQ0KICAgIGdlbmVyYXRlZCB0ZXh0IGZpbGVzLCBteSBwcmVmZXJlbmNl IHdvdWxkIGJlIHRvIG9ubHkgdGFnIHRoZW0gd2l0aCBhDQogICAgQk9NIGluIGNvbnRleHRzIHdo ZXJlIG5vIG90aGVyIHdheSBvZiBzaWduYWxsaW5nIHRoZSBlbmNvZGluZyBleGlzdHMuDQogICAg QnV0IHRoYXQgbWF5IGNvbXBsaWNhdGUgeW91ciB0b29sY2hhaW4gdG9vIG11Y2guICBTbyB0aGUg Y2hvaWNlIGlzIHRoZW4NCiAgICBiZXR3ZWVuIGdpdmluZyBhbGwgLnR4dCBmaWxlcyBhIEJPTSwg b3IgZ2l2aW5nIG9ubHkgLnR4dCBmaWxlcyB3aXRoIG5vbi0NCiAgICBBU0NJSSBjb250ZW50IGEg Qk9NLiAgQm90aCB3aWxsIHJlc3VsdCBpbiB2YWxpZCBmaWxlcywgYnV0IHRoZSBCT00gd2lsbA0K ICAgIGJlIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgYW5kIHVuaGVscGZ1bCBpZiB0aGUgY29udGVu dCBpcyBwdXJlIEFTQ0lJLg0KICAgIA0KICAgIFNvIEkgd291bGQgZ28gd2l0aCB0aGUgY29uY2Vw dCB5b3Ugc3RhdGVkIGluIHlvdXIgcXVlc3Rpb24gYWJvdmUsIG9mDQogICAgYXBwbHlpbmcgYSBC T00gb25seSB0byB0aGUgdGV4dCBmaWxlcyB3aGljaCBoYXZlIG5vbi1BU0NJSSBjb250ZW50Lg0K ICAgIA0KICAgIFlvdSBzaG91bGQgYmUgYWJsZSB0byBpZGVudGlmeSAudHh0IG91dHB1dCB3aXRo IG5vbi1hc2NpaSBjb250ZW50IGJ5IHVzZQ0KICAgIG9mIHRoZSAnZmlsZScgY29tbWFuZCwgZS5n LiwgIiQgZmlsZSAtLWJyaWVmIC0tbWltZS1lbmNvZGluZyByZmNOTk5OLnR4dCINCiAgICAtLSB0 aGlzIHNob3VsZCBvdXRwdXQgdGhlIGVuY29kaW5nLCBpbiBvdXIgY2FzZSBlaXRoZXIgJ3V0Zi04 JyBvciAndXMtYXNjaWknLg0KICAgIA0KICAgIA0KICAgIFRoaXMgdHVybmVkIG91dCBzb21ld2hh dCBsb25nLXdpbmRlZCwgYnV0IEkgaG9wZSBpdCBoZWxwcy4NCiAgICANCiAgICANCiAgICBCZXN0 IHJlZ2FyZHMsDQogICAgDQogICAgCUhlbnJpaw0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Sun May 21 01:56:59 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936D5127735 for ; Sun, 21 May 2017 01:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHyJtN0ZT2XM for ; Sun, 21 May 2017 01:56:56 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14058127201 for ; Sun, 21 May 2017 01:56:56 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:65214 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dCMfW-00033n-Ql; Sun, 21 May 2017 01:56:55 -0700 To: "HANSEN, TONY L" References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> <59200D03.60307@levkowetz.com> Cc: "tools-development@ietf.org" From: Henrik Levkowetz Message-ID: <59215646.8050800@levkowetz.com> Date: Sun, 21 May 2017 10:56:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uCTsfoe3aPEJM1OtHPT92DI8qbq4p1UVW" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, tony@att.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 08:56:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uCTsfoe3aPEJM1OtHPT92DI8qbq4p1UVW Content-Type: multipart/mixed; boundary="vGqKgMW0XDRetmDuxHWiMhs2JPDj17Ofd"; protected-headers="v1" From: Henrik Levkowetz To: "HANSEN, TONY L" Cc: "tools-development@ietf.org" Message-ID: <59215646.8050800@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> <59200D03.60307@levkowetz.com> In-Reply-To: --vGqKgMW0XDRetmDuxHWiMhs2JPDj17Ofd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-05-21 03:52, HANSEN, TONY L wrote: > Let=E2=80=99s just say that I=E2=80=99m not a fan of BOM on UTF-8 files= , ever, and > encoding=3D=E2=80=99ascii=E2=80=99 should just disappear. Oh, I agree. And I've voiced that sentiment about BOM in the context of utf-8 text RFCs before. But the decision isn't mine, and a couple of yea= rs ago a survey showed enough programs of note which couldn't deal with utf-= 8 files if they didn't have a BOM, that a decision was made to add BOMs. > Some would say that=E2=80=99s too extreme a stance, and others that it=E2= =80=99s just > right. To me it sounds just right :-) Henrik > Tony >=20 > On 5/20/17, 5:31 AM, "TOOLS-DEVELOPMENT on behalf of Henrik Levkowetz" = wr= ote: >=20 > Hi Sandy, > =20 > On 2017-05-19 23:43, Sandy Ginoza wrote: > > Hi Henrik > >=20 > >> On May 19, 2017, at 2:20 PM, Henrik Levkowetz wrote: > >>=20 > >>> 2) We see the encoding as utf-8. We were under the impression t= hat > >>> ascii would be the default unless utf-8 characters were include= d in > >>> the file, which they were not in our test cases. > >>=20 > >> utf-8 is the default encoding for XML; I have not made any effor= t to > >> set a different encoding based on detecting ascii or not. Does = this > >> make a difference for you? If so, could you give more details s= o I > >> understand better? > >>=20 > >> In the past, using encoding=3D'ascii' would make sense, to enfor= ce the > >> ascii-only policy; however going forward, I expect utf-8 will be= the > >> norm, and once utf-8 becomes permitted in some elements, it's pr= obably > >> better to consistently use encoding=3D'utf-8' in the xml files, = rather > >> than have different settings depending on content. However, I a= m not > >> the user here, and don't know all the wrinkles involved ,:-) > >=20 > >=20 > > Ah, this may have been my misunderstanding. I thought the .txt fi= les > > would be output differently depending, perhaps, on how encoding w= as > > set in the XML file. > =20 > Aha. No, but in a limited sense. More below. > =20 > > Is it correct that ALL .txt files will have a > > BOM, regardless of whether the encoding is set to UTF-8 (I was > > thinking it was only to be applied to those .txt files that conta= ined > > UTF-8 to let the reader know the file is not strictly ASCII)?>=20 > =20 > The important thing here is that ASCII is a subset of UTF-8. > =20 > Given that, it is equally correct to give an XML file with pure ASC= II > content the encoding=3D'utf-8' and to give it the encoding=3D'ascii= ', with > no change in the rest of the bytes in the file. And the same goes = for > the output; you can say that a file with pure ascii content is enco= ded > as UTF-8, and be perfectly right; there is no difference in the enc= oding > between ASCII and UTF-8 for pure-ASCII content. > =20 > So returning briefly to the 'No' above: If the XML content is pure = ASCII, > the output will be the same irrespective of whether the file states= > "encoding=3D'ascii'" or "encoding=3D'utf-8'". If the XML content i= s non-ASCII > UTF-8, and the file states "encoding=3D'ascii'", the file is invali= d. > =20 > For the XML files, I'd go with encoding=3D'utf-8' consistently. Fo= r the > generated text files, my preference would be to only tag them with = a > BOM in contexts where no other way of signalling the encoding exist= s. > But that may complicate your toolchain too much. So the choice is = then > between giving all .txt files a BOM, or giving only .txt files with= non- > ASCII content a BOM. Both will result in valid files, but the BOM = will > be completely unnecessary and unhelpful if the content is pure ASCI= I. > =20 > So I would go with the concept you stated in your question above, o= f > applying a BOM only to the text files which have non-ASCII content.= > =20 > You should be able to identify .txt output with non-ascii content b= y use > of the 'file' command, e.g., "$ file --brief --mime-encoding rfcNNN= N.txt" > -- this should output the encoding, in our case either 'utf-8' or '= us-ascii'. > =20 > =20 > This turned out somewhat long-winded, but I hope it helps. > =20 > =20 > Best regards, > =20 > Henrik > =20 > =20 > =20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --vGqKgMW0XDRetmDuxHWiMhs2JPDj17Ofd-- --uCTsfoe3aPEJM1OtHPT92DI8qbq4p1UVW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZIVZNAAoJEE6bV0uPuxcalS0QALwiZi3by20fjPdUHl9bqSHm JE/+DjNGiwlT1H0KO+8MEVm4LJ8nnUx1Z0/fvbwHI8+aBhfJTsYJoKZ2zsHmMC/b lPz5VA70ZMvn2QcgDioUCBVWZOxZ/4/L/axzIendAc0nOxPe0xWOhhBxzN0RLZbj 1m+1nMX3lrQXg90X37aElopX+eQ3MdCF1YwfYySlQkto42fNKmO6PpOOsMTjwHze pUW2a4irOOVdU98Nt1SfIBRNie8EBNM6LdtKW31/SR4rxd/97DcCVzLdKvYJD2T7 k1VnmJwJqtHBFYf7eZ1uacsv3pxm9mDR0O2brdBqPkELMS6DFnGH0fZ5FaCghsQ2 t28r/LY6i5IHZriJ1BXct4mmZ2ySyQD+SDYTGd5ZPFzPOSZ7TKlGgAbQg821Huar D2IKjR4dNsKQnAk7esDgRX6nxyWKr0AGKiYhPhPxQsy3CLQrzGMlqGWf91LfVsxR ZTcTCGy++3amu0yqke5SNScjKF4HwixZlu8pu7SJNdlSpdblJPe2YkYF4x333ZZi dr1HUlg0KrI6CNh5mckYZh8hkVZHha0SYmdJjHeBO2bpo0n+xa5bOKI4wkjN/Uha 5bTrfPCLiJaNop3D5bEr3AdxFXVVbI8ZrffuF+DwAVZNOYgnzoxC6ZrcSuYOyYiP 8rRchz6QaxZMWLIJUVgu =5rNp -----END PGP SIGNATURE----- --uCTsfoe3aPEJM1OtHPT92DI8qbq4p1UVW-- From nobody Sun May 21 04:12:24 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671E7127201 for ; Sun, 21 May 2017 04:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfGrQw63oSWB for ; Sun, 21 May 2017 04:12:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EE81200FC for ; Sun, 21 May 2017 04:12:20 -0700 (PDT) Received: from [192.168.178.20] ([93.217.107.35]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MZCUG-1dXEWD1ycm-00L175; Sun, 21 May 2017 13:12:01 +0200 To: Henrik Levkowetz , "HANSEN, TONY L" Cc: "tools-development@ietf.org" References: <0C8AEEDA-EB69-4E0D-9955-A122DBE77CEC@amsl.com> <591F6199.60801@levkowetz.com> <8588C55C-0F14-40AE-93E2-03262B794190@amsl.com> <59200D03.60307@levkowetz.com> <59215646.8050800@levkowetz.com> From: Julian Reschke Message-ID: <2b9f8945-7891-d0e0-bb44-d916e347a077@gmx.de> Date: Sun, 21 May 2017 13:11:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <59215646.8050800@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:lR5gF3tvIi6QPWCqrXXI1tQ6+60yeoYzY0VaJDQYGo/HlWtukSM A8hqVpc4FIOk8CMnj13hyx6OlRnCZ+o7Nx1Ct8oJ2k6KIeWrzg/Ok80t/peb5kKhwKV4zL1 WdFmLHchXiUzSiz0CJe/FQ0MYATMIdRBZwR2id9WiQoQlH0yiGy8o1A7bz69xCbdXHGN9Zg Hqw33K/NfijPEZcTpfu4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:EJ6bBrwMjTA=:Xx6DulwE4MLvypMIP4VYn6 NbQzy7ogetGJrUGBbFAvbCZh02qgnfS9xIGapvJNsMc4YoBI79iwTLAnK+8fsJaeChVqrtVGu LwDcyT02VzntmVtpMM+TvcjWAEZ7pKLDycncIKwMI8ojX6r6EwQoHV6E6BN9aOFj97B/BfyNN gyfkigqvwkXH/SNrFohQzohQeAOMJmvlw1x0NvwJ6vwqlyzOCOcT/lf/zsIMQAlLlwzAbNRki dLLkwLbRjGCo5E08y5a/WM0v4WF0guHg6d/KuONeSgN4cvzTTy4WQuf5IWL+cb+5GvTgP8PCI m8x9iTTMx4eearx5k/g8foQoGHlRlRx09vTeNEgd8QbHVDytwjfD+aMIKYwEUc5ylp4NCbfLC IAeHNc+1wgCns7MHIRjSD9yvefio8lZVrMz9oClWuhVh19BvEgYhirQQDCs9U5c5Ho/5jL7/j hPYrL6ovO98wBi0hK5+2d//jmC6OeH4KF0o1+PZhg+24M9u7zWripfisqWQ3doW7e6BEjlwLf n2hyU+RSMpT8iQeSuPSdJ5d/gHcBWc7AJm5n23R2PxYi1Viws6nsXxcJxDR5WS3k5wsbUFClY WBtwymZUShk74kafysa0GAbumMuQ/x3ulHjpmbRWaiDEHyZ61+ZwS//urNnM+6JYAdGfGZnAP 93eV1AaQ5WeyX3sFmcFXGjyIczLiGt9hE6LoiNWo8nr8aK4O3/txO6EiY14KRM9RJlAeFb0Of 8ZryoAxBPbYrSQY+9VtIlCy70MFaxZfkvi1xa4XJnKFlleWyhCqA8QwcbZkPAMZGyhdhYcXUH wheW6Nv Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 11:12:22 -0000 On 2017-05-21 10:56, Henrik Levkowetz wrote: > > > On 2017-05-21 03:52, HANSEN, TONY L wrote: >> Let’s just say that I’m not a fan of BOM on UTF-8 files, ever, and >> encoding=’ascii’ should just disappear. > > Oh, I agree. And I've voiced that sentiment about BOM in the context of > utf-8 text RFCs before. But the decision isn't mine, and a couple of years > ago a survey showed enough programs of note which couldn't deal with utf-8 > files if they didn't have a BOM, that a decision was made to add BOMs. > >> Some would say that’s too extreme a stance, and others that it’s just >> right. > > To me it sounds just right :-) Just throwing in pros and cons: - avoiding a BOM on documents that do not need it avoids clutter that some software might get confused by - having the BOM on all documents avoids a special-case, and might cause people to switch to software that handles the BOM correctly Best regards, Julian From nobody Fri May 26 11:49:04 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C70126C89 for ; Fri, 26 May 2017 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmFQpgeTLm8q for ; Fri, 26 May 2017 11:49:00 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D3C124217 for ; Fri, 26 May 2017 11:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D3AE61CA395; Fri, 26 May 2017 11:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB70iW4NXxf6; Fri, 26 May 2017 11:48:48 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 8EB701CA394; Fri, 26 May 2017 11:48:48 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson Date: Fri, 26 May 2017 11:49:00 -0700 Cc: tools-development@ietf.org, Sandy Ginoza , Alice Russo Content-Transfer-Encoding: quoted-printable Message-Id: References: <591F6199.60801@levkowetz.com> To: henrik@levkowetz.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 18:49:02 -0000 Hi Henrik, Thank you for your reply and explanations. Inline below with MF. Megan Begin forwarded message: > From: Henrik Levkowetz > Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission = Converter, id2xml > Date: May 19, 2017 at 2:20:25 PM PDT > To: Megan Ferguson > Cc: tools-development@ietf.org >=20 > Hi Megan, >=20 > On 2017-05-19 21:55, Megan Ferguson wrote: >> Hi Henrik, >>=20 >> Some notes on our initial test pass. Please let me know if you would >> like any further information on any of the points below. >=20 > In general, I'd very much appreciate the relevant draft name when you > point out an issue; that will let me use that in testing and fixing > the issue. As you'll see below, I believe that many of the issues you > mention below are fixed in the latest release (1.0.0-rc1), but there > are some cases below where the draft name would be good to have. MF- Ack. I used draft-ietf-isis-mi-bis-03 originally. I have rerun = this same file with the newer version and found=20 most of the items previously discussed to be resolved. I also tested on draft-ietf-rtgwg-yang-key-chain-24. Latest Release Notes: --------------------- 1) Missing references: When running id2xml (v1.0.0-rc1) on draft-ietf-isis-mi-bis-03, I = received the following warning: id2xml draft-ietf-isis-mi-bis-03test.txt Converting 'draft-ietf-isis-mi-bis-03test.txt' draft-ietf-isis-mi-bis-03test.txt(660): Warning: Failed parsing a = reference: [ISO10589] "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473), ISO/IEC 10589:2002, Second Edition.", Nov 2002. Written to 'draft-ietf-isis-mi-bis-03test.xml=92 With the reference being removed but the reference element still = included (causing v2 not to parse until the empty=20 element was removed). Note that I also got a similar error running = draft-ietf-rtgwg-yang-key-chain-24: id2xml draft-ietf-rtgwg-yang-key-chain-24test.txt Converting 'draft-ietf-rtgwg-yang-key-chain-24test.txt' draft-ietf-rtgwg-yang-key-chain-24test.txt(983): Warning: Failed parsing = a reference: [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol. 2, No. 2, Summer 1996. *This second instance was more interesting to me based on the fact that = the document contains a [Dobb96a] reference=20 that is used very similarly, but was picked up just fine. 2) I was curious about how a reference to a BCP that included more than = one RFC would be handled (for example, BCP 9 below). =20 In text, it would appear as: [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Kolkman, O., Bradner, S., and S. Turner, "Characterization of Proposed Standards", BCP 9, RFC 7127, January 2014. Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009. Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011. Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, December 2013. Dawkins, S., "Increasing the Number of Area Directors in an IETF Area", BCP 9, RFC 7475, March 2015. I don=92t have a draft in queue to test this on, so I just manually = added a reference to BCP 9 and corresponding citation=20 to draft-ietf-rtgwg-yang-key-chain-24.txt. Below is the resulting XML = from id2xml: The Internet Standards Process = -- Revision 3 *Note - references to multi-RFC BCPs and STDs are rare and require = manual post-xml2rfcv2 updates with our current tools.=20 The current possible workaround in xml is to include an = element. However, I *believe* only one such element is allowed. 3) There are XML snippets in the appendices of = draft-ietf-rtgwg-yang-key-chain-24. id2xml put the first two them into = lists,=20 which broke the alignment (the original XML by the authors used = ), but the third snippet in the last appendix was put into = . Original text: Appendix A. Examples A.1. Simple Key Chain with Always Valid Single Key keychain-no-end-time A key chain with a single key that is always valid for transmission and reception. 100 hmac-sha-256 keystring_in_ascii_100 id2xml text: Appendix A. Examples A.1. Simple Key Chain with Always Valid Single Key = keychain-no-end-time A key chain with a single key that is always valid for transmission and reception. 100 hmac-sha-256 keystring_in_ascii_100 [snip] >>=20 >> 1) We were surprised to see symrefs set to no as most reference >> entries we see use the RFC number as citation tag. >=20 > The generated xml should reflect the symrefs setting appropriate for > the input. If the input file uses symrefs=3D"no", the xml will try to > detect that; and likewise for symrefs=3D"yes". Could you send me the > input source which gave symrefs=3D"no" when you did not expect it, = please? MF - This was in the XML output from draft-ietf-isis-mi-bis-03.txt: it = appears to be set to =93yes=94 in the current version of id2xml. >=20 >=20 [snip] >> Artwork tags vs. lists=20 >> =97=97=97=97=97=97=97 >> 4) The following list was converted to a hanging list, which really = changed the output. =20 >> The author-submitted version had this list in artwork. >>=20 >>=20 >> Original text: >>=20 >> An MI-RTR MUST NOT support [RFC5120] multi-topology within a = non-zero >> instance when any non-zero ITID is supported. The following TLVs >> MUST NOT be sent in an LSP associated with a non-zero instance = which >> supports a non-zero ITID and such an LSP MUST be ignored when >> received: >>=20 >> TLV 222 - MT IS Neighbors >> TLV 235 - MT IP Reachability >> TLV 237 - MT IPv6 Reachability >>=20 >> id2xml text output: >>=20 >> An MI-RTR MUST NOT support [RFC5120] multi-topology within a = non-zero >> instance when any non-zero ITID is supported. The following TLVs >> MUST NOT be sent in an LSP associated with a non-zero instance = which >> supports a non-zero ITID and such an LSP MUST be ignored when >> received: >>=20 >> TLV 222 - MT IS Neighbors >>=20 >> TLV 235 - MT IP Reachability TLV 237 - MT IPv6 Reachability >=20 > Yes. A definite flaw. This is much improved in version 1.0.0-rc1, = which > I just released. There will, however, still be cases where id2xml = tries > to make lists out of something that originally was artwork. This is = for > good reasons: Artwork is the last fallback if nothing else will fit, = because > it doesn't map well to html elements -- it's just a fixed-width-font = blob. >=20 > I'll snip the other examples you give -- please try v1.0.0-rc1 on the > relevant documents, and see if it does better. I believe it will. If = not, > please let me know the document names I should use to reproduce the = issue. >=20 MF - This is greatly improved in the current version when running this = same file. >=20 >> 5) The text following this figure was originally included in an >> tag and appeared as slightly indented in the text. >>=20 >> original text: >=20 > ... >=20 >> id2xml text output: >>=20 >> Type: 7 >> Length: 2 - 254 >> Value: >> No. of octets >> +-------------------------+ >> | IID (0 - 65535) | 2 >> +-------------------------+ >> | Supported ITID | 2 >> +-------------------------+ >> : : >> +-------------------------+ >> | Supported ITID | 2 >> +-------------------------+ >>=20 >> When the IID =3D 0, the list of supported ITIDs MUST NOT be = present. >>=20 >> An IID-TLV with IID =3D 0 MUST NOT appear in an SNP or LSP. When >>=20 >> the TLV appears (with a non-zero IID) in an SNP or LSP, exactly >> one ITID MUST be present indicating the instance-specific = topology >> with which the PDU is associated. If no ITIDs or multiple ITIDs >> are present or the IID is zero, then the PDU MUST be ignored. >=20 >=20 > ( <> a number of similar cases ) >=20 > Yes. This was a recurring phenomenon for some documents in 0.9.3. > I believe it will be better handled by 1.0.0-rc1. Could you check? >=20 MF - Yes, this seems to be resolved. > If not, could you please provide the name of the input document, so > I can add it to my test suite and work in improving the handling? >=20 >=20 >>=20 >> Citations throughout text >> =97=97=97=97=97=97=97=97=97 >>=20 >> 6) It appears that citations were not converted to xref tags >> throughout. For example: >=20 > This should also be much improved in 1.0.0-rc1. Still missing is > conversion of citations within tables; I've found that the chances > of messing up there are higher. I'll have a look at addressing that > case, too. >=20 MF - Yes it is. >=20 >> Reference Entries in the References section >> =97=97=97=97=97=97=97=97 >> 7) We note that elements were not used and the references >> section was created using a
element instead of >> and appears in the as opposed to . >=20 > The detection of reference sections was very mixed in version 0.9.3. = If > the reference sections were numbered, they would be missed, if they = were > not, they would be processed. Version 1.0.0-rc1 attempts to recognize = also > numbered reference sections, and generate both inline = entries > and entity definitions at the top. MF - This seems to be the case when rerunning draft-ietf-isis-mi-bis-03. = =20 (Please note the 2 exceptions I encountered above.) >=20 >> Is it possible to make these be includes (e.g.,=20 >> )? That way, the RPC will = know the >> entries are being pulled from the citation library and contain the >> correct information. We understand that v3 will have to contain the >> expanded references. >=20 > It is possible, but as you indicate, the = construct is > deprecated. The best (I believe) alternative when working with both = v2 > and v3 xml sources is to use entity definitions, and have those = expanded by > xml2rfc (in v2) and by the preptool (in v3) during final processing. = In > order to make it easy to use entities, I insert entity definitions at = the > start of the generated xml both in 0.9.3 and in 1.0.0-rc1. >=20 > The choice of inserting both entity definitions at the start, and = expanded > xml refereces in the sections was done to make it easier = for > you to choose one or the other. If you'd rather I inserted the = appropriate > entity at the point of reference, I could do so. You would then = instead > of: >=20 > > > > > ... >=20 > see: >=20 > > > &RFC2119; > &RFC5304; > ... >=20 > and it would pull the reference entries from the citation library in = the > same way as with the pi. >=20 MF - We believe it is more desirable for our purposes to have the entity = definitions at the start and the &RFC2119;-style calls in the References = section. =20 >=20 >> 8) In v2, there is currently a setting to keep DOIs, draft strings, >> and URLs on the same line (if possible for the latter). >=20 > Ok; which setting are you thinking of? I can certainly insert it if > desired. MF - Sorry - I don=92t know of a specific setting. I simply remember = them implementing it into one of the v2 versions.=20 >=20 >> 9) We generally see a single space after the author initials instead >> of two spaces there. >> original text: >>=20 >> [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., >> and M. Fanto, "IS-IS Generic Cryptographic >> Authentication", RFC 5310, DOI 10.17487/RFC5310, = February >> 2009, . >>=20 >> id2xml text output: >>=20 >> [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., >> and M. Fanto, "IS-IS Generic Cryptographic >> Authentication", RFC 5310, DOI 10.17487/RFC5310, = February >> 2009, . >=20 > There was an issue in 0.9.2 where extra spaces were not stripped from = the > initials string; that was fixed in 0.9.3, and should also be fixed in=20= > 1.0.0-rc1. Please let me know if you find that it's not the case. >=20 MF - This is resolved. >=20 > Thank you so much for the feedback! >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 From nobody Fri May 26 12:18:08 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D6F1204DA for ; Fri, 26 May 2017 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZhbOTgI2E9Y for ; Fri, 26 May 2017 12:18:05 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BFC1201F2 for ; Fri, 26 May 2017 12:18:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2E37E1C6B8C; Fri, 26 May 2017 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqVbCAUgBUuL; Fri, 26 May 2017 12:17:54 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id DE21D1C52E7; Fri, 26 May 2017 12:17:53 -0700 (PDT) From: Sandy Ginoza Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C9ADF92B-5320-4259-BCE3-9849C6A50B11" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 26 May 2017 12:18:04 -0700 In-Reply-To: Cc: henrik@levkowetz.com, tools-development@ietf.org, Alice Russo To: Megan Ferguson References: <591F6199.60801@levkowetz.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 19:18:07 -0000 --Apple-Mail=_C9ADF92B-5320-4259-BCE3-9849C6A50B11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, xml v2 does not handle the formatting for these types of reference = entries, and I believe the goal for id2xml is to convert .txt to .xml v2 = (so this will not be addressed via id2xml) =E2=80=94 though, please = correct me if I=E2=80=99m mistaken. If not, we will continue to = manually update these entries post xml2rfc.=20 However, I am curious about where the reference information to create = the XML entry is being pulled from. Does it XMLize the text entry or = does it pull info from somewhere else?=20 Thanks, Sandy > On May 26, 2017, at 11:49 AM, Megan Ferguson = wrote: >=20 > 2) I was curious about how a reference to a BCP that included more = than one RFC would be handled (for example, BCP 9 below). =20 >=20 >=20 > In text, it would appear as: >=20 > [BCP9] Bradner, S., "The Internet Standards Process -- Revision > 3", BCP 9, RFC 2026, October 1996. >=20 > Kolkman, O., Bradner, S., and S. Turner, = "Characterization > of Proposed Standards", BCP 9, RFC 7127, January 2014. >=20 > Dusseault, L. and R. Sparks, "Guidance on Interoperation > and Implementation Reports for Advancement to Draft > Standard", BCP 9, RFC 5657, September 2009. >=20 > Housley, R., Crocker, D., and E. Burger, "Reducing the > Standards Track to Two Maturity Levels", BCP 9, RFC 6410, > October 2011. >=20 > Resnick, P., "Retirement of the "Internet Official > Protocol Standards" Summary Document", BCP 9, RFC 7100, > December 2013. >=20 > Dawkins, S., "Increasing the Number of Area Directors in > an IETF Area", BCP 9, RFC 7475, March 2015. >=20 > > >=20 >=20 > I don=E2=80=99t have a draft in queue to test this on, so I just = manually added a reference to BCP 9 and corresponding citation=20 > to draft-ietf-rtgwg-yang-key-chain-24.txt. Below is the resulting XML = from id2xml: >=20 > The Internet Standards = Process -- Revision 3 > > > > > > > > > > > > > > > > > > >=20 > *Note - references to multi-RFC BCPs and STDs are rare and require = manual post-xml2rfcv2 updates with our current tools.=20 > The current possible workaround in xml is to include an = element. However, I *believe* only one such element is allowed. --Apple-Mail=_C9ADF92B-5320-4259-BCE3-9849C6A50B11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

xml= v2 does not handle the formatting for these types of reference entries, = and I believe the goal for id2xml is to convert .txt to .xml v2 (so this = will not be addressed via id2xml) =E2=80=94 though, please correct me if = I=E2=80=99m mistaken.  If not, we will continue to manually update = these entries post xml2rfc. 

However, I am curious about where the = reference information to create the XML entry is being pulled from. =  Does it XMLize the text entry or does it pull info from somewhere = else? 

Thanks,
Sandy

On = May 26, 2017, at 11:49 AM, Megan Ferguson <mferguson@amsl.com> = wrote:

2) I was curious about how a = reference to a BCP that included more than one RFC would be handled (for = example, BCP 9 below).  

In text, it would appear as:
  [BCP9] =     Bradner, S., "The Internet Standards Process -- = Revision
          &nb= sp;  3", BCP 9, RFC 2026, October 1996.
          &nb= sp;  Kolkman, O., Bradner, S., and S. Turner, = "Characterization
          &nb= sp;  of Proposed Standards", BCP 9, RFC 7127, January = 2014.

          &nb= sp;  Dusseault, L. and R. Sparks, "Guidance on = Interoperation
          &nb= sp;  and Implementation Reports for Advancement to = Draft
          &nb= sp;  Standard", BCP 9, RFC 5657, September 2009.
          &nb= sp;  Housley, R., Crocker, D., and E. Burger, "Reducing = the
          &nb= sp;  Standards Track to Two Maturity Levels", BCP 9, RFC = 6410,
          &nb= sp;  October 2011.

          &nb= sp;  Resnick, P., "Retirement of the "Internet = Official
          &nb= sp;  Protocol Standards" Summary Document", BCP 9, RFC = 7100,
          &nb= sp;  December 2013.

          &nb= sp;  Dawkins, S., "Increasing the Number of Area Directors = in
          &nb= sp;  an IETF Area", BCP 9, RFC 7475, March 2015.
          &nb= sp;  <http://www.rfc-editor.org/info/bcp9>
I don=E2=80=99t have a draft in queue to test = this on, so I just manually added a reference to BCP 9 and corresponding = citation 
to draft-ietf-rtgwg-yang-key-chain-24.txt. Below = is the resulting XML from id2xml:

<reference = anchor=3D"BCP9"><front><title>The Internet Standards = Process -- Revision 3</title>
<author fullname=3D"S. Bradner" = initials=3D"S." surname=3D"Bradner"/>
<date month=3D"October" = year=3D"1996"/>
= </front>
<seriesInfo name=3D"BCP" = value=3D"9"/>
= <seriesInfo = name=3D"RFC" value=3D"2026"/>
</reference>
<reference><front/>
</reference>
<reference><front/>
</reference>
<reference><front/>
</reference>
<reference><front/>
</reference>
<reference><front/>
</reference>
<reference><front/>
</reference>
*Note - references to multi-RFC BCPs and STDs = are rare and require manual post-xml2rfcv2 updates with our current = tools. 
The current possible workaround in xml is to = include an <annotation> element.  However, I *believe* only = one such element is allowed.

= --Apple-Mail=_C9ADF92B-5320-4259-BCE3-9849C6A50B11-- From nobody Fri May 26 13:08:22 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7112940D for ; Fri, 26 May 2017 13:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K98N553CnUuw for ; Fri, 26 May 2017 13:08:20 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAFA124281 for ; Fri, 26 May 2017 13:08:19 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:50314 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dELWz-0005Y1-LC; Fri, 26 May 2017 13:08:19 -0700 To: Sandy Ginoza , Megan Ferguson References: <591F6199.60801@levkowetz.com> Cc: tools-development@ietf.org From: Henrik Levkowetz Message-ID: <59288B29.7040906@levkowetz.com> Date: Fri, 26 May 2017 22:08:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GThBIDrfk9saQTCukhGrvhwFQGPqUkdFx" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.com, sginoza@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 20:08:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GThBIDrfk9saQTCukhGrvhwFQGPqUkdFx Content-Type: multipart/mixed; boundary="9VRMlbe8BJ7KJuuNXq5xIGExMGEBk9p6i"; protected-headers="v1" From: Henrik Levkowetz To: Sandy Ginoza , Megan Ferguson Cc: tools-development@ietf.org Message-ID: <59288B29.7040906@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <591F6199.60801@levkowetz.com> In-Reply-To: --9VRMlbe8BJ7KJuuNXq5xIGExMGEBk9p6i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-05-26 21:18, Sandy Ginoza wrote: > Hi All, >=20 > xml v2 does not handle the formatting for these types of reference > entries, and I believe the goal for id2xml is to convert .txt to .xml > v2 (so this will not be addressed via id2xml) =E2=80=94 though, please > correct me if I=E2=80=99m mistaken. If not, we will continue to manuall= y > update these entries post xml2rfc. For version 1.x of id2xml this is right. The intention is to produce a version 2.x of id2xml which will produce vocabulary v3 xml as part of the= current work. At that time, entries like the one below should be correctly parsed into xml (v3) by id2xml. > However, I am curious about where the reference information to create > the XML entry is being pulled from. Does it XMLize the text entry or > does it pull info from somewhere else? That would be interesting to know, yes. Henrik > Thanks, > Sandy >=20 >> On May 26, 2017, at 11:49 AM, Megan Ferguson wrot= e: >>=20 >> 2) I was curious about how a reference to a BCP that included more tha= n one RFC would be handled (for example, BCP 9 below). =20 >>=20 >>=20 >> In text, it would appear as: >>=20 >> [BCP9] Bradner, S., "The Internet Standards Process -- Revision >> 3", BCP 9, RFC 2026, October 1996. >>=20 >> Kolkman, O., Bradner, S., and S. Turner, "Characterizatio= n >> of Proposed Standards", BCP 9, RFC 7127, January 2014. >>=20 >> Dusseault, L. and R. Sparks, "Guidance on Interoperation >> and Implementation Reports for Advancement to Draft >> Standard", BCP 9, RFC 5657, September 2009. >>=20 >> Housley, R., Crocker, D., and E. Burger, "Reducing the >> Standards Track to Two Maturity Levels", BCP 9, RFC 6410,= >> October 2011. >>=20 >> Resnick, P., "Retirement of the "Internet Official >> Protocol Standards" Summary Document", BCP 9, RFC 7100, >> December 2013. >>=20 >> Dawkins, S., "Increasing the Number of Area Directors in >> an IETF Area", BCP 9, RFC 7475, March 2015. >>=20 >> > >>=20 >>=20 >> I don=E2=80=99t have a draft in queue to test this on, so I just manua= lly added a reference to BCP 9 and corresponding citation=20 >> to draft-ietf-rtgwg-yang-key-chain-24.txt. Below is the resulting XML = from id2xml: >>=20 >> The Internet Standards Proces= s -- Revision 3 >> = >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>=20 >> *Note - references to multi-RFC BCPs and STDs are rare and require man= ual post-xml2rfcv2 updates with our current tools.=20 >> The current possible workaround in xml is to include an e= lement. However, I *believe* only one such element is allowed. >=20 >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --9VRMlbe8BJ7KJuuNXq5xIGExMGEBk9p6i-- --GThBIDrfk9saQTCukhGrvhwFQGPqUkdFx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZKIsqAAoJEE6bV0uPuxca4WcP/RPcKNdgSBhqwGvqrEHbkF1z IBHr8LF9LKDayKWsNGRk/OEZbaSUisFKjXWmOwimh5EbtqJ9GmRw/GniV/AoFgQV fCDt24aybfWhuRlfa3cpNtg0TrzjQD7J3ZjBgayfKFpnVDjmHD3lNTfzEhOfwAb0 BJvLOV04yOjfKs1mIZQoW3A9e6vxXyyYDq6gWJJYbSyK1jOmhg3tZokvETR+AYdK D1lY32D+JHcVV7l8HK1xEEcQBMEJ2AQyxjwboHVtHhqjisUixKYlls7VCdZixGAR kKokwhU6aLu0QIGVAS/LR74p8tTMQVxVKOVIabe8Gz2qz2fk1CgPPd4bh/LIy9P1 oYvSyJnXghFJTBgoo0Hq+YlyxZmMg++PuJ6T+RvJO7HwKTJ+PVo4xFiAde+psGvI LTOp/PPgpLspSBaXY40tudqhZyKP5oMmGYIN3/ZGyoIcfV0rNkVVf1I560vAGPm0 O07axS9LAUBmLdcByDubgjmiqcIEVQ8APZ4y+6Suc6krVlWBf9KFMTs44K3o8sjt LjmZFlHlCphVFEvco2ZfQ0TxFHnkVAqq2MSoTxliMmMKsVMs2vwiPt511Kyxq33G nM9M/RjBnPT6fivBAPoHWE3iD7IkhqI1kKL2IKn2ad57UIqv7y/L9HQPaw28WFtH Xuxry9LH55aF2MmxMXJ/ =9wJG -----END PGP SIGNATURE----- --GThBIDrfk9saQTCukhGrvhwFQGPqUkdFx-- From nobody Fri May 26 13:27:36 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945B7127ABE for ; Fri, 26 May 2017 13:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27XvnCXLXDto for ; Fri, 26 May 2017 13:27:31 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F2512E741 for ; Fri, 26 May 2017 13:27:30 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:50678 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dELpZ-0003ii-Np; Fri, 26 May 2017 13:27:30 -0700 To: Megan Ferguson References: <591F6199.60801@levkowetz.com> Cc: tools-development@ietf.org, Sandy Ginoza , Alice Russo From: Henrik Levkowetz Message-ID: <59288FA9.3010005@levkowetz.com> Date: Fri, 26 May 2017 22:27:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ATXKawwApoQnxSNe8WOIpqRKmPgLLTt2S" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: arusso@amsl.com, sginoza@amsl.com, tools-development@ietf.org, mferguson@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fwd: Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 20:27:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ATXKawwApoQnxSNe8WOIpqRKmPgLLTt2S Content-Type: multipart/mixed; boundary="dlCN7j2rpAM334Rjf474OxnJSNdbdHo7C"; protected-headers="v1" From: Henrik Levkowetz To: Megan Ferguson Cc: tools-development@ietf.org, Sandy Ginoza , Alice Russo Message-ID: <59288FA9.3010005@levkowetz.com> Subject: Re: Fwd: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <591F6199.60801@levkowetz.com> In-Reply-To: --dlCN7j2rpAM334Rjf474OxnJSNdbdHo7C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Megan, On 2017-05-26 20:49, Megan Ferguson wrote: > Hi Henrik, >=20 > Thank you for your reply and explanations. Inline below with MF. >=20 > Megan >=20 > Begin forwarded message: >=20 >> From: Henrik Levkowetz >> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Co= nverter, id2xml >> Date: May 19, 2017 at 2:20:25 PM PDT >> To: Megan Ferguson >> Cc: tools-development@ietf.org >>=20 >> Hi Megan, >>=20 >> On 2017-05-19 21:55, Megan Ferguson wrote: >>> Hi Henrik, >>>=20 >>> Some notes on our initial test pass. Please let me know if you would >>> like any further information on any of the points below. >>=20 >> In general, I'd very much appreciate the relevant draft name when you >> point out an issue; that will let me use that in testing and fixing >> the issue. As you'll see below, I believe that many of the issues you= >> mention below are fixed in the latest release (1.0.0-rc1), but there >> are some cases below where the draft name would be good to have. >=20 > MF- Ack. I used draft-ietf-isis-mi-bis-03 originally. I have rerun th= is same file with the newer version and found=20 > most of the items previously discussed to be resolved. >=20 > I also tested on draft-ietf-rtgwg-yang-key-chain-24. >=20 > Latest Release Notes: > --------------------- >=20 > 1) Missing references: >=20 > When running id2xml (v1.0.0-rc1) on draft-ietf-isis-mi-bis-03, I > received the following warning: >=20 > id2xml draft-ietf-isis-mi-bis-03test.txt > Converting 'draft-ietf-isis-mi-bis-03test.txt' >=20 > draft-ietf-isis-mi-bis-03test.txt(660): Warning: Failed parsing a refer= ence: > [ISO10589] > "Intermediate system to Intermediate system intra-domain > routeing information exchange protocol for use in > conjunction with the protocol for providing the > connectionless-mode Network Service (ISO 8473), ISO/IEC > 10589:2002, Second Edition.", Nov 2002. > Written to 'draft-ietf-isis-mi-bis-03test.xml=E2=80=99 >=20 > With the reference being removed but the reference element still > included (causing v2 not to parse until the empty element was > removed). Yes, this is the current behaviour with a reference that cannot be parsed= =2E If you are happy with the text in the input document (i.e., it looks the = way you would want to see it in an RFC, then please let me know, and I'll see= if I can adjust the set of regexes used to parse reference text. In the cas= e above, it seems to me that series information has incorrectly been made p= art of the document title. I would expect the reference to be correctly pars= ed if you break out the series info the way you'd like to see it in a publis= hed document. > Note that I also got a similar error running > draft-ietf-rtgwg-yang-key-chain-24: >=20 > id2xml draft-ietf-rtgwg-yang-key-chain-24test.txt > Converting 'draft-ietf-rtgwg-yang-key-chain-24test.txt' >=20 > draft-ietf-rtgwg-yang-key-chain-24test.txt(983): Warning: Failed parsin= g a reference: > [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack",= > CryptoBytes Vol. 2, No. 2, Summer 1996. Yes. There's nothing in the current rule set for reference text which kn= ows how to handle 'Summer 1996'. > *This second instance was more interesting to me based on the fact > that the document contains a [Dobb96a] reference that is used very > similarly, but was picked up just fine. >=20 > 2) I was curious about how a reference to a BCP that included more > than one RFC would be handled (for example, BCP 9 below). [snip] Sandy posted a comment on this, which was to-the-point. > 3) There are XML snippets in the appendices of > draft-ietf-rtgwg-yang-key-chain-24. id2xml put the first two them > into lists, which broke the alignment (the original XML by the > authors used ), but the third snippet in the last appendix > was put into . Right. This is something I also found meanwhile. I've enhanced the regex which identifies code snippets to recognise xml and relatives; this should be handled correctly in 2.0.0rc3. [snipping a number of points where you confirm that 1.0.0-rc1 fixed the issue -- thank you, good to get the confirmation] >> The choice of inserting both entity definitions at the start, and expa= nded >> xml refereces in the sections was done to make it easier= for >> you to choose one or the other. If you'd rather I inserted the approp= riate >> entity at the point of reference, I could do so. You would then inste= ad >> of: >>=20 >> >> >> >> >> ... >>=20 >> see: >>=20 >> >> >> &RFC2119; >> &RFC5304; >> ... >>=20 >> and it would pull the reference entries from the citation library in t= he >> same way as with the pi. >>=20 > MF - We believe it is more desirable for our purposes to have the > entity definitions at the start and the &RFC2119;-style calls in the > References section. Ok, I will remove the generated reference xml and instead insert the reference entities in the next release. >>=20 >>> 8) In v2, there is currently a setting to keep DOIs, draft strings, >>> and URLs on the same line (if possible for the latter). >>=20 >> Ok; which setting are you thinking of? I can certainly insert it if >> desired. >=20 > MF - Sorry - I don=E2=80=99t know of a specific setting. I simply reme= mber them implementing it into one of the v2 versions.=20 Ok. FWIW, when xml2rfc processes what id2xml currently generates, it tries to keep DOIs etc. on one line. That's actually a source of differences with the input documents in the test suite, in several cases,= because they don't always try as hard to keep the DOIs etc. on the same line ,:-) >>> 9) We generally see a single space after the author initials instead >>> of two spaces there. >>> original text: >>>=20 >>> [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,= >>> and M. Fanto, "IS-IS Generic Cryptographic >>> Authentication", RFC 5310, DOI 10.17487/RFC5310, Februar= y >>> 2009, . >>>=20 >>> id2xml text output: >>>=20 >>> [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,= >>> and M. Fanto, "IS-IS Generic Cryptographic >>> Authentication", RFC 5310, DOI 10.17487/RFC5310, Februar= y >>> 2009, . >>=20 >> There was an issue in 0.9.2 where extra spaces were not stripped from = the >> initials string; that was fixed in 0.9.3, and should also be fixed in = >> 1.0.0-rc1. Please let me know if you find that it's not the case. >>=20 > MF - This is resolved. Ok, splendid. Thank you again for the feedback! Best regards, Henrik --dlCN7j2rpAM334Rjf474OxnJSNdbdHo7C-- --ATXKawwApoQnxSNe8WOIpqRKmPgLLTt2S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZKI+pAAoJEE6bV0uPuxca3BkQAJCaWW08NShnROQ+PayHpIwF oDGEUwya4pOukMu2dyfaeX4o6YwPDJRVJ5xFaacKY2Lec5XdZ0hyL8CeJQjV2m8T XspgSFpMVcdbh7o8cgFgZQIUcbu4w2e1D77wT8Idfm6b8RxyjAj1F7xeadX5N466 0RVxj871F1DgVCK8qf8wK/GQCAyPmXPPSvIwIRamgu//+kIgVxucRTEls/vsHLc1 qdwA0HBuZMe28IRjaofqL7NlmKdwTBoZiCMkiIU32KPwWCfNIi0Cnde6J51XXzi1 x/ey6m4MTkwq8gVOrs7ePE5DC/+4lSr3ocj46q33kfeiWmhHy/uolujXqNZiGLa5 9rLyYf6uHCxBaibolNRxpfhFpu+z5qT3DB5r6gSk6YaDJcrQh6+LqwbZOygJH+ZA am8NFJla5u3WUfDE7Tzp9eQcBbfT+Q3aHo4OsI8AzasQ6Bke56+L/NCMXfLhg+/l wl6FjrH5/3PsWeRQjNUpANHDjN/ZXHYD4dGkwxNkErOYN9sN6KHuQenAfig7asOq ERvvUDVbVZzxpL24IG8Y+YxXJMtnAHuT0gXcW9y1qjeV8gAYv7Bnp1HsRjEQ7J8l jM8DFPFkr/IyowibRkWjt413oB1d30hPaDR+kNy4wvbN9UNZGTYEWEx9QEeD9eoy 04qM6RpY80RQkpFZ+AWO =ATdr -----END PGP SIGNATURE----- --ATXKawwApoQnxSNe8WOIpqRKmPgLLTt2S--