From trac@tools.ietf.org Wed Jan 1 18:07:38 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9C51AE092 for ; Wed, 1 Jan 2014 18:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 o826EmgVRKFb for ; Wed, 1 Jan 2014 18:07:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A36301AE091 for ; Wed, 1 Jan 2014 18:07:36 -0800 (PST) Received: from localhost ([127.0.0.1]:54882 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VyXgp-00016P-2L; Thu, 02 Jan 2014 03:07:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Thu, 02 Jan 2014 02:07:14 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/201#comment:2 Message-ID: <078.0ca546477e7ea011cdb47655f5bdf317@tools.ietf.org> References: <063.14f94add5ae172e5021a179265141b48@tools.ietf.org> X-Trac-Ticket-ID: 201 In-Reply-To: <063.14f94add5ae172e5021a179265141b48@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@augustcellars.com, sginoza@amsl.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org, sginoza@amsl.com Subject: Re: [xml2rfc] #201: bug with cref element and PI inline=yes X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 02:07:38 -0000 #201: bug with cref element and PI inline=yes Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1108] We now do the correct things for crefs. -- ------------------------------+------------------------------------ Reporter: arusso@amsl.com | Owner: ietf@augustcellars.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+------------------------------------ Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 1 18:09:03 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F7E1AE091 for ; Wed, 1 Jan 2014 18:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 mG5rYaLNHpzz for ; Wed, 1 Jan 2014 18:09:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B9BF31AE07C for ; Wed, 1 Jan 2014 18:09:00 -0800 (PST) Received: from localhost ([127.0.0.1]:54945 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VyXiN-000422-SG; Thu, 02 Jan 2014 03:08:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, infrastation@yandex.ru, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Thu, 02 Jan 2014 02:08:51 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/133#comment:3 Message-ID: <085.40894bf8dec12dcad3bfe0d561f3f732@tools.ietf.org> References: <070.11e72dc5023d67cbc392417eb36cd549@tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <070.11e72dc5023d67cbc392417eb36cd549@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, infrastation@yandex.ru, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #133: URIs paragraph missing for EREF footnotes X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 02:09:03 -0000 #133: URIs paragraph missing for EREF footnotes Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1108] We now put an URIs section into the references if it is needed for text based outputs. There are no changes in the html outputs. -- -------------------------------------+---------------------------------- Reporter: infrastation@yandex.ru | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: -------------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 1 18:09:52 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA71AE091 for ; Wed, 1 Jan 2014 18:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 5QTHFwZa3C5Q for ; Wed, 1 Jan 2014 18:09:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF01AE07C for ; Wed, 1 Jan 2014 18:09:50 -0800 (PST) Received: from localhost ([127.0.0.1]:54971 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VyXjD-0002Eo-8Y; Thu, 02 Jan 2014 03:09:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Thu, 02 Jan 2014 02:09:43 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/218#comment:2 Message-ID: <085.8d33b181da868f8e7d3ed059c8be7afe@tools.ietf.org> References: <070.3d5046cae37eda5cc9b19e00287e521c@tools.ietf.org> X-Trac-Ticket-ID: 218 In-Reply-To: <070.3d5046cae37eda5cc9b19e00287e521c@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #218: Nested lists using style "format" incorrectly number X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 02:09:52 -0000 #218: Nested lists using style "format" incorrectly number Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1108] We now append the level to the auto-created counter if one is not supplied by the input file. -- -------------------------------------+------------------------------------ Reporter: ietf@augustcellars.com | Owner: ietf@augustcellars.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: -------------------------------------+------------------------------------ Ticket URL: xml2rfc From trac@tools.ietf.org Sun Jan 5 08:03:38 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291D41AED48 for ; Sun, 5 Jan 2014 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 KsO92kIGBxiP for ; Sun, 5 Jan 2014 08:03:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF301AED47 for ; Sun, 5 Jan 2014 08:03:36 -0800 (PST) Received: from localhost ([127.0.0.1]:44707 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VzqAh-0002vL-5l; Sun, 05 Jan 2014 17:03:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, schmidt@informatik.haw-hamburg.de X-Trac-Project: xml2rfc Date: Sun, 05 Jan 2014 16:03:27 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/220 Message-ID: <081.305a1502ab7d17de2c0a8f73fd87dc02@tools.ietf.org> X-Trac-Ticket-ID: 220 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, schmidt@informatik.haw-hamburg.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #220: Failure in ID Database X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 16:03:38 -0000 #220: Failure in ID Database When updating a draft with xml2rfc, an outdated ID version is resolved (which indeed is latest in the draft DB). IDNITS, though, discovers the current version of the draft and complains. Details: Referenced draft: draft-ietf-multimob-fmipv6-pfmipv6-multicast Current version: draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 Latest version in DB: draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 Who can resolve this inconsistency?? Thanks, Thomas -- -----------------------------------------------+--------------------------- Reporter: schmidt@informatik.haw-hamburg.de | Owner: Type: defect | henrik@levkowetz.com Priority: medium | Status: new Component: Version 2 cli | Milestone: Keywords: | Version: 2.4.x -----------------------------------------------+--------------------------- Ticket URL: xml2rfc From arusso@amsl.com Mon Jan 6 09:21:28 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CE31AE129 for ; Mon, 6 Jan 2014 09:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham 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 8tyG4cfM5hZC for ; Mon, 6 Jan 2014 09:21:23 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [64.170.98.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6301AE113 for ; Mon, 6 Jan 2014 09:21:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c9a.amsl.com (Postfix) with ESMTP id CBB64A61B0; Mon, 6 Jan 2014 09:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c9a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLYOUhqdTAlh; Mon, 6 Jan 2014 09:19:41 -0800 (PST) Received: from rfc2.home (pool-68-238-162-118.washdc.fios.verizon.net [68.238.162.118]) by c9a.amsl.com (Postfix) with ESMTPSA id 2DE62A60B6; Mon, 6 Jan 2014 09:19:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alice Russo In-Reply-To: <20140106102657.GA6473@nic.fr> Date: Mon, 6 Jan 2014 12:21:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <525A73E5-0C23-4FA3-988D-FFC0FB5E1F26@amsl.com> References: <20140106102657.GA6473@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1085) Cc: alexandre.dulaunoy@circl.lu, RFC Interest , xml2rfc list , "W.C.A. Wijngaards" Subject: Re: [xml2rfc] [rfc-i] Several Internet-Drafts missing at xml.resource.org X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:21:28 -0000 Stephane, Yes; this issue with the XML citation libraries for I-Ds and RFCs = (bibxml3 and bibxml) has been reported, and Tony Hansen wrote Dec 27, = 2013 (to the xml2rfc list): > The problem has been identified. Hopefully a fix can be worked out = soon. Thank you. RFC Editor/ar On Jan 6, 2014, at 5:26 AM, Stephane Bortzmeyer wrote: > Anything wrong recently in this repository? xml2rfc tells me: >=20 > ERROR: Unable to parse the XML document: = draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml > draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml: Line 0: Unable to = resolve external request: = "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijngaards-dnsop= -confidentialdns" >=20 > But there is a wijngaards-dnsop-confidentialdns, since November 2013 > >=20 > Same problem for draft-bortzmeyer-dnsop-privacy-sol. You can check in > that there is nothing > recent, for instance nothing in 2014 while several -00 drafts have > been created already this year. > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest >=20 From brian.e.carpenter@gmail.com Mon Jan 6 11:20:18 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D00F1AE1C5 for ; Mon, 6 Jan 2014 11:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 TEOWD8q7iVJa for ; Mon, 6 Jan 2014 11:20:16 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8642F1AE1CC for ; Mon, 6 Jan 2014 11:20:15 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fa1so18941940pad.31 for ; Mon, 06 Jan 2014 11:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rHFGo7O4GrdNzphW2E4pRqXp/jShEvEDspuAg+k68dM=; b=MnLAG+zmcsN5gm5CYOMOCluah0BuynHIOjB8xelK0JfrhHxs6z//iZDRr5xP+HfTNo T0eq+DKmr4C6hoEEdQrAHpjCzG7L3e8D47JggBFizX6Vz96dxFfkQ1skPK+mAkVAX0SR YsHACoLa9OCjt/uMrJlDf3u1XRyt7vKXGdepxM/9CWnp8KtqxphAz3e/zXxMRRLiNis2 DHomnUlYOjQ6qsNyYSVf6PWH1KYq/h+/JUvz6kETkWibMu014SirobsPsgfS0HVjRqvB YG7oTOVR/0tlrhmeokPn1MYZ5hfytkNWVNXbDng2hEGM6YID9NKAq9dtZzXbdmPW71om UyEQ== X-Received: by 10.66.184.168 with SMTP id ev8mr115251pac.152.1389036007032; Mon, 06 Jan 2014 11:20:07 -0800 (PST) Received: from [192.168.178.21] (122.195.69.111.dynamic.snap.net.nz. [111.69.195.122]) by mx.google.com with ESMTPSA id sy10sm171018876pac.15.2014.01.06.11.20.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 11:20:06 -0800 (PST) Message-ID: <52CB01E6.9020000@gmail.com> Date: Tue, 07 Jan 2014 08:20:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: xml2rfc References: <20140106102657.GA6473@nic.fr> In-Reply-To: <20140106102657.GA6473@nic.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: alexandre.dulaunoy@circl.lu, "W.C.A. Wijngaards" Subject: Re: [xml2rfc] [rfc-i] Several Internet-Drafts missing at xml.resource.org X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 19:20:18 -0000 (Switched to xml2rfc list) There's also an issue with missing RFCs; RFC7084 was missing yesterday, for example. Similarly, idnits seems to have an incomplete list of drafts at the moment. But a different incomplete list from xml2rfc: Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-homenet-arch - is the name correct? -- No information found for draft-ietf-v6ops-64share - is the name correct? Brian On 06/01/2014 23:26, Stephane Bortzmeyer wrote: > Anything wrong recently in this repository? xml2rfc tells me: > > ERROR: Unable to parse the XML document: draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml > draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml: Line 0: Unable to resolve external request: "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijngaards-dnsop-confidentialdns" > > But there is a wijngaards-dnsop-confidentialdns, since November 2013 > > > Same problem for draft-bortzmeyer-dnsop-privacy-sol. You can check in > that there is nothing > recent, for instance nothing in 2014 while several -00 drafts have > been created already this year. > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > . > From tony@att.com Mon Jan 6 11:28:03 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4068F1AE167 for ; Mon, 6 Jan 2014 11:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 ENLK_oXdjoJJ for ; Mon, 6 Jan 2014 11:28:00 -0800 (PST) Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBE1AE15F for ; Mon, 6 Jan 2014 11:27:59 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id s06JRo3I023927 for ; Mon, 6 Jan 2014 11:27:51 -0800 Received: from vpn-135-70-96-25.vpn.swst.att.com ([135.70.96.25]) by maillennium.att.com (mailgw1) with ESMTP id <20140106192748gw100j0ccte>; Mon, 6 Jan 2014 19:27:49 +0000 X-Originating-IP: [135.70.96.25] Message-ID: <52CB03B5.50703@att.com> Date: Mon, 06 Jan 2014 14:27:49 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RFC Interest , xml2rfc list References: <20140106102657.GA6473@nic.fr> <525A73E5-0C23-4FA3-988D-FFC0FB5E1F26@amsl.com> In-Reply-To: <525A73E5-0C23-4FA3-988D-FFC0FB5E1F26@amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xml2rfc] [rfc-i] Several Internet-Drafts missing at xml.resource.org X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 19:28:03 -0000 The problem dates back to when one of the tools servers (merlot) croaked and xml.resource.org was repointed at another one of the tools servers. Unfortunately, the bibxml updating code is not running on that new tools server. The fix is to either get the updating code running on the new tools server or to repoint xml.resource.org back to merlot. Only Henrik knows for sure what the real status of these machines are. Tony On 1/6/14, 12:21 PM, Alice Russo wrote: > Stephane, > > Yes; this issue with the XML citation libraries for I-Ds and RFCs (bibxml3 and bibxml) has been reported, and Tony Hansen wrote Dec 27, 2013 (to the xml2rfc list): > >> The problem has been identified. Hopefully a fix can be worked out soon. > Thank you. > RFC Editor/ar > > On Jan 6, 2014, at 5:26 AM, Stephane Bortzmeyer wrote: > >> Anything wrong recently in this repository? xml2rfc tells me: >> >> ERROR: Unable to parse the XML document: draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml >> draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml: Line 0: Unable to resolve external request: "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijngaards-dnsop-confidentialdns" >> >> But there is a wijngaards-dnsop-confidentialdns, since November 2013 >> >> >> Same problem for draft-bortzmeyer-dnsop-privacy-sol. You can check in >> that there is nothing >> recent, for instance nothing in 2014 while several -00 drafts have >> been created already this year. >> _______________________________________________ >> rfc-interest mailing list >> rfc-interest@rfc-editor.org >> https://www.rfc-editor.org/mailman/listinfo/rfc-interest >> > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From ietf@augustcellars.com Tue Jan 7 17:47:58 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775C01AE285 for ; Tue, 7 Jan 2014 17:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 59dwLX5u9gen for ; Tue, 7 Jan 2014 17:47:55 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 78C061AE284 for ; Tue, 7 Jan 2014 17:47:55 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 798D82C9FD; Tue, 7 Jan 2014 17:47:46 -0800 (PST) From: "Jim Schaad" To: Date: Tue, 7 Jan 2014 17:46:14 -0800 Message-ID: <064801cf0c13$6a5326e0$3ef974a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0649_01CF0BD0.5C3209C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8L7QEOZNmeZASWRiCRFk15xJ6B3w== Content-Language: en-us Cc: RFC Interest Subject: [xml2rfc] Current Cacheing behavior for current XML2RFC X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 01:47:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0649_01CF0BD0.5C3209C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There are a number of issues of caching of references on a local machine, I am not sure what the current behavior is for the server but it could have some of the same types of interesting problems as well. 1. The path that is used for caching of references on the local machine is coded into the software as ['/var/cache/xml2rfc', '~/.cache/xml2rfc']. A command line option exists to insert a new directory at the front of this set of paths. I am not sure how the first directory was arrived at, the second one I recognize as being per user specific. It is not clear that having an absolute path encoded into the system makes sense for Linux, it is really a potential problem for Windows unless we are going to tell people where it is going to exist before we start. 2. The current cache can be filled and emptied, however it is never checked and refreshed in any sense. I am going to assume that there is a script on the servers that clear the cache between any pair of invocations of the script (or that something similar is done to get things refreshed). If I am really the only person that is running Xml2rfc locally on a Windows system, then there is no real reason the try and fix the first one so that the paths are going to make more sense. I have figure out where the caches are and how to play with them so it falls into the no-harm no-foul rule. I would however like to see the second issue fixed in one of a couple of different ways. There are some easy ways and some harder ways to fix the problem that would have different behaviors on the user experience. a. Just delete any item that is in the cache longer than a specific amount of time and force it to be re-downloaded. This means that documents which are no longer current will disappear, however if you go off line you might not be able to use that cached file at a later date. b. If an item is over than a specific amount of time, then try and down load it again. However if you fail then just leave the current item in the cache. This would mean that updates would be found, however items that disappear would never vanish from the cache unless the user uses the clear cache option on the command line (or deletes the contents of the cache). c. Something else that might make sense Jim ------=_NextPart_000_0649_01CF0BD0.5C3209C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are = a number of issues of caching of references on a local machine, I am not = sure what the current behavior is for the server but it could have some = of the same types of interesting problems as well.

 

1.       =  The path that is used for caching of = references on the local machine is coded into the software as = [‘/var/cache/xml2rfc’, = ‘~/.cache/xml2rfc’].  A command line option exists to = insert a new directory at the front of this set of paths.  I am not = sure how the first directory was arrived at, the second one I recognize = as being per user specific.   It is not clear that having an = absolute path encoded into the system makes sense for Linux, it is = really a potential problem for Windows unless we are going to tell = people where it is going to exist before we start.  =

2.       The = current cache can be filled and emptied, however it is never checked and = refreshed in any sense.  I am going to assume that there is a = script on the servers that clear the cache between any pair of = invocations of the script (or that something similar is done to get = things refreshed).

 

If I am = really the only person that is running Xml2rfc locally on a Windows = system, then there is no real reason the try and fix the first one so = that the paths are going to make more sense.  I have figure out = where the caches are and how to play with them so it falls into the = no-harm no-foul rule.

 

I would = however like to see the second issue fixed in one of a couple of = different ways.  There are some easy ways and some harder ways to = fix the problem that would have different behaviors on the user = experience.

 

a.       = Just delete any item that is in the cache longer = than a specific amount of time and force it to be re-downloaded.  = This means that documents which are no longer current will disappear, = however if you go off line you might not be able to use that cached file = at a later date.

b.      = If an item is over than a specific amount of = time, then try and down load it again.  However if you fail then = just leave the current item in the cache.  This would mean that = updates would be found, however items that disappear would never vanish = from the cache unless the user uses the clear cache option on the = command line (or deletes the contents of the cache).

c.       = Something else that might make = sense

 

Jim

 

------=_NextPart_000_0649_01CF0BD0.5C3209C0-- From ietf@augustcellars.com Tue Jan 7 21:45:29 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C681ADEB4 for ; Tue, 7 Jan 2014 21:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2] autolearn=ham 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 lFXCK2i5CXFY for ; Tue, 7 Jan 2014 21:45:27 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2A1ADBF7 for ; Tue, 7 Jan 2014 21:45:27 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s085jCXm067663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jan 2014 21:45:13 -0800 (PST) (envelope-from ietf@augustcellars.com) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 7749E2CA11; Tue, 7 Jan 2014 21:45:12 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , "'xml2rfc'" Date: Tue, 7 Jan 2014 21:43:39 -0800 Message-ID: <067501cf0c34$957acf00$c0706d00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8EOGdmcEjcB4JlQnKRiXxO2156eg== Content-Language: en-us Subject: [xml2rfc] Comments and Text for draft-reschke-xml2rfc-03 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 05:45:30 -0000 I am going to mail this off because I don't seem to be doing it very fast. I don't know if you want more detail or less detail on than what is in this message. Jim Section 2.5 - The 'alt', 'height', 'width', 'file', 'type', 'src' and 'xml:space' attributes are currently not used when generating documents.' Section 2.6 - From what I can tell from the code, it is expected that while the author name can be absent in a reference, the name attributes are expected to be present for the author elements that appear in the front element. They will default to empty strings, but the empty strings will then be emitted in the either the header or author sections. Section 2.6.2 - The current code allows for the separator to be either whitespace or a dot (or any combination of). Unclear if it should be noted that the initials attribute is only used if a surname attribute is also present. The current code is inconsistent on this statement. It is true for references, but is not true for the header. Section 2.6.4 - Should add the text "Authors Surname (used on the front page and in references)." Section 2.8 - I am not sure that this is the correct location for this to appear, however it needs to appear someplace. The number of columns in the table is determined by the number of ttcol elements. The number of rows in the table is determined by the number of c elements divided by the number of ttcol elements. There is no requirement that the number of c elements be evenly divisible by the number of ttcol elements. Section 2.13 - When matching the month, the abbreviated version of the month may be used as well as the full month. Section 2.13 - Currently in the second case, the day attribute is ignored when creating a reference. Section 2.15 - The text states that the URI of the target is enclosed in angle brackets. This is not true in the current system. Section 2.17 - height and width would only duplicate the functionality of these attributes on the artwork if there is not a preamble or postamble present. If these are present, then the height and width would include these as well, which the one on the figure would not. Section 2.17 - Currently the alt, height, src and width attributes are ignored. Section 2.18 - This element is ignored by the current code. Section 2.20.2 - This attribute is ignored by the current code Section 2.22.1 - When the style format is used, it is possible to use a single counter across multiple list element by naming the counter to be used. If the attribute is absent, a unique counter is synthetized. Section 2.22.2 - hangIndent This attributes allows for a specific indentation level to be specified for both the 'hanging' and 'format' styles. The value is the number of characters to indent the list paragraphs. Section 2.22.3 - style The style attribute controls how the elements in the list are going to be numbered. If a list does not have style attribute, then the style for the current list is inherited from its parent. If a list has no parent then the style 'empty' is used. The style attributes are: uses a set of symbols to tag each paragraph. The set of symbols is controlled by the PI text-list-symbols and defaults to 'o*+-'. There is currently no way to change the set of symbols to be used between different lists. uses digits to tag each paragraph uses upper and lower case letters to tag each paragraph. Upper case letters are used if the depth of the list is even and lower case letters are used if the depth is odd. The depth computation does not take into account the style attribute. allows for arbitrary text to be used to tag each paragraph. If the hangIndent attribute is not specified, then the value of 3 will be used for indentation. allows for characters to be used for tagging each paragraph along with additional decoration. The style attribute is the string 'format ' followed by text containing one of '%c', '%C', '%d', '%i', '%I', '%o', '%x', '%X'. If the hangIndent attribute is not specified, then the value of 3 will be used for indentation. uses not character to tag each paragraph. While this is the list of recognized styles, there does not appear to be any enforcement of the list of styles in either the dtd or XML2RFC. Unknown style strings will be treated as 'empty'. From julian.reschke@gmx.de Wed Jan 8 03:19:00 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD051AE18B for ; Wed, 8 Jan 2014 03:19:00 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 qsBLskC0lpY0 for ; Wed, 8 Jan 2014 03:18:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B4F781AE243 for ; Wed, 8 Jan 2014 03:18:58 -0800 (PST) Received: from [192.168.1.103] ([93.217.109.29]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MVayZ-1VtSOF3ajX-00Z2UV for ; Wed, 08 Jan 2014 12:18:49 +0100 Message-ID: <52CD3416.9070007@gmx.de> Date: Wed, 08 Jan 2014 12:18:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , xml2rfc@ietf.org References: <064801cf0c13$6a5326e0$3ef974a0$@augustcellars.com> In-Reply-To: <064801cf0c13$6a5326e0$3ef974a0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zutQDN1gk08c757a3E29vt84LnvgnHo6W1JdlIhhtpufjSLWOBR NqNFBb7WV0JlA4hYiCfD6YVChG8IJC77EsOeN4t01oxOQWtjJwp8Bx+k1P0eRr6r+GnUjz7 FV8+YkaEBH3AGDCe6cm5EXVFxl2acMrmCB+svrC7Ybz6SrDlpRarB7jIcy/PU1SUKOl9rXU jpY3ju0qcEcxLVoN2ZHwA== Cc: RFC Interest Subject: Re: [xml2rfc] [rfc-i] Current Cacheing behavior for current XML2RFC X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 11:19:00 -0000 On 2014-01-08 02:46, Jim Schaad wrote: > ... I continue to believe is that using out-of-document references simply is a bad idea; it causes all kinds of trouble, such as failures in absence of a network connection, or silent changes that don't get checked properly. What would be much more useful is to have an automated way to check in-lined references, such as with or an xml2rfc-aware variant of id-nits. That being said, I realize this is a minority opinion :-) Best regards, Julian From julian.reschke@gmx.de Wed Jan 8 03:46:19 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9D1AE342 for ; Wed, 8 Jan 2014 03:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_FAIL=0.001] autolearn=ham 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 D8D1z2CUIvWq for ; Wed, 8 Jan 2014 03:46:17 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEE1AE1D7 for ; Wed, 8 Jan 2014 03:46:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s08Bk1Re077504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 8 Jan 2014 03:46:02 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: from [192.168.1.103] ([93.217.109.29]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Me5Q2-1VkxWX3Tri-00Pvqj for ; Wed, 08 Jan 2014 12:45:55 +0100 Message-ID: <52CD3A72.2040103@gmx.de> Date: Wed, 08 Jan 2014 12:45:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , "'xml2rfc'" References: <067501cf0c34$957acf00$c0706d00$@augustcellars.com> In-Reply-To: <067501cf0c34$957acf00$c0706d00$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1P683KwoOkOBdPBoSIyRaXnvI/CSFteVFffJgO1/1ENh1icJoCs KtQRPi8fSUCa2I8RElDwcD4iIeyIM+gNULwuppUPjOImgIEuaNi+SSbFkOr9F0snIFteBGe 1HV3mb+jx/a7JsIeW/QCuE2x5jHgUtOmoW4PKF6CedB1HauAUANQljkHDjUpAR4ntzyXNem uOCr9T83HVWT8Ui5oZIZw== Subject: Re: [xml2rfc] Comments and Text for draft-reschke-xml2rfc-03 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 11:46:19 -0000 On 2014-01-08 06:43, Jim Schaad wrote: > I am going to mail this off because I don't seem to be doing it very fast. > I don't know if you want more detail or less detail on than what is in this > message. > > Jim Thanks a lot! > Section 2.5 - The 'alt', 'height', 'width', 'file', 'type', 'src' and > 'xml:space' attributes are currently not used when generating documents.' They are used by xml2rfc.tcl and rfc2629.xslt. If v2 doesn't use them then that is a bug that should be fixed. (xml:space is special in that it's a signal to the XML processor) > Section 2.6 - From what I can tell from the code, it is expected that while > the author name can be absent in a reference, the name attributes are > expected to be present for the author elements that appear in the front > element. They will default to empty strings, but the empty strings will > then be emitted in the either the header or author sections. This absolutely needs a test case, and also we need to clarify with the RSE whether that's a legal use case for an RFC. > Section 2.6.2 - The current code allows for the separator to be either > whitespace or a dot (or any combination of). Is there a reason why we need to support more than one format? > Unclear if it should be noted that the initials attribute is only > used if a surname attribute is also present. The current code is > inconsistent on this statement. It is true for references, but is not true > for the header. That sounds like an xml2rfcv2 problem, no? > Section 2.6.4 - Should add the text "Authors Surname (used on the front page > and in references)." Or maybe "used when the 'full name' is not". > Section 2.8 - I am not sure that this is the correct location for this to > appear, however it needs to appear someplace. > > The number of columns in the table is determined by the number of ttcol > elements. The number of rows in the table is determined by the number of c > elements divided by the number of ttcol elements. There is no requirement > that the number of c elements be evenly divisible by the number of ttcol > elements. Thanks, added. > Section 2.13 - When matching the month, the abbreviated version of the month > may be used as well as the full month. In xml2rfcv2. I'd prefer we have exactly one format. > Section 2.13 - Currently in the second case, the day attribute is ignored > when creating a reference. True, but will this always be true? > Section 2.15 - The text states that the URI of the target is enclosed in > angle brackets. This is not true in the current system. It is true for xml2rfc.tcl when producing plain text, and for rfc2629.xslt. xml2rfc.tcl doesn't include the brackets in HTML, but I consider this a bug because it means that the text content does not match the text version. For v3 we may want to discuss how far the text content may vary between output formats. > Section 2.17 - height and width would only duplicate the functionality of > these attributes on the artwork if there is not a preamble or postamble > present. If these are present, then the height and width would include > these as well, which the one on the figure would not. Can you explain how "height" would affect preamble and postamble? > Section 2.17 - Currently the alt, height, src and width attributes are > ignored. In xml2rfcv2 and rfc2629.xslt, but not in xml2rfc.tcl. > Section 2.18 - This element is ignored by the current code. In xml2rfcv2 and rfc2629.xslt, that's why I want to get rid of it. > Section 2.20.2 - This attribute is ignored by the current code In xml2rfcv2? That's a bug. > Section 2.22.1 - > When the style format is used, it is possible to use a single counter > across multiple list element by naming the counter to be used. If the > attribute is absent, a unique counter is synthetized. > > Section 2.22.2 - hangIndent > > This attributes allows for a specific indentation level to be specified > for both the 'hanging' and 'format' styles. The value is the number of > characters to indent the list paragraphs. > > Section 2.22.3 - style > > The style attribute controls how the elements in the list are going to be > numbered. If a list does not have style attribute, then the style for the > current list is inherited from its parent. If a list has no parent then the > style 'empty' is used. > The style attributes are: > > uses a set of symbols to tag each paragraph. The set > of symbols is controlled by the PI text-list-symbols and defaults to 'o*+-'. > There is currently no way to change the set of symbols to be used between > different lists. > uses digits to tag each paragraph > uses upper and lower case letters to tag each > paragraph. Upper case letters are used if the depth of the list is even and > lower case letters are used if the depth is odd. The depth computation does > not take into account the style attribute. > allows for arbitrary text to be used to tag each > paragraph. If the hangIndent attribute is not specified, then the value of > 3 will be used for indentation. > allows for characters to be used for tagging each > paragraph along with additional decoration. The style attribute is the > string 'format ' followed by text containing one of '%c', '%C', '%d', '%i', > '%I', '%o', '%x', '%X'. If the hangIndent attribute is not specified, then > the value of 3 will be used for indentation. > uses not character to tag each paragraph. > > > While this is the list of recognized styles, there does not appear to be > any enforcement of the list of styles in either the dtd or XML2RFC. Unknown > style strings will be treated as 'empty'. > Will get to these soonish. Thanks for the text! Best regards, Julian From paul.hoffman@vpnc.org Wed Jan 8 07:27:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75A1AE459 for ; Wed, 8 Jan 2014 07:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 mA6IOjIGv9ym for ; Wed, 8 Jan 2014 07:27:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4ED1AE450 for ; Wed, 8 Jan 2014 07:27:23 -0800 (PST) Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s08F7GpX077746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 08:07:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <52CD3416.9070007@gmx.de> Date: Wed, 8 Jan 2014 07:27:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <064801cf0c13$6a5326e0$3ef974a0$@augustcellars.com> <52CD3416.9070007@gmx.de> To: RFC Interest X-Mailer: Apple Mail (2.1827) Cc: "xml2rfc@ietf.org Group" Subject: Re: [xml2rfc] [rfc-i] Current Cacheing behavior for current XML2RFC X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:27:24 -0000 On Jan 8, 2014, at 3:18 AM, Julian Reschke = wrote: > On 2014-01-08 02:46, Jim Schaad wrote: >> ... >=20 > I continue to believe is that using out-of-document references simply = is a bad idea; it causes all kinds of trouble, such as failures in = absence of a network connection, or silent changes that don't get = checked properly. >=20 > What would be much more useful is to have an automated way to check = in-lined references, such as with = or an xml2rfc-aware variant of id-nits. >=20 > That being said, I realize this is a minority opinion :-) I have been the editor of a document with dozens of in-lined references, = and it worked OK after the initial pain. I have been the editor of a document with many fewer out-of-band = references, and got bit on the ass. I'll join Julian's minority and hope that the community supports it as = well. --Paul Hoffman= From tony@att.com Wed Jan 8 08:00:08 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02C21ADF7E for ; Wed, 8 Jan 2014 08:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 LS53CIr57W4O for ; Wed, 8 Jan 2014 08:00:06 -0800 (PST) Received: from tlpi046.enaf.dadc.sbc.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id D96F01AD9AD for ; Wed, 8 Jan 2014 08:00:04 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com (8.14.4/8.14.4) with ESMTP id s08FxsmA000864 for ; Wed, 8 Jan 2014 09:59:55 -0600 Received: from vpn-135-70-97-182.vpn.swst.att.com ([135.70.97.182]) by maillennium.att.com (mailgw1) with ESMTP id <20140108155953gw100j0cdre>; Wed, 8 Jan 2014 15:59:54 +0000 X-Originating-IP: [135.70.97.182] Message-ID: <52CD75F8.1050303@att.com> Date: Wed, 08 Jan 2014 10:59:52 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RFC Interest , xml2rfc list References: <20140106102657.GA6473@nic.fr> <525A73E5-0C23-4FA3-988D-FFC0FB5E1F26@amsl.com> <52CB03B5.50703@att.com> In-Reply-To: <52CB03B5.50703@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xml2rfc] [rfc-i] Several Internet-Drafts missing at xml.resource.org X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:00:08 -0000 I manually updated a bunch of bibxml files on xml.resource.org last night. This should bring things up-to-date to that point. Getting the automatic updates fixed is taking longer than expected. (Henrik appears to be on vacation still.) Tony Hansen On 1/6/14, 2:27 PM, Tony Hansen wrote: > The problem dates back to when one of the tools servers (merlot) > croaked and xml.resource.org was repointed at another one of the tools > servers. Unfortunately, the bibxml updating code is not running on > that new tools server. The fix is to either get the updating code > running on the new tools server or to repoint xml.resource.org back to > merlot. Only Henrik knows for sure what the real status of these > machines are. > > Tony > > On 1/6/14, 12:21 PM, Alice Russo wrote: >> Stephane, >> >> Yes; this issue with the XML citation libraries for I-Ds and RFCs >> (bibxml3 and bibxml) has been reported, and Tony Hansen wrote Dec 27, >> 2013 (to the xml2rfc list): >> >>> The problem has been identified. Hopefully a fix can be worked out >>> soon. >> Thank you. >> RFC Editor/ar >> >> On Jan 6, 2014, at 5:26 AM, Stephane Bortzmeyer wrote: >> >>> Anything wrong recently in this repository? xml2rfc tells me: >>> >>> ERROR: Unable to parse the XML document: >>> draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml >>> draft-bortzmeyer-dnsop-dns-privacy-02BETA.xml: Line 0: Unable to >>> resolve external request: >>> "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijngaards-dnsop-confidentialdns" >>> >>> But there is a wijngaards-dnsop-confidentialdns, since November 2013 >>> >>> >>> Same problem for draft-bortzmeyer-dnsop-privacy-sol. You can check in >>> that there is nothing >>> recent, for instance nothing in 2014 while several -00 drafts have >>> been created already this year. From ietf@augustcellars.com Wed Jan 8 10:47:53 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF11AE0DC for ; Wed, 8 Jan 2014 10:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] autolearn=ham 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 a6jNHLPSy7sb for ; Wed, 8 Jan 2014 10:47:48 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id C87BC1AE085 for ; Wed, 8 Jan 2014 10:47:47 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s08IlXDN091943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Jan 2014 10:47:33 -0800 (PST) (envelope-from ietf@augustcellars.com) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 609C32CA07; Wed, 8 Jan 2014 10:47:32 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , "'xml2rfc'" References: <067501cf0c34$957acf00$c0706d00$@augustcellars.com> <52CD3A72.2040103@gmx.de> In-Reply-To: <52CD3A72.2040103@gmx.de> Date: Wed, 8 Jan 2014 10:45:59 -0800 Message-ID: <06ec01cf0ca1$e0067020$a0135060$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_06ED_01CF0C5E.D1E4B6C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLgfVk9mTzFSGVj/xlh606zMUPYlAI1pirnmEaQb5A= Content-Language: en-us Subject: Re: [xml2rfc] Comments and Text for draft-reschke-xml2rfc-03 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:47:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06ED_01CF0C5E.D1E4B6C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06EE_01CF0C5E.D1E4B6C0" ------=_NextPart_001_06EE_01CF0C5E.D1E4B6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, January 08, 2014 3:46 AM > To: Jim Schaad; 'xml2rfc' > Subject: Re: Comments and Text for draft-reschke-xml2rfc-03 > > On 2014-01-08 06:43, Jim Schaad wrote: > > I am going to mail this off because I don't seem to be doing it very fast. > > I don't know if you want more detail or less detail on than what is in > > this message. > > > > Jim > > Thanks a lot! > > > Section 2.5 - The 'alt', 'height', 'width', 'file', 'type', 'src' and > > 'xml:space' attributes are currently not used when generating documents.' > > They are used by xml2rfc.tcl and rfc2629.xslt. If v2 doesn't use them then that > is a bug that should be fixed. > > (xml:space is special in that it's a signal to the XML processor) I will have to do a test case to try and figure out if xml:space is understood and kept by the system. I was looking for it in the code and did not consider it being somehow kept by the parser itself. Given that this document is targeted at the v2 grammar, I am ignoring behavior of the tcl code because it is v1 grammar. I am also assuming that you understand the rfc2629.xslt rules and therefore I don't need to worry about what piece of code would or would not do. > > > Section 2.6 - From what I can tell from the code, it is expected that > > while the author name can be absent in a reference, the name > > attributes are expected to be present for the author elements that > > appear in the front element. They will default to empty strings, but > > the empty strings will then be emitted in the either the header or author > sections. > > This absolutely needs a test case, and also we need to clarify with the RSE > whether that's a legal use case for an RFC > > > Section 2.6.2 - The current code allows for the separator to be either > > whitespace or a dot (or any combination of). > > Is there a reason why we need to support more than one format? > > > Unclear if it should be noted that the initials attribute is only > > used if a surname attribute is also present. The current code is > > inconsistent on this statement. It is true for references, but is not > > true for the header. > > That sounds like an xml2rfcv2 problem, no? I don't think of initials as requiring a period necessarily. I would easily write J L Schaad as my name as J. L. Schaad so that for me initials="J L" is a reasonable alternative. > > > Section 2.6.4 - Should add the text "Authors Surname (used on the > > front page and in references)." > > Or maybe "used when the 'full name' is not". That does not help me from a documentation point of view if I don't know where the full name is going to be the used version. It can say you use a unless you use b. And you use b in the following cases. However without the second qualification the first is not completely useful. > > > Section 2.8 - I am not sure that this is the correct location for this > > to appear, however it needs to appear someplace. > > > > The number of columns in the table is determined by the number of > > ttcol elements. The number of rows in the table is determined by the > > number of c elements divided by the number of ttcol elements. There > > is no requirement that the number of c elements be evenly divisible by > > the number of ttcol elements. > > Thanks, added. > > > Section 2.13 - When matching the month, the abbreviated version of the > > month may be used as well as the full month. > > In xml2rfcv2. I'd prefer we have exactly one format. V2 has both formats. You can have this argument in v3. > > > Section 2.13 - Currently in the second case, the day attribute is > > ignored when creating a reference. > > True, but will this always be true? Unless we change v2 - then yes it is aways true. You can have a discussion on this for v3. > > > Section 2.15 - The text states that the URI of the target is enclosed > > in angle brackets. This is not true in the current system. > > It is true for xml2rfc.tcl when producing plain text, and for rfc2629.xslt. > > xml2rfc.tcl doesn't include the brackets in HTML, but I consider this a bug > because it means that the text content does not match the text version. > > For v3 we may want to discuss how far the text content may vary between > output formats. For the XML2RFC v2 system, we are consistent - we don't put the angle brackets in for either the html or the text version. > > > Section 2.17 - height and width would only duplicate the functionality > > of these attributes on the artwork if there is not a preamble or > > postamble present. If these are present, then the height and width > > would include these as well, which the one on the figure would not. > > Can you explain how "height" would affect preamble and postamble? Where this starts having real effects if you start doing flowing of text around the picture. In the above picture there are two blocks that are sized - the figure and the artwork. Each has the possibility of having a size set to it that controls how much real estate it will be allowed to occupy. Normally if one were to specify a width for the figure then the preamble, postamble and title would be restricted in width to that of the figure - something that is easier to do in HTML than it is in a text version. One of the things that frequently happens is to allow for outside text to flow around the figure. This means that specifying the width on the figure itself becomes important. > > > Section 2.17 - Currently the alt, height, src and width attributes are > > ignored. > > In xml2rfcv2 and rfc2629.xslt, but not in xml2rfc.tcl. > > > Section 2.18 - This element is ignored by the current code. > > In xml2rfcv2 and rfc2629.xslt, that's why I want to get rid of it. I will note that this field is populated in the current reference files that we get from bibxml > > > Section 2.20.2 - This attribute is ignored by the current code > > In xml2rfcv2? That's a bug. What is the correct behavior for a text based document? What is the correct behavior for an html based document? I don't know what this is supposed to do so there is no way for me to correctly file a bug on it. On the other hand I have never had a need for iref in any document that I have ever written so I would be willing to kill in this is v3 > > > Section 2.22.1 - > > When the style format is used, it is possible to use a single > > counter across multiple list element by naming the counter to be used. > > If the attribute is absent, a unique counter is synthetized. > > > > Section 2.22.2 - hangIndent > > > > This attributes allows for a specific indentation level to be > > specified for both the 'hanging' and 'format' styles. The value is > > the number of characters to indent the list paragraphs. > > > > Section 2.22.3 - style > > > > The style attribute controls how the elements in the list are going > > to be numbered. If a list does not have style attribute, then the > > style for the current list is inherited from its parent. If a list > > has no parent then the style 'empty' is used. The style > > attributes are: > > > > uses a set of symbols to tag each paragraph. > > The set of symbols is controlled by the PI text-list-symbols and defaults to > 'o*+-'. > > There is currently no way to change the set of symbols to be used > > between different lists. uses digits to tag > > each paragraph uses upper and lower case > > letters to tag each paragraph. Upper case letters are used if the > > depth of the list is even and lower case letters are used if the depth > > is odd. The depth computation does not take into account the style > > attribute. allows for arbitrary text to be > > used to tag each paragraph. If the hangIndent attribute is not > > specified, then the value of > > 3 will be used for indentation. > > allows for characters to be used for tagging > > each paragraph along with additional decoration. The style attribute > > is the string 'format ' followed by text containing one of '%c', '%C', > > '%d', '%i', '%I', '%o', '%x', '%X'. If the hangIndent attribute is > > not specified, then the value of 3 will be used for indentation. > > uses not character to tag each paragraph. > > While this is the list of recognized styles, there > > does not appear to be any enforcement of the list of styles in either > > the dtd or XML2RFC. Unknown style strings will be treated as 'empty'. > > > > Will get to these soonish. Thanks for the text! > > Best regards, Julian ------=_NextPart_001_06EE_01CF0C5E.D1E4B6C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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

> From: Julian = Reschke [mailto:julian.reschke@gmx.de]

> = Sent: Wednesday, January 08, 2014 3:46 AM

> To: Jim Schaad; 'xml2rfc'

> Subject: Re: Comments and Text for = draft-reschke-xml2rfc-03

>

> On 2014-01-08 06:43, Jim Schaad wrote:

> > I am going to mail this off because I = don't seem to be doing it very fast.

> = > I don't know if you want more detail or less detail on than what is = in

> > this message.

> >

> > = Jim

>

> = Thanks a lot!

>

> > Section 2.5 - The 'alt', 'height', = 'width', 'file', 'type', 'src' and

> > = 'xml:space' attributes are currently not used when generating = documents.'

>

> They are used by xml2rfc.tcl and rfc2629.xslt. = If v2 doesn't use them then that

> is a = bug that should be fixed.

>

> (xml:space is special in that it's a signal to = the XML processor)

 

I will have to do a = test case to try and figure out if xml:space is understood and kept by = the system.  I was looking for it in the code and did not consider = it being somehow kept by the parser itself.

 

Given that this = document is targeted at the v2 grammar, I am ignoring behavior of the = tcl code because it is v1 grammar.  I am also assuming that you = understand the rfc2629.xslt rules and therefore I don't need to worry = about what piece of code would or would not do.

 

>

> > Section = 2.6 - From what I can tell from the code, it is expected that

> > while the author name can be absent in a = reference, the name

> > attributes are = expected to be present for the author elements that

> > appear in the front element.  They = will default to empty strings, but

> > = the empty strings will then be emitted in the either the header or = author

> sections.

>

> This = absolutely needs a test case, and also we need to clarify with the = RSE

> whether that's a legal use case for = an RFC

 

>

> > Section = 2.6.2 - The current code allows for the separator to be either

> > whitespace or a dot (or any combination = of).

>

> Is = there a reason why we need to support more than one format?

>

> > =          Unclear if it should be = noted that the initials attribute is only

> > used if a surname attribute is also = present.  The current code is

> > = inconsistent on this statement.  It is true for references, but is = not

> > true for the header.

>

> That sounds = like an xml2rfcv2 problem, no?

 

I don't think of = initials as requiring a period necessarily.  I would easily write J = L Schaad as my name as J. L. Schaad so that for me initials=3D"J = L" is a reasonable alternative.

 

>

> > Section = 2.6.4 - Should add the text "Authors Surname (used on the

> > front page and in = references)."

>

> Or maybe "used when the 'full name' is = not".

 

That does not help me = from a documentation point of view if I don't know where the full name = is going to be the used version.  It can say you use a unless you = use b.  And you use b in the following cases.  However without = the second qualification the first is not completely = useful.

 

>

> > Section = 2.8 - I am not sure that this is the correct location for this

> > to appear, however it needs to appear = someplace.

> >

> > The number of columns in the table is = determined by the number of

> > ttcol = elements.  The number of rows in the table is determined by = the

> > number of c elements divided by = the number of ttcol elements.  There

> > is no requirement that the number of c = elements be evenly divisible by

> > the = number of ttcol elements.

>

> Thanks, added.

> =

> > Section 2.13 - When matching the = month, the abbreviated version of the

> = > month may be used as well as the full month.

>

> In xml2rfcv2. = I'd prefer we have exactly one format.

 

V2 has both = formats.  You can have this argument in v3.

 

>

> > Section = 2.13 - Currently in the second case, the day attribute is

> > ignored when creating a reference.

>

> True, but = will this always be true?

 

Unless we change v2 - = then yes it is aways true.   You can have a discussion on this = for v3.

 

>

> > Section = 2.15 - The text states that the URI of the target is enclosed

> > in angle brackets.  This is not true = in the current system.

>

> It is true for xml2rfc.tcl when producing = plain text, and for rfc2629.xslt.

>

> xml2rfc.tcl doesn't include the brackets in = HTML, but I consider this a bug

> because = it means that the text content does not match the text version.

>

> For v3 we may = want to discuss how far the text content may vary between

> output formats.

 

For the XML2RFC v2 = system, we are consistent - we don't put the angle brackets in for = either the html or the text version.

 

>

> > Section = 2.17 - height and width would only duplicate the functionality

> > of these attributes on the artwork if = there is not a preamble or

> > = postamble present.  If these are present, then the height and = width

> > would include these as well, = which the one on the figure would not.

> =

> Can you explain how "height" = would affect preamble and postamble?

 

 

Where this starts = having real effects if you start doing flowing of text around the = picture.   In the above picture there are two blocks that are = sized – the figure and the artwork.  Each has the possibility = of having a size set to it that controls how much real estate it will be = allowed to occupy.  Normally if one were to specify a width for the = figure then the preamble, postamble and title would be restricted in = width to that of the figure – something that is easier to do in = HTML than it is in a text version.

 

One of the things that = frequently happens is to allow for outside text to flow around the = figure.  This means that specifying the width on the figure itself = becomes important.

 

>

> > Section = 2.17 - Currently the alt, height, src and width attributes are

> > ignored.

> =

> In xml2rfcv2 and rfc2629.xslt, but not = in xml2rfc.tcl.

>

> > Section 2.18 - This element is ignored by = the current code.

>

> In xml2rfcv2 and rfc2629.xslt, that's why I = want to get rid of it.

 

I will note that this = field is populated in the current reference files that we get from = bibxml

 

>

> > Section = 2.20.2 - This attribute is ignored by the current code

>

> In xml2rfcv2? = That's a bug.

 

What is the correct = behavior for a text based document?  What is the correct behavior = for an html based document?  I don’t know what this is = supposed to do so there is no way for me to correctly file a bug on = it.  On the other hand I have never had a need for iref in any = document that I have ever written so I would be willing to kill in this = is v3

 

>

> > Section = 2.22.1 -

> >   When the style = format is used, it is possible to use a single

> > counter across multiple list element by = naming the counter to be used.

> > If = the attribute is absent, a unique counter is synthetized.

> >

> > = Section 2.22.2 - hangIndent

> >

> > <t>This attributes allows for a = specific indentation level to be

> > = specified for both the 'hanging' and 'format' styles.  The value = is

> > the number of characters to = indent the list paragraphs.</t>

> = >

> > Section 2.22.3 - style

> >

> > = <t>The style attribute controls how the elements in the list are = going

> > to be numbered.  If a = list does not have  style attribute, then the

> > style for the current list is inherited = from its parent.  If a list

> > = has no parent then the style 'empty' is used.</t> <t>The = style

> > attributes are:

> > <list = style=3D"hanging">

> > = <t hangText=3D"symbols"> uses a set of symbols to tag = each paragraph.

> > The set of symbols = is controlled by the PI text-list-symbols and defaults to

> 'o*+-'.

> > = There is currently no way to change the set of symbols to be used

> > between different lists.</t> <t = hangText=3D"numbers"> uses digits to tag

> > each paragraph</> <t = hangText=3D"letters"> uses upper and lower case

> > letters to tag each paragraph.  = Upper case letters are used if the

> > = depth of the list is even and lower case letters are used if the = depth

> > is odd.  The depth = computation does not take into account the style

> > attribute.</t> <t = hangText=3D"hanging"> allows for arbitrary text to be

> > used to tag each paragraph.  If the = hangIndent attribute is not

> > = specified, then the value of

> > 3 will = be used for indentation. </t>

> > = <t hangText=3D"format"> allows for characters to be used = for tagging

> > each paragraph along = with additional decoration.  The style attribute

> > is the string 'format ' followed by text = containing one of '%c', '%C',

> > '%d', = '%i', '%I', '%o', '%x', '%X'.  If the hangIndent attribute is

> > not specified, then the value of 3 will = be used for indentation.</t>

> > = <t hangText=3D"empty"> uses not character to tag each = paragraph.</t>

> > </list> = </t> <t>While this is the list of recognized styles, = there

> > does not appear to be any = enforcement of the list of styles in either

> > the dtd or XML2RFC.  Unknown style = strings will be treated as 'empty'.

> > = </t>

>

> Will get to these soonish. Thanks for the = text!

>

> = Best regards, Julian

------=_NextPart_001_06EE_01CF0C5E.D1E4B6C0-- ------=_NextPart_000_06ED_01CF0C5E.D1E4B6C0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAcQAAAHNCAIAAAAPMpyAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAKAhJREFUeF7t3bGO4tx7x3E7N/GvUkSCKUa0/wYuIIJtphop1RaRTBUNivRW GeWvV5puGyhxEWm7aKppFpQLgCZNCjTFQJcryBWQ59hgDMMMsPP4wfb5Wu+72mHM8Tmfc/zbYxvs cL1eBywIIIAAAl8T+LuvvZ13I4AAAgg4AcKUcYAAAggoCBCmCogUgQACCBCmjAEEEEBAQYAwVUCk CAQQQIAwZQwggAACCgKEqQIiRSCAAAKEKWMAAQQQUBAgTBUQKQIBBBAgTBkDCCCAgIJAePLrpGEY KmyHIhBAAIFrC5yMu69UkJnpV/R4LwIIILARIEwZCggggICCAGGqgEgRCCCAAGHKGEAAAQQUBC6+ AFXoGVyFBlEEAgggsBU4uH5eaHwxM2XcIYAAAgoChKkCIkUggAAChCljAAEEEFAQIEwVECkCAQQQ IEwZAwgggICCAGGqgEgRCCCAAGHKGEAAAQQUBAhTBUSKQAABBAhTxgACCCCgIECYKiBSBAIIIECY MgYQQAABBQHCVAGRIq4sMO2HndHqSCVWo07Yn165dmzeEwHC1JOOPquZEkr5JY0h9+LxqDqrTMWV zqkJ8akITlEXCRCmF3HVf+X2cCl31kmXcde1tzter2cPjRI0vTw1KQEGVSidAGFaui4pW4XcfDA7 VD4yd92fC+6OuJO/jdK5bvp+t+Z2OTz43ivl3SZ3c+TsfbvCOqO31My91BzMg7gnW8lNprNKl2OC XbYOpj5KAoSpEqQXxUz7vUU6c10O20E02cxdP2z7fDAIJts57rTfHLSSn9zbF739ZGt8u2/HL+np zdVb0M79sAiiu2SOnFtWo++DYDOJfnwdxMmvGg+zbcVyk+m493Sb1HkSzQc/OIHqxUi9SiMJ06uw l3ej80Hzo8mjhNwiaN0kB/yNm1aweDt2zWevadEkPVXgZo1PcXv4x+anxsNjNH/+lX+/KzFN09Wv 5+DxMUqLlx/mR7LUvfq4OffQHU+iT0CjyeYkRfcuOqfO5e0balZuAcK03P1jXrvcOdNtDmZ1yCXo 9CXe5ur5VcwFddhLJ5O5Jcu65Wvrrtu8DVzYHs/SYPk6P3+zrImAiQBhasJcj424mekmEHvxbtJ5 duPkvEB+ObyqJWnqZqvTl8VtM5DDfpemkprv56VB0Lxtn71VVkTARoAwtXGuxVZcsmV5mM1bd8fn 7grQ+xln2vTknOjT0Q+DZjZJmv54WSSnEqTY+euPl/hYliZnGbalvd/oGecfatEfNKJcAoRpufqj 1LWRk5OBu1C+WbZXkNw5y+QCeth8ffzw9KVcHVreP2cnZI9+dtWlaRzLQb5jkB/i+HiWus9rLYdB enpXNuouh20WF9rJ7Jkr96UeS3WsHE8nrWOvFtMmmQI2n++X26Nz+cCRXCYvxydQi2kwpVZfgKeT Vr8P69gCd9VnczFfmudOoLIggEAmwMyUwXC+gJubyofi00Wu+zMtPd+ONa8iYDkzJUyv0sVsFAEE LAQsw5QLUBY9yjYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2 AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqh zDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKA gIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp 7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqhzDYQQKD2AoRp7buYBiKAgIUAYWqh/ME2 VqNO2J8e+eW0Hx7/xRUry6YRQOBTAcLU8bjw2i1H841xhAACCHwmQJhudNrD5TpZlsNFj2khew0C CFwoQJgegjUeHqMgfnFH3zJh7YxG6aw1na66A/PtkpvA5l7eviovdUarbMorL2cryev5jWbrHLye rfPBRi/saVZHAIFCBQjTd7yrt0XQvm2mr88Hg2DiJqzjrgvX5qCV/JROYDfpN+1/D35uXmzHT1lU zgfNl7t03XbcC5uvj+kPweD7Lk7j3tNtMid2rzePnGH4YKOFjgoKRwCBiwUI00Oy6Y/BvH3/rbF5 PZq4GE1npU9xe/jH5ic3gZ0//3JzzO549pCu3vh2356/LrdFbt/rXg6yH25awd46mzcnM+LF296k 9ZONXtzTvAEBBAoVIEw3vDKNTI/fe4vhchuO7+iztdyK8fbXu+Pw5mD+pe7KpeyunOMb/dJ2eDMC CGgLEKYb0ewC1PrDJJU1o81Bfnqon666fxze/lIPZacX8qUc2+iXtsKbEUBAX4AwPdvUHaznzoge e587RXB2eemK8fbMa3IWYXd6YVPMGRu9cIOsjgAChQgQpuezNh5my/vnzdkAd0YgvQDVHU8iub7k lqfbYXR+eW7N9nCyKdJd2zoyKf5go5dthbURQKBwgVAOVj/fiGREfoWT6xdeZTaAAAIInCdgGV/M TM/rE9ZCAAEEPhUgTBkgCCCAgIIAYaqASBEIIIAAYcoYQAABBBQECFMFRIpAAAEECFPGAAIIIKAg QJgqIFIEAgggQJgyBhBAAAEFAcJUAZEiEEAAAcKUMYAAAggoCBCmCogUgQACCBCmjAEEEEBAQYAw VUCkCAQQQIAwZQwggAACCgKEqQIiRSCAAAKEKWMAAQQQUBAgTBUQKQIBBBAgTBkDCCCAgIIAYaqA SBEIIIAAYcoYQAABBBQECFMFRIpAAAEECFPGAAIIIKAgQJgqIFIEAgggQJgyBhBAAAEFAcJUAZEi EEAAAcKUMYAAAggoCBCmCogUgQACCBCmjAEEEEBAQYAwVUCkCAQQQIAwZQwggAACCgKEqQIiRSCA AALher3+XCEMw/wKJ9evlulB66pVeWqLwFUEKhQClvHFzPQqo5GNIoBA3QQI07r1KO1BAIGrCBCm V2FnowggUDcBwrRuPUp7EEDgKgJcgKrz5bWrDCk2Wj8By8s4unqWNWdmqtt3lIYAAp4KEKaedjzN RgABXQHCVNeT0hBAwFMBwtTTjqfZCCCgK0CY6npSGgIIeCpAmHra8TQbAQR0BQhTXU9KQwABTwUI U087nmYjgICuAGGq60lpCCDgqQBh6mnHV7zZq1En7E8LaMS0H3ZGqyMFF7bFAhpBkVcRIEyvwu7R RssZQpKZH4TmrmvKWXOPhk7VmkqYVq3HqK+GQHe8Xs8eGhpFUQYCqQBhykj4goCbvG2W7UF3cpw8 komfLJ1OJ2wO5kHccz+MVntzPTc5zI7U8z/kCt1bISt2//j+3STznK3sbXy3wc7oLdVwL+VrvjVy 70ubdvRcwBcoeWvlBQjTynfh9Row7X8PfsojLNbr5bAdP2XxMh8Mgol7eTabuV8FkftJJoKNb/ft +CU91bl6C9q5HxZBdNdNU6w5aCXvdsUuers8zYoduxXTRcKttxgu9yaZZ2wlb7YafR8Ew2WywcfX QZz8rvGwX/P0DXHv6TZZcRLNBz+KOGV7vc5ky18WIEy/TOhvAd3xNsRcfs1fl1uKaJLLu7xP46YV pGm6+vUcPD5Gizd3sUd+mG+y1P0te3fj4TEK0lXccljs26jzLkmTJDy1lb0sdVt83Bzxd8eT6JP+ jCabBnfv8vXydwTQ8rwAYcp4+H2B3fGxOyQ+Z8lSaPnauus2b4PnX6tclgbL1/1ymrf5kN7fQjz4 aKOntpIv53CL57SCdRA4IkCYMix+V2Dazx+Qt88rRnJuLgE6fVncNgOZ0Lo0lTxL56VBIOG5V478 qi0rHl3k5MFyGAy+Hzl7eWIr+eIOt3heM1gLgXcChCmDQkFg+uPTmenuSD0Ikpz78bJo3ci1dDkg n7/+eIm3WeritR33tleYVqOnuH3/7eOL7o2HnxKnzfefOP18K/kWJ+cENud7ZabdS8+Zbpd8zRWc KKLWAumZ/k+Wg9afWr1iv69364rujOwEY3s4jNLLTHJtxp3czG3ZXYFyS3tzkSdZI1tl74f0XbnT ltl7DovNLmtt1t+tuN3y51vZq+W2hq5W8vesrL2a57eY1PH9Jovmvl751d1NLGvOM6B4BlStJws0 TkPA8klKGvXdlWFZcw7zdfuO0hBAwFMBwtTTjqfZCCCgK0CY6npSGgIIeCpAmHra8TQbAQR0BQhT XU9KQwABTwUIU087nmYjgICuAGGq60lpCCDgqQBh6mnH02wEENAVIEx1PSkNAQQ8FSBMPe14mo0A AroChKmuJ6UhgICnAoSppx1PsxFAQFeAMNX1pDQEEPBUgDD1tONpNgII6AoQprqelIYAAp4KEKae djzNRgABXQHCVNeT0hBAwFMBwtTTjqfZCCCgK0CY6npSGgIIeCpAmHra8TQbAQR0BQhTXU9KQwAB TwUIU087nmYjgICuAGGq60lpCCDgqQBh6mnH02wEENAVIEx1PSkNAQQ8FSBMPe14mo0AAroChKmu J6UhgICnAoSppx1PsxFAQFeAMNX1pDQEEPBUgDD1tONpNgII6AoQprqelIYAAp4KEKaedjzNRgAB XQHCVNeT0hBAwFMBwtTTjqfZCCCgK0CY6npSGgIIeCpAmHra8TQbAQR0BQhTXU9KQwABTwUIU087 nmYjgICuAGGq60lpCCDgqQBh6mnH02wEENAVIEx1PSkNAQQ8FSBMPe14mo0AAroChKmuJ6UhgICn AoSppx1PsxFAQFeAMNX1pDQEEPBUgDD1tONpNgII6AoQprqelIYAAp4KEKaedjzNRgABXQHCVNeT 0hBAwFMBwtTTjqfZCCCgK0CY6npSGgIIeCpAmCp3fGe0Oijx/SvKm6Q4BBAogUC4Xq8/r0YYhvkV Tq5fgkZdUAX11kmBeSJJ1ub+KxdUjlURKIeA+m5i1izLmhOmav9UhP2pGyJxL4gmu7GyeGvPB7NT /2KZjS02hMBvCFhG0m9U75O3WNacMFUL09WoI53aHMyXw3a+dxvf7oPGg+4QoTQELAUsI0m3XZY1 J0zVwjQdBKNO+DA7ceZEd7hQGgJFC1hGkm5bLGtOmCqHaRDIadLGwUWohu4AoTQEbAUsI0m3ZZY1 J0yVw1Qu5g9+TIPFW35MrGcc5uvuI5RmKmAZSboNs6w5YaocpmHYmUTz7l20Nya6Y90hQmkIWApY RpJuuyxrTpiqh+lpUt3hQmkIFC1gGUm6bbGsOR/a1+27QGak7z62r7wJikMAgRIKnJ5GWUa7PZBW 69LPmCbLNO49RZNZvi3jrn3L2CICagJau4lahc4uyLLmhKnOYb58IuqT/uXDUmcPflYso4BlJOm2 37LmhKlOmCafiPpk4cNRuvsIpZkKWEaSbsMsa06YaoXpZgzIl0rX4677rOl2UMjfvyenUWcPRKru nkJpRgKWkaTbJMuaE6baYSr3hZHv5svnTFs3k3FXTpaGndGkNXhbBM/3ywLyNJ/buuOQ0hDYThEq e7cjwtRuEKtbS4Hy3fzGTWv6EvfiaL0eH9xHSrtthKm2KOW9E1DfTcyMLWvOzFR/Zprdgi+N0YLD 1GxYsiF/BSwjSVfZsuZ8zlSp7+SeUdJvydFQ5z8C+aDUaOU+LTUa9ZU2QDEIIFBqAcJUpXum/e/B T5mFrtfL6C/zf/6Hfwv7r81//UsQDAb/++f+N0tVtkchCCBQNgEO85UP8wOZojb/63H5j93G//XD vwV/RuN/54v5ZRv21OcyAcuD5ctqdmpty5ozMz3VG+f9fnuUH4Zyd+jg75O7Qf/VvfWvJOl5gqyF QMUFmJlqzEyn/bAXBO1budVe+E/94D//N4j+JQj+O4j/FnQnEq3yydOKjxOq77WA5fxOF9qy5sxM 1fruz9ZAyvrzf2L5ev6fQW8S/E0StOv+IkHLggACNRdgZqoxM5X4lLmppKhMT4fD1uD1zs1Fk/nq hFlpzXchH5pnOb/T9bSsOWGqE6b5ESAfo/+VfFM//foon6rX3T0ozV7AMpJ0W2dZcw7zdfvOfcK0 2Rm9NjuDpntYqSzyo/I2KA4BBMonwMxUeWYahv3lcNF4eAzDXvpVqMp+A4opdfn21yvVyHJ+p9tE y5oTpuphuiHNMrSyYao7qimtwgKWkaTLZFlzDvN1+47SEEDAUwHCVLnjh+1AbmmaPgZKzp92Rit5 hQUBBGovwGG+8mG+XL2f9ptPsSToPAii+3b8MFvmbhVd+xFFA2soYHmwrMtnWXPCVD1Mk8Gw2l7B b3wjSXV3D0qzF7CMJN3WWdacMC0kTA8eCMXjSnT3EEozFrCMJN2mWda8qDCtSpqoW8vZ0sGPqXts SW6R7+zrDhFKQ8BSQH03Mau8Zc31w7RaaaJuHYadSTTv3u3fxLTLvaPMdh82pC+gvpvoV/GDEi1r rh+m1UoTdWs+VWq2n7AhMwH13aSWNS8iTE+XaUZ5ckPqo6QfhrfLNQ91PinPChUSUN9NzNpuWfPT wXdpbaqVJpe27qNB0HcPfEqXadx7iiaz/JrcztRs52FDRQho7SZF1O3zMi1rrhamFU0TLWt5nN4n nfowc1/SZ0GgogJau4l98y1rrhamFU0TPeuDzy8cDBs+HGW/H7FFNQG93UStSmcWZFlztTBN7tv5 yVLSNLG0PrP7WQ2BsglUdzexrLnid/MlLt1/yd07N3/PvVK24UF9jgvI4wFkyZ20kdV2Twt0v9v8 Ml3xYNl/H8YI+CSgODPdsB18Nkjmq83w9FauZW75D9e12njJdiUin4IoiIPH3ONW3NOrn++Xs+Qz CocPY9n75SWbYt3qCFR3N7GsueLM1N0tKZ21pH9J/5P7zHt116T0flH5RW4cVZm9ZvoSt+//+ENu z/Ky+3jCfu3d9xEWb9VpUmXsqWjVBTTDdHn7JP+JSPqXzX/3z7PlsOpM59dfnlaShackjvxz0ho0 z3/7dddMsvRbo/FN0vTp+L8Bq9FTHLRuSnoK/Lp8bN1zAXm0xufLgc+p1ddy+86T65RnhUtbd7rm E/kiaXu4XMt/7lGlTmNy+l1lWGMplXU1lyX3181PGdRmjazC+6uWoR3UQV1AfzdRr+IHBVrWXHNm mtZ70HLz0PxhoPxdZmtVOtr9yj+w3fF60npOHqi3vH9Obmba/Up5Zu9d/Xqeu3mp26Cbm86f02es pssmQ+W+A+4+LiwIIHAooB+mQTxIT5XKn+leJ39/fG3eS8BU6OzhhUNFzhXv/gvGreG93Bz6x82s P21U5Aq3y9JgPpCrhW5pDuSHvTRNQbp/DD88A3AhGasjUC+B09fZL70cJuvLkV/jpiUn4HpxtF6P t9f3V7KPpg/sLM9yaes+qnlFv7Owa467SL8Ybq7Yu5fdVfpBa+Iu6u9fsD+4nM/V/PKM5sJqorWb FFbBDwu2rHkhYZolZhqj2YelDj41ZS/7fot61ptDYpmMHzuqL/sFm8MPPDmp7LWDvNxflzAtwzgu uA56u0nBFX1XvGXNCwlTuYghl3vl4zNy0JiGqVzVkDipdZhuulE+0y6Tceshw/YQKFLAMpJ022FZ c/1zputJ9NrsPIV9+VM+YSpnTuX6dnoK1Y/ndMZcn9HdHygNgUoI6M9Mk2ZPg9Vb0Lhxfy5fg+5Y jgWXr/PuuHTP6VT/h2s06g8GQTTZm5xyC75K7AxU8iMB9d3EjNqy5pphKmcNy35qsPhTKv2wkzzk eW8Zl+yym9lQZkP1ELCMJF0xy5prhmnYGcmT4w5ukpHS5L7orWv11dIKsD56lF+Nj5p+VZP311Sg gN3ESMqy5pphKld55RPr8ud7J3ndCO/CzRRhLWkqF99el8FtM5DPwFdutn4hIavXX6CI3cRGzbLm mmFqo6O7FXVrSdJe2Jd7gdy256/ztnzXPffZTd26UxoCRgLqu4lRvZNPEOW3Vejn3AsJUzl5mn4T MX2uXJnPpapby0ejlsNF4+FRvvklt3yR+4LI3evk7IfZ6GFDCKgLqO8m6jX8qEDLmuuHqZuadUbR /DmWU6Vr91y59FyqGd9FG1K3fv9Z2hJ+uvYiIlZGQH03MSO1rLl+mGZTszDspZPqMqeJujVharaf sCEzAfXdpJY11//QfhDEjQeZkHp6/Vq+mJDe4SX9T/4ut+RjQQCB2gsUMTPdlJnN0byamaZ3CHme R/JZU/kCmNxl+WE28fafltrvP540kJnpOR2tPzNNp2bpzfZkaia33fPjW6SZtszLl7Pl7XoSyJ8V up/pOcOFdRBA4MOLXSc/K3D5P0qrab/5FMu0TCZnUTI1K923SDOOy1t3YizJ3Uvvur6e42A/q6mA +m5i5mRZc/3D/A3Tyj3x2S2Nb2X+lqm6tTwAeRFE8+guuuuSqmb7DBsqVEB9Nym0tvnCLWteVJge PL2ytN8CKsDa3eRFblsvN65/nUdxkqrc6MRs52FDRQgUsJsUUc0jZVrWXD9M5Wype0rQ4i3fMn8+ Z5q1ehWsfq2Wrz9e4jg+eS7FaGSxGQR+S8Aykn6rgh++ybLm+mEahh156pp7unp+6Zb0fsnq1nLN TR457x4s//zrPni+aSUUZW2+7sCltLoKqO8mZlCWNS8iTE+XaUZ5ckPq1vKdhXY7fnyMus3bkp8v PonDCgikAuq7iRmsZc1PB9+ltZErMLfLdfqt/PIvl7budIumfbkj9q/n4LV1t7httm4aXIY6jcYa 5RbQ302s2mtZc7UwzT3QeBr3nqKJ+1Z+tpT2Ckxh1nIFbrmavvx4WcRxi6dCWe07bKcQgcJ2k0Jq my/UsuZqYVrRZx0XYZ2dNpUHz8sNX+7kDHJZb+da+FhmA7UQKGI3sYGxrLlamCZ32vtkKelhv7q1 fPurHb+0gthddkr+57ukNrsNWylOQH03Ka6qByVb1lwxTM18NDekbi3fzG98u3cPE+RrUJodRVnX FFDfTcwaY1lz/e/mmzGVc0Pfg59BQ27eurtpltydoJxVpVYIIKAowMxU+akG8i9h/iP6kqPN/VcU O4+iELARsJzf6bbIsuaFhKmfjy3ZPJY17gWR3HNvuyze2vPBjEc96+4ilGYrYBlJui2zrLl+mHr7 2BI5WyrjoDmYL/fvOZicQi3pU1t0By6l1VXAMpJ0DS1rrh+mnj+2pNMJZ7OSPtdad5hSmj8ClpGk q2pZ8yLC1Os77cutCdLHCLIgUBsBy0jSRbOsOVfzdftOSpvLiQ4WBBDwTUA/TD1/bMlwGPXCvny5 Nv+fb6OK9iLgoYD+Yb58Fcrrx5aEchlKnteyt4y5mu/hvlWjJlseLOuyWdZcP0zlINd9YN3Xx5Yk TxF8v3j64GvdHYPSriVgGUm6bbSsuX6YytX8Ct0kqQhrd8Oo/RFBlOruIZRmLFDEbmLTBMuaFxGm 4WS9rkp8qFvLqdL4adSW5z8FweYBrUEwXpf0QQM2A5qtVF1AfTcxA7GsuX6Yjkb9wUC+BLQXH/7c z1Q6Tz60Lx/UD5uD9XI4/TF4uh3OHvjQvtnuw4b0BSwjSbf2ljXXD9N+pa7AqFtn381//xfdUUJp CJgJqO8mtay5fphW6wqM+ijphOHP9Vru3ioly+kOGTQ9bnRituuwoWIE1HeTYqp5pFTLmuuH6dH7 zZX01tBFPClsNep/D8azB/mqfnPQku6dRDF32jfbedhQEQKWkaRbf8ua64dp2Bm951jPSnrSsBjr zcfDgmnfUfCcZ939g9LMBYrZTSyaYVlz/TDdJMgWqtOLHydRt6yBYmltMXbYBgIFCFR3N7GseQFh etCXq1HYfC3tJ08trQsY5BSJgIVAdXcTy5oXH6bJecn8zectOv/sbVhan10pVkSgXALV3U0sa346 5i6tjXxqPb/EL9Mo7pX2y+mXtq5cY5zaIGAiUN3dxLLm+mE66uw9VemmJRdg5DEeJf1KlKW1ybBn IwjoC1R3N7GsuX6Yyj1O9juztB+LctW0tNYf45SIgIlAdXcTy5rr38807MtdPhqrQDI0/c+Fqzzu mCcemwx7NoIAAtcR0J+Zun8K5PGci7egdTMZd+XwXj55OmkN3hbB8/1y9lCuiarlP1zX6WG2isCX Baq7m1jWvJAwdXf6uGlNX+JeHMmHorZX81dh2CzbZX1L6y8PaQpA4DoC1d1NLGteSJhmiZnGaPbR qBJ+RsrS+jr7AVtF4MsC1d1NLGuuf85UOm60creblz+z5egX9r/cxRSAAAIIlEVAP0zXk+i12XkK +/Kn3B057E8nUdDsjOQv8qw9FgQQQKCWAvqH+QnTNFi9BY0b9+fyVT5oKrdQWr7Ou2N3ob9UjpZH AaVqOJVB4HyB6u4mljXXDFM5li9XUp4xWCytz6gOqyBQRoHq7iaWNdcMU/kIlNxqTw7n3w+HdVmf W2JpXca9hDohcIZAdXcTy5prhum0H8pdkOXP971T2rsjW1qfMWhZBYEyClR3N7GsuWaYlnEUnKqT pfWpuvB7BEoqUN3dxLLmmlfz88f3Rw71SzpOqBYCCCCgIKA5M81/Jj8M+6W9IXSezfIfLoXuoggE riFQ3d3EsubFhenpkq8xKg63aWldhvZSBwR+Q6C6u4llzTUP83+jk3gLAgggUA+B0/PH86Nd1mwP 5WP5bpkPmtnf5cey3Swq67zzW1eP/qYVCPyGQHV3E8uaa4bp0Q9FpT3HR6N+YwTzFgRKImAZSbpN tqy5ZpjqKtiUZmlt0yK2goC6QHV3E8uac85UfeBRIAII+ChAmPrY67QZAQTUBQhTdVIKRAABHwUI Ux97nTYjgIC6AGGqTkqBCCDgowBh6mOv02YEEFAXIEzVSSkQAQR8FCBMfex12owAAuoChKk6KQUi gICPAoSpj71OmxFAQF2AMFUnpUAEEPBRgDD1sddpMwIIqAsQpuqkFIgAAj4KEKY+9jptRgABdQHC VJ2UAhFAwEcBwtTHXqfNCCCgLkCYqpNSIAII+ChAmPrY67QZAQTUBQhTdVIKRAABHwUIUx97nTYj gIC6AA/UC9VNKRCBegus1+uqNJAH6lWlp6gnAgggsBHgMJ+hgAACCCgIEKYKiBSBAAIIEKaMAQQQ QEBBwPcLUAqEFIEAAmUV4AJUWXuGeiGAAAIfCHCYz9BAAAEEFAQIUwVEikAAAQQIU8YAAgggoCBA mCogUgQCCCBAmDIGEEAAAQUBwlQBkSIQQAABwpQxgAACCCgIEKYKiBSBAAIIEKaMAQQQQEBBgDBV QKQIBBBAgDBlDCCAAAIKAoSpAiJFIIAAAoQpYwABBBBQECBMFRApAgEEECBMGQMIIICAggBhqoBI EQgggABhyhhAAAEEFAQIUwVEikAAAQQIU8YAAgggoCBAmCogUgQCCCBAmDIGEEAAAQUBwlQBkSIQ QAABwpQxgAACCCgIEKYKiBSBAAIIEKaMAQQQQEBBgDBVQKQIBBBAgDBlDCCAAAIKAoSpAiJFIIAA AoQpYwABBBBQECBMFRApAgEEECBMyzYGVqNO2J8eqdW0Hx7/RdlaQH0Q8FKAMN10u4uq3XI0zU4M kA9T0MuBRaMR8E2AMN31eHu4XCfLcrjoMQn0bVegvQh8TYAwPeLXeHiMgvhlc6ztZpzbZTdjzb3a Ga3cT83BPIh7sqb87ArNrbF9m7wkv8wmwfJyttLmTdvaZOscvP613ubdCCBQmABheox29bYI2rfN NBGbg9bkcMa6Gn3PXl3PHhqNh5nMZ9tB5NaUn4Ng2v8e/NzMc9vxU5qvsswHzZe7dPrbluhtvj6m PwSD79k6kslPt8ks2b3e/J1zDoUNGApGAIHjAoTpEZfpj8G8ff9NInH163keTcbddKVkxrp42+Ri NnU9KtsdJ5nq3vXtvj1/XW7X2hbnXpbwTctu3LSCvXU2b97fIoMYAQTKK0CY7vpGJo3p4XxvMVym abZ8ne/1XfM2zUWZiSYnVncH9e+6eHeU747/v7LkUvYrxfBeBBAoUoAw3elmF6DSA3W3SHju6Uu4 pof/SZ66A/FJ6+hx+LSfPzuwX8il/bnd4qXvY30EEDAUIEw/xXbH4nFvd/3oKU4P/3fLftxm5wBy a7iTBhf2aNzLLmK93+KFZbE6AgiYCBCmnzPL/HMSJdfoZWk+328O/3efSnUT0M15T3du1J0pcEHY HWdve7odRpf1ZXs4uX9OTjm40rNp8mWFsDYCCJgKhHKk+vkGZZfOr3ByfdPqszEEEEDgYwHL+GJm ykhEAAEEFAQIUwVEikAAAQQIU8YAAgggoCBAmCogUgQCCCBAmDIGEEAAAQUBwlQBkSIQQAABwpQx gAACCCgIEKYKiBSBAAIIEKaMAQQQQEBBgDBVQKQIBBBAgDBlDCCAAAIKAoSpAiJFIIAAAoQpYwAB BBBQECBMFRApAgEEECBMGQMIIICAggBhqoBIEQgggABhyhhAAAEEFAQIUwVEikAAAQQIU8YAAggg oCBAmCogUgQCCCBAmDIGEEAAAQUBwlQBkSIQQAABwpQxgAACCCgIEKYKiBSBAAIIEKaMAQQQQEBB gDBVQKQIBBBAgDBlDCCAAAIKAoSpAiJFIIAAAoQpYwABBBBQECBMFRApAgEEECBMGQMIIICAggBh qoBIEQgggABhyhhAAAEEFAQIUwVEikAAAQQIU8YAAgggoCBAmCogUgQCCCBAmDIGdgLTfhj2p4gg gMBvCBCmv4FWsbesRp18RLrE7IxWSSMOflWxhlFdBMokQJiWqTdM6tIdr9ezh4bJttgIAv4IEKY1 72uZlTYH8yDuhdv56PZY3s1KD361b+FW2C4c/Nd8nNC8rwsQpl83LHUJD7P1ctgOosn6cD7a+PhX rkXTfnPQcu+SZTlc9LZnBkrdWiqHwPUECNPr2Zd5y6vRU9we/tFN69h4eIzmz7/S86wsCCBwTIAw ZVx8JDAfNLPD/F6MEwIIfCpAmDJAPhJITg3sFi5aMVQQ+EyAMPVjfCzePjxGP/qrxrf7dvy0+QCV H0S0EoGvCRCmX/OrwrtdMCaH7O+vIX38K7k8tbx/3h3nH3lzFdpOHREwEwjlMO7zjclps/wKJ9c3 qzobQgABBMoTX8xMGY0IIICAggBhqoBIEQgggABhyhhAAAEEFAQIUwVEikAAAQQIU8YAAgggoCBA mCogUgQCCCBAmDIGEEAAAQUBwlQBkSIQQAABwpQxgAACCCgIEKYKiBSBAAIIEKaMAQQQQEBBgDBV QKQIBBBAgDBlDCCAAAIKAoSpAiJFIIAAAoQpYwABBBBQECBMFRApAgEEECBMGQMIIICAggBhqoBI EQgggABhyhhAAAEEFAQIUwVEikAAAQQufqAeZAgggEBFBQp9Higz04qOCqqNAALlEiBMy9Uf1AYB BCoqQJhWtOOoNgIIlEuAMC1Xf1AbBBCoqMDpC1AVbRjVRgABBCwFmJlaarMtBBCorQBhWtuupWEI IGApQJhaarMtBBCorQBhWtuupWEIIGApQJhaarMtBBCorQBhWtuupWEIIGApQJhaarMtBBCorQBh WtuupWEIIGApQJhaarMtBBCorQBhWtuupWEIIGApQJhaarMtBBCorQBhWtuupWEIIGApQJhaarMt BBCorQBhWtuupWEIIGApQJhaarMtBBCorQBhWtuupWEIIGApQJhaarMtBBCorQBhWtuupWEIIGAp 8P/1od1FiGUbiwAAAABJRU5ErkJggg== ------=_NextPart_000_06ED_01CF0C5E.D1E4B6C0-- From julian.reschke@gmx.de Wed Jan 8 11:19:49 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00921ADF59 for ; Wed, 8 Jan 2014 11:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, SPF_FAIL=0.001] autolearn=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 2Nw3bIWMjhxZ for ; Wed, 8 Jan 2014 11:19:48 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0015F1ADFAC for ; Wed, 8 Jan 2014 11:19:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s08JJWkX092668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 8 Jan 2014 11:19:33 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: from [192.168.2.117] ([93.217.91.122]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MTfZc-1VsDEc1QbA-00QR2v for ; Wed, 08 Jan 2014 20:19:26 +0100 Message-ID: <52CDA4BC.5000901@gmx.de> Date: Wed, 08 Jan 2014 20:19:24 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , "'xml2rfc'" References: <067501cf0c34$957acf00$c0706d00$@augustcellars.com> <52CD3A72.2040103@gmx.de> <06ec01cf0ca1$e0067020$a0135060$@augustcellars.com> In-Reply-To: <06ec01cf0ca1$e0067020$a0135060$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Q9L6lfUiqDmAMNU7qVv/4Xff4dO4NIeWpzEUtZsyB5cRCUMAvqc /9u8qpXTmOE036XxFxKpzLKxPI0cpPdg90UuIvTxxyMmGcJCmHeIUC4omgo2QRP0yR2d9Aa ncqAXmHLexHkiP7lWt8APtwi8fpmTI0ntM4/EwFP+CU24tRrDpZfW1c+CpqTRJNNji+i8Wd cpgP7nOC0Z03u+svGHVZw== Subject: Re: [xml2rfc] Comments and Text for draft-reschke-xml2rfc-03 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:19:50 -0000 On 2014-01-08 19:45, Jim Schaad wrote: > ... > > > Section 2.5 - The 'alt', 'height', 'width', 'file', 'type', 'src' and > > > > 'xml:space' attributes are currently not used when generating > documents.' > > > > > > They are used by xml2rfc.tcl and rfc2629.xslt. If v2 doesn't use them > then that > > > is a bug that should be fixed. > > > > > > (xml:space is special in that it's a signal to the XML processor) > > I will have to do a test case to try and figure out if xml:space is > understood and kept by the system. I was looking for it in the code and > did not consider it being somehow kept by the parser itself. If xml:space is not "preserve", a processor might remove whitespace. > Given that this document is targeted at the v2 grammar, I am ignoring > behavior of the tcl code because it is v1 grammar. I am also assuming The TCL code implements the v2 grammar. > I don't think of initials as requiring a period necessarily. I would > easily write J L Schaad as my name as J. L. Schaad so that for me > initials="J L" is a reasonable alternative. Adding micro-formats just makes implementations harder. Why can't we standardize on a single syntax? > > > Section 2.6.4 - Should add the text "Authors Surname (used on the > > > > front page and in references)." > > > > > > Or maybe "used when the 'full name' is not". > > That does not help me from a documentation point of view if I don't know > where the full name is going to be the used version. It can say you use > a unless you use b. And you use b in the following cases. However > without the second qualification the first is not completely useful. This is a document that describes the vocabulary. It's not supposed to fully describe what various processors do with it. > > In xml2rfcv2. I'd prefer we have exactly one format. > > V2 has both formats. You can have this argument in v3. The TCL version even has more formats, because AFAIK it just uses the TCL date parser. That doesn't make all of these formats valid. I'd like to have a single variant. The date format already is overly complex (it shouldn't have used english month names in the first place), let's not make it worse. > > > Section 2.13 - Currently in the second case, the day attribute is > > > > ignored when creating a reference. > > > > > > True, but will this always be true? > > Unless we change v2 - then yes it is aways true. You can have a > discussion on this for v3. I think you are conflating vocabularies, implementations, and target formats. What we can say is that when used in references, the day is not used when formatting as ID or RFC. > > > Section 2.15 - The text states that the URI of the target is enclosed > > > > in angle brackets. This is not true in the current system. > > > > > > It is true for xml2rfc.tcl when producing plain text, and for > rfc2629.xslt. > > > > > > xml2rfc.tcl doesn't include the brackets in HTML, but I consider this > a bug > > > because it means that the text content does not match the text version. > > > > > > For v3 we may want to discuss how far the text content may vary between > > > output formats. > > For the XML2RFC v2 system, we are consistent - we don't put the angle > brackets in for either the html or the text version. Well, that's a change from the TCL version. I would consider this a bug. > > > Section 2.17 - height and width would only duplicate the functionality > > > > of these attributes on the artwork if there is not a preamble or > > > > postamble present. If these are present, then the height and width > > > > would include these as well, which the one on the figure would not. > > > > > > Can you explain how "height" would affect preamble and postamble? > > Where this starts having real effects if you start doing flowing of text > around the picture. In the above picture there are two blocks that are But we don't do that. > sized – the figure and the artwork. Each has the possibility of having > a size set to it that controls how much real estate it will be allowed > to occupy. Normally if one were to specify a width for the figure then > the preamble, postamble and title would be restricted in width to that > of the figure – something that is easier to do in HTML than it is in a > text version. > > One of the things that frequently happens is to allow for outside text > to flow around the figure. This means that specifying the width on the > figure itself becomes important. > ... > > > Section 2.18 - This element is ignored by the current code. > > > > > > In xml2rfcv2 and rfc2629.xslt, that's why I want to get rid of it. > > I will note that this field is populated in the current reference files > that we get from bibxml Yes. > > > Section 2.20.2 - This attribute is ignored by the current code > > > > > > In xml2rfcv2? That's a bug. > > What is the correct behavior for a text based document? What is the > correct behavior for an html based document? I don’t know what this is > supposed to do so there is no way for me to correctly file a bug on it. > On the other hand I have never had a need for iref in any document that > I have ever written so I would be willing to kill in this is v3 In HTML, the obvious thing is to make the output stand out, such as by making it bold. > ... Best regards, Julian From duerst@it.aoyama.ac.jp Wed Jan 8 20:09:58 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CAF1AE173 for ; Wed, 8 Jan 2014 20:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 OQCSmSYesAXt for ; Wed, 8 Jan 2014 20:09:56 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 029311AE15F for ; Wed, 8 Jan 2014 20:09:55 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0947xpu006701; Thu, 9 Jan 2014 13:08:00 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2b21_7bdf_a07726b2_78e3_11e3_9dd9_001e6722eec2; Thu, 09 Jan 2014 13:07:58 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 22116BF548; Thu, 9 Jan 2014 13:07:59 +0900 (JST) Message-ID: <52CE2091.2070406@it.aoyama.ac.jp> Date: Thu, 09 Jan 2014 13:07:45 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <064801cf0c13$6a5326e0$3ef974a0$@augustcellars.com> <52CD3416.9070007@gmx.de> In-Reply-To: <52CD3416.9070007@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: RFC Interest , xml2rfc@ietf.org Subject: Re: [xml2rfc] [rfc-i] Current Cacheing behavior for current XML2RFC X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 04:09:58 -0000 I strongly agree with Julian. Even if we happen to be in a minority, I'd note that adding tool support is a volunteer effort, so anybody (even a minority) can contribute. Regards, Martin. [Unfortunately, I don't have the time to volunteer myself, and on top of that face the handicap to prefer Ruby over Python :-(.] On 2014/01/08 20:18, Julian Reschke wrote: > On 2014-01-08 02:46, Jim Schaad wrote: >> ... > > I continue to believe is that using out-of-document references simply is > a bad idea; it causes all kinds of trouble, such as failures in absence > of a network connection, or silent changes that don't get checked properly. > > What would be much more useful is to have an automated way to check > in-lined references, such as with > > or an xml2rfc-aware variant of id-nits. > > That being said, I realize this is a minority opinion :-) > > Best regards, Julian > > > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > From trac@tools.ietf.org Fri Jan 10 15:08:56 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101C21AE0F9 for ; Fri, 10 Jan 2014 15:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 pZjUvZc_4z7F for ; Fri, 10 Jan 2014 15:08:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 904C41AC82A for ; Fri, 10 Jan 2014 15:08:51 -0800 (PST) Received: from localhost ([127.0.0.1]:58604 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W1lBw-0006Bt-Cn; Sat, 11 Jan 2014 00:08:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, john-ietf@jck.com X-Trac-Project: xml2rfc Date: Fri, 10 Jan 2014 23:08:40 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/221 Message-ID: <065.df3f7d3c9f028114dd99e745fd592626@tools.ietf.org> X-Trac-Ticket-ID: 221 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, john-ietf@jck.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #221: XmlRfcParser instance has no attribute 'rfc_number' followed by "file is not there" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 23:08:56 -0000 #221: XmlRfcParser instance has no attribute 'rfc_number' followed by "file is not there" An attempt to compile the attached file with the current online version yields no output, the error message "file is not there" and a traceback of File "/usr/local/bin/xml2rfc", line 225, in main() File "/usr/local/bin/xml2rfc", line 139, in main xmlrfc = parser.parse() File "/usr/local/lib/python2.7/dist- packages/xml2rfc-2.4.5-py2.7.egg/xml2rfc/parser.py", line 433, in parse rfc_number = self.rfc_number, AttributeError: XmlRfcParser instance has no attribute 'rfc_number' I identified this as "medium" priority because a quick scan with Bill's validator turned up the fact that a major chunk of source (including the end of the front element and beginning of the middle one) got lost in editing, but I still don't think XML2RFC should get quite this confused. -- -------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Keywords: | -------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Mon Jan 13 05:50:50 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B181AE115 for ; Mon, 13 Jan 2014 05:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 bNNFm3DSZnZb for ; Mon, 13 Jan 2014 05:50:48 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 328131AE114 for ; Mon, 13 Jan 2014 05:50:48 -0800 (PST) Received: from localhost ([127.0.0.1]:47321 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W2huW-00018j-Mi; Mon, 13 Jan 2014 14:50:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Mon, 13 Jan 2014 13:50:36 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/220#comment:1 Message-ID: <096.01dcbf9ff1e47d0df56954c7f24bf20e@tools.ietf.org> References: <081.305a1502ab7d17de2c0a8f73fd87dc02@tools.ietf.org> X-Trac-Ticket-ID: 220 In-Reply-To: <081.305a1502ab7d17de2c0a8f73fd87dc02@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #220: Failure in ID Database X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:50:50 -0000 #220: Failure in ID Database Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => fixed Comment: This was caused by a cron-job which wasn't running on the active server after the server crash in december. Fixed about a week ago. -- ------------------------------------------------+-------------------------- Reporter: schmidt@informatik.haw-hamburg.de | Owner: Type: defect | henrik@levkowetz.com Priority: medium | Status: closed Component: Version 2 cli | Milestone: Resolution: fixed | Version: 2.4.x | Keywords: ------------------------------------------------+-------------------------- Ticket URL: xml2rfc From henrik@levkowetz.com Fri Jan 17 13:42:57 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2A21AE181 for ; Fri, 17 Jan 2014 13:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] autolearn=ham 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 o2OYhqM6gKca for ; Fri, 17 Jan 2014 13:42:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4708B1ACCED for ; Fri, 17 Jan 2014 13:42:53 -0800 (PST) Received: from localhost ([127.0.0.1]:43352 helo=vigonier.tools.ietf.org ident=henrik) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W4HBU-0000sD-50; Fri, 17 Jan 2014 22:42:36 +0100 Message-ID: <52D9A3CB.9000504@levkowetz.com> Date: Fri, 17 Jan 2014 22:42:35 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: XML2RFC Interest Group , Ray Pelletier , Russ Housley , Alice Russo , Sandy Ginoza , Tony Hansen , Julian Reschke X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rpelletier@isoc.org, housley@vigilsec.com, arusso@amsl.com, sginoza@amsl.com, tony@att.com, julian.reschke@gmx.de, glen@amsl.com, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 17 Jan 2014 13:57:44 -0800 Cc: Glen Barney Subject: [xml2rfc] New xml2rfc release: 2.4.5 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 21:42:57 -0000 This announces the release of xml2rfc version 2.4.5, available for download from: http://pypi.python.org/pypi/xml2rfc http://tools.ietf.org/tools/xml2rfc2/cli/ This release is almost exclusively a result of bugfix work done by Jim Schaad. The focus of this release has been to refine the page-breaking code, and make the .nroff output, after processing through nroff, match the .txt output. For full details on all tickets, there's always the issue tracker: http://trac.tools.ietf.org/tools/xml2rfc/trac/report/. An extract from the changelog is available below. Best regards, Henrik -------- Release notes: Another bugfix release, with a majority of the contributions from Jim Schaad. * If there is not an RFC number then XXXX is used for the RFC number for to internal:/rfc.number - matches v1 behavior. Fixes issue #114. * We now do a better (but not perfect) job of mking sure that section headings are not orphaned. If you have two section headings in a row then the first may still be orphaned. Fixes issue #166. * All known page breaking issues have been fixed. Closes issue #172. * Fixed a number of places where the code has to be made to work with both Python 2.7 unicode and string whitespace, and Python 3.3. whitespace strings, which are always unicode. Fixes issue #217. * Don't count formatting lines (which we can now tell) when computing break hints. * Catch any syntax errors raised while we're looking for an RFC number attribute on , so that we'll show all syntax errors found (during the next parse) instead of just one and one. * Added tests which generate .txt from .nroff and compares that to the xml2rfc-generated .txt (with some tweaks to handle different number of starting blanklines. Also corrected the number of initial blank lines output for RFCs in the raw text writer. * Not all files on Windows systems have a common root. This means that one cannot always get a relative path between to absolute path file names. Catch the error that occurs in these circumstances and just use the absolute path name. * Nested "format" style lists now include the level in the auto-generated counter value. Fixes issue #218. * EREFs are now put into the references section for text based output. Fixes issue #133. * cref elements are not dealt with when inline is either yes or no for text files. They are also now populated for html files as well. Fixes issue #201. From miek@miek.nl Fri Jan 17 14:06:33 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5841AD75F for ; Fri, 17 Jan 2014 14:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 EEK18Ld1HzDa for ; Fri, 17 Jan 2014 14:06:31 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 22B7F1ACCF8 for ; Fri, 17 Jan 2014 14:06:30 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so5154607wes.13 for ; Fri, 17 Jan 2014 14:06:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=hUigcoANweRghK/TG/qq4/S2T6Vh5YyesCdFGPkp3lQ=; b=TYbOwl5t+N0UiV9t1kG/GFGMt0C4hMACQI3JyzhssaIZHEAIwNBXXpU4oiix/Nrj1s ns/DOaN0tfHns22vOT9JA0DN2zphloj8haxiJyNW3hw3bE9SsYxncMdpeuZIDXt+439N JexBtSoXKk2wvCjzKD9c8M/TqQEUkVuOGoQGk5bfxuMOGmATytkeZ124IRZVQ7vKroI5 /7LN7r2ZRRvafUZAa1fdOflMJpOR2u8DgwbBv/BbpAFQcHtHuUNcXJDSeF5nL1D7j9WI /U7iibIMe5k2xLstVew2iuf6txYuKq8o23H06SQsKuVc4w0xYSNAvAjXEVSZh3MiPcB9 Dw3A== X-Gm-Message-State: ALoCoQkXCr4gOVi8r5ZaFgCdvGEiGB15KJICQgZA8P+xSCcC3Vlqkga4IL+/lLZ1XFkiW4rlLMed X-Received: by 10.180.218.171 with SMTP id ph11mr390031wic.7.1389996377945; Fri, 17 Jan 2014 14:06:17 -0800 (PST) Received: from miek.nl (host109-156-124-42.range109-156.btcentralplus.com. [109.156.124.42]) by mx.google.com with ESMTPSA id p1sm5353083wie.1.2014.01.17.14.06.16 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 14:06:17 -0800 (PST) Date: Fri, 17 Jan 2014 22:06:16 +0000 From: Miek Gieben To: xml2rfc@ietf.org Message-ID: <20140117220616.GA29882@miek.nl> Mail-Followup-To: xml2rfc@ietf.org References: <52D9A3CB.9000504@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D9A3CB.9000504@levkowetz.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [xml2rfc] New xml2rfc release: 2.4.5 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 22:06:33 -0000 [ Quoting in "[xml2rfc] New xml2rfc release: 2.4...." ] > This announces the release of xml2rfc version 2.4.5, available for download > from: > > http://pypi.python.org/pypi/xml2rfc > http://tools.ietf.org/tools/xml2rfc2/cli/ > > This release is almost exclusively a result of bugfix work done by Jim Schaad. > The focus of this release has been to refine the page-breaking code, and make > the .nroff output, after processing through nroff, match the .txt output. ubuntu deb: https://launchpad.net/~miek/+archive/pandoc2rfc (still processing) debian deb: http://pandoc2rfc.implementers.org/unstable/all/ Grtz Miek From trac@tools.ietf.org Mon Jan 20 12:09:37 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A3D1A024C for ; Mon, 20 Jan 2014 12:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 QbPj8oZIkAGq for ; Mon, 20 Jan 2014 12:09:35 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6621A025D for ; Mon, 20 Jan 2014 12:09:22 -0800 (PST) Received: from localhost ([127.0.0.1]:34763 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5L9t-0001K8-IX; Mon, 20 Jan 2014 21:09:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, miek@miek.nl X-Trac-Project: xml2rfc Date: Mon, 20 Jan 2014 20:09:21 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://tools.ietf.org/tools/xml2rfc/trac/ticket/186#comment:1 Message-ID: <080.9ef27db5eeffa8e7fcb249fe2085a81c@tools.ietf.org> References: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, miek@miek.nl, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #186: "private" processing directive failing X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 20:09:38 -0000 #186: "private" processing directive failing Comment (by miek@miek.nl): Just test with 2.4.5, this is still an issue. -- -------------------------------+------------------------------------------- Reporter: john- | Owner: henrik@levkowetz.com ietf@jck.com | Status: new Type: defect | Milestone: Priority: medium | Version: 2.4.x Component: Version 2 cli | Keywords: private, processing driective Resolution: | -------------------------------+------------------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Mon Jan 20 12:31:21 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213071A021A for ; Mon, 20 Jan 2014 12:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 MTsG5Ic8_C2r for ; Mon, 20 Jan 2014 12:31:18 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7071A0169 for ; Mon, 20 Jan 2014 12:31:18 -0800 (PST) Received: from localhost ([127.0.0.1]:36375 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5LV6-0006Ra-SD; Mon, 20 Jan 2014 21:31:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, miek@miek.nl X-Trac-Project: xml2rfc Date: Mon, 20 Jan 2014 20:31:16 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/186#comment:2 Message-ID: <080.a4e1660060966a41d274bac03b4ef561@tools.ietf.org> References: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, miek@miek.nl, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #186: "private" processing directive failing X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 20:31:21 -0000 #186: "private" processing directive failing Comment (by miek@miek.nl): The patch in this link works: although it's a reverse one (patch -R) http://www.ietf.org/mail-archive/web/xml2rfc/current/msg03978.html -- -------------------------------+------------------------------------------- Reporter: john- | Owner: henrik@levkowetz.com ietf@jck.com | Status: new Type: defect | Milestone: Priority: medium | Version: 2.4.x Component: Version 2 cli | Keywords: private, processing driective Resolution: | -------------------------------+------------------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Tue Jan 21 10:02:29 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8FF1A011D for ; Tue, 21 Jan 2014 10:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 P3-QtdwwLZ7r for ; Tue, 21 Jan 2014 10:02:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2536E1A00C8 for ; Tue, 21 Jan 2014 10:02:26 -0800 (PST) Received: from localhost ([127.0.0.1]:37812 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5feb-0004PI-Ee; Tue, 21 Jan 2014 19:02:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, miek@miek.nl X-Trac-Project: xml2rfc Date: Tue, 21 Jan 2014 18:02:25 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/222 Message-ID: <060.25022a7a2598475a90f4f6ea49310555@tools.ietf.org> X-Trac-Ticket-ID: 222 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, miek@miek.nl, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #222: URIs and references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:02:29 -0000 #222: URIs and references When having a URIs section and a reference section, the reference section is listed as being on page 0 in the toc. {{{ 1. Bla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. References . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Normative References . . . . . . . . . . . . . . . . . . 0 2.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 2 }}} This is with version 2.4.5. Attached xml triggers this. -- ---------------------------+---------------------------------- Reporter: miek@miek.nl | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Keywords: | ---------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Tue Jan 21 13:26:21 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE6B1A0250 for ; Tue, 21 Jan 2014 13:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 Sohc_Df8tADb for ; Tue, 21 Jan 2014 13:26:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 48DFA1A0263 for ; Tue, 21 Jan 2014 13:26:17 -0800 (PST) Received: from localhost ([127.0.0.1]:45775 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5ipp-0003rb-Gh; Tue, 21 Jan 2014 22:26:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, miek@miek.nl, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Tue, 21 Jan 2014 21:26:13 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/186#comment:3 Message-ID: <080.51de71eb92ccd640c2fdec1b764095ac@tools.ietf.org> References: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, miek@miek.nl, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #186: "private" processing directive failing X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:26:21 -0000 #186: "private" processing directive failing Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1126]: * Fix ticket #186 based on diffs provided by Leif Johansson * If the first parse of the XML tree generates a syntax error, then we now produce a warning of that fact. This is in part to help me track down what is happening at odd intervolts on my system where it generates an error and then has entity resolution problems. -- -------------------------------+------------------------------------------- Reporter: john- | Owner: henrik@levkowetz.com ietf@jck.com | Status: closed Type: defect | Milestone: Priority: medium | Version: 2.4.x Component: Version 2 cli | Keywords: private, processing driective Resolution: fixed | -------------------------------+------------------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Tue Jan 21 13:52:12 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4D1A035F for ; Tue, 21 Jan 2014 13:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 kZWQDDq7vwOP for ; Tue, 21 Jan 2014 13:52:11 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EC1DC1A024C for ; Tue, 21 Jan 2014 13:52:10 -0800 (PST) Received: from localhost ([127.0.0.1]:46356 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5jEw-0002fY-20; Tue, 21 Jan 2014 22:52:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Tue, 21 Jan 2014 21:52:09 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/222#comment:1 Message-ID: <075.5cb1cb22e42b4f25a137f75d5307a2b9@tools.ietf.org> References: <060.25022a7a2598475a90f4f6ea49310555@tools.ietf.org> X-Trac-Ticket-ID: 222 In-Reply-To: <060.25022a7a2598475a90f4f6ea49310555@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #222: URIs and references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:52:13 -0000 #222: URIs and references Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1127]. Missed the need to emit the header in the references section when there is one reference section and erefs. Now works correctly. -- ----------------------------+---------------------------------- Reporter: miek@miek.nl | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ----------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Tue Jan 21 13:57:23 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA51A01CA for ; Tue, 21 Jan 2014 13:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 9oNa-KvjNFFC for ; Tue, 21 Jan 2014 13:57:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCC91A0182 for ; Tue, 21 Jan 2014 13:57:21 -0800 (PST) Received: from localhost ([127.0.0.1]:46495 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5jJx-0004IF-2S; Tue, 21 Jan 2014 22:57:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Tue, 21 Jan 2014 21:57:21 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/221#comment:1 Message-ID: <080.2f4d63b920facf7ba18aaaef42aa2c2e@tools.ietf.org> References: <065.df3f7d3c9f028114dd99e745fd592626@tools.ietf.org> X-Trac-Ticket-ID: 221 In-Reply-To: <065.df3f7d3c9f028114dd99e745fd592626@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #221: XmlRfcParser instance has no attribute 'rfc_number' followed by "file is not there" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:57:23 -0000 #221: XmlRfcParser instance has no attribute 'rfc_number' followed by "file is not there" Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed Comment: This was fixed in 2.4.5 -- --------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: --------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 22 00:02:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF091A037E for ; Wed, 22 Jan 2014 00:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 Ka87vcWd10RR for ; Wed, 22 Jan 2014 00:02:22 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3CE1A037A for ; Wed, 22 Jan 2014 00:02:22 -0800 (PST) Received: from localhost ([127.0.0.1]:42866 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5slQ-0006xS-8y; Wed, 22 Jan 2014 09:02:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, john-ietf@jck.com X-Trac-Project: xml2rfc Date: Wed, 22 Jan 2014 08:02:20 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/223 Message-ID: <065.4fd702a033c009912b4c79742fdc6711@tools.ietf.org> X-Trac-Ticket-ID: 223 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, john-ietf@jck.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #223: Including the same attribute twice results in no file output, no messages X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:02:24 -0000 #223: Including the same attribute twice results in no file output, no messages If one accidentally lists two anchor attributes in a section element with the current online version (2.4.5 apparently) and with "file" output enabled, processing appears to complete normally (no messages are generated) but a zero-length file is produced. The "old version" (at http://xml.resource.org/old.html) produces a useful error message. This is of only medium priority as long as the old version and Bill's validator are available. If either or both are not (fenron.net did not appear to be responding tonight), the priority should be higher. -- -------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Keywords: zerolength output | -------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 22 00:18:18 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985EF1A007B for ; Wed, 22 Jan 2014 00:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 J84t6kBusI0e for ; Wed, 22 Jan 2014 00:18:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6831A0077 for ; Wed, 22 Jan 2014 00:18:16 -0800 (PST) Received: from localhost ([127.0.0.1]:43261 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5t0p-0008Ti-MY; Wed, 22 Jan 2014 09:18:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, john-ietf@jck.com X-Trac-Project: xml2rfc Date: Wed, 22 Jan 2014 08:18:15 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/224 Message-ID: <065.7f27c2cd642b096b561f56bc128dbc6d@tools.ietf.org> X-Trac-Ticket-ID: 224 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, john-ietf@jck.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #224: Web output for "file" option X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:18:18 -0000 #224: Web output for "file" option With the current online version, if one selects "file" in the last line of the "Convert your XML source" box and then converts a file, the file disposition box that pops up (at least in current versions of Firefox on Windows) shows "open file" as the default. If "open file" were desired, some other option would have been chosen. The "file" output option should default to "save file" as it did in prior (pre-Python) online versions of xml2rfc. -- -------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Keywords: | -------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 22 02:04:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDE41A02D0 for ; Wed, 22 Jan 2014 02:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 HqnX8TLg1m45 for ; Wed, 22 Jan 2014 02:04:22 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BE2D81A0099 for ; Wed, 22 Jan 2014 02:04:22 -0800 (PST) Received: from localhost ([127.0.0.1]:47665 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5ufT-0006Cb-HC; Wed, 22 Jan 2014 11:04:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, tony@att.com, john-ietf@jck.com X-Trac-Project: xml2rfc Date: Wed, 22 Jan 2014 10:04:19 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/198#comment:3 Message-ID: <080.c1ff27de46afdf2e07d60ba2d44c0413@tools.ietf.org> References: <065.270f26f919042693c1a1087744dfd2f1@tools.ietf.org> X-Trac-Ticket-ID: 198 In-Reply-To: <065.270f26f919042693c1a1087744dfd2f1@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, tony@att.com, john-ietf@jck.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #198: Misleading "premature end of data" indication X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:04:24 -0000 #198: Misleading "premature end of data" indication Comment (by john-ietf@jck.com): Sorry, Henrik's comment got lost in the noise. I hacked up a relatively small file that illustrates the problem. With the current version (apparently 2.4.5) and output set to "Use frames to show", I get the rather annoying "The file is not there -- check for error messages or you may have clicked reload" message with no [other] error messages. With output set to file, I get no messages at all but an empty file, reminiscent of the issue just reported in #223. -- --------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: --------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 22 13:23:38 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9921A0494 for ; Wed, 22 Jan 2014 13:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 5SDeaAe13g16 for ; Wed, 22 Jan 2014 13:23:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 695681A0480 for ; Wed, 22 Jan 2014 13:23:36 -0800 (PST) Received: from localhost ([127.0.0.1]:47359 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W65Go-0002nn-HE; Wed, 22 Jan 2014 22:23:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, arusso@amsl.com X-Trac-Project: xml2rfc Date: Wed, 22 Jan 2014 21:23:34 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/138#comment:5 Message-ID: <078.82c906640e1598dc7d2e4e7527f9c835@tools.ietf.org> References: <063.7df830cfb660368411c74d0c341cef5e@tools.ietf.org> X-Trac-Ticket-ID: 138 In-Reply-To: <063.7df830cfb660368411c74d0c341cef5e@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, arusso@amsl.com, sginoza@amsl.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org, sginoza@amsl.com Subject: Re: [xml2rfc] #138: default should be to display one initial X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:23:38 -0000 #138: default should be to display one initial Comment (by arusso@amsl.com): Regarding [872], the new PI multiple-initials has side effects: - in the header: extraneous " ." when 1 initial is set (e.g., B. . Smith) - in the header: lacks smart handling of a period so extraneous " ." when 2 initials (e.g., A. Y. . Mous) - in the references: adds extraneous " ." for each author, even if the placement of the PI multiple-initials="yes" is altered (e.g., to after the ) The attached sample file generates "J. A. Doe" in the header, but the PI affects the output of the document's other author elements and the references' author elements. For example: {{{ [RFC5234] Crocker, D. . and P. . Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. }}} Rather than a PI, perhaps better as an attribute of an author element. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 22 14:33:42 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8532A1A04FD for ; Wed, 22 Jan 2014 14:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 mtKTwtFlXAPV for ; Wed, 22 Jan 2014 14:33:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 32E781A04FA for ; Wed, 22 Jan 2014 14:33:39 -0800 (PST) Received: from localhost ([127.0.0.1]:49832 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W66Ma-00046P-6o; Wed, 22 Jan 2014 23:33:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, miek@miek.nl, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Wed, 22 Jan 2014 22:33:36 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/186#comment:4 Message-ID: <080.64f3f97ea02f3a578620d547607b2bf7@tools.ietf.org> References: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <065.a79858936eb7aeb76ed366036811e9ea@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, miek@miek.nl, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #186: "private" processing directive failing X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:33:42 -0000 #186: "private" processing directive failing Comment (by miek@miek.nl): Added patch because I noticed that 'Expires xxxx' was still printed with private='yes' -- -------------------------------+------------------------------------------- Reporter: john- | Owner: henrik@levkowetz.com ietf@jck.com | Status: closed Type: defect | Milestone: Priority: medium | Version: 2.4.x Component: Version 2 cli | Keywords: private, processing driective Resolution: fixed | -------------------------------+------------------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Thu Jan 23 07:59:50 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846181A0005 for ; Thu, 23 Jan 2014 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 kNFMNjpNGBFv for ; Thu, 23 Jan 2014 07:59:48 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AF28D1A0008 for ; Thu, 23 Jan 2014 07:59:48 -0800 (PST) Received: from localhost ([127.0.0.1]:33239 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W6Mgy-0002UR-2W; Thu, 23 Jan 2014 16:59:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, tony@att.com, john-ietf@jck.com X-Trac-Project: xml2rfc Date: Thu, 23 Jan 2014 15:59:44 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/198#comment:4 Message-ID: <080.d3f3219b49ff12624025ca059a799087@tools.ietf.org> References: <065.270f26f919042693c1a1087744dfd2f1@tools.ietf.org> X-Trac-Ticket-ID: 198 In-Reply-To: <065.270f26f919042693c1a1087744dfd2f1@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, tony@att.com, john-ietf@jck.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #198: Misleading "premature end of data" indication X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:59:50 -0000 #198: Misleading "premature end of data" indication Comment (by henrik@levkowetz.com): Thanks for the attached file. The problem is with the indicated encoding in the PI, which was set to US-ASCII when the encoding was UTF-8 (with no BOM). Changing the encoding to UTF-8 lets xml2rfc process the file. After correcting some minor things (like a missing definition of &rfc2119;) xml2rfc 2.4.5 processes the file correctly, producing a text file, with some appropriate warnings: {{{ henrik@tannat $ xml2rfc show-bogus-eof.xml Parsing file show-bogus-eof.xml WARNING: Illegal character replaced in string: — WARNING: Illegal character replaced in string: 愚 WARNING: Illegal character replaced in string: 蠢 WARNING: Illegal character replaced in string: г WARNING: Illegal character replaced in string: л WARNING: Illegal character replaced in string: у WARNING: Illegal character replaced in string: п WARNING: Illegal character replaced in string: ы WARNING: Illegal character replaced in string: й Created file show-bogus-eof.txt }}} The section which had unicode characters embedded is rendered with the appropriate xml entities written out, which I believe is as desired with the current specification: {{{ 2. Introduction Hi, Jim. The dashes on this line — setting off this phrase — are Unicode Em Dash, U+2014. And the problem, if it still exists, is rather 愚蠢 or, if you prefer, глупый. Given Heather's plans, both SHOULD probably generate warnings and either be rendered properly or create clear error messages. }}} The remaining issue is then to identify input files which are declared as xml in encoding "US-ASCII" or "ASCII" which contains non-ascii characters. At the moment, it unfortunately seems like this has to happen before the file is read by the xml parser, which means another pass over the file with a simple parser which can read the PI, extract the encoding, and flag violations, but that should be doable. -- --------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: --------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Thu Jan 23 08:09:11 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C8D1A001B for ; Thu, 23 Jan 2014 08:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 uYvp8Bzqo2dg for ; Thu, 23 Jan 2014 08:09:10 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 15E5F1A0015 for ; Thu, 23 Jan 2014 08:09:10 -0800 (PST) Received: from localhost ([127.0.0.1]:33607 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W6Mq4-0001XE-Sp; Thu, 23 Jan 2014 17:09:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Thu, 23 Jan 2014 16:09:08 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/223#comment:1 Message-ID: <080.7260fd0eb76191885c28c2561ab59f6e@tools.ietf.org> References: <065.4fd702a033c009912b4c79742fdc6711@tools.ietf.org> X-Trac-Ticket-ID: 223 In-Reply-To: <065.4fd702a033c009912b4c79742fdc6711@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #223: Including the same attribute twice results in no file output, no messages X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:09:12 -0000 #223: Including the same attribute twice results in no file output, no messages Comment (by henrik@levkowetz.com): This seems to be a problem with the online service only; the command-line version of xml2rfc (v2.4.5) provides clear error messages: {{{ henrik@tannat $ xml2rfc urnbis-reg-transition-01a.xml Parsing file urnbis-reg-transition-01a.xml ERROR: Unable to parse the XML document: urnbis-reg-transition-01a.xml urnbis-reg-transition-01a.xml: Line 303: Attribute anchor redefined urnbis-reg-transition-01a.xml: Line 303: Attribute anchor redefined }}} -- --------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: zerolength output --------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Thu Jan 23 08:15:13 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262321A0008 for ; Thu, 23 Jan 2014 08:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 0Jaks-pSFH6c for ; Thu, 23 Jan 2014 08:15:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A860F1A001B for ; Thu, 23 Jan 2014 08:15:05 -0800 (PST) Received: from localhost ([127.0.0.1]:33851 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W6Mvo-0003IU-Db; Thu, 23 Jan 2014 17:15:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Thu, 23 Jan 2014 16:15:04 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/223#comment:2 Message-ID: <080.99a40152afbcebae7e6f59bb8550b358@tools.ietf.org> References: <065.4fd702a033c009912b4c79742fdc6711@tools.ietf.org> X-Trac-Ticket-ID: 223 In-Reply-To: <065.4fd702a033c009912b4c79742fdc6711@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #223: Including the same attribute twice results in no file output, no messages X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:15:13 -0000 #223: Including the same attribute twice results in no file output, no messages Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => worksforme Comment: Hmm. I've now tried this with the online service, too, and I get clear error messages for all 3 choices of output: "file", "window", and "frames". In all 3 cases I see this at the top of the resulting web-page: {{{ #!html

Unable to Validate File

ERROR: Unable to parse the XML document: INPUT
  INPUT: Line 303: Attribute anchor redefined
  INPUT: Line 303: Attribute anchor redefined
}}} -- --------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: worksforme | Keywords: zerolength output --------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Thu Jan 23 13:55:41 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267871A035C for ; Thu, 23 Jan 2014 13:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 BAmrO6WZkVZk for ; Thu, 23 Jan 2014 13:55:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF131A0221 for ; Thu, 23 Jan 2014 13:55:39 -0800 (PST) Received: from localhost ([127.0.0.1]:48710 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W6SFO-00064J-4r; Thu, 23 Jan 2014 22:55:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, john-ietf@jck.com X-Trac-Project: xml2rfc Date: Thu, 23 Jan 2014 21:55:38 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/225 Message-ID: <065.bccdae39f2dc4aa7df96539fcf591c68@tools.ietf.org> X-Trac-Ticket-ID: 225 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, john-ietf@jck.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #225: Another simple error yielding no output and no useful error message X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:55:41 -0000 #225: Another simple error yielding no output and no useful error message Hi. Apparently a simple invalid attribute in a file passed to the current online version also produces the "no error message, input file not found, zero-length output file" situation discussed in other contexts in tickets #198 and #223. The problem is diagnosed as an invalid attribute value with the correct line number in the older version at http://xml.resource.org/old.html. I've increased my opinion of the priority of what appears to be a fairly serious, and fairly generic, problem in the parser or something close to it. -- -------------------------------+---------------------------------- Reporter: john-ietf@jck.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Keywords: | -------------------------------+---------------------------------- Ticket URL: xml2rfc From miek@miek.nl Fri Jan 24 14:00:57 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7BD1A00AB for ; Fri, 24 Jan 2014 14:00:57 -0800 (PST) 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 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 rmFEuxSDmtfy for ; Fri, 24 Jan 2014 14:00:55 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id B13861A001A for ; Fri, 24 Jan 2014 14:00:55 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0OM0kZp086885 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 24 Jan 2014 14:00:48 -0800 (PST) (envelope-from miek@miek.nl) Received: by mail-wg0-f53.google.com with SMTP id y10so3502398wgg.8 for ; Fri, 24 Jan 2014 14:00:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=TT2P1lOiNliah0Ekn/TjVQIYnHsnjfk/FfwZRXioDAw=; b=nOhevenRYTT1lFjdVbNUgwGf64qJxpJm0ddfQu1rY2cCrdGVlhQx8UfoeMds1dwa3N auQfTG77/UsQAPVQJTIjLr2aov5oB7TEdifFW6qjRa4P50QUc2R4dsLQGYjMwmdlYMeb BUGHvznnchwF3N2wISumTyaTawKaP8HU5oqNZ1mPikMHBVNbGc11Z/Ew8iXdwOluhS7k nnPw+jsWzYTZ/U/ptdrOmSsvwYWr/MgKw3HVnCrmOBWXPVB6bKvlXQIHTGeJmuup5+Sk jBuBOGh2jvDn8o+SEKEz279EE73ch+MxF4KI8CJatzicdU6UCBFZVrbk+oAs6ov15ctf Ry8g== X-Gm-Message-State: ALoCoQmBIZyvjbzhOHvIFl9Tb0qNZjHC0FArUB8Uo7KcV+bLw3ZiVh1c045/qNa34xyCjHgKkuSR X-Received: by 10.180.20.15 with SMTP id j15mr4733548wie.4.1390600841146; Fri, 24 Jan 2014 14:00:41 -0800 (PST) Received: from miek.nl (host86-166-247-17.range86-166.btcentralplus.com. [86.166.247.17]) by mx.google.com with ESMTPSA id j9sm5209704wjz.13.2014.01.24.14.00.39 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 24 Jan 2014 14:00:40 -0800 (PST) Date: Fri, 24 Jan 2014 22:00:38 +0000 From: Miek Gieben To: Xml2rfc list Message-ID: <20140124220038.GA18270@miek.nl> Mail-Followup-To: Xml2rfc list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: [xml2rfc] private='yes' and left_header in xml2rfc X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:00:57 -0000 Hello, There are some patches underway to make PI private='yes' work really well in xml2rfc v2. If I use it however, the left page header in the paginated txt output is set to empty and this makes the page header look a bit odd. Would it make sense to use the value of of the private PI to set the left page header? So you can use private='xyz' and the string 'xyz' is then used as the left page header? Regards, -- Miek Gieben From ietf@augustcellars.com Fri Jan 24 14:39:39 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A694C1A01E5 for ; Fri, 24 Jan 2014 14:39:39 -0800 (PST) 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 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 EqEsP-TnJmVw for ; Fri, 24 Jan 2014 14:39:38 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD261A01A1 for ; Fri, 24 Jan 2014 14:39:38 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0OMdWhp087254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Jan 2014 14:39:32 -0800 (PST) (envelope-from ietf@augustcellars.com) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id B3DC62C9BE; Fri, 24 Jan 2014 14:39:31 -0800 (PST) From: "Jim Schaad" To: "'Miek Gieben'" , "'Xml2rfc list'" References: <20140124220038.GA18270@miek.nl> In-Reply-To: <20140124220038.GA18270@miek.nl> Date: Fri, 24 Jan 2014 14:37:55 -0800 Message-ID: <005501cf1954$eca00110$c5e00330$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfnpB8X8V3qK6Ebc6b5E0ZtYW8eJtzbKPA Content-Language: en-us Subject: Re: [xml2rfc] private='yes' and left_header in xml2rfc X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:39:39 -0000 Would you want to keep private='yes' as producing nothing? > -----Original Message----- > From: xml2rfc [mailto:xml2rfc-bounces@ietf.org] On Behalf Of Miek Gieben > Sent: Friday, January 24, 2014 2:01 PM > To: Xml2rfc list > Subject: [xml2rfc] private='yes' and left_header in xml2rfc > > Hello, > > There are some patches underway to make PI private='yes' work really well > in xml2rfc v2. If I use it however, the left page header in the paginated txt > output is set to empty and this makes the page header look a bit odd. Would > it make sense to use the value of of the private PI to set the left page > header? So you can use private='xyz' and the string 'xyz' is then used as the > left page header? > > Regards, > > -- > Miek Gieben > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From miek@miek.nl Fri Jan 24 15:02:02 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4EC1A01E5 for ; Fri, 24 Jan 2014 15:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham 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 Ww_bbR4Q0Dst for ; Fri, 24 Jan 2014 15:02:01 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 699451A0154 for ; Fri, 24 Jan 2014 15:02:01 -0800 (PST) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0ON1sQH087462 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 24 Jan 2014 15:01:55 -0800 (PST) (envelope-from miek@miek.nl) Received: by mail-we0-f169.google.com with SMTP id u57so3348327wes.0 for ; Fri, 24 Jan 2014 15:01:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ztAuO9W+adQPOmwgOK4Gm1aal+q60XREhJa/4ZLoq1Y=; b=ij73Ch7RXjb21GD8ApSIV4f8E7vbLZQq1x6O3T2pXH3HhO+Ro9Aw2QxgouQAWXY4GY kNZxwd3PPEymskbiUO/357wfPfvNdc09kP21Lx0XyrujPcDcRdfbk/3BCZjZxx8klQzM OKdutYxmhhecOEAtXHBAboqtZMjwV0i3AHCrI9IBOvojLSd0ZtgYxQ1T0D4Jczjm+ViD +xh6Y5MXEx74vZV6gd5k7o+Rt4HVCRjHVNEV96yogQrPDubN+OnkzrJdCHIJ4PyEHVFW yhvovzHoQVs3RLQ6gum60itYmWIBrEFWGzaBhkXZdIMPs/mrBUsmKla7C4wrWPl76jTq cB5Q== X-Gm-Message-State: ALoCoQlJRvBP/WERDdvtAQ+q2q45a2kxKiKhCBBirbpFUze25mlPMU3LGTiKcdkUbZCiNBij7rW8 X-Received: by 10.180.38.41 with SMTP id d9mr4758496wik.9.1390604508116; Fri, 24 Jan 2014 15:01:48 -0800 (PST) Received: from miek.nl (host86-166-247-17.range86-166.btcentralplus.com. [86.166.247.17]) by mx.google.com with ESMTPSA id fo6sm9056362wib.7.2014.01.24.15.01.46 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 24 Jan 2014 15:01:47 -0800 (PST) Date: Fri, 24 Jan 2014 23:01:46 +0000 From: Miek Gieben To: "'Xml2rfc list'" Message-ID: <20140124230146.GA23773@miek.nl> Mail-Followup-To: 'Xml2rfc list' References: <20140124220038.GA18270@miek.nl> <005501cf1954$eca00110$c5e00330$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005501cf1954$eca00110$c5e00330$@augustcellars.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [xml2rfc] private='yes' and left_header in xml2rfc X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:02:02 -0000 [ Quoting in "RE: [xml2rfc] private='yes' and lef..." ] > Would you want to keep private='yes' as producing nothing? Excellent observation.... Yes, that would make things really weird. A new PI then? Grtz, Miek From miek@miek.nl Fri Jan 24 15:55:26 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110A91A01F5 for ; Fri, 24 Jan 2014 15:55:26 -0800 (PST) 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 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 G04nDw5SZByy for ; Fri, 24 Jan 2014 15:55:25 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 227321A01B9 for ; Fri, 24 Jan 2014 15:55:25 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0ONtIbc092598 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 24 Jan 2014 15:55:19 -0800 (PST) (envelope-from miek@miek.nl) Received: by mail-wg0-f52.google.com with SMTP id b13so3671147wgh.7 for ; Fri, 24 Jan 2014 15:55:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=JSm5/TqKrrT5I4zZLFmBDSQpOo28zEq2+M23rNbEIW8=; b=PNmBL+YgLzmDHsoTqAiLrI0T9mEd0znqzdvuQSaLvq13hruDzslka07vxMZQprqViY AswGoY5AUmxidRI7cdZkMnxg8ZwhoCOTY0J6+RLybmrDjTbbJSBe092SvJmgOt++dwtM bpn8LVcp2m9HLi+6bgx9qIDz1njb0sox99gY+f1kGtdI19qUE7Uv/RvgNgZiebn4hIq3 VKLEOGsEOB36G6Zc+z0s3s3xdZb8ziVMiBckIvtxbbTdyraxp6H4bQKlLQXXYNB/v9te JcGWWzbqLlT3Pqi2NfWqvySVTaAYROqefMLwSBa0G6BwrIc3ZyCOQjpB8ZqZBBQce3Cw SvFA== X-Gm-Message-State: ALoCoQlm9MeYJb5gcHPJwQafNw1s9h+NfS20BRIP6n+qd1VuIA+fpprQdJPFaWpLO7Hp+wOkoxHt X-Received: by 10.194.240.41 with SMTP id vx9mr169979wjc.70.1390607712043; Fri, 24 Jan 2014 15:55:12 -0800 (PST) Received: from miek.nl (host86-166-247-17.range86-166.btcentralplus.com. [86.166.247.17]) by mx.google.com with ESMTPSA id ff9sm10544427wib.11.2014.01.24.15.55.10 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 24 Jan 2014 15:55:11 -0800 (PST) Date: Fri, 24 Jan 2014 23:55:09 +0000 From: Miek Gieben To: "'Xml2rfc list'" Message-ID: <20140124235509.GA3894@miek.nl> Mail-Followup-To: 'Xml2rfc list' References: <20140124220038.GA18270@miek.nl> <005501cf1954$eca00110$c5e00330$@augustcellars.com> <20140124230146.GA23773@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140124230146.GA23773@miek.nl> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [xml2rfc] private='yes' and left_header in xml2rfc X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:55:26 -0000 [ Quoting in "Re: [xml2rfc] private='yes' and lef..." ] > Excellent observation.... Yes, that would make things really weird. A new PI then? ...and while looking through the code to implement this, it turns out it already exist. The PI is named 'header' (and there is 'footer' too for the center footer text) Regards, Miek From randy@psg.com Sun Jan 26 06:58:53 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700191A0147 for ; Sun, 26 Jan 2014 06:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RANDOM_SURE=0.499, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 deUlNPOBxWkd for ; Sun, 26 Jan 2014 06:58:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0BB1A0144 for ; Sun, 26 Jan 2014 06:58:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W7RAf-0001Pz-AU for xml2rfc@ietf.org; Sun, 26 Jan 2014 14:58:49 +0000 Date: Sun, 26 Jan 2014 23:58:47 +0900 Message-ID: From: Randy Bush To: XML2RFC Interest Group User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 14:58:53 -0000 draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated where these lines are the ------BEGIN etc of The result is (note this ought not be reproducible because each key better be unique, but you ought to get the same format):
-----BEGIN EC PRIVATE KEY----- MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== -----END EC PRIVATE KEY-----
To convert the result to PKCS#8, issue the following command: openssl pkcs8 -topk8 -inform PEM -outform PEM -in ecKey.pem -out ecKey-p8.pem -nocrypt
-----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgTMUt+qSVdSmh29qo a6K9qlVHNHGIhOHhR2Un8lMCArGhRANCAAQzhWBX+pQHToFn1vOpjJch9pwLk0Ov 3Jq/DF9tmcZ6Mhp5de3Y47+qSZBCrcTub8YQn5cXJyIu/Z1r3BpkxNVC -----END PRIVATE KEY-----
From yaronf.ietf@gmail.com Sun Jan 26 12:07:27 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772CB1A0164 for ; Sun, 26 Jan 2014 12:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=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 AjygcM93fT4R for ; Sun, 26 Jan 2014 12:07:26 -0800 (PST) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 06A241A00AE for ; Sun, 26 Jan 2014 12:07:25 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id d49so1886500eek.34 for ; Sun, 26 Jan 2014 12:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JIQ4Xou+tk0n5uP2A/m8RFjc/qPnamEKiNFdbxDWSII=; b=xJyIpNDDRPHI5zuduINxocI58mxnBSyG9j7a9ccU3NCM/sHB7F/BWXCntbNfdG+rcc JHi1sLTmBa/rNHKc2oHL7mIbqdrcBbhTHefxCJQY2VcZz40Imhn/QkSiAgEjP/HcSh0P FWckLIgIm5AkLYHDPeiVSWnG8K4zUDF+0bIDWd++et0kji9bGlA8ANWd4wBcQV9OhQAa qGLXU0G+zWjXGGmnBD75QJdyJvv85yxSK9v3d4zbTYp9nrG8dO9rYU+ITKvfQnXJevEF r2adk4RW6tmFWwm5ISJAFKXC5TMlTTWqkmvRhy+KDiARHH+xbvgHnEegMw6i/IAvAwG2 rlYA== X-Received: by 10.14.104.6 with SMTP id h6mr5175534eeg.29.1390766843655; Sun, 26 Jan 2014 12:07:23 -0800 (PST) Received: from [10.0.0.6] (bzq-79-182-111-162.red.bezeqint.net. [79.182.111.162]) by mx.google.com with ESMTPSA id v1sm32980201eef.9.2014.01.26.12.07.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 12:07:23 -0800 (PST) Message-ID: <52E56AFA.8060102@gmail.com> Date: Sun, 26 Jan 2014 22:07:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: xml2rfc@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [xml2rfc] Stack trace on incorrect date X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 20:07:27 -0000 Input:

<date year="2013" />

Output consists of a useful error message, followed by an exception:

WARNING: Incomplete and out-of date <date/> element: <date year="2013"/>
Traceback (most recent call last):
  File "/usr/local/bin/xml2rfc", line 225, in <module>
    main()
  File "/usr/local/bin/xml2rfc", line 192, in main
    htmlwriter.write(filename)
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1152, in write
    self._format_date()
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 473, in _format_date
    datetime.datetime.strptime(date.attrib.get('year')+date.attrib.get('month'), '%Y%B')
TypeError: cannot concatenate 'str' and 'NoneType' objects

Thanks,
    Yaron
From eagle@eyrie.org Sun Jan 26 12:08:47 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39BD1A00AE for ; Sun, 26 Jan 2014 12:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 yyvcHECdlNiU for ; Sun, 26 Jan 2014 12:08:46 -0800 (PST) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCDC1A0093 for ; Sun, 26 Jan 2014 12:08:46 -0800 (PST) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 670BD341007; Sun, 26 Jan 2014 12:08:44 -0800 (PST) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 5CAF8340FD8; Sun, 26 Jan 2014 12:08:41 -0800 (PST) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 66BC52F4AE; Sun, 26 Jan 2014 12:08:41 -0800 (PST) From: Russ Allbery To: Randy Bush In-Reply-To: (Randy Bush's message of "Sun, 26 Jan 2014 23:58:47 +0900") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Sun, 26 Jan 2014 12:08:41 -0800 Message-ID: <8761p65wvq.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 20:08:47 -0000 Randy Bush writes: > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > where these lines are the ------BEGIN etc of > The result is (note this ought not be reproducible because each > key better be unique, but you ought to get the same format): >
> > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 > AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ > qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== > -----END EC PRIVATE KEY----- This should be: I think. At least, that's always worked for me. -- Russ Allbery (eagle@eyrie.org) From henrik@levkowetz.com Sun Jan 26 14:09:36 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19F71A0090 for ; Sun, 26 Jan 2014 14:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 06rb7LY-ayMZ for ; Sun, 26 Jan 2014 14:09:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7B06F1A0092 for ; Sun, 26 Jan 2014 14:09:32 -0800 (PST) Received: from localhost ([127.0.0.1]:37393 helo=vigonier.tools.ietf.org ident=henrik) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W7XtR-0005mp-Ti; Sun, 26 Jan 2014 23:09:29 +0100 Message-ID: <52E58798.7040903@levkowetz.com> Date: Sun, 26 Jan 2014 23:09:28 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yaron Sheffer , xml2rfc@ietf.org References: <52E56AFA.8060102@gmail.com> In-Reply-To: <52E56AFA.8060102@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: yaronf.ietf@gmail.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Subject: Re: [xml2rfc] Stack trace on incorrect date X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 22:09:36 -0000 Hi Yaron, On 2014-01-26 21:07 Yaron Sheffer said the following: > Input: > > > > Output consists of a useful error message, followed by an exception: Right. Which version of xml2rfc are you running? Best regards, Henrik > WARNING: Incomplete and out-of date element: > Traceback (most recent call last): > File "/usr/local/bin/xml2rfc", line 225, in > main() > File "/usr/local/bin/xml2rfc", line 192, in main > htmlwriter.write(filename) > File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1152, in write > self._format_date() > File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 473, in _format_date > datetime.datetime.strptime(date.attrib.get('year')+date.attrib.get('month'), '%Y%B') > TypeError: cannot concatenate 'str' and 'NoneType' objects > > > Thanks, > Yaron > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > From yaronf.ietf@gmail.com Sun Jan 26 14:36:40 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C4B1A0092 for ; Sun, 26 Jan 2014 14:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 N0I-KylIe0ZV for ; Sun, 26 Jan 2014 14:36:38 -0800 (PST) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6251A0060 for ; Sun, 26 Jan 2014 14:36:38 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id g15so1987867eak.17 for ; Sun, 26 Jan 2014 14:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IMDqUm90ekKkzDe5LgOQTpAWqTNKYWZviGYEmiCu1nc=; b=EPLtnC/V45BeOZ26iz2Fzj/Ne7DR1KdHflz0BALOahAGZrpp0L8/FuptJvsL3FzD9D eVfeqHsWqdoEUiyWF1VPZw8ZqvD8TlMjXuAbu+OMQnGxt7Rku1vmPv/MzSGkRzAwrXhQ sL3nm8wZC8LS+kTWeg/QxtdeyQ9ckzY9590xE6xrlz/0NzSaw1i86+WLzpTGlB+1pBMC tbRiwpLGSwNTHU+np3MqBklRTd9nXR46cGIij4oQ5qKyPjgr8VPwI08Qcn9PqP0hIAdI tVCfgMyytVB7TYK9JSZ1T62aiEfK7JxumeyjPEcqhQ38Y6pVHg/8epFfFfyd6Zm806U5 0ZbQ== X-Received: by 10.15.55.193 with SMTP id v41mr1647961eew.80.1390775795446; Sun, 26 Jan 2014 14:36:35 -0800 (PST) Received: from [10.0.0.6] (bzq-79-182-111-162.red.bezeqint.net. [79.182.111.162]) by mx.google.com with ESMTPSA id v7sm34434357eel.2.2014.01.26.14.36.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 14:36:34 -0800 (PST) Message-ID: <52E58DF1.509@gmail.com> Date: Mon, 27 Jan 2014 00:36:33 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Henrik Levkowetz , xml2rfc@ietf.org References: <52E56AFA.8060102@gmail.com> <52E58798.7040903@levkowetz.com> In-Reply-To: <52E58798.7040903@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xml2rfc] Stack trace on incorrect date X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 22:36:40 -0000 Hi Henrik, This is the online version. Thanks, Yaron On 01/27/2014 12:09 AM, Henrik Levkowetz wrote: > Hi Yaron, > > On 2014-01-26 21:07 Yaron Sheffer said the following: >> Input: >> >> >> >> Output consists of a useful error message, followed by an exception: > > Right. Which version of xml2rfc are you running? > > > Best regards, > > Henrik > >> WARNING: Incomplete and out-of date element: >> Traceback (most recent call last): >> File "/usr/local/bin/xml2rfc", line 225, in >> main() >> File "/usr/local/bin/xml2rfc", line 192, in main >> htmlwriter.write(filename) >> File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1152, in write >> self._format_date() >> File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 473, in _format_date >> datetime.datetime.strptime(date.attrib.get('year')+date.attrib.get('month'), '%Y%B') >> TypeError: cannot concatenate 'str' and 'NoneType' objects >> >> >> Thanks, >> Yaron >> >> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> From randy@psg.com Sun Jan 26 14:41:27 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C901A015C for ; Sun, 26 Jan 2014 14:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 zU0YbF6PP2hL for ; Sun, 26 Jan 2014 14:41:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 91FB81A015B for ; Sun, 26 Jan 2014 14:41:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W7YOJ-0002Fw-AW; Sun, 26 Jan 2014 22:41:23 +0000 Date: Mon, 27 Jan 2014 07:41:21 +0900 Message-ID: From: Randy Bush To: Russ Allbery In-Reply-To: <8761p65wvq.fsf@windlord.stanford.edu> References: <8761p65wvq.fsf@windlord.stanford.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 22:41:28 -0000 > This should be: > > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 > AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ > qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== > -----END EC PRIVATE KEY----- > ]]> > The result is (note this ought not be reproducible because each key better be unique, but you ought to get the same format):
produces ERROR: Unable to parse the XML document: draft-ymbk-bgpsec-rtr-keying.xml draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated i suspect it is triggering on the ----- stuff, but what do i know? randy From brian.e.carpenter@gmail.com Sun Jan 26 19:48:01 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529E21A0190 for ; Sun, 26 Jan 2014 19:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 aXE0T2b5YD-p for ; Sun, 26 Jan 2014 19:48:00 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0692B1A00E1 for ; Sun, 26 Jan 2014 19:47:59 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so5377539pab.18 for ; Sun, 26 Jan 2014 19:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=exiXDi5E1hvovVnIkAebGNnfkUR/FcZYjLw4DDT+kvw=; b=FEMT5K+UzCvcw/DW6EpxsJ1BtK4TFA6rAMOeh3DIBsAndqzwlOFia3E2HtcOiIloe9 m+0KkhI8o303lx4RwJwklRHKqByDbGelAgolmXztptycL4q4yuq4SN7JtSoEdbtttNrs VhkYnjOQL90V+ZFmnzygisqVV+iaSLr8+0pf5zK+qowtBg78pkAyfoaFOA7r3g4kL6pM 2mP6/bmg+1AGfktrQfiQuCqOy6Tl3b9dcrdVFmfU/QMdvobl7xP/NElVxcN28St18KPu AXCSibLExl3rz9DALyV6JO6b7NF/rvQLImAGVSkAodFrQKqsVUILQM7M7VBo+3dofe/5 6l6A== X-Received: by 10.66.221.199 with SMTP id qg7mr4572510pac.88.1390794478067; Sun, 26 Jan 2014 19:47:58 -0800 (PST) Received: from [192.168.178.23] (100.199.69.111.dynamic.snap.net.nz. [111.69.199.100]) by mx.google.com with ESMTPSA id zc6sm74009598pab.18.2014.01.26.19.47.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 19:47:57 -0800 (PST) Message-ID: <52E5D6EA.5050300@gmail.com> Date: Mon, 27 Jan 2014 16:47:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: xml2rfc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xml2rfc] draft-odell-8+8-00.txt X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 03:48:01 -0000 draft-odell-8+8-00.txt isn't in bibxml3 It's in the tools archive: http://tools.ietf.org/id/draft-odell-8+8-00.txt Can anyone help? Regards Brian Carpenter From julian.reschke@gmx.de Sun Jan 26 23:18:42 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53431A01D0 for ; Sun, 26 Jan 2014 23:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 MF-Sh6flOupq for ; Sun, 26 Jan 2014 23:18:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id D80B01A01CF for ; Sun, 26 Jan 2014 23:18:40 -0800 (PST) Received: from [192.168.2.117] ([93.217.74.90]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MhAAr-1VuqXy3wZ7-00MM79 for ; Mon, 27 Jan 2014 08:18:38 +0100 Message-ID: <52E60841.9030508@gmx.de> Date: Mon, 27 Jan 2014 08:18:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Randy Bush , XML2RFC Interest Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OzTZAXt0dk8xEIMAxEUldn4oS8i1dOnu9FhgSywlABXM2xJZCA9 I9QH+tksyYT8CUzzswBTdLCNxvLzLls+4UwI30HcOUSj32eDvhxxphZ9Iud9CYQ2KxYazq8 wSFGud4+tAwcndtxITfE/nZVMXhqfyIV0Z/XTXNgvTd9nWwnBe56hAEKEhEx7Wgod8jiKb0 A2a+VQB6swvqz3uPuhymA== Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 07:18:43 -0000 On 2014-01-26 15:58, Randy Bush wrote: > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > > where these lines are the ------BEGIN etc of > > The result is (note this ought not be reproducible because each > key better be unique, but you ought to get the same format): >
> > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 > AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ > qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== > -----END EC PRIVATE KEY----- > >
> To convert the result to PKCS#8, issue the following command: > > openssl pkcs8 -topk8 -inform PEM -outform PEM -in ecKey.pem > -out ecKey-p8.pem -nocrypt >
> > -----BEGIN PRIVATE KEY----- > MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgTMUt+qSVdSmh29qo > a6K9qlVHNHGIhOHhR2Un8lMCArGhRANCAAQzhWBX+pQHToFn1vOpjJch9pwLk0Ov > 3Jq/DF9tmcZ6Mhp5de3Y47+qSZBCrcTub8YQn5cXJyIu/Z1r3BpkxNVC > -----END PRIVATE KEY----- > >
The text above seems to be fine. I recommend running the XML file though a generic XML parser to get better diagnostics. Or post the whole file over here (or send it to me directly). Best regards, Julian From julian.reschke@gmx.de Sun Jan 26 23:20:32 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F2D1A01D1 for ; Sun, 26 Jan 2014 23:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Bmm9zXuQGP4V for ; Sun, 26 Jan 2014 23:20:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 439761A01D0 for ; Sun, 26 Jan 2014 23:20:31 -0800 (PST) Received: from [192.168.2.117] ([93.217.74.90]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MXIov-1VkzEM0Tzx-00WI8u for ; Mon, 27 Jan 2014 08:20:28 +0100 Message-ID: <52E608B0.3020705@gmx.de> Date: Mon, 27 Jan 2014 08:20:16 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Russ Allbery , Randy Bush References: <8761p65wvq.fsf@windlord.stanford.edu> In-Reply-To: <8761p65wvq.fsf@windlord.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mt1ho4ue/Ga6ffbBZgjqbRB4IQ/rM1Y4RuFwAA7/SsBvkgkEi5f U5uk/Q4RgjDDa5+QF3cxDGrn/XDTSKlCm/yutRpZlo3WjjZnRUj3QGi/31Id1ypqYTDJRaS lc4wCW386FJrzgjpXQz5zbCI3vaopXzZy920a2XG0v6jZvjcoqROO9qqtKm38wKJPtQBr44 AgRCvwfwmqn4j2SL+BRDw== Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 07:20:32 -0000 On 2014-01-26 21:08, Russ Allbery wrote: > ... > This should be: > > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 > AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ > qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== > -----END EC PRIVATE KEY----- > ]]> > > > I think. At least, that's always worked for me. Not needed (and doesn't make any difference) unless the text contains "<" or "&" characters. Best regards, Julian From henrik@levkowetz.com Mon Jan 27 04:46:07 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397F31A0200 for ; Mon, 27 Jan 2014 04:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 FzQLU2e-DDP5 for ; Mon, 27 Jan 2014 04:46:04 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CEBB51A01FA for ; Mon, 27 Jan 2014 04:46:03 -0800 (PST) Received: from [2a01:3f0:1:0:9885:bc3d:4c4e:f435] (port=49353 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W7lZg-0003Gc-QV; Mon, 27 Jan 2014 13:46:01 +0100 Message-ID: <52E65508.2060803@levkowetz.com> Date: Mon, 27 Jan 2014 13:46:00 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yaron Sheffer , xml2rfc@ietf.org References: <52E56AFA.8060102@gmail.com> <52E58798.7040903@levkowetz.com> <52E58DF1.509@gmail.com> In-Reply-To: <52E58DF1.509@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:9885:bc3d:4c4e:f435 X-SA-Exim-Rcpt-To: yaronf.ietf@gmail.com, xml2rfc@ietf.org, henrik-sent@levkowetz.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 grenache.tools.ietf.org) Subject: Re: [xml2rfc] Stack trace on incorrect date X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 12:46:07 -0000 Hi Yaron, On 2014-01-26 23:36 Yaron Sheffer said: > Hi Henrik, > > This is the online version. Ok, thanks; I'll track it down. Best regards, Henrik > Thanks, > Yaron > > On 01/27/2014 12:09 AM, Henrik Levkowetz wrote: >> Hi Yaron, >> >> On 2014-01-26 21:07 Yaron Sheffer said the following: >>> Input: >>> >>> >>> >>> Output consists of a useful error message, followed by an exception: >> >> Right. Which version of xml2rfc are you running? >> >> >> Best regards, >> >> Henrik >> >>> WARNING: Incomplete and out-of date element: >>> Traceback (most recent call last): >>> File "/usr/local/bin/xml2rfc", line 225, in >>> main() >>> File "/usr/local/bin/xml2rfc", line 192, in main >>> htmlwriter.write(filename) >>> File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1152, in write >>> self._format_date() >>> File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 473, in _format_date >>> datetime.datetime.strptime(date.attrib.get('year')+date.attrib.get('month'), '%Y%B') >>> TypeError: cannot concatenate 'str' and 'NoneType' objects >>> >>> >>> Thanks, >>> Yaron >>> >>> >>> >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> > From julian.reschke@gmx.de Mon Jan 27 04:59:02 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517651A0209 for ; Mon, 27 Jan 2014 04:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 0yBMCY85wZ7N for ; Mon, 27 Jan 2014 04:59:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0F91A0138 for ; Mon, 27 Jan 2014 04:59:00 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M2t0Q-1VFOo30Wog-00sfkB for ; Mon, 27 Jan 2014 13:58:57 +0100 Message-ID: <52E6580E.5090907@gmx.de> Date: Mon, 27 Jan 2014 13:58:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: XML2RFC Interest Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hnXZDQiOIM/sFG0E5H/xqdaztesZtfoKsd1wFD73yDH1mcT1gSE Jff/d4Fh3XpwTIfO4GCGc3uRHKzvpiVGI/jAnhkLhRb+IWXKMt3cTF+z7IECY1y8UIkiRaD LwbpCRUFNUh7Gyb9x1tBfOyF8e9n0wRqE5pa0uqp5xLXpm1ziHTwcd2pr/KIykWf4N0h8Fb qssAsyihlHoYxoH8kA6gw== Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 12:59:02 -0000 On 2014-01-26 15:58, Randy Bush wrote: > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 264: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > draft-ymbk-bgpsec-rtr-keying.xml: Line 268: Comment not terminated > > where these lines are the ------BEGIN etc of > > The result is (note this ought not be reproducible because each > key better be unique, but you ought to get the same format): >
> > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 > AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ > qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== > -----END EC PRIVATE KEY----- > >
> To convert the result to PKCS#8, issue the following command: > > openssl pkcs8 -topk8 -inform PEM -outform PEM -in ecKey.pem > -out ecKey-p8.pem -nocrypt >
> > -----BEGIN PRIVATE KEY----- > MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgTMUt+qSVdSmh29qo > a6K9qlVHNHGIhOHhR2Un8lMCArGhRANCAAQzhWBX+pQHToFn1vOpjJch9pwLk0Ov > 3Jq/DF9tmcZ6Mhp5de3Y47+qSZBCrcTub8YQn5cXJyIu/Z1r3BpkxNVC > -----END PRIVATE KEY----- > >
> ... This was caused by the whole quoted section sitting inside an XML comment, and XML comments can't contain the string "--". Best regards, Julian From julian.reschke@gmx.de Mon Jan 27 08:27:08 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A11A033D for ; Mon, 27 Jan 2014 08:27:08 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 HUDcdIZdTPyG for ; Mon, 27 Jan 2014 08:27:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7471A0231 for ; Mon, 27 Jan 2014 08:27:04 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LZz01-1VR5pL1Qx3-00llFR for ; Mon, 27 Jan 2014 17:27:02 +0100 Message-ID: <52E688C6.40104@gmx.de> Date: Mon, 27 Jan 2014 17:26:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "xml2rfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:d2/tqzY1Ds5L+MMMZ7kSQgOKgFszBKSGdcNgB7cL7loFuqLgPWV B/Ajd6ggqIwNQM6hlz8U9V7fpyGYZV6exNGXB0GeUdC44rvRWAwAx9E7j1/2ceNM4OjSKyH WH4T96JmHHKO3gDEu0P0DCOHb7AxtN76a2rJ5WwR7rRx8jywFgSa9LiqZ3Apkt1w8q6j3q8 tuVxJTfM+oEPT+VTyDuew== Subject: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 16:27:08 -0000 Hi there, for , I'm currently trying to figure out what to say about hangIndent. The tricky thing here is that hangIndent is a formatting hint that is very specific to how xml2rfc formats "hanging" lists. Example: 12 Test 123 Test 12345 Test With hangIndent, the default depth can be tuned. Now this kind of list formatting is specific to TXT output. When producing HTML, the processors that I'm aware of produce HTML definition lists (dl/dt/dd). Those will be displayed differently than in TXT, such as: 12 Test 123 Test 12345 Test Consequently, xml2rfc has *ignored* hangIndent when producing HTML. rfc2629.xslt does unterstand it, and uses it to override the default indentation. xml2rfcv2 does something weird (all values != 0 lead to the same indentation). We can document the intended behavior for output that uses "compact lists". However, I'm not sure what to say for the HTML case (and similar formats). Best regards, Julian From ietf@augustcellars.com Mon Jan 27 09:07:26 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831031A035C for ; Mon, 27 Jan 2014 09:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 PkAD7RXvatIt for ; Mon, 27 Jan 2014 09:07:24 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id B7FF41A0158 for ; Mon, 27 Jan 2014 09:07:24 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8059938F0E; Mon, 27 Jan 2014 09:07:22 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> In-Reply-To: <52E688C6.40104@gmx.de> Date: Mon, 27 Jan 2014 09:05:45 -0800 Message-ID: <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6pg3OXYg Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 17:07:26 -0000 > -----Original Message----- > From: xml2rfc [mailto:xml2rfc-bounces@ietf.org] On Behalf Of Julian > Reschke > Sent: Monday, January 27, 2014 8:27 AM > To: xml2rfc@ietf.org > Subject: [xml2rfc] list/@style='hanging' and @hangIndent > > Hi there, > > for > latest.html#element.list.attribute.hangIndent>, > I'm currently trying to figure out what to say about hangIndent. > > The tricky thing here is that hangIndent is a formatting hint that is very > specific to how xml2rfc formats "hanging" lists. > > Example: > > 12 Test > > 123 Test > > 12345 Test > > With hangIndent, the default depth can be tuned. > > Now this kind of list formatting is specific to TXT output. When producing > HTML, the processors that I'm aware of produce HTML definition lists > (dl/dt/dd). Those will be displayed differently than in TXT, such as: > > 12 > Test > > 123 > Test > > 12345 > Test > > Consequently, xml2rfc has *ignored* hangIndent when producing HTML. > rfc2629.xslt does unterstand it, and uses it to override the default > indentation. xml2rfcv2 does something weird (all values != 0 lead to the same > indentation). > > We can document the intended behavior for output that uses "compact > lists". However, I'm not sure what to say for the HTML case (and similar > formats). I would propose that we make these styles distinct and make the txt and html versions do the same things. That is have a hang text version and a dictionary version (as previously proposed). I would be more than willing to make the changes to xml2rfc and the dtd today if people would agree it Is the right thing to do. (Not that I would expect that response.) Jim > > Best regards, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From julian.reschke@gmx.de Mon Jan 27 11:02:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7F01A027B for ; Mon, 27 Jan 2014 11:02:24 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 F1ymTWKO8bAL for ; Mon, 27 Jan 2014 11:02:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 323C71A0256 for ; Mon, 27 Jan 2014 11:02:22 -0800 (PST) Received: from [192.168.2.117] ([93.217.77.182]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LuOYx-1V6mhJ3nkN-011mP4 for ; Mon, 27 Jan 2014 20:02:19 +0100 Message-ID: <52E6AD34.10207@gmx.de> Date: Mon, 27 Jan 2014 20:02:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , xml2rfc@ietf.org References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> In-Reply-To: <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PSiMXBX61mh2xxECEKquAxclTA07+pvBwuyOdXVO9gSCIpR4Y0j BWPb4FxHhg9ofXfET7wLNj1BTYIeBeDMghIpGLYbNg/0GNpNcRz3xIWAoeS+AWZefB1NVXY jgtDGV+AsQ/+41+YhazobsHudz3/EF361uvLRAO1BZZI+bixudyqlME2NAAVMKg2O2XVfkl 1AAsB1hrZRusgWmNTrflA== Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:02:24 -0000 On 2014-01-27 18:05, Jim Schaad wrote: > > >> -----Original Message----- >> From: xml2rfc [mailto:xml2rfc-bounces@ietf.org] On Behalf Of Julian >> Reschke >> Sent: Monday, January 27, 2014 8:27 AM >> To: xml2rfc@ietf.org >> Subject: [xml2rfc] list/@style='hanging' and @hangIndent >> >> Hi there, >> >> for >> > latest.html#element.list.attribute.hangIndent>, >> I'm currently trying to figure out what to say about hangIndent. >> >> The tricky thing here is that hangIndent is a formatting hint that is very >> specific to how xml2rfc formats "hanging" lists. >> >> Example: >> >> 12 Test >> >> 123 Test >> >> 12345 Test >> >> With hangIndent, the default depth can be tuned. >> >> Now this kind of list formatting is specific to TXT output. When producing >> HTML, the processors that I'm aware of produce HTML definition lists >> (dl/dt/dd). Those will be displayed differently than in TXT, such as: >> >> 12 >> Test >> >> 123 >> Test >> >> 12345 >> Test >> >> Consequently, xml2rfc has *ignored* hangIndent when producing HTML. >> rfc2629.xslt does unterstand it, and uses it to override the default >> indentation. xml2rfcv2 does something weird (all values != 0 lead to the > same >> indentation). >> >> We can document the intended behavior for output that uses "compact >> lists". However, I'm not sure what to say for the HTML case (and similar >> formats). > > I would propose that we make these styles distinct and make the txt and html > versions do the same things. That is have a hang text version and a > dictionary version (as previously proposed). I would be more than willing > to make the changes to xml2rfc and the dtd today if people would agree it Is > the right thing to do. (Not that I would expect that response.) The problem here is that there simply isn't an HTML/CSS construct that will do the same... Best regards, Julian From brian.e.carpenter@gmail.com Mon Jan 27 11:05:36 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB991A0379 for ; Mon, 27 Jan 2014 11:05:36 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RANDOM_SURE=0.499, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 8kH6YHYdgK9u for ; Mon, 27 Jan 2014 11:05:35 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1605C1A03A6 for ; Mon, 27 Jan 2014 11:05:35 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so6220672pbc.41 for ; Mon, 27 Jan 2014 11:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7hYq7jlW/66mzHzALIrNAZn2CMkxhDggXhV3GVlL2t0=; b=q54lF7l6jUHjI6k3qoOTks3Dsel+WLSFDWykSyVVXRMmXTA+jshCILEZ7+cEM3JrQ9 mCYMx5uixullYSuzAfz0TsUOkUFQ1WnI4PSvhsLME/ShziAwiaPt9UCUSVotXCU/Apyw 3IQPk7kwSGhjD/HoGonfogM03F2So7Qi2oyT8zZiCDcyx4rnaId+5gSPBUPrGOMkhQjK UcNLsxITbyfqxnx0vtgcI7SuLVtoOJctHD4poGpjUA4/nicg2Z6+9zXArCR2y6V0QSPj IZSy/098WhBIUBvg1dLS6y+wDtmsf2JYd0+Hf0DmP98MagkSSK6laqLr5M4R/mnkSElp PUTg== X-Received: by 10.68.236.9 with SMTP id uq9mr32084578pbc.10.1390849532903; Mon, 27 Jan 2014 11:05:32 -0800 (PST) Received: from [192.168.178.23] (4.196.69.111.dynamic.snap.net.nz. [111.69.196.4]) by mx.google.com with ESMTPSA id sd3sm34205526pbb.42.2014.01.27.11.05.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 11:05:32 -0800 (PST) Message-ID: <52E6ADFB.7090804@gmail.com> Date: Tue, 28 Jan 2014 08:05:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julian Reschke References: <52E6580E.5090907@gmx.de> In-Reply-To: <52E6580E.5090907@gmx.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:05:36 -0000 On 28/01/2014 01:58, Julian Reschke wrote: ... > This was caused by the whole quoted section sitting inside an XML > comment, and XML comments can't contain the string "--". Which, incidentally, is really annoying, because it means you can't comment out an XML segment that includes a comment. A bad design choice, IMHO, but not one we can fix. However, the latest XML2RFC gives a decent diagnostic: to do this --> ERROR: Unable to parse the XML document: INPUT INPUT: Line 66: Double hyphen within comment Brian From ietf@augustcellars.com Mon Jan 27 11:55:38 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2E1A02B7 for ; Mon, 27 Jan 2014 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 68rz_HrC4Hrq for ; Mon, 27 Jan 2014 11:55:36 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA901A028B for ; Mon, 27 Jan 2014 11:55:36 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id DFCCD38F40; Mon, 27 Jan 2014 11:55:33 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> In-Reply-To: <52E6AD34.10207@gmx.de> Date: Mon, 27 Jan 2014 11:53:56 -0800 Message-ID: <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6gGZWHKfAfDgV52YGxU6sA== Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:55:38 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, January 27, 2014 11:02 AM > To: Jim Schaad; xml2rfc@ietf.org > Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent > > On 2014-01-27 18:05, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: xml2rfc [mailto:xml2rfc-bounces@ietf.org] On Behalf Of Julian > >> Reschke > >> Sent: Monday, January 27, 2014 8:27 AM > >> To: xml2rfc@ietf.org > >> Subject: [xml2rfc] list/@style='hanging' and @hangIndent > >> > >> Hi there, > >> > >> for > >> >> latest.html#element.list.attribute.hangIndent>, > >> I'm currently trying to figure out what to say about hangIndent. > >> > >> The tricky thing here is that hangIndent is a formatting hint that is > >> very specific to how xml2rfc formats "hanging" lists. > >> > >> Example: > >> > >> 12 Test > >> > >> 123 Test > >> > >> 12345 Test > >> > >> With hangIndent, the default depth can be tuned. > >> > >> Now this kind of list formatting is specific to TXT output. When > >> producing HTML, the processors that I'm aware of produce HTML > >> definition lists (dl/dt/dd). Those will be displayed differently than in TXT, > such as: > >> > >> 12 > >> Test > >> > >> 123 > >> Test > >> > >> 12345 > >> Test > >> > >> Consequently, xml2rfc has *ignored* hangIndent when producing HTML. > >> rfc2629.xslt does unterstand it, and uses it to override the default > >> indentation. xml2rfcv2 does something weird (all values != 0 lead to > >> the > > same > >> indentation). > >> > >> We can document the intended behavior for output that uses "compact > >> lists". However, I'm not sure what to say for the HTML case (and > >> similar formats). > > > > I would propose that we make these styles distinct and make the txt > > and html versions do the same things. That is have a hang text > > version and a dictionary version (as previously proposed). I would be > > more than willing to make the changes to xml2rfc and the dtd today if > > people would agree it Is the right thing to do. (Not that I would > > expect that response.) > > The problem here is that there simply isn't an HTML/CSS construct that will > do the same... I would have thought that

Would have done this. Jim > > Best regards, Julian From julian.reschke@gmx.de Mon Jan 27 12:42:02 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1877F1A0371 for ; Mon, 27 Jan 2014 12:42:02 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 87a5r2TzOVso for ; Mon, 27 Jan 2014 12:42:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 632CB1A00F6 for ; Mon, 27 Jan 2014 12:42:00 -0800 (PST) Received: from [192.168.2.117] ([93.217.77.182]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LiDrv-1VTvks2B2R-00nO93 for ; Mon, 27 Jan 2014 21:41:57 +0100 Message-ID: <52E6C492.4020405@gmx.de> Date: Mon, 27 Jan 2014 21:41:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , xml2rfc@ietf.org References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> In-Reply-To: <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mPJmncxh13xZn+xpFcOzw4xotOcnqltEKeFml6b13/D0J8P8IlV 2k6yi8hKK0GDwCwR9er4bVzg8e/hBDVYiidawJI7hzVllEVPnVugk/eLAJH95KtqD+v7Fnc 4KcQN1R/JPuSoZiCISCqV7vK5rebxL4WEJc0gFE3ZLlIo2A63cj6X5t2XrEV327UdaVcNom efeC58wHjJXZ9udsd6Ngw== Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 20:42:02 -0000 On 2014-01-27 20:53, Jim Schaad wrote: > ... >> The problem here is that there simply isn't an HTML/CSS construct that > will >> do the same... > > I would have thought that > >

> > Would have done this. > ... Can you provide an example? Best regards, Julian From ietf@augustcellars.com Mon Jan 27 15:45:19 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015BE1A0396 for ; Mon, 27 Jan 2014 15:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.72 X-Spam-Level: **** X-Spam-Status: No, score=4.72 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] autolearn=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 zGvWqOYB7ny9 for ; Mon, 27 Jan 2014 15:44:51 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id DE0F91A008F for ; Mon, 27 Jan 2014 15:44:50 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 08B142C9F4; Mon, 27 Jan 2014 15:44:47 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> <52E6C492.4020405@gmx.de> In-Reply-To: <52E6C492.4020405@gmx.de> Date: Mon, 27 Jan 2014 15:43:10 -0800 Message-ID: <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0230_01CF1B76.7BC89EB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6gGZWHKfAfDgV50BpxrFLgGzTBOfmACDuJA= Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:45:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0230_01CF1B76.7BC89EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So look at section 3. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, January 27, 2014 12:42 PM > To: Jim Schaad; xml2rfc@ietf.org > Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent > > On 2014-01-27 20:53, Jim Schaad wrote: > > ... > >> The problem here is that there simply isn't an HTML/CSS construct that > > will > >> do the same... > > > > I would have thought that > > > >

> > > > Would have done this. > > ... > > Can you provide an example? > > Best regards, Julian ------=_NextPart_000_0230_01CF1B76.7BC89EB0 Content-Type: text/html; name="eps-token.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eps-token.html" =0A= =0A= =0A= =0A= Plasma Service Trust Processing=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Network Working GroupJ. Schaad
Internet-DraftSoaring Hawk Consulting
Intended status: Standards TrackJanuary 20, 2014
Expires: July 24, 2014=0A=
=0A=

Plasma Service Trust Processing
=0A= draft-schaad-plasma-service-04=0A=

=0A=

=0A= Abstract=0A=

=0A=

RFC TBD describes a new model and set of requirements to implement = a labeling system on Cryptographic Message Syntax (CMS) objects where = the entity in charge of doing the label enforcement is under the control = of a central authority rather than the recipient of the object.

=0A=

This document describes a protocol to be used by senders and = recipients of CMS objects to communicate with a centralized label = enforcement server. The document outlines how a client will get the set = of labels or policies that it can use for sending messages, composes a = secure CMS object with a label on it and gets the necessary keys to = decrypt a CMS object from the server. This document is designed to be = used with RFC TBD2 which describes the extensions used in CMS objects to = hold the label information.

=0A=

=0A= Status of This Memo=0A=

=0A=

This Internet-Draft is submitted in full conformance with the = provisions of BCP 78 and BCP 79.

=0A=

Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF). Note that other groups may also distribute working = documents as Internet-Drafts. The list of current Internet-Drafts is at = http://datatracker.ietf.org/drafts/current/.

=0A=

Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at = any time. It is inappropriate to use Internet-Drafts as reference = material or to cite them other than as "work in progress."

=0A=

This Internet-Draft will expire on July 24, 2014.

=0A=

=0A= Copyright Notice=0A=

=0A=

Copyright (c) 2014 IETF Trust and the persons identified as the = document authors. All rights reserved.

=0A=

This document is subject to BCP 78 and the IETF Trust's Legal = Provisions Relating to IETF Documents = (http://trustee.ietf.org/license-info) in effect on the date of = publication of this document. Please review these documents carefully, = as they describe your rights and restrictions with respect to this = document. Code Components extracted from this document must include = Simplified BSD License text as described in Section 4.e of the Trust = Legal Provisions and are provided without warranty as described in the = Simplified BSD License.

=0A=
=0A=

=0A= Table of Contents=0A=

=0A= =0A=

=0A= 1. Introduction

=0A=

RFC TBD [I-D.freeman-plasma-requirement= s] describes a new model and set of requirements to implement a = labeling system on Cryptographic Message Syntax (CMS) objects where the = entity in charge of doing the label enforcement is under the control of = a central authority rather than the recipient of the object.

=0A=

This document describes a protocol to be = used by senders and recipients of CMS objects to communicate with a = centralized label enforcement server. The document outlines how a = client will get the set of labels or policies that it can use for = sending messages, composes a secure CMS object with a label on it and = gets the necessary keys to decrypt a CMS object from the server. This = document is designed to be used with RFC TBD [I-D.schaad-plasma-cms] which = describes the extensions used in CMS objects to hold the label = information.

=0A=

=0A= 1.1. XML Nomenclature and Name = Spaces

=0A=

The following name spaces are used in = this document:

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
PrefixNamespaceSpecification(s)
epshttp://ietf.org/2011/plasma/This Specification
wsthttp://docs.oasis-open.org/ws-sx/ws-trust/200512=0A= [WS-TRUST]=0A=
xacmlhttp://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-c= s-01-en.html=0A= [XACML]=0A=
ds2http://www.w3.org/2000/09/xmldsig#=0A= [XML-Signature]=0A=
xshttp://www.w3.org/2001/XMLSchema[XML-Schema1][XML-Schema2]
=0A=

=0A= 1.2. Requirements Terminology

=0A=

The key words "MUST", "MUST NOT", = "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this document are to be interpreted as = described in [RFC2119].

=0A=

When the words appear in lower case, = their natural language meaning is used.

=0A=

=0A= 2. Components

=0A=

In designing this specification we used a = number of pre-existing specifications as building blocks. In some cases = we use the entirety of the specification and in other case we use only = select pieces.

=0A=

=0A= 2.1. XACML 3.0

=0A=

The XACML specification (eXtensible = Access Control Markup Language) [XACML] provides = a framework for writing access control policies and for creating = standardized access control queries and responses. The request and = response portion of the specification is used to build the request (Section 5.2) and response (Section 6.1) messages in this = specification. The structure for writing the access control policies is = out of scope for this document, but XACML is one of the possibilities = that can be used for that purpose.

=0A=

=0A= 2.2. SAML

=0A=

A number of different methods for = carrying both identification and attributes of the party requesting = access is permitted in this specification. SAML is one of the methods = that is permitted for that purpose.

=0A=

SAML has defined three different types = of assertions in it's core specification [OASIS-CORE]:

=0A=
    =0A=
  • Authentication: The assertion subject was authenticated by a = particular means at a particular time.
    • =0A=
  • Attribute: The assertion subject is associated with the supplied = attributes.
    • =0A=
  • Authorization Decision:[CREF1]Trevor: I don't see Plasma = using this type=0A= A request to allow the assertion subject to access the = specified resource has been granted or denied.
    • =0A=
=0A=

While a PDP can use an Authorization Decision as input, this is = unexpected and MAY be supported. In addition there are three different = ways that the subject of a SAML statement can be identified:

=0A=
    =0A=
  • A bearer statement: These statements are belong to anybody who = presents them. The owner is required to take the necessary precautions = to protect them.
    • =0A=
  • A holder of key statement: These statements belong to anybody who = can use the key associated with the statement.
    • =0A=
  • Subject match:[CREF2]Trevor: What about attribute match?=0A= These statements can be associated to an identity by matching = the name of the entity.
    • =0A=
=0A=

=0A=

We cannot pass a SAML assertion with = attributes as a single attribute in the XACML request as XACML wants = each of the different attributes to be individually listed in the = request. This greatly simplifies the XACML code, but means that one = needs to do a mapping process from the SAML attributes to the XACML = attributes. This process has been discussed in Section 2 of [SAML-XACML]. This mapping process MUST be = done by a trusted agent, as there are a number of steps that need to be = done including the validation of the signature on the SAML assertion. = This process cannot be done by the PEP that is residing on the Plasma = client's system as this is considered to be an untrusted entity by the = Plasma system as a whole. One method for this to be addressed is to = treat the Plasma server as both a PDP (for the Plasma client) and a PDP = for the true XACML policy evaluator. In this model, the Plasma server = becomes the trusted PEP party and has the ability to do the necessary = signature validation and mapping processes. A new XACML request is then = created and either re-submitted to itself for complete evaluation or to = a third party which does the actual XACML processing.[CREF3]Trevor: This sounds like we = ignore the mapping on the wire. There is no reason to mandate the = mapping occurs inside the PDP.=0A= =0A=

=0A=

=0A= 2.3. WS-Trust 1.4

=0A=

The WS-Trust 1.4 [WS-TRUST] standard provides for methods for = issuing, renewing, and validating security tokens. This specification = uses only a small portion of that standard, specifically the structure = that returns a trust token from the issuer to the requester.

=0A=

This specification makes no statements = on the content and format of the token returned from the Plasma server = to the Plasma client in the wst:RequestSecurityTokenResponse field. = These tokens may be parseable by the client, but there is no requirement = that the client be able to understand the token. The token can always = be treated as an opaque blob by the client which is simply reflected = back to the server at a later time. The attributes that client needs to = understand in order to use the token, such as the life time, are = returned as fields of the token response.

=0A=

TODO: need to discuss the content model = and say what elements need to be supported and what elements can be = ignored -- safely.

=0A=

=0A= 3.=0A= Model=0A=

=0A=

To be supplied from the problem statement = document. [CREF4]Brian: Should one be able to create a policy on the fly = for specific item where a set of attributes can be defined by the sender = of the message.=0A= =0A=

=0A=
=0A=
=0A= 
=0A=
=0A=
        (1)(3)     +----------+  =0A=
      +----------->|Sending   |<------------+=0A=
      |            |Agent     |             |=0A=
 (2)  v            +----------+             v=0A=
+----------+           ^               +---------+=0A=
|Email     |           |               |Mail     |=0A=
|Policy    |<----------+               |Transfer |=0A=
|Service   |                           |Agent    |=0A=
+----------+                           +---------+=0A=
 ()   ^            +----------+             ^=0A=
      |            |Receiving |             |=0A=
      +----------->|Agent     |<------------+=0A=
        ()()       +----------+ =0A=
=0A=
=0A=

Figure 1: Message Access Control Actors

=0A=

List the boxes above and give some info = about them.

=0A=

=0A= Email Policy Service is the gateway controller for accessing a = message. Although it is represented as a single box in the diagram, = there is no reason for it to be in practice. Each of the three = protocols could be talking to different instances of a common system. = This would allow for a server to operated by Company A, but be placed in = Company B's network thus reducing the traffic sent between the two = networks.

=0A=

=0A= Mail Transfer Agent=0A= is the entity or set of entities that is used to move the message from = the sender to the receiver. Although this document describes the = process in terms of mail, any method can be used to transfer the = message.

=0A=

=0A= Receiving Agent=0A= is the entity that consumes the message.

=0A=

=0A= Sending Agent=0A= is the entity that originates the message.=0A=

=0A=

=0A=

=0A= 3.1. Sender Processing

=0A=

We layout the general steps that need to = be taken by the sender of an EPS message. The numbers in the steps = below refer to the numbers in the upper half of Figure = 1. A more detailed description of the processing is found in Section 7 for obtaining the security policies = that can be applied to a messages and Section = 8 for sending a message.

=0A=

=0A=

    =0A=
  1. The Sending Agent sends a message to one or more Email Policy = Services in order to obtain the set of policies that it can apply to a = message along with a security token to be used in proving the = authorization. Details of the message send can be found in Section 7.1.
    2. =0A=
  2. The Email Policy Service examines the set of policies that it = understands and checks to see if the requester is authorized to send = messages with the policy.
    3. =0A=
  3. The Email Policy Service returns the set of policies and an = security token to the Sending Agent. Details of the message sent can be = found in Section 7.2.
    4. =0A=
  4. The Sending Agent selects the Email Policy(s) to be applied to = the message, along with the set of recipients for the message.
    5. =0A=
  5. The Sending Agent relays the selected information to the Email = Policy Service along with the security token. Details of this message = can be found in Section 8.1.
    6. =0A=
  6. The Email Policy Service creates the recipient info attribute as = defined in [I-D.schaad-plasma-cms].
    7. =0A=
  7. The Email Policy Service returns the created attribute to the = Sending Agent. Details of this message can be found in Section 8.2.
    8. =0A=
  8. The Sending Agent composes the CMS EnvelopedData content type = placing the returned attribute into a KEKRecipientInfo structure and = then send the message to the Mail Transport Agent.
    9. =0A=
=0A=

=0A=

=0A= 3.2. Recieving Agent Processing

=0A=

We layout the general steps that need to = be taken by the sender of an EPS message. The numbers in the steps = below refer to the numbers in the lower half of Figure = 1. A more detailed description of the processing is found in Section 9.

=0A=

=0A=

    =0A=
  1. The Receiving Agent obtains the message from the Mail Transport = Agent.
    2. =0A=
  2. The Receiving Agent starts to decode the message and in that = process locates an EvelopedData content type which has a = KEKRecipientInfo structure with a XXXX attribute.
    3. =0A=
  3. The Receiving Agent processes the SignedData content of the XXXX = attribute to determine that communicating with it falls within accepted = policy.
    4. =0A=
  4. The Receiving Agent transmits the content of the XXXX attribute = to the referenced Email Policy Service. The details of this message can = be found in Section 9.1.
    5. =0A=
  5. The Email Policy Service decrypts the content of the message and = applies the policy to the credentials provided by the Receiving = Agent.
    6. =0A=
  6. If the policy passes, the Email Policy Service returns the = appropriate key or RecipientInfo structure to the Receiving Agent. = Details of this message can be found in Section 9.2.
    7. =0A=
  7. The Receiving Agent proceeds to decrypt the message and perform = normal processing.
    8. =0A=
=0A=

=0A=

=0A= 4.=0A= Protocol Overview=0A=

=0A=

The protocol defined in this document is = designed to take place between a Plasma server and a Plasma client. The = protocol takes place in terms of a request/response dialog from the = client to the server. A single dialog can consist of more than one = request/response message pair. Multiple round trips within allow a = client to provide additional authentication, authorization and attribute = information to the server.

=0A=

Each dialog contains one or more action = attributes specifying what actions the client wishes the server to take. = Depending on the action requested, additional attributes may be present = providing data for the action to use as input. Finally, each dialog = will contain authentication and attributes supplied by one or more = authorities that the server can use either as input to the action or as = input to policy decisions about whether to perform the action.

=0A=

The protocol MUST be run over a secure = transport, the secure transport is responsible for providing the = confidentiality and integrity protection services over the entire = message. The protocol allows for signature operations to occur on = sub-sections of the message structure, howewever this is used for = creation of identity proofs and not for integrity protection.

=0A=

Multiple dialogs may be run over a single = secure transport session. Before a new dialog may be started, the = previous dialog MUST have completed to a state of success, failure or = not applicable. A new dialog MUST NOT be started after receiving a = response with an indeterminate status. If a new dialog is desired in = these circumstances, then the transport session MUST to be closed and = re-opened. [CREF5]JLS: --- I want to say that TLS reconnect using caching = is OK here. Is that a reasonable statement? I don't think we want to = say that the server will keep Plasma session data across TLS = sessions.=0A= =0A=

=0A=

=0A= 5. Plasma Request

=0A=

The specification is written using XACML = as the basic structure to frame a request for an operation. The request = for operations to occur are written using XACML action items. This = specification defines actions specific to Plasma in a CMS environment. = Other specifications can define additional action items for other = environments (for example the XML encryption environment) or other = purposes. (Future work could use this basic structure to standardize = the dialogs between PDPs and PAPs or to facilitate legal signatures on = emails.)

=0A=

In addition to the XACML action request = there is a set of structures to allow for a variety of authentication = mechanisms to be used. By allowing for the use of SAML and GSS-API as = base authentication mechanisms, the mechanism used is contained in a = sub-system and thus does not directly impact the protocol.

=0A=

The request message uses a single XML = structure. This structure is the eps:PlasmaRequest object. The XML = Schema used to describe this structure is:

=0A= 
=0A=
  <xs:element name=3D"PlasmaRequest" type=3D"eps:RequestType"/>=0A=
  <xs:complexType name=3D"RequestType">=0A=
    <xs:sequence>=0A=
      <xs:element ref=3D"eps:Authentication" minOccurs=3D"0"/>=0A=
      <xs:element ref=3D"xacml:Request"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"Version" type=3D"xs:string" =
default=3D"1.0"/>=0A=
  </xs:complexType>=0A=
=0A=

The RequestType has two elements in it: =

=0A=
=0A=
Authentication
=0A=
is an optional element that holds the = structures used for doing authentication and authorization. Unless no = authentication is required by the Plasma server, the element is going to = exist for one or more requests in the dialog.
=0A=
xacml:Request
=0A=
is a required element that contains the = control information for the action requested. The control information = takes the form of an action request plus additional data to be used as = part of the action request. The data and actions are to be treated as = self-asserted, that is they are deemed not to come from a reliable = source even in the event that an authentication is successfully = completed. As self-asserted values, Plasma servers need to exercise = extreme care about which are included in the policy enforcement = decisions. As an example, it makes sense to allow for the action = identifier to be included in the policy enforcement, but assertions = about the identity of the subject should be omitted. This element is = taken from the XACML specification.
=0A=
=0A=

=0A=

For some operations, display string values = are returned as part of the response from the server. The xml:lang = attribute SHOULD be included in the RequestType element to inform the = server as to what language client wishes to have the strings in. The = server SHOULD attempt to return strings in the language requested or a = related language if at all possible.

=0A=

=0A= 5.1.=0A= Authentication Element=0A=

=0A=

One of the major goals in the Plasma = work is to detach the process of authentication specifics from the = Plasma protocol. In order to accomplish this we are specifying the use = of two general mechanisms (SAML and GSS-API) which can be configured and = expanded without changing the core Plasma protocol itself. The = authentication element has two main purposes: 1) to process the = authentication being used by the client and 2) to carry authenticated = attributes for use in the policy evaluation.

=0A=

When transporting the authentication = information, one needs to recognize that there may be a single or = multiple messages in the dialog in order to complete the authentication = process. In performing the process of authenticating, any or all of the = elements in this structure can be used. If there are multiple elements = filled out, the server can choose to process the elements in any order. = This means that the Plasma protocol itself does not favor any specific = mechanism. The current set of mechanisms that are built into the Plasma = specification are:

=0A=
    =0A=
  • SAML Assertions - many different types of SAML assertions are = supported. The specification uses both bearer and holder of key = assertions.
    • =0A=
  • X.509 Certificates can be used for the purpose of authentication = by creating a signature with the XML Digital Signature standard.
    • =0A=
  • GSS-API - the specification allows for the use of GSS-API in = performing the authentication process. The ABFAB mechanism in GSS-API = is specifically designed for use in a federated community and allows for = both authentication and attribute information to be queried from the = identity server.
    • =0A=
  • WS-Trust tokens allow for much of the same type of information to = be passed as SAML assertions. The Plasma specification has been = designed mainly for the use of WS-Trust tokens to be used for caching = prior authentication sessions.
    • =0A=
=0A=

=0A=

More than one authentication element can = be present in any single message. This is because a client may need to = provide more than one piece of data to a server in order to = authenticate, for example a holder of key SAML Assertion along with a = signature created with that key. Additionally a client may want to = provide the server an option of different ways of doing the = authentication. In a federated scenario, an X.509 certificate with a = signature can be presented and the server may not be able to build a = trust path to it's set of trust anchors. In this case the client may = need to use the GSS-API/EAP protocol for doing the authentication. The = client may want to provide the server with one or more SAML Assertion = that binds a number of attributes to it's identities so that the server = does not need to ask for those attributes at a later time. Finally, = multiple entities may need to be validated (for example the user and the = user's machine).

=0A=

When transporting the attribute = information, one needs to recognize that there may be single or multiple = messages in the dialog in order to complete the authorization process. = The server will return a status code of = urn:oasis:names:xacml:1.0:status:missing-attribute in the event that one = or more attributes are needed in order to complete the authorization = process. The details on how XACML returns missing attribute information = is found in Section 7.17.3 of [XACML]. When the = list of attributes is returned, the client has two choices: 1) It can = close the dialog, look for a source of the missing attributes and then = start a new dialog, 2) it can just get an assertion for the missing = attributes and send the new assertion as in a new request message within = the same dialog. The decision of which process to use will depend in = part on how long it is expected to take to get the new attribute = assertion to be returned.

=0A=

The same authentication data does not = need to be re-transmitted to the server in a subsequent message within a = single dialog. The server MUST retain all authenticated assertion = information during a single dialog.

=0A=

The schema for the Authentication = element directly maps to the ability to hold the above elements. The = schema for the Authentication element is:

=0A= 
=0A=
  <xs:element name=3D"Authentication" =
type=3D"eps:AuthenticationType"/>=0A=
  <xs:complexType name=3D"AuthenticationType">=0A=
    <xs:choice maxOccurs=3D"unbounded">=0A=
      <xs:element ref=3D"saml:Assertion"/>=0A=
      <xs:element name=3D"GSSAPI" type=3D"xs:hexBinary"/>=0A=
      <xs:element name=3D"RoleToken">=0A=
        <xs:complexType>=0A=
          <xs:sequence>=0A=
            <xs:any namespace=3D"##any" processContents=3D"lax"/>=0A=
          </xs:sequence>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
      <xs:element ref=3D"ds2:Signature"/>=0A=
      <xs:element name=3D"Other">=0A=
        <xs:complexType>=0A=
          <xs:sequence>=0A=
            <xs:any namespace=3D"##other"/>=0A=
          </xs:sequence>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
    </xs:choice>=0A=
  </xs:complexType>=0A=
=0A=

The schema allows for multiple = authentication elements to occur in any order. It is suggested, but not = required, that the ds2:Signature element occur after the authentication = element that has an assoicated key. This makes it easier for servers to = make a one pass validate of all authentication elements.

=0A=

The Other element is provided to allow = for additional authentication elements, include SAML version 1.1, to be = used.

=0A=

=0A= 5.1.1.=0A= SAML Assertion=0A=

=0A=

SAML Assertions can provide = authentication or attribute information to the server. A SAML statement = only needs to be provided once during a single dialog, the server MUST = remember all attributes during the dialog.

=0A=

When a SAML Assertion contains a = SubjectConformation element using the KeyInfoConfirmationDataType as a = subject conformation element, the confirmation shall be performed by the = creation of an XML Signature authentication element. The signature = element shall be created using an appropriate algorithm for the key = referenced in the SAML statement.

=0A=

Identify a SAML statement in the = delegation/subject/environment space - need text for this [CREF6]JLS: I don't = remember what this is supposed to be anymore.=0A= =0A=

=0A=

=0A= 5.1.2. WS Trust Tokens

=0A=

WS Trust tokens are used in two = different ways by this specification. They can be used as the primary = introduction method of a client to the server, or they can be used by = the server to allow the client to be re-introduced to the server in such = a way that the server can use cached information.

=0A=

WS Trust tokens come in two basic = flavors: Bearer tokens and Holder of Key tokens. With the first = flavor, presentation of the token is considered to be sufficient to = allow the server to validate the identity of the presenter and know the = appropriate attributes to make a policy decision. In the second flavor = some type of cryptographic operation (usually a signature or MAC = computation) is needed in addition to just presenting the token. The = Signature element (Section 5.1.3) provides = necessary infrastructure to permit the cryptographic result to be passed = to the server.

=0A=

This document does not define the = content or structure of any tokens to be used. This is strictly an = implementation issue for the servers in question. This is because the = client can treat the WS Token value presented to it as an opaque blob.[CREF7]trevor: Is this = totally true? Don't we need some kind of identifier so the server can = indicate when the token can be replayed in a subsequence request? E.g. = give me these attributes or a foo token.=0A= Only the servers need to understand how to process the blob. = However there are some additional fields which can be returned in = addition to the token that need to be discussed:

=0A=
=0A=
wst:TokenType
=0A=
SHOULD be returned if more than one type = of token is used by the set of servers. If a token type is returned to = the client, the client MUST include the element when the token is = returned to the server.
=0A=
wst:BinarySecret
=0A=
SHOULD be returned for moderate duration = tokens. If a binary secret is returned then the client MUST provide = protection for the secret value. When a binary secret has been = returned, then the client MUST create either a signature or MAC value = and place it into the Signature element Section = 5.1.3. [CREF8]JLS: I don't know of any way to say use the asymmetric = key that you authenticated with originally - can this be done?=0A= .
=0A=
wst:Lifetime
=0A=
MUST be returned with the wsu:Expires = element set. The wsu:Created element MAY be included. The element = provides the client a way to know when a token is going to expire and = obtain a new one as needed.
=0A=
=0A=

=0A=

=0A= 5.1.3.=0A= XML Signature Element=0A=

=0A=

When a holder of key credential is = used to determine the attributes associated with an entity, there is a = requirement that the key be used in a proof of possession step so that = the Plasma server can validate that the entity does hold the key. The = credentials can hold either asymmetric keys (X.509 certificates and SAML = Assertions) or symmetric keys (WS Trust Tokens and SAML Assertions) = which use Digital Signatures or Message Authentication Codes (MACs) = respectively to create and validate a key usage statement. The XML = signature standard [XML-Signature] = provides an infrastructure to for conveying the proof of possession = information.

=0A=

The signature is computed over the = XACML request element as a detached signature. When a signature element = exists in the message, the ChannelBinding attribute (Section 10.1.1) MUST be included in the = request. By the use of a value which is derived from the cryptographic = keys used in for protecting the tunnel, it is possible for the server to = verify that the authentication values computed were done specifically = for this specific dialog and are not replayed.

=0A=

When creating either a signature or a = MAC, the following statements hold:

=0A=
    =0A=
  • The canonicalization algorithm Canonical XML 1.1 [XML-C14N11] without comments MUST be supported = and SHOULD be used in preparing the XML node set for hashing. Other = canonicalization algorithms MAY be used.
    • =0A=
  • The signature algorithms RSAwithSHA256 and ECDSAwithSHA256 MUST = be supported by servers. At least one of the algorithms MUST be = supported by clients. The MAC algorithm HMAC-SHA256 MUST be supported by = both clients and servers. Other signature and MAC algorithms MAY be = supported.
    • =0A=
  • Set the additional attributes that must be included in a = signature - what should they be?
    • =0A=
  • If an xacml:Request element is referenced by an XML Signature = element, the xacml:Request element MUST include the ChannelBinding token = (Section 10.1.1) as one of the = attributes.
    • =0A=
  • The keys used in computing the authentication value need to be = identified for the recipient. For X509 certificates, the full raw = certificate will normally be included as part of the signature, but MAY = be referenced instead. For SAML assertions, the specific assertion = carrying the asymmetric key can be identified by TBD HERE. In the event = that symmetric keys are used by holder of key assertions, the specific = assertion will be identified by TBD HERE. In these cases the server is = expected to be able to associated the key with the assertion by some = means (either locally or perhaps encrypted into the assertion).
    • =0A=
=0A=

=0A=

=0A= 5.1.4. GSS-API Element

=0A=

GSS-API [RFC2743] provides a security services to callers = in a generic fasion, supportable with a range of underlying mechanisms = and technologies. GSS-API has been extended by providing a mechanism = for EAP [RFC7055] which is designed to work in = a federated environment. This effort was done by the Application = Bridging for Federated Access Beyond web (ABFAB) working group. In this = document the mechanism is referred to as ABFAB. This is the same type = of environment that the Plasma protocol is expected to operate as well. =

=0A=

GSS-API offers a number of security = services that are not used by the Plasma architecture.

=0A=

TBD - rules for using GSS-API in = general and the EAP version from ABFAB particularly.

=0A=
    =0A=
  • How to build the name.
    • =0A=
  • Must use a secure tunnel for the outer EAP method and an = appropriate inner EAP method(s) to accomplish the required level of = authentication.
    • =0A=
  • Server query of attributes and specification of LOA to the EAP = IdP.
    • =0A=
  • Any additional Trust model items.
    • =0A=
  • How round trips are accomplished - the only case that a server = will send back an Authentication element is on return processing of = GSS-API messages.
    • =0A=
=0A=

=0A=

=0A= 5.1.4.1. Generic = Requirements

=0A=

Not all GSS-API mechanisms have the = required features to support the necessary security that is needed by = Plasma. GSS-API mechanisms need to support the following features:

=0A=
    =0A=
  • The mechanism MUST support the binding of the TLS tunnel to the = authentication.
    • =0A=
  • Either the mechanism MUST support mutual authentication or the = TLS tunnel MUST be usable to authenticate the server being talked to. = Anonymous TLS sessions can be use when mutual authentication is provided = by the GSS-API mechanism.
    • =0A=
=0A=

=0A=

=0A= 5.1.4.2. GSS-EAP = Requirements

=0A=

=0A= 5.1.4.3. Channel Bindings

=0A=

The calls to GSS_Init_sec_content = and GSS_Accept_sec_context take a chan_bindings parameter. The value is = a GSS_CHANNEL_BINDINGS structure [RFC5554]. =

=0A=

The initiator-address-type and = acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST = be set to 0. The initiator-address and acceptor-address fields MUST be = the empty string.

=0A=

The application-data field MUST be = set to the channel binding value defined in Section 10.1.1.

=0A=

=0A= 5.2.=0A= xacml:Request = Element=0A=

=0A=

The request for an action to be = performed by the Plasma server along with the data that needs to be = supplied by the client in order for the server to complete the action = are placed into the xacml:Request element of the request. This document = defines a set of actions that are to be understood by the Plasma server. = One (or more) action is to be placed in the request message.

=0A=

In addition to the request for a = specific action to occur, the client can place additional attributes in = the request as well. These attributes are provided in order to assist = the server either in identifying who the various agents on the client = side are or to provide suggestions of attributes for using in making = control decisions. Any data provided by the client in this manner is to = be considered as a self-asserted value and to be treated as if it comes = from the client as oppose to a trusted attribute agent.

=0A=

For convenience the schema for the = xacml:Request element is reproduced here:

=0A= 
=0A=
<xs:element name=3D"Request" type=3D"xacml:RequestType"/>=0A=
<xs:complexType name=3D"RequestType">=0A=
  <xs:sequence>=0A=
    <xs:element ref=3D"xacml:RequestDefaults" minOccurs=3D"0"/>=0A=
    <xs:element ref=3D"xacml:Attributes" maxOccurs=3D"unbounded"/>=0A=
    <xs:element ref=3D"xacml:MultiRequests" minOccurs=3D"0"/>=0A=
  </xs:sequence>=0A=
  <xs:attribute name=3D"ReturnPolicyIdList" type=3D"xs:boolean" =
use=3D"required"/>=0A=
  <xs:attribute name=3D"CombinedDecision" type=3D"xs:boolean" =
use=3D"required"/>=0A=
</xs:complexType>=0A=
=0A=

The RequestDefaults element of the XACML = Request MUST be omitted by the clients. If present servers MUST ignore = the RequestDefaults element. The use of the MultiRequest element is = current not defined for a Plasma server and SHOULD be omitted by = clients.

=0A=

Clients MAY set ReturnPolicyIdList to = true in order to find out which policies where used by the server in = making the decision. Server MAY ignore this field and not return the = policy list even if requested.

=0A=

A number of different entities may need = to be identified to Plasma server as part of a request. These entities = include:

=0A=
    =0A=
  1. The subject making the request to the server.
    2. =0A=
  2. The machine on the subject is using.
    3. =0A=
  3. The entity the subject is acting for. Converse about = Delegation.
    4. =0A=
=0A=

=0A=

=0A= 6. Plasma Response Element

=0A=

There is a single top level structure that = is used by the server to respond to a client request.

=0A=

The XML Schema used to describe the top = level response is as follows:

=0A= 
=0A=
  <xs:element name=3D"PlasmaResponse" type=3D"eps:ResponseType"/>=0A=
  <xs:complexType name=3D"ResponseType">=0A=
    <xs:sequence>=0A=
      <xs:element ref=3D"xacml:Response"/>=0A=
      <xs:element ref=3D"eps:PlasmaReturnToken" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"Version" type=3D"xs:string" =
default=3D"1.0"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"PlasmaReturnToken" =
type=3D"eps:PlasmaReturnTokenType"/>=0A=
  <xs:complexType name=3D"PlasmaReturnTokenType">=0A=
    <xs:sequence>=0A=
      <xs:any namespace=3D"##any" processContents=3D"lax"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"DecisionId" type=3D"xs:string"/>=0A=
  </xs:complexType>=0A=
=0A=

A Plasma Response has two elements:

=0A=
=0A=
xacml:Response
=0A=
is a mandatory element that returns the = status of the access request.
=0A=
PlasmaReturnToken
=0A=
is an optional element to return a = token. These tokens represent the answer, for a success, of the = request. If multiple tokens are being returned, then the element will = occur mutiple times.
=0A=
=0A=

=0A=

A Plasma Return Token is a wrapper for the = actual token being returned. The returned token may be any content. = This document defines the following elements that are to be returned in = this location

=0A=
    =0A=
  • RoleToken - used to return roles.
    • =0A=
  • CMSMessageToken - used to return one or more CMS RecipientInfo = strucutures.
    • =0A=
  • CMSKeyToken - used to return either a CMS RecipientInfo structure = or a bare content encryption key.
    • =0A=
=0A=

=0A=

The PlasmaReturneTokenType has an optional = attribute DecisionId. This attribute is used when in the case multiple = requests are made at the same time in order to assoicate the rquest and = the response tokens.

=0A=

=0A= 6.1.=0A= xacml:Response = Element=0A=

=0A=

The xacml:Response element has the = ability to return both a decision, but additionally information about = why a decision was not made.

=0A=

The schema for the xacml:Response = element is reproduced here for convenience:

=0A= 
=0A=
<xs:element name=3D"Response" type=3D"xacml:ResponseType"/>=0A=
<xs:complexType name=3D"ResponseType">=0A=
  <xs:sequence>=0A=
    <xs:element ref=3D"xacml:Result" maxOccurs=3D"unbounded"/>=0A=
  </xs:sequence>=0A=
</xs:complexType>=0A=
=0A=
<xs:element name=3D"Result" type=3D"xacml:ResultType"/>=0A=
<xs:complexType name=3D"ResultType">=0A=
  <xs:sequence>=0A=
    <xs:element ref=3D"xacml:Decision"/>=0A=
    <xs:element ref=3D"xacml:Status" minOccurs=3D"0"/>=0A=
    <xs:element ref=3D"xacml:Obligations" minOccurs=3D"0"/>=0A=
    <xs:element ref=3D"xacml:AssociatedAdvice" minOccurs=3D"0"/>=0A=
    <xs:element ref=3D"xacml:Attributes" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    <xs:element ref=3D"xacml:PolicyIdentifierList" =
minOccurs=3D"0"/>=0A=
  </xs:sequence>=0A=
</xs:complexType>=0A=
=0A=

The xacml:Response element consists of = one child the Result.

=0A=

The xacml:Response element consists of = the following elements:

=0A=
=0A=
xacml:Decision
=0A=
is a mandatory element that returns the = possible decisions of the access control decision. The set of permitted = values are Permit, Deny, Indeterminate and No Policy.
=0A=
xacml:Status
=0A=
is an optional element returned for the = Indeterminate status which provides for the reason that a decision was = not able to be reached. Additionally it can contain hints for remedying = the situation. This document defines an additional set of status values = to be returned. Formal declaration may be found in Section 15.
    =0A=
  • gss-api indicates that a gss-api message has been returned as = part of the authentication process.
    • =0A=
=0A=

=0A=
=0A=
xacml:Obligations
=0A=
is designed to force the PEP to perform = specific actions prior to allowing access to the resource. If a response = is returned with this element present, the processing MUST fail unless = the PEP can perform the required action. A set of Plasma specific = obligations are found in Section 10.2. = [CREF9]Trevor: What = about audit obligatiouns=0A= =0A=
=0A=
xacml:AssocatedAdvice
=0A=
is designed to give suggestions to the = PEP about performing specific actions prior to allowing access to the = resource. This element is not used by Plasma and SHOULD be absent. If = the response is returned with this element present, processing will = succeed even if the PEP does not know how to perform the required = action. A set of Plasma specific advice elements are found in Section 10.2.
=0A=
xacml:Attributes
=0A=
provides a location for the server to = return attributes used in the access control evaluation process. Only = those attributes requested in the Attributes section of the request are = to be returned. Since Plasma does not generally supply attributes for = the evaluation process, this field will normally be absent.
=0A=
xacml:PolicyIdentifierList
=0A=
provides a location to return the set of = policies used to grant access to the resource. This element is expected = to be absent for Plasma. [CREF10]Trevor: Should we ignore it if present?=0A= =0A= [CREF11]JLS: I = don't think we need to say anything about looking at it or ignoring it. = While it would be something for debugging, as a general rule the client = does not care which policies where evaluated and passed to grant = access.=0A= =0A=
=0A=
=0A=

=0A=

=0A= 7.=0A= Role Token and Policy = Acquisition=0A=

=0A=

In order to send an email using a Plasma = server, the first step is to obtain a role token that provides the = description of the labels that can be applied and the authorization to = send an email using one or more of the labels. The process of obtaining = the role token is designed to be a request/response round trip to the = Plasma server. In practice a number of round trips may be necessary in = order to provide all of the identity and attributes to the Plasma server = that are needed to evaluate the policies for the labels.

=0A=

When a Plasma server receives a role token = request from a client, it needs to perform a policy evaluation for all = of the policies that it arbitrates along with all of the options for = those policies. In general, the first time that a client requests a = role token from the server, it will not know the level of authentication = that is needed or the set of attributes that needs to be presented in = order to get the set of tokens. A server MUST NOT issue a role token = without first attempting to retrieve from an attribute source (either = the client or a back end server) all of the attributes required to check = all policies. Since the work load required on the server is expected to = be potentially extensive for creating the role token, it is expected = that the token returned will be valid for a period of time. This will = allow for the frequency of the operation to be reduced. While the use = of an extant role token can be used for identity proof, it is not = generally suggested that a new token be issued without doing a full = evaluation of the attributes of the client as either the policy or the = set of client attributes may have changed in the mean time.

=0A=

=0A= 7.1.=0A= Role Token = Request=0A=

=0A=

The process starts by a client sending a = server a role token request. Generally, but not always, the request = will include some type of identity proof information and a set of = attributes. It is suggested that, after the first successful = conversation, the client cache hints about the identity and attributes = needed for a server. This allows for fewer round trips in later = conversations. An example of a request token can be found in Appendix B.

=0A=

The role token request, as with all = requests, uses the eps:PlasmaRequest XML structure. The = eps:Authentication MAY be included on the first message and MUST be = included on subsequent authentication round trips.

=0A=

A role token request by a client MUST = include the GetRoleTokens Plasma action request as an attribute of the = xacml:Request element. Details on the action can be found in section Section 15.1. When role tokens are requested, = no additional data needs to be supplied by the requester.

=0A=

An example of a message requesting the = set of policy information is:

=0A= 
=0A=
<esp:PlasmaRequest>=0A=
  <eps:Authentication>...</eps:Authentication>=0A=
  <xacml:Request>=0A=
    <xacml:Attributes Category=3D"...:action">=0A=
      <xacml:Attribute AttributeId=3D"urn:plasma:action-id">=0A=
        <xacml:AttributeValue=0A=
           DataType=3D"http://www.w3.org/2001/XMLSchema#string">=0A=
          GetRoleToken</xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
  </xacml:Request>=0A=
</esp:PlasmaRequest>=0A=
=0A=

=0A= 7.2.=0A= Request = Role Token Response=0A=

=0A=

In response to a role token request, the = Plasma server returns a role token response. The response uses the = eps:PlasmaResponse XML structure. When a response is create the = following should be noted:

=0A=

An xacml:Decision is always included in = a response. The values permitted are:

=0A=
=0A=
Permit
=0A=
is used to signal success. In this case = the response MUST include one or more eps:RoleToken element.
=0A=
Deny
=0A=
is used to signal failure. In this case = the xacml:Status element MUST be present an contain a failure = reason.
=0A=
Indeterminate
=0A=
is used to signal that a final result = has not yet been reached. When this decision is reached, the server = SHOULD return a list of additional attributes to be returned and SHOULD = return the list of role tokens that have been granted based on the = attributes received to that point.
=0A=
NotApplicable
=0A=
is returned if the Plasma server does = not have the capability to issue role tokens.
=0A=
=0A=

=0A= 
=0A=
<eps:PlasmaResponse>=0A=
  <xacml:Response>=0A=
    <xacml:Result>=0A=
      <xacml:Decision>Permit</xacml:Decision>=0A=
    </xacml:Result>=0A=
  </xacml:Response>=0A=
  <eps:PlasmaTokens>=0A=
    <eps:PlasmaToken>=0A=
      <eps:PolicyList>=0A=
        <eps:Policy>=0A=
          Details of a policy=0A=
        </eps:Policy>=0A=
        ... More policies ...=0A=
        <wst:RequestSecurityTokenResponse>=0A=
          =
<wst:TokenType>urn:...:plasma:roleToken</wst:TokenType>=0A=
          =
<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>=0A=
        </wst:RequestSecurityTokenResponse>=0A=
      </eps:PolicyList>=0A=
    </eps:PlasmaToken>=0A=
  </eps:PlasmaTokens>=0A=
</eps:PlasmaResponse>=0A=
=0A=

An example of a response returning the = set of policy information is:

=0A=

The process of getting role tokens has a = problem that is not part of the normal XACML design. It is possible to = compute a partial result based on the current set of attributes that = have been supplied by the client, while having other role tokens that = cannot be provided to the client since required attributes have not been = provided. Since this is not part of the standard XACML model, one only = has a single access/deny decision and if the attributes have not been = provided then the response would be deny, we need to look at it in a bit = more detail here.

=0A=

In the process of discussions three = different solutions to the problem were considered:

=0A=
    =0A=
  • A signal could be added that allows for the client to signal that = it cannot provide any more attributes to the server. This would allow = for a final decision to be provided, but would potentially involve an = additional round trip as the set of attributes can be determined based = on the set of attributes provided. Supplying new attributes from the = client can result in the server asking for new attributes from the = client. This is not currently supported by the XACML model and there is = no clear point where it would go into our model.
    • =0A=
  • The server can return a partial result on each round trip. This = maps directly onto the XACML model, but leads to some other problems. = It means that all of the policies must be designed such that adding a = new attribute to the policy evaluation process will not cause a policy = that previously had been permitted is now denied.
    • =0A=
  • A method could be added that allows for the client to state that = it either does not have or does not know what an attribute is. This = method would allow for the server to make a definitive answer, but it = requires that one extra round trip be made to get the final answer. =
    • =0A=
=0A=

=0A=

The normal mode that Plasma servers are = expected to operate in is returning incremental results, however they = can also keep internal state looking at what additional attributes are = being provided by the client. If the client provides no new attributes, = then the server can return a set of role tokens close down the = conversation. If the server expects to get all attributes from the back = end, and just get authentication from client, then it can return a set = of role tokens immediately without providing a list of attributes to the = client for it to try and satisfy.

=0A=

=0A= 7.2.1. RoleToken XML element

=0A=

The eps:PlasmaReturnToken element is = used to return a role token to the client. Multiple role tokens can be = returned by using multiple eps:PlasmaReturnToken elements. Each role = token returned contains one or more policies that can be asserted, the = role token, and optionally one or more set of obligations or advice that = need to be observed when creating messages. Additionally the name of a = Plasma server to be used with the token can be included as well as = cryptographic information to be used with the token.

=0A=

The schema used for the PlasmaTokens = element is:

=0A= 
=0A=
  <xs:element name=3D"RoleToken" type=3D"eps:RoleTokenType"/>=0A=
  <xs:complexType name=3D"RoleTokenType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"FriendlyName" type=3D"xs:string"/>=0A=
      <xs:element name=3D"PDP" type=3D"xs:anyURI" =
maxOccurs=3D"unbounded"/>=0A=
      <xs:choice>=0A=
        <xs:element name=3D"PolicyList">=0A=
          <xs:complexType>=0A=
            <xs:sequence>=0A=
              <xs:element name=3D"Policy" type=3D"eps:PolicyDescType" =
maxOccurs=3D"unbounded"/>=0A=
            </xs:sequence>=0A=
          </xs:complexType>=0A=
        </xs:element>=0A=
        <xs:element ref=3D"eps:Policy"/>=0A=
        <xs:element ref=3D"eps:PolicySet"/>=0A=
      </xs:choice>=0A=
      <xs:element ref=3D"wst:RequestSecurityTokenResponse"/>=0A=
      <xs:element ref=3D"xacml:Obligations" minOccurs=3D"0"/>=0A=
      <xs:element ref=3D"xacml:AssociatedAdvice" minOccurs=3D"0"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:complexType name=3D"PolicyDescType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"FriendlyName" type=3D"xs:string"/>=0A=
      <xs:element name=3D"Options" minOccurs=3D"0">=0A=
        <xs:complexType>=0A=
          <xs:complexContent>=0A=
            <xs:extension base=3D"xs:anyType">=0A=
              <xs:attribute name=3D"optionsType" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
            </xs:extension>=0A=
          </xs:complexContent>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"PolicyId" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
  </xs:complexType>=0A=
=0A=

The eps:RoleToken element contains the = following items:

=0A=
=0A=
FriendlyName
=0A=
This element returns a descriptive name = of the role as a whole. The string returned SHOULD be selected based on = the language attribute on the request message. The string is suitable = for display to the user and should be indicative of the scope of the = role. Examples of role descriptive strings would be "Company = President", "Senior Executive", "Project X Electrical Engineer".
=0A=
PDP
=0A=
The element provides one or more URLs to = be used for contacting a Plasma server for the purpose of sending a = message. This element allows for the use of different Plasma servers = for issuing role tokens and message tokens. No ranking of the servers = is implied by the order of the URLs returned.[CREF12]JLS: Should perhaps rename = to be more understandable - perhaps Server=0A= =0A=
=0A=
PolicyList
=0A=
contains the description of one or more = policies that can be asserted using the issued role token. Any of the = policies contained in the list may be combined together using the policy = logic in constructing a label during the send message process.
=0A=
Policy
=0A=
contains a single simple policy. This = element is returned as part of a read message token. The purposes is to = allow for a recipient to reply to a message that they would not normally = be able to assert.
=0A=
PolicySet
=0A=
contains a complex policy. This element = is returned as part of a read message token The purpose is to allow for = a recipient to reply to a message that they would not normally be able = to assert.
=0A=
wst:RequestSecurityTokenResponse
=0A=
contains the actual token itself.
=0A=
xacml:Obligations
=0A=
This optional element contains a set of = obligations that the client is required to enforce in order to use any = of the policies listed when combined with the returned security token. = These obligations can include items such as required algorithms or = required operational steps such as requiring a signature to be placed on = the content. A policy can be listed in multiple role tokens and the set = of obligations may be different depending on which role token is used. = If the client is unable to fulfill the obligations then it MUST NOT = allow the role token to be used.
=0A=
xacml:AssociatedAdvice
=0A=
This optional element contains a set of = advice statements that the client is requested to enforce when using any = of the policies listed when combined with the returned security token. = This advice can include items such as encryption or signature algorithms = or operational steps such as requiring a signature to be placed on the = content. The client is SHOULD fulfill the advice, however if it cannot = fulfill the advice the role token may still be used.
=0A=
=0A=

=0A=

The eps:PolicyType type is used to = represent the elements of a policy to the client. The elements in this = type are:

=0A=
=0A=
FriendlyName
=0A=
contains a display string that = represents the policy. This element is localized in response to the = xs:lang attribute in the eps:PlasmaRequest node.
=0A=
PolicyId
=0A=
contains a "unique" identifier for the = policy. This is the value that identifies the policy to the software. = The type for the value is defined as a URI.
=0A=
Options
=0A=
This element is used to inform the = client what the set of options that need to be filled in as part of = asserting the policy. If the client software does not understand how to = set the options for the supplied type, then the client software MUST NOT = allow the user to assert the policy. The option structure is identified = by the URI in the optionsType attribute. This document defines one = option structure for holding a list of email addresses (section Section 7.2.2). This option structure is = used in the basic policies defined in [PlasmaBasicPolicy].
=0A=
=0A=

=0A=

When building the = wst:RequestSecurityTokenResponse element, the following should be noted: =

=0A=
    =0A=
  • A wst:RequestedSecurityToken element containing the security = token MUST be included. The format of the security token is not = specified and is implementation specific, it is not expected that = clients should be able to get useful information from the token itself. = Information such as lifetimes need to be provided as addition elements = in the response. Examples of items that could be used as security = tokens are SAML statements or encrypted record numbers in a server = database.
    • =0A=
  • A wst:Lifetime giving the life time of the token SHOULD be = included. It is not expected that this should be determinable from the = token itself and thus must be independently provided. There is no = guarantee that the token will be good during the lifetime as it may get = revoked due to changes in the environment (for example, if the policies = are updated then all existing tokens may need to be re-issued), however = the client is permitted to act as if it were. The token provided may be = used for duration. If this element is absent, it should be assumed that = the token is either a one time token or of limited duration.
    • =0A=
  • Talk about cryptographic information - There are three different = types of crypto information that can be returned and we need to figure = out how to talk about them. These are 1) a symmetric key, 2) a new = asymmetric key and 3) a pre-existing asymmetric key - for example from = the certificate used for authentication purposes. There is probably = good ways to do 1 and 2, but I don't know how to talk about 3 at this = point in time.
    • =0A=
=0A=

=0A=

=0A= 7.2.2.=0A= Email Address List = Options=0A=

=0A=

Some policies are designed to be = restricted to a set of explicitly named people by the sender of the = message. This policy is used for the set of basic policies defined in = [PlasmaBasicPolicy]. In these cases = the creator of the message specifies a set of recipients by using email = address names without any decoration.

=0A=

The Email Address List Option is = identified by the uri = "urn:ietf:params:xml:ns:plasma:options:emailAddrs". The type associated = with the structure is a string. The string contains a space separated = set of internalized email addresses. Domains SHOULD be encoded as = U-labels rather than using puny code.

=0A=

All Plasma clients and servers MUST be = able to create, parse and use the Email Address List Option for any = policy.

=0A=

As of the release of this document, = Plasma clients and servers are not expected to understand any other = options.

=0A=

=0A= 8.=0A= Sending An Email=0A=

=0A=

After having obtained a role token from a = Plasma server, the client can then prepare to send an Email by = requesting a message token from the Plasma server. As part of the = preparatory process, the client will construct the label to be applied = to the Email from the set of policies that it can assert, determine the = optional elements for those policies which have options, generate the = random key encryption key and possible create the key recipient = structures for the email. Although this section is written in terms of = a CMS Encrypted message, there is nothing to prevent the specification = of different formats and still use this same basic protocol. An example = of a send mail request token can be found in Appendix D.

=0A=

=0A= 8.1.=0A= Send = Message Request=0A=

=0A=

The send message request is built using = the eps:PlasmaRequest XML structure. When building the request, the = following applies:

=0A=
    =0A=
  • The eps:Authentication element MUST be included in the initial = message. The role token that authorizes the use of the label MUST be = included in the initial message. If the role token is dependent on a = cryptographic key for authentication, then that authentication MUST be = included in the initial message.
    • =0A=
  • The client MUST include an action attribute. This document = defines the GetSendCMSToken action attribute for this purpose.
    • =0A=
  • The client MUST include a data attribute. This attribute = contains the information that is used to build the CMS Message token to = be returned. There MAY be more than one data attribute, but this will = not be a normal case. More details on this attribute are in Section 8.1.1.
    • =0A=
  • If the client is using the XML Digital Signature element in this = message, then the client MUST include the cryptographic channel binding = token (Section 10.1.1) in the set of XACML = attributes.
    • =0A=
=0A=

=0A= 
=0A=
<eps:PlasmaRequest>=0A=
  <eps:Authentication>=0A=
    <eps:WS_Token>=0A=
      Role Token goes here=0A=
    </eps:WS_Token>=0A=
    <xacml:Request>=0A=
      <xacml:Attributes Category=3D"...:action">=0A=
        <xacml:Attribute AttributeId=3D"urn:plasma:action-id">=0A=
          <xacml:AttributeValue>=0A=
            GetSendCMSToken=0A=
          </xacml:AttributeValue>=0A=
        </xacml:Attribute>=0A=
      </xacml:Attributes>=0A=
      <xacml:Attributes Category=3D"...:data">=0A=
        <xcaml:Attribute AttributeId=3D"urn:plasma:data-id">=0A=
          <xacml:AttributeValue>=0A=
            Label and keys=0A=
          </xacml:AttributeValue>=0A=
        </xcaml:Attribute>=0A=
      </xacml:Attributes>=0A=
    </xacml:Request>=0A=
  </eps:Authentication>=0A=
</eps:PlasmaRequest>=0A=
=0A=

A message requesting that a CMS message = token be created looks like this:

=0A=

=0A= 8.1.1.=0A= CMS = Message Token Data Structure=0A=

=0A=

The message token data structure is = used as an attribute to carry the necessary information to issue a CMS = message token. The schema that describes the structure is:

=0A= 
=0A=
  <xs:element name=3D"GetCMSToken" =
type=3D"eps:CMSTokenRequestType"/>=0A=
  <xs:complexType name=3D"CMSTokenRequestType">=0A=
    <xs:sequence>=0A=
      <xs:choice>=0A=
        <xs:element ref=3D"eps:Policy"/>=0A=
        <xs:element ref=3D"eps:PolicySet"/>=0A=
      </xs:choice>=0A=
      <xs:element name=3D"Hash">=0A=
        <xs:complexType>=0A=
          <xs:sequence>=0A=
            <xs:element ref=3D"ds2:DigestMethod"/>=0A=
            <xs:element ref=3D"ds2:DigestValue"/>=0A=
          </xs:sequence>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
      <xs:element name=3D"LockBox" type=3D"eps:LockBoxType" =
minOccurs=3D"0" maxOccurs=3D"unbounded"/>=0A=
      <xs:element name=3D"CEK" type=3D"xs:hexBinary" =
minOccurs=3D"0"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"LockBox" type=3D"eps:LockBoxType"/>=0A=
  <xs:complexType name=3D"LockBoxType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"Subject" maxOccurs=3D"unbounded">=0A=
        <xs:complexType>=0A=
          <xs:simpleContent>=0A=
            <xs:extension base=3D"xs:anySimpleType">=0A=
              <xs:attribute name=3D"type" type=3D"xs:string" =
use=3D"required"/>=0A=
            </xs:extension>=0A=
          </xs:simpleContent>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
      <xs:element name=3D"CMSLockBox" type=3D"xs:base64Binary"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
=0A=

When used in an xacml:Attribute, the = structure is identified by:
=0A=
Category =3D "urn:ietf:params:xml:ns:plasma:data"
= AttributeId =3D "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest"
DataType =3D = "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenRequestType"

=0A=

The elements of the structure are used = as:

=0A=
=0A=
Policy
=0A=
=0A=
This element contains a the policy to be applied to the = message when a single policy is used.
=0A=
PolicySet
=0A=
=0A=
This element contains the policy to be applied to the message = when a combination of policies is to be applied.
=0A=
Hash
=0A=
=0A=
This element contains the hash of the encrypted content of = the message that the policy is being applied to. The algorithm used to = compute the hash is contained in the DigestMethod element and the value = is contained in the DigestValue element.
=0A=
LockBox
=0A=
=0A=
This optional element contains a pre-computed CMS recipient = info structure for a message recipient. This element may be repeated = when more than one lock box is pre-computed for recipients by the = message sender. This element is used in those cases where the sender = does not want to share the content encryption key with the Plasma server = and the sender has the ability to retrieve the necessary keys for all of = the recipients. If the #### obligation was returned for the role token, = then a recipient info lock box MUST be created for the Plasma server and = the CEK element MUST absent. [CREF13]JLS: Do we define this = obligation or remove the previous sentence?=0A= =0A=
=0A=
CEK
=0A=
=0A=
This optional element contains the content encryption key = (CEK) to decrypt the message.
=0A=
=0A=

One or both of CEK and Recipients elements MUST be present.

=0A=

The elements of the LockBoxType = structure are:

=0A=
=0A=
Subject
=0A=
=0A=
This element contains a subject identifier. The element can = occur more than one time in situations where a subject has multiple = names or a key is used by multiple subjects. Since a CMS recipient info = structure does not contain a great deal of information about the = recipient, this element contains a string which can be used to identify = the subject. The format of the subject name is provided by the required = type attribute of the element. All implementations MUST recognize = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" as a name type. = [CREF14]JLS: Call = for other mandatory to implement name types=0A= Other name types MAY be recognized.
=0A=
CMSLockBox
=0A=
=0A=
This element contains a base64 encoded CMS Recipient Info = structure. If the recipient info structure is placed here, it MUST NOT = be placed in the CMS EnvelopedData structure as well.
=0A=
=0A=

=0A=

=0A= 8.1.2.=0A= XML Label Structure=0A=

=0A=

A client is allowed to build a complex = label to be sent to the Plasma server for evaluation. While there are = some cases that a simple single policy is applied to a message, it is = expected that many, if not most, messages will have more than one policy = applied to it with logical statements connected those policies.

=0A= 
=0A=
  <xs:element name=3D"PolicySet" type=3D"eps:PolicySetType"/>=0A=
  <xs:complexType name=3D"PolicySetType">=0A=
    <xs:sequence>=0A=
      <xs:choice maxOccurs=3D"unbounded">=0A=
        <xs:element ref=3D"eps:Policy"/>=0A=
        <xs:element ref=3D"eps:PolicySet"/>=0A=
      </xs:choice>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"PolicyCombiningAlgId" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"Policy" type=3D"eps:PolicyType"/>=0A=
  <xs:complexType name=3D"PolicyType">=0A=
    <xs:sequence>=0A=
      <xs:any namespace=3D"##any" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"PolicyId" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
  </xs:complexType>=0A=
=0A=

The schema for specifying a label is: =

=0A=

The Policy and the PolicySet elements = are used when specifying a policy for a message depending on whether a = single policy or multiple policies are to be evaluated.

=0A=

The Policy element is used to specify = a single policy to the server along with any options that are defined = for that policy. The Policy element contains:

=0A=
=0A=
PolicyId
=0A=
=0A=
Is an attribute that contains the URI which identifies a = specific policy to be evaluated.
=0A=
inner content
=0A=
=0A=
The content of the Policy element can be any XML element. = The content is to be the set of selected options for the policy (if any = exist). The schema applied to the content is based on the policy = selected.
=0A=
=0A=

=0A=

The PolicySet element is used to = specify a logical set of policies to be applied to the message. This = element allows one to specify multiple policies along with a logic = operation to combine them together.

=0A=
=0A=
Policy
=0A=
=0A=
This element allows for a single policy and any policy = specific options for the policy to be specified. This element can occur = zero or more times.
=0A=
PolicySet
=0A=
=0A=
This element allows for a logical set of policies to be = recursively evaluated. This element can occur zero or more times.
=0A=
PolicyCombiningAlgId
=0A=
=0A=
This attribute specifies the operation to be used in = combining the elements of the tree together. This specification uses = the XACML policy combining algorithms from [XACML]. Servers and clients MUST support the = unordered Deny-Overrides and Permit-Overrides policy combining rules. = Servers SHOULD support all of the policy combining rules defined in [XACML]. Clients are expected to use a friendly = name when displaying the policy combining rule to users. When = displaying strings to users, the following strings are suggested:
=0A=
AND
=0A=
Is used to represent either the = ordered or unordered Deny-Overrides combining algorithm.
=0A=
OR
=0A=
Is used to represent either the = ordered or unordered Permit-Overrides combining algorithm.
=0A=
=0A=

=0A=
=0A=
=0A=

=0A=

=0A= 8.2.=0A= Send = Message Response=0A=

=0A=

In response to a send message request, = the Plasma server returns a send message response message. The response = messages uses the eps:PlasmaResponse XML structure. When the response = message is created, the following should be noted:

=0A=
    =0A=
  • The xacml:Decision is always included in the response. If the = 'Permit' value is returned then a CMS Token Response element MUST be = present.
    • =0A=
  • The PlasmaReturnToken element with a eps:CMSToken content is = included with a permit response. The CMSToken contains one or more CMS = RecipientInfo objects to be included in the message sent.
    • =0A=
=0A=

=0A= 
=0A=
<eps:PlasmaResponse>=0A=
  <xacml:Response>=0A=
    <xacml:Result>=0A=
      <xacml:Decision>Permit</xacml:Decision>=0A=
    </xacml:Result>=0A=
  </xacml:Response>=0A=
  <eps:CMSToken>234e34d3</eps:CMSToken>=0A=
</eps:PlasmaResponse>=0A=
=0A=

An example of a message returning the = set of policy information is:

=0A=

The schema use for returning a CMS token = is:

=0A= 
=0A=
  <xs:element name=3D"CMSToken" type=3D"eps:CMSTokenResponseType"/>=0A=
  <xs:complexType name=3D"CMSTokenResponseType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"CMSLockBox" maxOccurs=3D"unbounded">=0A=
        <xs:complexType>=0A=
          <xs:simpleContent>=0A=
            <xs:extension base=3D"xs:base64Binary">=0A=
              <xs:attribute name=3D"CMSType" type=3D"xs:string"/>=0A=
            </xs:extension>=0A=
          </xs:simpleContent>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
=0A=

This schema fragment extends the Plasma = response token type and allows for the return of one or more base64 = encoded RecipientInfo structures. The Plasma server can return = recipient info information for any recipient that it pre-authorizes to = receive the message (see Section ### of [I-D.freeman-plasma-requirement= s] for examples of when this would occur). Additionally the Plasma = server can return a KEKRecipientInfo structure with the Plasma Other Key = attribute. (For details see [I-D.schaad-plasma-cms].) In some = extremely rare cases where the Plasma server can pre-authorize the = entire set of recipients , the KEKRecipientInfo structure with the = Plasma Other Key Attribute may not be included in the returned set of = recipients. The recipient info structure for the plasma server SHOULD = be placed last in the list of recipients infos.

=0A=

The CMSTokenResponse type has the = following:

=0A=
=0A=
CMSLockBox
=0A=
=0A=
This element contains the ASN.1 encoding for a CMS = RecipientInfo structure to be placed in the final message. This element = will occur multiple times if there are multiple CMS RecipientInfo = structures being returned from the server.
=0A=
CMSType
=0A=
=0A=
This attribute of the RecipientInfo structure is an optional = text value that identifies the type of recipient info structure = returned. NOTE: This attribute is currently optional and is likely to = disappear if I do not find it useful.
=0A=
=0A=

=0A=

=0A= 9.=0A= Decoding A Message=0A=

=0A=

When the receiving agent is ready to = decrypt the email, it identifies that there is a KEKRecipientInfo object = which contains a key attribute identified by id-keyatt-eps-token. It = validates the signature, determines that communicating with the Plasma = Service is within local policy, and then sends a request to the service = to obtain the decryption key for the message.

=0A=

In some cases the recipient of a message = is not authorized to use the same set of labels for sending a message. = For this purpose a token can be returned in the message along with the = key so that recipient of the can reply to the message using the same set = of security labels.

=0A=

=0A= 9.1.=0A= Requesting Message Key=0A=

=0A=

The client sends a request to the Plasma = server that is identified in the token. For the CMS base tokens, the = address of the Plasma server to use is defined in [I-D.schaad-plasma-cms] this is = located in the aa-eps-url attribute.

=0A=

The request uses the eps:PlasmaRequest = XML structure. When building the request, the following should be = noted:

=0A=
    =0A=
  • The xacml:Request MUST be present in the first message of the = exchange.
    • =0A=
  • The action used to denote that a CMS token should be decrypted is = "ParseCMSToken".
    • =0A=
  • The CMS token to be cracked is identified by "CMSToken"
    • =0A=
  • In the event that a reply to role token is wanted as well, then = that is supplied as a separate action. [CREF15]jls: We may want to require = that a reply token always be returned instead of just returning it on = demand.=0A= In this case the action is "GetReplyToken".
    • =0A=
  • If the client is using the XML Digital Signature element in this = message, then the client MUST include the cryptographic channel binding = token (Section 10.1.1) in the set of XACML = attributes.
    • =0A=
=0A=

=0A= 
=0A=
<eps:PlasmaRequest>=0A=
  <eps:Authentication>...</eps:Authentication>=0A=
  <xacml:Request>=0A=
    <xacml:Attributes Category=3D"...:action">=0A=
      <xacml:Attribute AttributeId=3D"..:action-id">=0A=
        =
<xacml:AttributeValue>ParseCMSToken</xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
    <xacml:Attribute Category=3D"...:data">=0A=
      <xacml:Attribute AttreibuteId=3D"..:data-id">=0A=
        <xacml:AttributeValue>=0A=
          Hex encoded CMS Token Value=0A=
        </xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attribute>=0A=
  </xacml:Request>=0A=
</eps:PlasmaRequest>=0A=
=0A=

An example of a message returning the = set of policy information is:

=0A=

When used in an xacml:Attribute, the = structure is identified by:
=0A=
Category =3D "urn:ietf:params:xml:ns:plasma:data"
= AttributeId =3D "urn:ietf:params:xml:ns:plasma:data:CMSToken"
= DataType =3D "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenResponseType =

=0A=

=0A= 9.2.=0A= Requesting Message Key Response=0A=

=0A=

In response to a message key request, = the Plasma server returns a decrypted key in the message key response. = The response message uses the eps:Plasma XML structure. When a response = message is create the following should be noted:

=0A=
    =0A=
  • If the value of xacml:Decision is Permit, then response MUST = include an eps:CMSKey element.
    • =0A=
  • For all other decision types the eps:CMSKey MUST be absent.
    • =0A=
  • If a reply token was requested and granted, then the response = MUST include an eps:PlasmaToken element. The eps:PlasmaToken element = MUST use the Label option
    • =0A=
=0A=

=0A= 
=0A=
<eps:PlasmaResponse>=0A=
  <xacml:Response>=0A=
    <xacml:Result>=0A=
      <xacml:Decision>Permit</xacml:Decision>=0A=
    </xacml:Result>=0A=
  </xacml:Response>=0A=
  <eps:CMSKey>=0A=
    <eps:DisplayString>Label TExt</eps:DisplayString>=0A=
    <eps:KEK>hex based KEK</eps:KEK>=0A=
  </eps:CMSKey>=0A=
</eps:PlasmaResponse>=0A=
=0A=

An example of a message returning the = set of policy information is:

=0A=

The schema for returning the decrypted = key is:

=0A= 
=0A=
  <xs:element name=3D"CMSKey" type=3D"eps:CMSKeyResponseType"/>=0A=
  <xs:complexType name=3D"CMSKeyResponseType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"DisplayString" type=3D"xs:string"/>=0A=
      <xs:choice>=0A=
        <xs:element name=3D"CEK" type=3D"xs:base64Binary"/>=0A=
        <xs:element name=3D"CMSLockBox" type=3D"xs:base64Binary"/>=0A=
      </xs:choice>=0A=
      <xs:element ref=3D"eps:RoleToken" minOccurs=3D"0"/>=0A=
      <xs:element ref=3D"xacml:Attributes" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
=0A=

This schema extends the Plasma response = token type and restricts the content to the listed elements. The values = returned are:

=0A=
=0A=
DisplayString
=0A=
returns a localized display string for = the policy(s) which were applied to the message. The lang attribute on = the request is used to determine which language to use for this = string.
=0A=
CEK
=0A=
returns the base64 encoded content = encryption key.
=0A=
CMSLockBox
=0A=
returns the content encryption key in = the form of a CMS RecipientInfo structure.
=0A=
RoleToken
=0A=
optionally returns a role token for = replying to this message.
=0A=
Attributes
=0A=
optionally returns a set of attributes = associated with the message.
=0A=
=0A=

=0A=

=0A= 10. Plasma Attributes

=0A=

In this document a number of different = XACML attributes have been defined, this section provides a more = detailed description of these elements.

=0A=

=0A= 10.1. Data Attributes

=0A=

=0A= 10.1.1.=0A= Channel Binding Data = Attribute=0A=

=0A=

The channel binding data attribute is = used to provide for a binding of the TLS session that is being used to = transport the Plasma messages with the content of the Plasma requests = themselves. There is a need for the server to be able to validate that = the cryptographic operations related to holder of key statements be made = specifically for the current conversation and not be left over from a = previous one as a replay attack. By deriving a cryptographic value from = the shared TLS session key and signing that value we are able to do so. =

=0A=

The channel binding value to be used = is created by the TLS key exporter specification defined in RFC 5705 [RFC5705]. This allows for a new cryptographic = value to be derived from the existing shared secret key with additional = input to defined the context in which the key is being derived. When = using the exporter, the label to be input into the key exporter is = "EXPORTER_PLASMA". The value to be derived is 512 bits in length, and = no context is provided to the exporter.

=0A=

When used as an XACML attribute in a = request:

=0A=
    =0A=
  • The category of the attribute is = "urn:ietf:params:xml:ns:plasma:data".
    • =0A=
  • The AttributeId attribute is = "urn:ietf:params:xml:ns:plasma:data:ChannelBinding".
    • =0A=
  • The Issuer attribute is absent.
    • =0A=
  • The DataType is either base64Binary or hexBinary
    • =0A=
=0A=

=0A=

The same value is used for both the = XACML channel binding data attribute and the XM1L channel binding = structure defined in Section 5.1.3.

=0A=

=0A= 10.1.2.=0A= CMS Signer Info Data = Attribute=0A=

=0A=

In many cases a policy states that = the client is required to sign the message before encrypting it. The = server cannot verify that a signature is applied to the message and = included, but we can require that a signature be supplied to the server. = This signature can then be validated by the server (except for the = message digest attribute value), and the server can take a hash of the = value and return it as part of the key returned to a decrypting agent. = This agent can then validate that the signature is a part of the message = and complain if it absent. This means we do not have an enforcement = mechanism, but we do have a way of performing an audit at a later time = to see that the signature operation was carried out correctly.

=0A=

By requiring that a signature be = supplied to the server as part of the authentication process, the Plasma = server can also be setup so that the supplied signature is automatically = feed into archival operations. One way to do archiving is to use the = data records defined in [RFC4998].

=0A=

The following applies when this data = value is present:

=0A=
    =0A=
  • The Category attribute is = "urn:ietf:params:xml:ns:plasma:data".
    • =0A=
  • The AttributeId attribute is = "urn:ietf:params:xml:ns:plasma:data:CMSSignerInfo".
    • =0A=
  • The Issuer attribute is absent.
    • =0A=
  • The DataType attribute is either base64Binary or hexBinary.
    • =0A=
  • The data value is a CMSSignerInfo ASN.1 encoded object.
    • =0A=
=0A=

=0A=

=0A= 10.1.3.=0A= S/MIME Capabilities Data = Attribute=0A=

=0A=

Policies sometimes require that = specific algorithms be used in order to meet the security needs of the = policy. This attribute allows for an S/MIME Capabilities to be carried = in a DER encoded SMIMECapabilities ASN.1 structure to be transmitted to = the client. Details on how the S/MIME Capabilities function can be = found in [RFC5751].

=0A=

The following attributes are to be = set for the data value:

=0A=
    =0A=
  • The Category attribute is = "urn:ietf:params:xml:ns:plasma:data".
    • =0A=
  • The AttributeId attribute is = "urn:ietf:params:xml:ns:plasma:data:SMIME-Capabilties".
    • =0A=
  • The Issuer attribute is absent.
    • =0A=
  • The DataType attribute is either base64binary or hexBinary.
    • =0A=
=0A=

=0A=

=0A= 10.1.4.=0A= EMAIL Recipient = Addreses=0A=

=0A=

In order for Plasma Servers to do = pre-authentication in the Email environment, it is necessary for the set = of recipient addresses to be delivered to the Plasma Server. The Plasma = Server cannot reliably determine the set of recipients from the policies = set on the message as the set of recipients and the set of people = authorized to view the message may not have a one-to-one correspondance. = People may be authorized to see the content who are not recipients of = the message or visa versa.

=0A=

The content of the attribute is a = space separated list of email addresses. Each address represents an = Email recipient address that the client will be placing in one or more = of the recipient fields in the message submission.

=0A=

The following attributes are to be = set for the data value:

=0A=
    =0A=
  • The Category for the attribute is = "urn:ietf:params:xml:ns:plasma:data".
    • =0A=
  • The AttributeId for the attribute is = "urn:ietf:params:xml:ns:plasma:data:SMTPRecipients".
    • =0A=
  • The Issuer for the attribute is absent.
    • =0A=
  • The DataType for the attribute is = "http://www.w3.org/2001/XMLSchema#string".
    • =0A=
=0A=

=0A=

=0A= 10.1.5. Return Lockbox Key = Information

=0A=

Some policies require that the = content encryption key be transported wrapped by another key rather than = being sent in plain text. This data value allows for this state to be = indicated by the Plasma Server to the Plasma Client, and for the client = to provide the necessary key information to the server.

=0A=

This data attribute is returned as a = missing attribute under the circumstances where it is required by the = policy and has not been provided the client. This is an indication that = the content encryption key needs to be returned in a lock box rather = than as plain text. The Plasma Server MAY ignore this data value if it = is provided in a situation where the policy does not require that the = content encryption key be returned in an encrypted form.

=0A=

The following attributes are to be = set for this data value:

=0A=
    =0A=
  • The Category for the attribute is = "urn:ietf:params:xml:ns:plasma:data".
    • =0A=
  • The AttributeId for the attribute is = "urn:ietf:params:xml:ns:plasma:data:LockboxKey".
    • =0A=
  • The issue for the attribute is absent.
    • =0A=
  • The DataType for the attribute is = "urn:ietf:params:xml:schema:plasma:1.0LockboxKey".
    • =0A=
=0A=

=0A=

The schema for the type LockboxKey = is:

=0A= 
=0A=
  <xs:complexType name=3D"LockboxKey">=0A=
    <xs:sequence>=0A=
      <xs:choice>=0A=
        <xs:element name=3D"X509Certificate" =
type=3D"xs:base64Binary"/>=0A=
        <xs:element name=3D"PGPKey" type=3D"xs:base64Binary"/>=0A=
        <xs:element ref=3D"ds2:KeyInfo"/>=0A=
      </xs:choice>=0A=
      <xs:element name=3D"Capabilities" type=3D"xs:base64Binary" =
minOccurs=3D"0"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
=0A=

The fields of this structure are as = follows:

=0A=
=0A=
X509Certificate
=0A=
holds a certificate with the public key = to be used in building the CMS Lockbox returned containing the content = encryption key.
=0A=
PGPKey
=0A=
holds a PGP public key to be used in = building the PGP lock box returned containing the content encryption = key.
=0A=
ds2:KeyInfo
=0A=
holds a public key to be used in = building a CMS lock box returned containing the content encryption = key.
=0A=
Capabilities
=0A=
contains a base64 encoded = SMimeCapablities ASN.1 structure allowing the client to advertise to the = server which algorithms are supported for building the lockbox = structure. This element is optional. If the element is omitted then = the server will make the selection of algorithms to be used based solely = on the pubic key.
=0A=
=0A=

=0A=

=0A= 10.2.=0A= Obligations and = Advice=0A=

=0A=

Obligations and advice consist of = actions that the Plasma server either requires or requests that the = client PEP perform in order to gain access or before granting access to = the data. These normally represent actions or restrictions that the PDP = itself cannot enforce and thus are not input attributes to the policy = evaluation. The same set of values can be used either as obligations or = advice, the difference being that if the PEP cannot do an obligation it = is required to change the policy decision.

=0A=

=0A= 10.2.1. Signature Required

=0A=

Many policies require that a message = be signed before it is encrypted and sent. Since the unencrypted = version of message is not sent to the Plasma server, the policy cannot = verify that a signature has been placed onto the signed message. The = attribute is not for use as a returned obligation from an XACML = decisions, rather it is for a pre-request obligations used in role = responses (Section 7.2).

=0A=

When used as an Obligation:

=0A=
    =0A=
  • The ObligationId attribute is = "urn:ietf:params:xml:ns:plasma:obligation:signature-required".
    • =0A=
  • A S/MIME Capabilities data value can optionally be included. If = it is included, then it contains the set of S/MIME capabilities that = describes the set of signature algorithms from which the signature = algorithm for the message MUST be selected.
    • =0A=
=0A=

=0A=

=0A= 10.2.2. Content Encryption = Algorithm Required

=0A=

Occasionally a policy requires a = specific set of encryption algorithms be used for a message, when this = is the case then the encryption required obligation is included in the = returned set of obligations. If the default set of encryption = algorithms is sufficient then the obligation is omitted.

=0A=

When used as an Obligation:

=0A=
    =0A=
  • The ObligationId attribute is = "urn:ietf:params:xml:schema:plasma:1.0:obligation:content-encryption".=0A=
  • An S/MIME Capabilities data value MUST be included containing the = set of permitted encryption algorithms. The algorithms included MUST = include a sufficient set of algorithms for the message to be encrypted. = An absolute minimum would be a content encryption algorithm and key = encryption algorithm.
    • =0A=
=0A=

=0A=

=0A= 10.2.3. Lock Box Required

=0A=

This obligation will be used in one = of two situations:

=0A=
    =0A=
  1. The policy requires that the plain content encryption key not be = given to the Plasma server, but instead the Plasma client is required to = locate the appropriate certificates and create lock boxes for each of = the message recipients. In this situation, the Plasma server would = never have any access to the content encryption key and thus would be = unable to provide the key to any entity. The Plasma server in this case = is responsible only for the enforcement of the policy enforcement on the = message access.
    2. =0A=
  2. The policy requires that the content encryption key not be given = to the Plasma server as a base64 encoded blob, but instead the Plasma = client is required to use the provided certificate to create a lock box = for the Plasma server. In this situation, the Plasma server does have = access to the content encryption key and thus has the ability to do late = binding. The Plasma server is also still responsible for the = enforcement of the policy on message access.
    3. =0A=
=0A=

=0A=

When used as an Obligation:

=0A=
    =0A=
  • The ObligationId attribute is = "urn:ietf:params:xml:schema:plasma:1.0:obligation:lockbox-required".
    • =0A=
  • There is no data value when the client is required to create lock = boxes for every recipient, i.e. early binding.
    • =0A=
  • The data value is an X509 certificate when the Plasma client is = required to create a lock box for the Plasma server. The certificate = provided MUST have the Plasma CEK Transport EKU specified.
    • =0A=
=0A=

=0A=

=0A= 11. Certificate Profiles

=0A=

We need to put in text to express the = following items:

=0A=
    =0A=
  • DNS or IPAddr subject alt name to be present
    • =0A=
  • Have one of four EKUs
      =0A=
    • Plasma Token EKU - Signals that it can sign and/or encrypt a = plasma object
      • =0A=
    • Plasma Secure Session - Use for the TLS session
      • =0A=
    • Plasma CEK Transport - Used for transporting the CEK to the = server in high security situations
      • =0A=
    =0A=

    MUST NOT have the anyPolicy EKU set

    =0A=
    • =0A=
=0A=

=0A=

=0A= 12. Message Transmission

=0A=

Plasma messages are sent over a TCP = connection using port TBD1 on the server. The client first setups up = TLS on the connection, then sends the UTF8 encoded XML message over the = TLS connection as an atomic message. The XML MUST be encoded as UTF8, = however the Byte Order Mark (BOM) is sent. The response comes back on = the same connection. The client is responsible for closing the TLS = session and the TCP connection when either no more messages are to be = sent to the server or a final indeterminate state has been reached.

=0A=

If a Plasma server receives an XML = request which is not well formed XML, the server if free to close the = connection without first sending an error reply.

=0A=

The Plasma server SHOULD support TLS = resumption [RFC5077].

=0A=

Plasma clients and server MUST support = TLS 1.1 [RFC4346] and above. Implementations = SHOULD NOT allow for the use of TLS 1.0 or SSL.

=0A=

=0A= 13. Plasma URI Scheme

=0A=

=0A= 13.1. Plasma URI Schema Syntax

=0A=

The scheme name for is "plasma".

=0A=

The syntax for the plasma URI Schema = is:
=0A=
URI =3D "plasma" ":" "//" authority path-empty
=0A=
Using the ABNF defined in [RFC3986]. = When the port component is absent, then the value of TBD1 will be used. = The userinfo portion of the authority MUST be absent.

=0A=

=0A= 13.2. Definition of Operations

=0A=

This schema is defined to provide the = location of a Plasma server. The sole operation is to establish a = connection to the Plasma server over which the protocol defined in this = document is to run.

=0A=

=0A= 14. Security Considerations

=0A=

To be supplied after we have a better = idea of what the document looks like.

=0A=

=0A= 14.1. Plasma URI Schema = Considerations

=0A=

TBD

=0A=

=0A= 15.=0A= IANA Considerations=0A=

=0A=

We define the following name spaces

=0A=

New name space for the plasma documents = urn:ietf:params:xml:ns:plasma

=0A=

=0A= 15.1.=0A= Plasma Action Values=0A=

=0A=

A new registry is established for = Plasma server action identifiers using the tag "actions". The full urn = for the registry is "urn:ietf:params:xml:ns:plasma:actions". This = registry operates under a specification required policy. All entries in = this registry require the following elements:

=0A=
    =0A=
  • A string in camel case which identifies the action to be = performed.
    • =0A=
  • An optional XML data structure used to carry the control data for = the action.
    • =0A=
  • An optional XML data structure used to return the result of the = action from the server.
    • =0A=
  • A document reference describing the steps to be taken by the = server.
    • =0A=
=0A=

=0A=

The registry will be initially = populated with the following:

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Action IdInput StructureOutput Structure
GetRoleTokensnoneeps:RoleToken
GetSendCMSTokeneps:GetCMSTokeneps:CMSLockBox
ParseCMSTokeneps:CMSLockBoxeps:CMSKey
GetReplyTokennoneeps:RoleToken
=0A=

When these actions are placed in an = xacml:Request,

=0A=
    =0A=
  • the Category is = "urn:oasis:names:tc:xacml:3.0:attribute-category:action",
    • =0A=
  • the AttributeId is "urn:ietf:params:xml:ns:plasma:actions",
    • =0A=
  • the DataType is "http://www.w3.org/2001/XMLSchema#string"
    • =0A=
=0A=

=0A=

=0A= 15.2. non

=0A=

Define a new data name space = urn:ietf:params:xml:ns:plasma:data

=0A=
    =0A=
  • CMSToken
    • =0A=
  • ChannelBinding
    • =0A=
  • SMIME-Capabilities
    • =0A=
=0A=

=0A=

Define a new name space for status = codes at urn:ietf:params:xml:ns:plasma:status. The initial set of = values is

=0A=
=0A=
authentication-error
=0A=
This identifier indicates that the = authentication methods failed to successfully complete.
=0A=
=0A=

=0A=

Define a new name space for = obligations. The same namespace will be used both for obligations and = for advice and the values may appear in either section.

=0A=
=0A=
signature-required
=0A=
This identifier indicates that that the = encrypted body must contain a signature element. The data value of this = type shall be "http://www.w3.org/2001/XMLSchema#hexBinary" and the data = structure shall consist of a DER encoded CMSCapabilities structure [RFC5751] with the list of permitted signature = algorithms. If there are no restrictions on the algorithms or the = restriction is implicit, then the data value MAY be omitted.
=0A=
encryption-algorithms
=0A=
see above
=0A=
ambigous-identity
=0A=
The identity of the client is either not = stated in a form the Plasma server understands, or there are multiple = identities in the authentication data. To remedy this situation, the = client includes an explicit identity in the xacml:Reqeust element.
=0A=
=0A=

=0A=

We define a schema in appendix A at = urn:ietf:params:xml:schema:plasma:1.0:RFCTBD

=0A=

Define a new Status Code for use in the = Status URI field.

=0A=
    =0A=
  • urn:ietf:params:xml:ns:plasma:status:gss-api-response - This = status is returned only with Indefinite responses. Indicates a GSS-API = response object was returned in the GSSAPIResponse token type. Will = return until authentication has been completed.
    • =0A=
=0A=

=0A=

=0A= 15.3. Port Assignment

=0A=

We request that IANA assign a new port = for the use of this protocol.

=0A=

Service name: plasma

=0A=

Port Number: TBD1

=0A=

Transport Protocol: TCP

=0A=

Description: Plasma Service Protocol

=0A=

Reference: This document

=0A=

Assignee: iesg@ietf.org

=0A=

Contact: chair@ietf.org

=0A=

Notes: The protocol requires that TLS = be used to communicate over this port. There is no provision for = unsecure messages to be sent to this protocol.

=0A=

=0A= 16. Open Issues

=0A=

List of Open Issues:

=0A=
    =0A=
  • JLS: Should we require that any SignatureProperty be present for = XML Signature elements?
    • =0A=
  • JLS: Need to figure out an appropriate way to reference the = assertion from a dig sig element. Could use a special version of = RetrievalMethod with a transform, but that does not seem correct. May = need to define a new KeyInfo structure to do it.
    • =0A=
  • JLS: Should X.509 certificates and attribute certificates be = fully specified as an authentication method?
    • =0A=
  • JLS: Should a SignerInfo attribute be placed under the = access-subject Category for a senders version and under Environment for = a machine version? Currently both are under Data
    • =0A=
  • JLS: Need an obligation to say that CEK must be encrypted. Do we = also need to have recipient info structures encrypted?
    • =0A=
=0A=

=0A=

=0A= 17. References

=0A=

=0A= 17.1. Normative References

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= [ABFAB]=0A= =0A= Hartman, S. and J. Howlett, "A GSS-API Mechanism = for the Extensible Authentication Protocol", Work In Progress = draft-ietf-abfab-gss-eap-04, Oct 2011.
=0A= [RFC2119]=0A= =0A= Bradner, S., "Key words for use in RFCs to = Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
=0A= [I-D.schaad-plasma-cms]=0A= =0A= Schaad, J., "Email Policy Service ASN.1 Processing", = Work In Progress draft-schaad-plamsa-cms, Jan 2011.
=0A= [XML-Signature]=0A= =0A= Roessler, T., Reagle, J., Hirsch, F., = Eastlake, D. and D. Solo, "XML = Signature Syntax and Processing (Second Edition)", World Wide Web = Consortium Recommendation REC-xmldsig-core-20080610, June 2008.
=0A= [XML-C14N11]=0A= =0A= Boyer, J. and G. Marcy, "Canonical XML = Version 1.1", World Wide Web Consortium Recommendation = REC-xml-c14n11-20080502, May 2008.
=0A= [WS-TRUST]=0A= =0A= Lawrence, K., Kaler, C., Nadalin, A., = Goodner, M., Gudgin, M., Barbir, A. and H. = Granqvist, "WS-= Trust 1.4", OASIS Standard ws-trust-200902, March 2007.
=0A= [XACML]=0A= =0A= Rissanen, E., "eXtensible Access Control Markup Language (XACML) Version = 3.0", OASIS Standard xacml-201008, August 2010.
=0A= [I-D.freeman-plasma-requirements]<= /b>=0A= =0A= Freeman, T., Schaad, J. and P. Patterson, = "Requirements for Message Access Control", Work in progress = draft-freeman-message-access-control, October 2011.
=0A= [OASIS-CORE]=0A= =0A= Cantor, S., Kemp, J., Philpott, R. and E. = Maler, "Assertions and Protocols for the OASIS Security Assertion = Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March = 2005.
=0A= [RFC5705]=0A= =0A= Rescorla, E., "Keying Material Exporters = for Transport Layer Security (TLS)", RFC 5705, March 2010.
=0A= [RFC5751]=0A= =0A= Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet = Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC = 5751, January 2010.
=0A= [RFC7055]=0A= =0A= Hartman, S. and J. Howlett, "A GSS-API Mechanism for the = Extensible Authentication Protocol", RFC 7055, December 2013.
=0A=

=0A= 17.2. Informative References

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= [RFC5554]=0A= =0A= Williams, N., "Clarifications and = Extensions to the Generic Security Service Application Program Interface = (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.
=0A= [RFC2743]=0A= =0A= Linn, J., "Generic Security Service = Application Program Interface Version 2, Update 1", RFC 2743, = January 2000.
=0A= [RFC4346]=0A= =0A= Dierks, T. and E. Rescorla, "The Transport Layer Security = (TLS) Protocol Version 1.1", RFC 4346, April 2006.
=0A= [RFC4998]=0A= =0A= Gondrom, T., Brandner, R. and U. Pordesch, = "Evidence Record Syntax = (ERS)", RFC 4998, August 2007.
=0A= [RFC5077]=0A= =0A= Salowey, J., Zhou, H., Eronen, P. and H. = Tschofenig, "Transport Layer Security = (TLS) Session Resumption without Server-Side State", RFC 5077, = January 2008.
=0A= [RFC3986]=0A= =0A= Berners-Lee, T., Fielding, R. and L. = Masinter, "Uniform = Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, = January 2005.
=0A= [SAML-XACML]=0A= =0A= Anderson, A. and H. Lockhart, "SAML 2.0 profile = of XACML v2.0", OASIS Standard = access_control-xacml-2.0-saml-profile-spec-os.pdf, February 2005.
=0A= [PlasmaBasicPolicy]=0A= =0A= Anon, A., "IETF Defined Plasma Policies", February = 2005.
=0A= [SOAP11]=0A= =0A= Box, D., Ehnebuske, D., Kakivaya, G., = Layman, A., Mendelsohn, N., Nielsen, H., Thatte, = S. and D. Winer, "Simple Object Access Protocol (SOAP) = 1.1", W3C NOTE NOTE-SOAP-20000508, May 2000.
=0A= [SOAP12]=0A= =0A= Lafon, Y., Gudgin, M., Hadley, M., Moreau, = J., Mendelsohn, N., Karmarkar, A. and H. = Nielsen, "SOAP = Version 1.2 Part 1: Messaging Framework (Second Edition)", World = Wide Web Consortium Recommendation REC-soap12-part1-20070427, April = 2007.
=0A=

=0A= Appendix A. XML Schema

=0A=

This appendix represents the entirety of = the XML Schema for Plasma documents.

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8"?>=0A=
<!-- edited with XMLSpy v2007 rel. 3 sp1 (http://www.altova.com) by =
James Schaad (exmsft) -->=0A=
<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" =
xmlns:wst=3D"http://schemas.xmlsoap.org/ws/2005/02/trust" =
xmlns:eps=3D"urn:ietf:params:ns:plasma:1.0" =
xmlns:ds2=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:saml=3D"urn:oasis:names:tc:SAML:2.0:assertion" =
targetNamespace=3D"urn:ietf:params:ns:plasma:1.0" =
elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified">=0A=
  <xs:annotation>=0A=
    <xs:documentation>=0A=
    The PlasmaRequest element is one of two top level elements defined =
by this XSD schema.=0A=
    The PlasmaRequest element is sent from the client to the server in =
order to =0A=
  </xs:documentation>=0A=
  </xs:annotation>=0A=
  <xs:element name=3D"PlasmaRequest" type=3D"eps:RequestType"/>=0A=
  <xs:complexType name=3D"RequestType">=0A=
    <xs:sequence>=0A=
      <xs:element ref=3D"eps:Authentication" minOccurs=3D"0"/>=0A=
      <xs:element ref=3D"xacml:Request"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"Version" type=3D"xs:string" =
default=3D"1.0"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"PlasmaResponse" type=3D"eps:ResponseType"/>=0A=
  <xs:complexType name=3D"ResponseType">=0A=
    <xs:sequence>=0A=
      <xs:element ref=3D"xacml:Response"/>=0A=
      <xs:element ref=3D"eps:PlasmaReturnToken" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"Version" type=3D"xs:string" =
default=3D"1.0"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"PlasmaReturnToken" =
type=3D"eps:PlasmaReturnTokenType"/>=0A=
  <xs:complexType name=3D"PlasmaReturnTokenType">=0A=
    <xs:sequence>=0A=
      <xs:any namespace=3D"##any" processContents=3D"lax"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"DecisionId" type=3D"xs:string"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"Authentication" =
type=3D"eps:AuthenticationType"/>=0A=
  <xs:complexType name=3D"AuthenticationType">=0A=
    <xs:choice maxOccurs=3D"unbounded">=0A=
      <xs:element ref=3D"saml:Assertion"/>=0A=
      <xs:element name=3D"GSSAPI" type=3D"xs:hexBinary"/>=0A=
      <xs:element name=3D"RoleToken">=0A=
        <xs:complexType>=0A=
          <xs:sequence>=0A=
            <xs:any namespace=3D"##any" processContents=3D"lax"/>=0A=
          </xs:sequence>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
      <xs:element ref=3D"ds2:Signature"/>=0A=
      <xs:element name=3D"Other">=0A=
        <xs:complexType>=0A=
          <xs:sequence>=0A=
            <xs:any namespace=3D"##other"/>=0A=
          </xs:sequence>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
    </xs:choice>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"RoleToken" type=3D"eps:RoleTokenType"/>=0A=
  <xs:complexType name=3D"RoleTokenType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"FriendlyName" type=3D"xs:string"/>=0A=
      <xs:element name=3D"PDP" type=3D"xs:anyURI" =
maxOccurs=3D"unbounded"/>=0A=
      <xs:choice>=0A=
        <xs:element name=3D"PolicyList">=0A=
          <xs:complexType>=0A=
            <xs:sequence>=0A=
              <xs:element name=3D"Policy" type=3D"eps:PolicyDescType" =
maxOccurs=3D"unbounded"/>=0A=
            </xs:sequence>=0A=
          </xs:complexType>=0A=
        </xs:element>=0A=
        <xs:element ref=3D"eps:Policy"/>=0A=
        <xs:element ref=3D"eps:PolicySet"/>=0A=
      </xs:choice>=0A=
      <xs:element ref=3D"wst:RequestSecurityTokenResponse"/>=0A=
      <xs:element ref=3D"xacml:Obligations" minOccurs=3D"0"/>=0A=
      <xs:element ref=3D"xacml:AssociatedAdvice" minOccurs=3D"0"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:complexType name=3D"PolicyDescType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"FriendlyName" type=3D"xs:string"/>=0A=
      <xs:element name=3D"Options" minOccurs=3D"0">=0A=
        <xs:complexType>=0A=
          <xs:complexContent>=0A=
            <xs:extension base=3D"xs:anyType">=0A=
              <xs:attribute name=3D"optionsType" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
            </xs:extension>=0A=
          </xs:complexContent>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"PolicyId" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"PolicySet" type=3D"eps:PolicySetType"/>=0A=
  <xs:complexType name=3D"PolicySetType">=0A=
    <xs:sequence>=0A=
      <xs:choice maxOccurs=3D"unbounded">=0A=
        <xs:element ref=3D"eps:Policy"/>=0A=
        <xs:element ref=3D"eps:PolicySet"/>=0A=
      </xs:choice>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"PolicyCombiningAlgId" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"Policy" type=3D"eps:PolicyType"/>=0A=
  <xs:complexType name=3D"PolicyType">=0A=
    <xs:sequence>=0A=
      <xs:any namespace=3D"##any" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    </xs:sequence>=0A=
    <xs:attribute name=3D"PolicyId" type=3D"xs:anyURI" =
use=3D"required"/>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"GetCMSToken" =
type=3D"eps:CMSTokenRequestType"/>=0A=
  <xs:complexType name=3D"CMSTokenRequestType">=0A=
    <xs:sequence>=0A=
      <xs:choice>=0A=
        <xs:element ref=3D"eps:Policy"/>=0A=
        <xs:element ref=3D"eps:PolicySet"/>=0A=
      </xs:choice>=0A=
      <xs:element name=3D"Hash">=0A=
        <xs:complexType>=0A=
          <xs:sequence>=0A=
            <xs:element ref=3D"ds2:DigestMethod"/>=0A=
            <xs:element ref=3D"ds2:DigestValue"/>=0A=
          </xs:sequence>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
      <xs:element name=3D"LockBox" type=3D"eps:LockBoxType" =
minOccurs=3D"0" maxOccurs=3D"unbounded"/>=0A=
      <xs:element name=3D"CEK" type=3D"xs:hexBinary" =
minOccurs=3D"0"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"LockBox" type=3D"eps:LockBoxType"/>=0A=
  <xs:complexType name=3D"LockBoxType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"Subject" maxOccurs=3D"unbounded">=0A=
        <xs:complexType>=0A=
          <xs:simpleContent>=0A=
            <xs:extension base=3D"xs:anySimpleType">=0A=
              <xs:attribute name=3D"type" type=3D"xs:string" =
use=3D"required"/>=0A=
            </xs:extension>=0A=
          </xs:simpleContent>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
      <xs:element name=3D"CMSLockBox" type=3D"xs:base64Binary"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"CMSKey" type=3D"eps:CMSKeyResponseType"/>=0A=
  <xs:complexType name=3D"CMSKeyResponseType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"DisplayString" type=3D"xs:string"/>=0A=
      <xs:choice>=0A=
        <xs:element name=3D"CEK" type=3D"xs:base64Binary"/>=0A=
        <xs:element name=3D"CMSLockBox" type=3D"xs:base64Binary"/>=0A=
      </xs:choice>=0A=
      <xs:element ref=3D"eps:RoleToken" minOccurs=3D"0"/>=0A=
      <xs:element ref=3D"xacml:Attributes" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:element name=3D"CMSToken" type=3D"eps:CMSTokenResponseType"/>=0A=
  <xs:complexType name=3D"CMSTokenResponseType">=0A=
    <xs:sequence>=0A=
      <xs:element name=3D"CMSLockBox" maxOccurs=3D"unbounded">=0A=
        <xs:complexType>=0A=
          <xs:simpleContent>=0A=
            <xs:extension base=3D"xs:base64Binary">=0A=
              <xs:attribute name=3D"CMSType" type=3D"xs:string"/>=0A=
            </xs:extension>=0A=
          </xs:simpleContent>=0A=
        </xs:complexType>=0A=
      </xs:element>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
  <xs:complexType name=3D"LockboxKey">=0A=
    <xs:sequence>=0A=
      <xs:choice>=0A=
        <xs:element name=3D"X509Certificate" =
type=3D"xs:base64Binary"/>=0A=
        <xs:element name=3D"PGPKey" type=3D"xs:base64Binary"/>=0A=
        <xs:element ref=3D"ds2:KeyInfo"/>=0A=
      </xs:choice>=0A=
      <xs:element name=3D"Capabilities" type=3D"xs:base64Binary" =
minOccurs=3D"0"/>=0A=
    </xs:sequence>=0A=
  </xs:complexType>=0A=
</xs:schema>=0A=
=0A=

=0A= Appendix B.=0A= Example: Get Roles = Request=0A=

=0A=

This section provides an example of a = request message to obtain the set of roles for an individual named = 'bart@simpsons.com'. The authentication provided in this is a SAML = statement included in the SAML_Collection element.

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8"?>=0A=
<PlasmaRequest xmlns=3D"urn:ietf:schema:plasma:1.0" =0A=
    xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"=0A=
    xmlns:saml=3D"urn:oasis:names:tc:SAML:2.0:assertion"=0A=
    xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=0A=
    xsi:schemaLocation=3D"urn:ietf:schema:plasma:1.0 =
C:\ietf\drafts\Schema\Plasma.xsd" >=0A=
  <Authentication>=0A=
      <WS-Token>123456</WS-Token>=0A=
    <!-- <saml:Assertion>....</saml:Assertion> -->=0A=
  </Authentication>=0A=
  <xacml:Request CombinedDecision=3D"false" =
ReturnPolicyIdList=3D"false">=0A=
    <xacml:Attributes =
Category=3D"urn:oasis:names:tc:xaml:3.0:attribute-catagory:action">=0A=
      <xacml:Attribute IncludeInResult=3D"false" =
AttributeId=3D"urn:plasma:action-id">=0A=
        <xacml:AttributeValue =
DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetRoleTokens<=
/xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
    <xacml:Attributes =
Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category:environment"&=
gt;=0A=
      <xacml:Attribute AttributeId=3D"urn:ietf:plasma:data:channel" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"http://www.w3.org/2001/XMLSchema#base64Binary">ABCDEFGH<=
;/xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
  </xacml:Request>=0A=
</PlasmaRequest>=0A=
=0A=

=0A= Appendix C.=0A= Example: Get = Roles Response=0A=

=0A=

This section provides an example response = to a successful request for a role sets.

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8" =
standalone=3D"yes"?>=0A=
<eps:PlasmaResponse xmlns:eps=3D"urn:ietf:params:ns:plasma:1.0">=0A=
  <xacml:Response =
xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">=0A=
    <xacml:Result>=0A=
      <xacml:Decision>Permit</xacml:Decision>=0A=
    </xacml:Result>=0A=
  </xacml:Response>=0A=
  <eps:PlasmaReturnToken>=0A=
    <eps:RoleToken>=0A=
      <eps:FriendlyName>Role #1</eps:FriendlyName>=0A=
      <eps:PDP>plasma://localhost:8080</eps:PDP>=0A=
      <eps:PolicyList>=0A=
        <eps:Policy =
PolicyId=3D"urn:example:PlasmaPolicies:Policy1">=0A=
          <eps:FriendlyName>Schaad Policy =
1</eps:FriendlyName>=0A=
        </eps:Policy>=0A=
      </eps:PolicyList>=0A=
      <wst:RequestSecurityTokenResponse =
xmlns:wst=3D"http://schemas.xmlsoap.org/ws/2005/02/trust">=0A=
        <wst:RequestedSecurityToken>=0A=
          <ex:MyToken =
xmlns:ex=3D"http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEB=
MBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN</ex:MyToken>=0A=
        </wst:RequestedSecurityToken>=0A=
        <wst:Lifetime>=0A=
          <wsu:Expires =
xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse=
curity-utility-1.0.xsd">2013-01-10T04:22:00</wsu:Expires>=0A=
        </wst:Lifetime>=0A=
      </wst:RequestSecurityTokenResponse>=0A=
      <Obligations =
xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">=0A=
        <Obligation ObligationId=3D"Obligation-Fred" />=0A=
      </Obligations>=0A=
    </eps:RoleToken>=0A=
  </eps:PlasmaReturnToken>=0A=
  <eps:PlasmaReturnToken>=0A=
    <eps:RoleToken>=0A=
      <eps:FriendlyName>Plasma Basic =
Policy</eps:FriendlyName>=0A=
      <eps:PDP>plasma://localhost:8080</eps:PDP>=0A=
      <eps:PolicyList>=0A=
        <eps:Policy PolicyId=3D"urn:ietf:ns:plasma:policy:basic">=0A=
          <eps:FriendlyName>Plasma Basic =
Policy</eps:FriendlyName>=0A=
        </eps:Policy>=0A=
        <eps:Policy =
PolicyId=3D"urn:example:PlasmaPolicies:Policy1">=0A=
          <eps:FriendlyName>Schaad Policy =
1</eps:FriendlyName>=0A=
        </eps:Policy>=0A=
      </eps:PolicyList>=0A=
      <wst:RequestSecurityTokenResponse =
xmlns:wst=3D"http://schemas.xmlsoap.org/ws/2005/02/trust">=0A=
        <wst:RequestedSecurityToken>=0A=
          <ex:MyToken =
xmlns:ex=3D"http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEB=
MBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN</ex:MyToken>=0A=
        </wst:RequestedSecurityToken>=0A=
        <wst:Lifetime>=0A=
          <wsu:Expires =
xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse=
curity-utility-1.0.xsd">2013-01-10T04:22:00</wsu:Expires>=0A=
        </wst:Lifetime>=0A=
      </wst:RequestSecurityTokenResponse>=0A=
    </eps:RoleToken>=0A=
  </eps:PlasmaReturnToken>=0A=
</eps:PlasmaResponse>
=0A=

In this example a role is returned that = has two different policies that can be used by that role. Along with = the role token, a binary secret is returned that is to be used in = proving that the same entity is returning to use the roles.

=0A=

=0A= Appendix D.=0A= Example: = Get CMS Token Request=0A=

=0A=

This section contains an example of a = request from a client to a server for a CMS message token to be issued. = The authentication for the request is provided by using a WS-Trust token = previously issued as part of a role request/response dialog. The = request contains the following elements:

=0A=
    =0A=
  • A complex rule set is requested where permission to is to be = granted to anyone who meets either of the two policies given.
    • =0A=
  • A specific recipient info structure is provided for a subject = who's name is 'lisa@simpsons.com'. The details of the recipient info = structure are skipped but it would be any encoding of a RecipientInfo = structure from CMS.
    • =0A=
  • A generic key encryption key is provided for any other subject = who meets the policies specified.
    • =0A=
=0A=

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8" standalone=3D"yes"?>=0A=
<eps:PlasmaRequest xmlns:eps=3D"urn:ietf:params:ns:plasma:1.0">=0A=
  <eps:Authentication>=0A=
    <eps:RoleToken>=0A=
      <ex:MyToken =
xmlns:ex=3D"http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEB=
MBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN</ex:MyToken>=0A=
    </eps:RoleToken>=0A=
  </eps:Authentication>=0A=
  <xacml:Request CombinedDecision=3D"false" =
ReturnPolicyIdList=3D"false" id=3D"XACMLRequest" =
xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">=0A=
    <xacml:Attributes =
Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category:action">=0A=
      <xacml:Attribute =
AttributeId=3D"urn:ietf:params:xml:ns:params:actions" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</x=
acml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
    <xacml:Attributes =
Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category:environment"&=
gt;=0A=
      <xacml:Attribute =
AttributeId=3D"urn:ietf:params:xml:ns:plasma:data:channel" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"http://www.w3.org/2001/XMLSchema#base64Binary">tls-unique&=
lt;/xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
    <xacml:Attributes =
Category=3D"urn:ietf:params:xml:ns:params:data">=0A=
      <xacml:Attribute =
AttributeId=3D"urn:ietf:params:xml:ns:params:data:CMSTokenRequest" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"urn:ietf:params:ns:plasma:1.0#CMSTokenRequestType">=0A=
          <eps:GetCMSToken>=0A=
            <eps:PolicySet =
PolicyCombiningAlgId=3D"urn:oasis:names:tc:xacml:3.0:policy-combining-alg=
orithm:permit-overrides">=0A=
              <eps:Policy =
PolicyId=3D"urn:example:PlasmaPolicies:Policy1" />=0A=
            </eps:PolicySet>=0A=
            <eps:Hash>=0A=
              <ds2:DigestMethod =
Algorithm=3D"http://www.w3.org/2001/04/xmlenc#sha256" =
xmlns:ds2=3D"http://www.w3.org/2000/09/xmldsig#" />=0A=
              <ds2:DigestValue =
xmlns:ds2=3D"http://www.w3.org/2000/09/xmldsig#">AQIDBAUGBwgJCg=3D=3D&=
lt;/ds2:DigestValue>=0A=
            </eps:Hash>=0A=
            <eps:CEK>0102030405060708090A</eps:CEK>=0A=
          </eps:GetCMSToken>=0A=
        </xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
  </xacml:Request>=0A=
</eps:PlasmaRequest>=0A=
=0A=

=0A= Appendix E.=0A= Example: = Get CMS Token Response=0A=

=0A=

This section contains an example of a = response from a server to a client for a CMS message token to be issued. = The token is returned in the CMSToken element. This element would then = be placed into the CMS message being created by the client.

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8" =
standalone=3D"yes"?>=0A=
<eps:PlasmaResponse xmlns:eps=3D"urn:ietf:params:ns:plasma:1.0">=0A=
  <xacml:Response =
xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">=0A=
    <xacml:Result>=0A=
      <xacml:Decision>Permit</xacml:Decision>=0A=
    </xacml:Result>=0A=
  </xacml:Response>=0A=
  <eps:PlasmaReturnToken>=0A=
    =
<eps:CMSLockbox>MIIQJAYJKoZIhvcNAQcCoIIQFTCCEBECAQExCzAJBgUrDgMCGgU=
AMIIDOQYJKoZIhvcNAQcDoIIDKjCCAyYGCSqGSIb3DQEHA6CCAxcwggMTAgEAMYIB4TCCAd0C=
AQAwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlI=
ENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3=
d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW5=
0aWNhdGlvbiBhbmQgRW1haWwCEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBAQUABIIB=
AEB7LT/qFbvzz7xxan6Q01By/J8X12Mpq00jLVst0+mGl7cmsBknS6TXC13638r8ow904GMB/=
1YzmWVYs4Pc+p9l7UJ0MFjhVULuahMbwrpEEFg90GBvZzZXKy8syxTcyh3TwCMTpYHOJxz9Df=
owvSJi2TPUiXG0mXzzMkbS3yiyJasacbgmG2d9G/cYJpVDlQqMCOVui7UMlQAz3LQLa9GINTz=
s1I5j8uqPDwPKxKmWNJ5AYj3jb6uLsf0tD1h+mCKotjdVsC0Jx05xZ53UCYPg3K5IoK8v/hu8=
psH7Njq3aZ6McxgeBFKxswSD3ffipEWkwLyN0heyhvIn3/prEsAwggEnBgsqhkiG9w0BB4aNF=
zAUBggqhkiG9w0DBwQIirvrkunYtn+AggEAlPZGLqxBvE2sdmmzUfAljJpKredC3fUxXgvPcp=
f07hcDz+NRf/miOwNTCUNrXg82s1NYfhWAQEuTxDtuGq7Lwd70fohcX0mXgxGbqlaPjEVzhUQ=
wZvJfn1r7oosJ5qzO59sKStEntQdYR5cyYXnHDO2xGE1TdB7X6ibfTubPq52UC/Lt7xRyB1HM=
z+eeLTl6amF1lO8VOITkAEOeI9noaePDheHMS7k0xMQMEMHYU1TN/09/2RSbMY740MEDNpidt=
omFv4gvhWWzGrzYNPFNtHQh/4UDhqXl9eJ+MOXRdGupV9vdt6RhGKC6krszfMV9O0vHzh750X=
wqxtQ38FolZ6CCChEwggSKMIIDcqADAgECAhAn9OoR9HqGxG6du26pFwcHMA0GCSqGSIb3DQE=
BBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRk=
VHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsI=
ENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVV=
MxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFV=
TRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0=
BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCA=
SIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6=
K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/K=
YFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI=
4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvH=
XHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodN=
I0/zC27vZiMBSMLOsCAwEAAaOB4TCB3jAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMt=
UGjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud=
EwEB/wQFMAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ=
WRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC=
9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAGdiJEW8orKY=
AoueHwZuQA9t+oRL9HvPi8AGplFRCa5oJxKBt15CSBANmeUNx/Phvr9t2ReI3Gj3d5FkEeKwc=
9ING83rPW4RyLeVGwboYESnzy0l5hzy6bQWdpG1oT61yFDaoubH9v89/8KRqlDVQj8+BbVWx3=
VkwSt9toJxkH0l87za79ONp9Pg5j1qtS4U6tw7t088NRKL7BL/kL3COJftaVAaz0MS8bY37cz=
Is6ZuEJC3Wf5F6aAJQHw4/TenM9btn6NwcLjv8Ts3+Ao7jqBMKpSZEZekQ8k1Sp67cPsprMlx=
BbP71XaDq/9H6m4ZYbT2WR+X+LpUEwgDMjqHyuzCCBX8wggRnoAMCAQICEQDVeeyr0T13xrMg=
LQj+cJ0iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVB=
gNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxIT=
AfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJ=
zdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDUyNzAwMDAwMFoXDTEy=
MDUyNjIzNTk1OVowKTEnMCUGCSqGSIb3DQEJARYYamltc2NoYWFkQHpzLnBlbmFuZ28ubmV0M=
IIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBLgJtGWe6ib5nTzwL2QAVPwQCUeTl=
0ItoLig2/WhKcrZJIcM9c/opX6Mi7V44v38hFxwurjJplF74xLp5IqhaPGXHf0t8Yas/F06Un=
ZyMlXQ197jCIkqChfqnOxDJ+7zASoveRt6aNyFJRy3eJyYasqbURvmdBYom1UOYxfWrIM9Vau=
lvW5TCiJIpbKiEwdIcs+JCLuNs/OgtFXB7C+IjIw1C7ZTxBD9Q8g9RRr/TvmhGQ1Ru1BL7g52=
+Hs1vrAtjENxwmJwrZSsJHgMw5FfDbVLrwOI97iCWnrQ8acFiS5iRFGqWzQCJyWhJFHYvuw7R=
zQg761+tin8hpue2OsEwIDAQABo4ICGjCCAhYwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHz=
ePa4Ebn0wHQYDVR0OBBYEFNltOqTDux3i8fOkK7gnr5Zo/FEfMA4GA1UdDwEB/wQEAwIFoDAM=
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBh=
vhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaH=
R0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDo=
vL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu=
ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ=
2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQ=
UFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwY=
BBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAjBgNVHREEHDAagRhqaW1zY2hhYWRA=
enMucGVuYW5nby5uZXQwDQYJKoZIhvcNAQEFBQADggEBAK9Ndz6RqjMdXDXZ5xrkc1FYcq69G=
m/yacR4Lkj35uHZ6kzndhsdcsug06879gOsW1OTFMSRYvHhYkwknLL4PKISxozVmiDvVYzYXq=
E+Gj4jZaNzbF8suowQCq7dS82Ggoj68C4Hh5+PyUlySmQZKnsyDuE6PxIlFlhLCmFYl9hsgRm=
gqe4sbB2cxZu03SYWvWI92IwwrouOtrI3JbFXJnn9obKLYj3LMRr9VrAHBd3A99VW6OMNT75b=
0ScuwcoS96YZutVC/y1Y65mMlGQW+FOr8sIxxFz6lsvTxEul0VXUxbfAZ0MkrRxJH0Mw3W2QU=
AQ3dRR81Ba/g8GNhawC+jUxggKrMIICpwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBA=
gTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCB=
OZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU=
Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANV57KvRPXfGs=
yAtCP5wnSIwCQYFKw4DAhoFAKCBvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcDMBwGCSqGSI=
b3DQEJBTEPFw0xMzAxMDgwNjQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSHHd6eVaOraNTvfMOaBDO=
IsfS5eDArBgsqhkiG9w0BCYaNGjEcMBowDAYKKhCGSAFlAwQCAQQKAQIDBAUGBwgJCjAwBgsq=
hkiG9w0BCYaNGTEhDB9wbGFzbWE6cGxhc21hLmF1Z3VzdGNlbGxhcnMuY29tMA0GCSqGSIb3D=
QEBAQUABIIBAKUc/zlevtNMuRrfnRJA30ecoXgXr33rEsbj9xEgH+xaJwBotwLC/i7wKutjc+=
Z8sfUt9X+H/jNFyMFZwXYF2fgw6xKtSlkYXgTu9GioK6rpftHSifOd+aRJHMKJTeWAkwamF9X=
BmaWhQusDVHZmmd9uUEPNkUSo4T6r2atZ8avgMc8DhwKLw8NGf9ZhkNtJciIW76X3AO+XbUr4=
vIsLT1mTFr4wJ7Tk9rOnk6oyGS/q1jvgVl53xKCTP+xa1usZarYUo2u974JjADN8uGlI4gv1w=
H1scojgXVYp8HWe6Uh0fYFdFRmefHj5rEkiB4POVVQoq8Bsk4sJUR3+rfaM3QI=3D</eps=
:CMSLockbox>=0A=
  </eps:PlasmaReturnToken>=0A=
</eps:PlasmaResponse>
=0A=

=0A= Appendix F.=0A= Example: Get = CMS Key Request=0A=

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8" =
standalone=3D"yes"?>=0A=
<eps:PlasmaRequest xmlns:eps=3D"urn:ietf:params:ns:plasma:1.0">=0A=
  <eps:Authentication>=0A=
    <eps:RoleToken>=0A=
      <ex:MyToken =
xmlns:ex=3D"http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEB=
MBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN</ex:MyToken>=0A=
    </eps:RoleToken>=0A=
  </eps:Authentication>=0A=
  <xacml:Request CombinedDecision=3D"false" =
ReturnPolicyIdList=3D"false" =
xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">=0A=
    <xacml:Attributes =
Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category:action">=0A=
      <xacml:Attribute =
AttributeId=3D"urn:ietf:params:xml:ns:params:actions" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSKey</xac=
ml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
    <xacml:Attributes =
Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category:environment"&=
gt;=0A=
      <xacml:Attribute =
AttributeId=3D"urn:ietf:params:xml:ns:plasma:data:channel" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"http://www.w3.org/2001/XMLSchema#base64Binary">tls-unique&=
lt;/xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
    <xacml:Attributes =
Category=3D"urn:ietf:params:xml:ns:params:data">=0A=
      <xacml:Attribute =
AttributeId=3D"urn:ietf:params:xml:ns:params:data:CMSKeyRequest" =
IncludeInResult=3D"false">=0A=
        <xacml:AttributeValue =
DataType=3D"urn:ietf:params:ns:plasma:1.0#CMSLockbox">=0A=
          =
<eps:CMSLockbox>MIIQJAYJKoZIhvcNAQcCoIIQFTCCEBECAQExCzAJBgUrDgMCGgU=
AMIIDOQYJKoZIhvcNAQcDoIIDKjCCAyYGCSqGSIb3DQEHA6CCAxcwggMTAgEAMYIB4TCCAd0C=
AQAwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlI=
ENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3=
d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW5=
0aWNhdGlvbiBhbmQgRW1haWwCEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBAQUABIIB=
AEB7LT/qFbvzz7xxan6Q01By/J8X12Mpq00jLVst0+mGl7cmsBknS6TXC13638r8ow904GMB/=
1YzmWVYs4Pc+p9l7UJ0MFjhVULuahMbwrpEEFg90GBvZzZXKy8syxTcyh3TwCMTpYHOJxz9Df=
owvSJi2TPUiXG0mXzzMkbS3yiyJasacbgmG2d9G/cYJpVDlQqMCOVui7UMlQAz3LQLa9GINTz=
s1I5j8uqPDwPKxKmWNJ5AYj3jb6uLsf0tD1h+mCKotjdVsC0Jx05xZ53UCYPg3K5IoK8v/hu8=
psH7Njq3aZ6McxgeBFKxswSD3ffipEWkwLyN0heyhvIn3/prEsAwggEnBgsqhkiG9w0BB4aNF=
zAUBggqhkiG9w0DBwQIirvrkunYtn+AggEAlPZGLqxBvE2sdmmzUfAljJpKredC3fUxXgvPcp=
f07hcDz+NRf/miOwNTCUNrXg82s1NYfhWAQEuTxDtuGq7Lwd70fohcX0mXgxGbqlaPjEVzhUQ=
wZvJfn1r7oosJ5qzO59sKStEntQdYR5cyYXnHDO2xGE1TdB7X6ibfTubPq52UC/Lt7xRyB1HM=
z+eeLTl6amF1lO8VOITkAEOeI9noaePDheHMS7k0xMQMEMHYU1TN/09/2RSbMY740MEDNpidt=
omFv4gvhWWzGrzYNPFNtHQh/4UDhqXl9eJ+MOXRdGupV9vdt6RhGKC6krszfMV9O0vHzh750X=
wqxtQ38FolZ6CCChEwggSKMIIDcqADAgECAhAn9OoR9HqGxG6du26pFwcHMA0GCSqGSIb3DQE=
BBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRk=
VHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsI=
ENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVV=
MxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFV=
TRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0=
BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCA=
SIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6=
K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/K=
YFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI=
4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvH=
XHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodN=
I0/zC27vZiMBSMLOsCAwEAAaOB4TCB3jAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMt=
UGjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud=
EwEB/wQFMAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ=
WRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC=
9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAGdiJEW8orKY=
AoueHwZuQA9t+oRL9HvPi8AGplFRCa5oJxKBt15CSBANmeUNx/Phvr9t2ReI3Gj3d5FkEeKwc=
9ING83rPW4RyLeVGwboYESnzy0l5hzy6bQWdpG1oT61yFDaoubH9v89/8KRqlDVQj8+BbVWx3=
VkwSt9toJxkH0l87za79ONp9Pg5j1qtS4U6tw7t088NRKL7BL/kL3COJftaVAaz0MS8bY37cz=
Is6ZuEJC3Wf5F6aAJQHw4/TenM9btn6NwcLjv8Ts3+Ao7jqBMKpSZEZekQ8k1Sp67cPsprMlx=
BbP71XaDq/9H6m4ZYbT2WR+X+LpUEwgDMjqHyuzCCBX8wggRnoAMCAQICEQDVeeyr0T13xrMg=
LQj+cJ0iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVB=
gNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxIT=
AfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJ=
zdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDUyNzAwMDAwMFoXDTEy=
MDUyNjIzNTk1OVowKTEnMCUGCSqGSIb3DQEJARYYamltc2NoYWFkQHpzLnBlbmFuZ28ubmV0M=
IIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBLgJtGWe6ib5nTzwL2QAVPwQCUeTl=
0ItoLig2/WhKcrZJIcM9c/opX6Mi7V44v38hFxwurjJplF74xLp5IqhaPGXHf0t8Yas/F06Un=
ZyMlXQ197jCIkqChfqnOxDJ+7zASoveRt6aNyFJRy3eJyYasqbURvmdBYom1UOYxfWrIM9Vau=
lvW5TCiJIpbKiEwdIcs+JCLuNs/OgtFXB7C+IjIw1C7ZTxBD9Q8g9RRr/TvmhGQ1Ru1BL7g52=
+Hs1vrAtjENxwmJwrZSsJHgMw5FfDbVLrwOI97iCWnrQ8acFiS5iRFGqWzQCJyWhJFHYvuw7R=
zQg761+tin8hpue2OsEwIDAQABo4ICGjCCAhYwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHz=
ePa4Ebn0wHQYDVR0OBBYEFNltOqTDux3i8fOkK7gnr5Zo/FEfMA4GA1UdDwEB/wQEAwIFoDAM=
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBh=
vhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaH=
R0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDo=
vL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu=
ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ=
2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQ=
UFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwY=
BBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAjBgNVHREEHDAagRhqaW1zY2hhYWRA=
enMucGVuYW5nby5uZXQwDQYJKoZIhvcNAQEFBQADggEBAK9Ndz6RqjMdXDXZ5xrkc1FYcq69G=
m/yacR4Lkj35uHZ6kzndhsdcsug06879gOsW1OTFMSRYvHhYkwknLL4PKISxozVmiDvVYzYXq=
E+Gj4jZaNzbF8suowQCq7dS82Ggoj68C4Hh5+PyUlySmQZKnsyDuE6PxIlFlhLCmFYl9hsgRm=
gqe4sbB2cxZu03SYWvWI92IwwrouOtrI3JbFXJnn9obKLYj3LMRr9VrAHBd3A99VW6OMNT75b=
0ScuwcoS96YZutVC/y1Y65mMlGQW+FOr8sIxxFz6lsvTxEul0VXUxbfAZ0MkrRxJH0Mw3W2QU=
AQ3dRR81Ba/g8GNhawC+jUxggKrMIICpwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBA=
gTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCB=
OZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU=
Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANV57KvRPXfGs=
yAtCP5wnSIwCQYFKw4DAhoFAKCBvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcDMBwGCSqGSI=
b3DQEJBTEPFw0xMzAxMDgwNjQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSHHd6eVaOraNTvfMOaBDO=
IsfS5eDArBgsqhkiG9w0BCYaNGjEcMBowDAYKKhCGSAFlAwQCAQQKAQIDBAUGBwgJCjAwBgsq=
hkiG9w0BCYaNGTEhDB9wbGFzbWE6cGxhc21hLmF1Z3VzdGNlbGxhcnMuY29tMA0GCSqGSIb3D=
QEBAQUABIIBAKUc/zlevtNMuRrfnRJA30ecoXgXr33rEsbj9xEgH+xaJwBotwLC/i7wKutjc+=
Z8sfUt9X+H/jNFyMFZwXYF2fgw6xKtSlkYXgTu9GioK6rpftHSifOd+aRJHMKJTeWAkwamF9X=
BmaWhQusDVHZmmd9uUEPNkUSo4T6r2atZ8avgMc8DhwKLw8NGf9ZhkNtJciIW76X3AO+XbUr4=
vIsLT1mTFr4wJ7Tk9rOnk6oyGS/q1jvgVl53xKCTP+xa1usZarYUo2u974JjADN8uGlI4gv1w=
H1scojgXVYp8HWe6Uh0fYFdFRmefHj5rEkiB4POVVQoq8Bsk4sJUR3+rfaM3QI=3D</eps=
:CMSLockbox>=0A=
        </xacml:AttributeValue>=0A=
      </xacml:Attribute>=0A=
    </xacml:Attributes>=0A=
  </xacml:Request>=0A=
</eps:PlasmaRequest>
=0A=

=0A= Appendix G.=0A= Example: Get = CMS KeyResponse=0A=

=0A= 
=0A=
<?xml version=3D"1.0" encoding=3D"UTF-8" =
standalone=3D"yes"?>=0A=
<eps:PlasmaResponse xmlns:eps=3D"urn:ietf:params:ns:plasma:1.0">=0A=
  <xacml:Response =
xmlns:xacml=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">=0A=
    <xacml:Result>=0A=
      <xacml:Decision>Permit</xacml:Decision>=0A=
    </xacml:Result>=0A=
  </xacml:Response>=0A=
  <eps:PlasmaReturnToken>=0A=
    <CMSKey:eps xmlns:CMSKey=3D"urn:ietf:params:ns:plasma:1.0">=0A=
      <eps:DisplayString>Schaad Policy 1</eps:DisplayString>=0A=
      <eps:CEK>AQIDBAUGBwgJCg=3D=3D</eps:CEK>=0A=
    </CMSKey:eps>=0A=
  </eps:PlasmaReturnToken>=0A=
</eps:PlasmaResponse>
=0A=

=0A= Appendix H. Enabling the = MultiRequests option

=0A=

NOTE: RFC Editor please remove this = section prior to publication. This section exists as a note to the = author to make sure that it can be done. It will be published as a = separate document if desired.

=0A=

One of the issues in doing multiple = requests in a single message is the issue of correlation between the = request and the results. We have make this issue even worse by the fact = that we are return results that are not input attributes for the = decision and that we are not returning as attributes of the decision.

=0A=

The best way to deal with this is by = putting tags into the request and reflect them in the return values for = the response. The only place that this does not work is for the GSS-API = response token as this element would normally be part of the response of = multiple requests. You want to finish that authentication step before = issuing final decisions if the input is needed as part of that = decision.

=0A=

With this in mind what we do is the = following:

=0A=
    =0A=
  • Define a new data attribute for plasma as plasma-request-id. The = category for it is urn:ietf:params:xml:ns:plasma:data. The type will be = a string.
    • =0A=
  • When the new attribute is used, then the return attribute flag = MUST be set on the attribute.
    • =0A=
  • There MUST be one entity of the new attribute, with a unique = value, for each of the requests in the MultiRequest element.
    • =0A=
  • Exactly one of the new attributes MUST be referenced in each = request in the MultiRequest element.
    • =0A=
  • The server copies the value of the attribute into the *** = attribute of the returned token.
    • =0A=
=0A=

=0A=

We could probably relax the restrictions = if we know that the token can only be returned by one request, however = using the token to correlate the request and the decision is still = probably desired so that those values can be correlated.

=0A=

=0A= Author's Address=0A=

=0A=
=0A=
=0A= =0A= Jim Schaad=0A= =0A= Schaad=0A= =0A= =0A= Soaring Hawk Consulting=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= EMail: ietf@augustcellars.com=0A= =0A=
=0A=
=0A= =0A= =0A= ------=_NextPart_000_0230_01CF1B76.7BC89EB0-- From curtis@ipv6.occnc.com Mon Jan 27 17:48:16 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9588D1A0345 for ; Mon, 27 Jan 2014 17:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6rRJEdqmMC-W for ; Mon, 27 Jan 2014 17:48:15 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A74821A016C for ; Mon, 27 Jan 2014 17:48:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S1m7OG000249; Mon, 27 Jan 2014 20:48:08 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280148.s0S1m7OG000249@maildrop2.v6ds.occnc.com> To: Julian Reschke From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 17:26:46 +0100." <52E688C6.40104@gmx.de> Date: Mon, 27 Jan 2014 20:48:07 -0500 Cc: "xml2rfc@ietf.org" Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:48:16 -0000 In message <52E688C6.40104@gmx.de> Julian Reschke writes: > Hi there, > > for > , > I'm currently trying to figure out what to say about hangIndent. > > The tricky thing here is that hangIndent is a formatting hint that is > very specific to how xml2rfc formats "hanging" lists. > > Example: > > 12 Test > > 123 Test > > 12345 Test > > With hangIndent, the default depth can be tuned. > > Now this kind of list formatting is specific to TXT output. When > producing HTML, the processors that I'm aware of produce HTML definition > lists (dl/dt/dd). Those will be displayed differently than in TXT, such as: > > 12 > Test > > 123 > Test > > 12345 > Test > > Consequently, xml2rfc has *ignored* hangIndent when producing HTML. > rfc2629.xslt does unterstand it, and uses it to override the default > indentation. xml2rfcv2 does something weird (all values != 0 lead to the > same indentation). > > We can document the intended behavior for output that uses "compact > lists". However, I'm not sure what to say for the HTML case (and similar > formats). > > Best regards, Julian The old text behavior was to add hangIndent to the current indent so hangIndent=8 would be: 12 Test 123 Test 12345 Test If the indent was too small at least two spaces were used. Rarely is this used with a single line so what you'd typically have is: 123 Text ...... and more text. If you added you could get (in both text and HTML versions): 123 Test 12345 Test 123456789 Test This was very useful for things like defining terminology where some terms were long. If you wanted the text separated from the body, then blankLines="1" could be used. It would be nice if the vspace could be eliminated and a formating hint given to the list. For example, something like: Going from 1.x to 2.x hangIndent changed and it seems it is no longer added to the current indent. Curtis From curtis@ipv6.occnc.com Mon Jan 27 17:52:30 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD41A03E6 for ; Mon, 27 Jan 2014 17:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1nd1kPLsqMPz for ; Mon, 27 Jan 2014 17:52:29 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C42B91A016C for ; Mon, 27 Jan 2014 17:52:28 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S1p6Wh000273; Mon, 27 Jan 2014 20:51:06 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280151.s0S1p6Wh000273@maildrop2.v6ds.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 08:05:31 +1300." <52E6ADFB.7090804@gmail.com> Date: Mon, 27 Jan 2014 20:51:06 -0500 Cc: Julian Reschke , XML2RFC Interest Group Subject: Re: [xml2rfc] rude comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:52:30 -0000 /* this /* won't work */ either :) */ In message <52E6ADFB.7090804@gmail.com> Brian E Carpenter writes: On 28/01/2014 01:58, Julian Reschke wrote: ... > This was caused by the whole quoted section sitting inside an XML > comment, and XML comments can't contain the string "--". Which, incidentally, is really annoying, because it means you can't comment out an XML segment that includes a comment. A bad design choice, IMHO, but not one we can fix. However, the latest XML2RFC gives a decent diagnostic: to do this --> ERROR: Unable to parse the XML document: INPUT INPUT: Line 66: Double hyphen within comment Brian _______________________________________________ xml2rfc mailing list xml2rfc@ietf.org https://www.ietf.org/mailman/listinfo/xml2rfc From julian.reschke@gmx.de Mon Jan 27 23:17:47 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E3E1A025D for ; Mon, 27 Jan 2014 23:17:47 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 TjegSCC7D16o for ; Mon, 27 Jan 2014 23:17:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D58471A0161 for ; Mon, 27 Jan 2014 23:17:40 -0800 (PST) Received: from [192.168.2.117] ([93.217.77.182]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M08ia-1VIPiG2wCC-00uJtK for ; Tue, 28 Jan 2014 08:17:37 +0100 Message-ID: <52E75987.2060007@gmx.de> Date: Tue, 28 Jan 2014 08:17:27 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , xml2rfc@ietf.org References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> <52E6C492.4020405@gmx.de> <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> In-Reply-To: <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MVO+l0mvJBqvzhJzjoNl0kxnX4qSVCDQ+KLjKJkLxPJETQYrACJ MDL3ggCS5Yz2Rmdj7+3vP/UcI8TnEn3XAeJYaoI2iyq44aCdGPbemPQiBzmgXOsUGvIa+kp Gqe6s4OpY/IvTSzYDi1fpg8KPjTMOBmixCu+2phJ84s1PFzqpZbNQfaQpZZUZhQdv0MYwgp cQVOb7bnqRLtcZObf6uoQ== Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 07:17:47 -0000 On 2014-01-28 00:43, Jim Schaad wrote: > So look at section 3. > ... Awesome. I'll have a look (this is experimental output, right?) Best regards, Julian From julian.reschke@gmx.de Mon Jan 27 23:50:13 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035A61A02BB for ; Mon, 27 Jan 2014 23:50:13 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ktkvxq_irDPn for ; Mon, 27 Jan 2014 23:50:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 805A61A026B for ; Mon, 27 Jan 2014 23:50:11 -0800 (PST) Received: from [192.168.2.117] ([93.217.77.182]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxPAo-1VEZSW3IS2-016zbc for ; Tue, 28 Jan 2014 08:50:08 +0100 Message-ID: <52E76125.2040405@gmx.de> Date: Tue, 28 Jan 2014 08:49:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401280148.s0S1m7OG000249@maildrop2.v6ds.occnc.com> In-Reply-To: <201401280148.s0S1m7OG000249@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cQjQsKpNqNXNiHuq4bQsAOaQA453ZzvQe25uJy6D6Liutt7CdAo sLmfhN2IMzhcp99tVLymJGZxOeLTv+LXqIMBtH9FJ3V3ENxOLRMGBY6DH/IfDUnZBcRs2Pj hY2BMMsuaVXCkQItl7s+hPcJipTkJbB7P02a5/HWAPXHKE+ytZIdDQZ6ivUEWhWcjPAemXy A1n3HNr9m03T83+q5tWPA== Cc: "xml2rfc@ietf.org" Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 07:50:13 -0000 On 2014-01-28 02:48, Curtis Villamizar wrote: > The old text behavior was to add hangIndent to the current indent so > hangIndent=8 would be: > > 12 Test > > 123 Test > > 12345 Test What exactly do you mean by "add to the current indent"? It *overrides* the current indent, no? > If the indent was too small at least two spaces were used. > > Rarely is this used with a single line so what you'd typically have > is: > > 123 Text ...... > and more text. Yes. > If you added you could get (in both text and > HTML versions): > > 123 > Test > > 12345 > Test > > 123456789 > Test > > This was very useful for things like defining terminology where some > terms were long. Which is why we want a new list type for this. > If you wanted the text separated from the body, then blankLines="1" > could be used. For v3, I don't expect we'll optimize it for plain text output (which means: less control over vertical whitespace). > It would be nice if the vspace could be eliminated and a formating > hint given to the list. For example, something like: > Almost. What we should have is more list styles (such as the "dictionary" style proposed by Jim), but less formatting overrides. > Going from 1.x to 2.x hangIndent changed and it seems it is no longer > added to the current indent. In TXT or HTML output? The latter is known to be defunct, I believe. Best regards, Julian From julian.reschke@gmx.de Tue Jan 28 05:19:06 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75361A03D6 for ; Tue, 28 Jan 2014 05:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, SPF_FAIL=0.001] autolearn=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 c-Yta37vSpur for ; Tue, 28 Jan 2014 05:19:05 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8C1A03D9 for ; Tue, 28 Jan 2014 05:19:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0SDIbFb003431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jan 2014 05:18:38 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEnX8-1W5MKq3V7a-00FzOG for ; Tue, 28 Jan 2014 14:18:30 +0100 Message-ID: <52E7AE20.10702@gmx.de> Date: Tue, 28 Jan 2014 14:18:24 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: xml2rfc References: <52E7ADC7.7020902@greenbytes.de> In-Reply-To: <52E7ADC7.7020902@greenbytes.de> X-Forwarded-Message-Id: <52E7ADC7.7020902@greenbytes.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OyX5RBr6JtlSOhZxyfhA7MefgizIkJ7ylr0lX2Yh4JVYkdqnGMJ qc3C0t2OS1IIrnZnShlYjjreLeGVJxDDmE1r9tp7yGPC0tHPD3yL9nj0YwFnsSpsfQYclJi ByX4OAi7cuFhXJFTAPfLz+8FRXgGeFpR8HL1soaGBW/0z8odEE9Y2R2T1bh8/kE17pnkve+ /UtGuD/YIoycKZ8q5BtYg== Subject: [xml2rfc] whitespace handling X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:19:07 -0000 Hi there, claims: "(Note that leading and trailing whitespace is significant.)" Also, the DTD has: ...which implies that whitespace inside is significant. In practice, that doesn't seem to be the case (in xml2rfc.tcl, rfc2629.xslt, v2). I thus conclude that the statement was something like wishful thinking, and that we can remove the xml:space default from the definition. Best regards, Julian From julian.reschke@gmx.de Tue Jan 28 06:08:31 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12B1A03FE for ; Tue, 28 Jan 2014 06:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_FAIL=0.001] autolearn=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 mcH8nwEwWq1n for ; Tue, 28 Jan 2014 06:08:30 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90D1A0216 for ; Tue, 28 Jan 2014 06:08:29 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.42]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0SE8LLu004288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jan 2014 06:08:22 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M4nt7-1VMUAE0zj3-00yyyX for ; Tue, 28 Jan 2014 15:08:15 +0100 Message-ID: <52E7B9C6.2080800@gmx.de> Date: Tue, 28 Jan 2014 15:08:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "rfc-design@rfc-editor.org" , xml2rfc References: <20140128140456.20111.200.idtracker@ietfa.amsl.com> In-Reply-To: <20140128140456.20111.200.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140128140456.20111.200.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GS4ZrLYHD8S/iJZFG89M8102VDypaPlKwu8egdbUChexbtqB2zL 1lGV1F96/hyvptVPRckDBQ1+uoUntcmJUhC7GgdOkwDoPlmi8unhPCCk/+vSjeqea4Ml9re f3T3t3eJC8nYBhCiVR/gf1894QhGU/mQq0FpVWfR+xQwbsUiqB2hNrMyztpJ5J/C2tlWY9G /WGDKSivbL/fVvGAgxGcQ== Subject: [xml2rfc] Fwd: New Version Notification for draft-reschke-xml2rfc-04.txt X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 14:08:31 -0000 Hi there, this draft contains minor improvements, plus the description of (mainly contributed by Alice). I'll now get to s and anchors, which might take some time, thus the snapshot. Best regards, Julian -------- Original Message -------- Subject: New Version Notification for draft-reschke-xml2rfc-04.txt Date: Tue, 28 Jan 2014 06:04:56 -0800 From: internet-drafts@ietf.org To: Julian F. Reschke , "Julian F. Reschke" A new version of I-D, draft-reschke-xml2rfc-04.txt has been successfully submitted by Julian F. Reschke and posted to the IETF repository. Name: draft-reschke-xml2rfc Revision: 04 Title: The 'XML2RFC' version 2 Vocabulary Document date: 2014-01-28 Group: Individual Submission Pages: 60 URL: http://www.ietf.org/internet-drafts/draft-reschke-xml2rfc-04.txt Status: https://datatracker.ietf.org/doc/draft-reschke-xml2rfc/ Htmlized: http://tools.ietf.org/html/draft-reschke-xml2rfc-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-reschke-xml2rfc-04 Abstract: This document defines the 'XML2RFC' version 2 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the XML2RFC mailing list (xml2rfc@ietf.org), which has its home page at . Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From trac@tools.ietf.org Tue Jan 28 07:09:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59A1A0439 for ; Tue, 28 Jan 2014 07:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 Fi9QjFMuO7P9 for ; Tue, 28 Jan 2014 07:09:19 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 854E31A0432 for ; Tue, 28 Jan 2014 07:09:14 -0800 (PST) Received: from localhost ([127.0.0.1]:43451 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W8AHm-0000sn-C8; Tue, 28 Jan 2014 16:09:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Tue, 28 Jan 2014 15:09:10 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/226 Message-ID: <069.eab50c473906e244379ee77e08f072cb@tools.ietf.org> X-Trac-Ticket-ID: 226 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #226: xref generation failure for text output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:09:24 -0000 #226: xref generation failure for text output With the attached input and when generating plain text, the transformation aborts with: Traceback (most recent call last): File "/usr/local/bin/xml2rfc", line 225, in main() File "/usr/local/bin/xml2rfc", line 210, in main pagedwriter.write(filename) File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1156, in write self._build_document() File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1087, in _build_document self.write_section_rec(middle, None) File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 841, in write_section_rec level=level + 1, appendix=appendix) File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 841, in write_section_rec level=level + 1, appendix=appendix) File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 816, in write_section_rec self.write_t_rec(element, autoAnchor=autoAnchor) File "/usr/local/lib/python2.7/dist- packages/xml2rfc/writers/raw_txt.py", line 579, in write_t_rec inline_text, remainder = self._combine_inline_elements(remainder) File "/usr/local/lib/python2.7/dist- packages/xml2rfc/writers/raw_txt.py", line 406, in _combine_inline_elements line.append(self._expand_xref(element)) File "/usr/local/lib/python2.7/dist- packages/xml2rfc/writers/raw_txt.py", line 348, in _expand_xref return xref.text.rstrip() AttributeError: 'NoneType' object has no attribute 'rstrip' -- -----------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli txt | Version: 2.4.x Keywords: | -----------------------------------+---------------------------------- Ticket URL: xml2rfc From ietf@augustcellars.com Tue Jan 28 07:29:31 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2344D1A03FE for ; Tue, 28 Jan 2014 07:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 BZU_WRJclf6a for ; Tue, 28 Jan 2014 07:29:29 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6774F1A0345 for ; Tue, 28 Jan 2014 07:29:29 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id ACC7A38F35; Tue, 28 Jan 2014 07:29:26 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> <52E6C492.4020405@gmx.de> <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> <52E75987.2060007@gmx.de> In-Reply-To: <52E75987.2060007@gmx.de> Date: Tue, 28 Jan 2014 07:27:48 -0800 Message-ID: <02b901cf1c3d$809ded10$81d9c730$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6gGZWHKfAfDgV50BpxrFLgGzTBOfAtDftfkBHR+CyJfiG8/A Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:29:31 -0000 This is hand-blown output - it was hand coded not machine coded > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, January 27, 2014 11:17 PM > To: Jim Schaad; xml2rfc@ietf.org > Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent > > On 2014-01-28 00:43, Jim Schaad wrote: > > So look at section 3. > > ... > > Awesome. I'll have a look (this is experimental output, right?) > > Best regards, Julian From ietf@augustcellars.com Tue Jan 28 08:04:35 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7D1A026E for ; Tue, 28 Jan 2014 08:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8e_1LFS_pt4K for ; Tue, 28 Jan 2014 08:04:33 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id D2C571A0269 for ; Tue, 28 Jan 2014 08:04:33 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 5F7252CA3A; Tue, 28 Jan 2014 08:04:31 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> In-Reply-To: <52E688C6.40104@gmx.de> Date: Tue, 28 Jan 2014 08:02:53 -0800 Message-ID: <02bf01cf1c42$67178e50$3546aaf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6pg4ujQw Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:04:35 -0000 > -----Original Message----- > From: xml2rfc [mailto:xml2rfc-bounces@ietf.org] On Behalf Of Julian > Reschke > Sent: Monday, January 27, 2014 8:27 AM > To: xml2rfc@ietf.org > Subject: [xml2rfc] list/@style='hanging' and @hangIndent > > Hi there, > > for > latest.html#element.list.attribute.hangIndent>, > I'm currently trying to figure out what to say about hangIndent. > > The tricky thing here is that hangIndent is a formatting hint that is very > specific to how xml2rfc formats "hanging" lists. > > Example: > > 12 Test > > 123 Test > > 12345 Test > > With hangIndent, the default depth can be tuned. > > Now this kind of list formatting is specific to TXT output. When producing > HTML, the processors that I'm aware of produce HTML definition lists > (dl/dt/dd). Those will be displayed differently than in TXT, such as: > > 12 > Test > > 123 > Test > > 12345 > Test > > Consequently, xml2rfc has *ignored* hangIndent when producing HTML. > rfc2629.xslt does unterstand it, and uses it to override the default > indentation. xml2rfcv2 does something weird (all values != 0 lead to the same > indentation). No this is not what it does for text output. Html output does totally ignore it. For text output if not given it uses a default value. Otherwise it indents the paragraph by the given amount from the previous paragraph boundary (thus it is additive for nested lists). Jim > > We can document the intended behavior for output that uses "compact > lists". However, I'm not sure what to say for the HTML case (and similar > formats). > > Best regards, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From julian.reschke@gmx.de Tue Jan 28 08:15:04 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68D1A0438 for ; Tue, 28 Jan 2014 08:15:04 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 y3QPvLPD0985 for ; Tue, 28 Jan 2014 08:15:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C08161A0431 for ; Tue, 28 Jan 2014 08:15:01 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MDQI1-1W4cxT2gF3-00GnGy for ; Tue, 28 Jan 2014 17:14:58 +0100 Message-ID: <52E7D772.8090709@gmx.de> Date: Tue, 28 Jan 2014 17:14:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , xml2rfc@ietf.org References: <52E688C6.40104@gmx.de> <02bf01cf1c42$67178e50$3546aaf0$@augustcellars.com> In-Reply-To: <02bf01cf1c42$67178e50$3546aaf0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gZ6ssqk29L5UNyHrOLo3VrlW+dNZm26jRyrPj+474bzicROurTr vYpkf+Pkuhm3xVSgYSqfwF3sP8y0+fJI1mc40sYziHrsus/pB8Yp56eUesCs8OADtbBqdgN cLhyvzJOKktWwpAkXy29D/mZnhKaL6nmvaTI1Y3jXmb/8DKh09rQy9B/XrS4PQef1TthuJd slem8qc/BWQwL50KMPjpg== Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:15:04 -0000 On 2014-01-28 17:02, Jim Schaad wrote: > ... > No this is not what it does for text output. Html output does totally > ignore it. > ... ...in xml2rfc.tcl, it ignores it for HTML output. In V2, it seems to be broken (all values >= 1 yielding the same result). In rfc2629.xslt, it uses the value for indentation. > For text output if not given it uses a default value. Otherwise it indents > the paragraph by the given amount from the previous paragraph boundary (thus > it is additive for nested lists). Agreed (and this seems to be consistent with that I said except that I didn't consider nested lists -- but come on, nested lists with "hanging" style? that asks for trouble :-) Best regards, Julian From julian.reschke@greenbytes.de Tue Jan 28 05:17:13 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F161A03CF for ; Tue, 28 Jan 2014 05:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.264 X-Spam-Level: * X-Spam-Status: No, score=1.264 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_35=0.6, SPF_SOFTFAIL=0.665] autolearn=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 HaUeNh8PW-2K for ; Tue, 28 Jan 2014 05:17:11 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 71F631A03CD for ; Tue, 28 Jan 2014 05:17:11 -0800 (PST) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0SDH4Zp003423 for ; Tue, 28 Jan 2014 05:17:05 -0800 (PST) (envelope-from julian.reschke@greenbytes.de) Received: from [192.168.1.102] (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 9779010C00F9 for ; Tue, 28 Jan 2014 14:17:02 +0100 (CET) Message-ID: <52E7ADC7.7020902@greenbytes.de> Date: Tue, 28 Jan 2014 14:16:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: xml2rfc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Jan 2014 08:41:14 -0800 Subject: [xml2rfc] whitespace handling X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:17:13 -0000 Hi there, claims: "(Note that leading and trailing whitespace is significant.)" Also, the DTD has: ...which implies that whitespace inside is significant. In practice, that doesn't seem to be the case (in xml2rfc.tcl, rfc2629.xslt, v2). I thus conclude that the statement was something like wishful thinking, and that we can remove the xml:space default from the definition. Best regards, Julian From ietf@augustcellars.com Tue Jan 28 08:56:59 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720201A017D for ; Tue, 28 Jan 2014 08:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Oe1OBGbKJqLx for ; Tue, 28 Jan 2014 08:56:58 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEB1A0146 for ; Tue, 28 Jan 2014 08:56:57 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 76C7038F17; Tue, 28 Jan 2014 08:56:55 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> <02bf01cf1c42$67178e50$3546aaf0$@augustcellars.com> <52E7D772.8090709@gmx.de> In-Reply-To: <52E7D772.8090709@gmx.de> Date: Tue, 28 Jan 2014 08:55:17 -0800 Message-ID: <001701cf1c49$b9646af0$2c2d40d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6gMYipAXAcQ3JmWYEeJ18A== Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:56:59 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, January 28, 2014 8:15 AM > To: Jim Schaad; xml2rfc@ietf.org > Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent > > On 2014-01-28 17:02, Jim Schaad wrote: > > ... > > No this is not what it does for text output. Html output does totally > > ignore it. > > ... > > ...in xml2rfc.tcl, it ignores it for HTML output. In V2, it seems to be broken (all > values >= 1 yielding the same result). In rfc2629.xslt, it uses the value for > indentation. Given that it is not doing hanging lists in HTML, it is not surprising that the value is ignored. > > > For text output if not given it uses a default value. Otherwise it > > indents the paragraph by the given amount from the previous paragraph > > boundary (thus it is additive for nested lists). > > Agreed (and this seems to be consistent with that I said except that I didn't > consider nested lists -- but come on, nested lists with "hanging" > style? that asks for trouble :-) I hate to disappoint you, but this is a very common way that I have found for people to deal with describing fields in nested structures. It is something that I do quite frequently. Additionally a nested list does not need to be a hang inside of a hang, it could be a hang side of a numbered list. Jim > > Best regards, Julian From curtis@ipv6.occnc.com Tue Jan 28 10:06:49 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876061A0232 for ; Tue, 28 Jan 2014 10:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mJ3a_rifmKIs for ; Tue, 28 Jan 2014 10:06:47 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4E1A0230 for ; Tue, 28 Jan 2014 10:06:47 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0SI6dES015515; Tue, 28 Jan 2014 13:06:39 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401281806.s0SI6dES015515@maildrop2.v6ds.occnc.com> To: Julian Reschke From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 08:49:57 +0100." <52E76125.2040405@gmx.de> Date: Tue, 28 Jan 2014 13:06:39 -0500 Cc: "xml2rfc@ietf.org" Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:06:49 -0000 In message <52E76125.2040405@gmx.de> Julian Reschke writes: > On 2014-01-28 02:48, Curtis Villamizar wrote: > > The old text behavior was to add hangIndent to the current indent so > > hangIndent=8 would be: > > > > 12 Test > > > > 123 Test > > > > 12345 Test > > What exactly do you mean by "add to the current indent"? It *overrides* > the current indent, no? That is a bug IMHO. See comment below. In xml2rfc 1.x it added to the current indent. So if the indent was 3, it added to that. If lists got nested and the indent was 6 (or more) it added to that. > > If the indent was too small at least two spaces were used. > > > > Rarely is this used with a single line so what you'd typically have > > is: > > > > 123 Text ...... > > and more text. > > Yes. > > > If you added you could get (in both text and > > HTML versions): > > > > 123 > > Test > > > > 12345 > > Test > > > > 123456789 > > Test > > > > This was very useful for things like defining terminology where some > > terms were long. > > Which is why we want a new list type for this. > > > If you wanted the text separated from the body, then blankLines="1" > > could be used. > > For v3, I don't expect we'll optimize it for plain text output (which > means: less control over vertical whitespace). But please at least leave the option to add the linebreak using or some other means. > > It would be nice if the vspace could be eliminated and a formating > > hint given to the list. For example, something like: > > > > Almost. What we should have is more list styles (such as the > "dictionary" style proposed by Jim), but less formatting overrides. Either way works for me. > > Going from 1.x to 2.x hangIndent changed and it seems it is no longer > > added to the current indent. > > In TXT or HTML output? The latter is known to be defunct, I believe. In txt. I had a draft complete WGLC a while back and then ended up with all sorts of diffs due to this (plus one diff due to a bug in eref). > Best regards, Julian Thanks for your work on this. Curtis From curtis@ipv6.occnc.com Tue Jan 28 11:41:35 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893F31A034E for ; Tue, 28 Jan 2014 11:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xI1xQhNq9UK6 for ; Tue, 28 Jan 2014 11:41:34 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0F38E1A026A for ; Tue, 28 Jan 2014 11:41:33 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0SJe9sZ016616; Tue, 28 Jan 2014 14:40:09 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401281940.s0SJe9sZ016616@maildrop2.v6ds.occnc.com> To: Julian Reschke From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 17:14:42 +0100." <52E7D772.8090709@gmx.de> Date: Tue, 28 Jan 2014 14:40:09 -0500 Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:41:35 -0000 In message <52E7D772.8090709@gmx.de> Julian Reschke writes: > On 2014-01-28 17:02, Jim Schaad wrote: > > ... > > No this is not what it does for text output. Html output does totally > > ignore it. > > ... > > ...in xml2rfc.tcl, it ignores it for HTML output. In V2, it seems to be > broken (all values >= 1 yielding the same result). In rfc2629.xslt, it > uses the value for indentation. > > > For text output if not given it uses a default value. Otherwise it indents > > the paragraph by the given amount from the previous paragraph boundary (thus > > it is additive for nested lists). > > Agreed (and this seems to be consistent with that I said except that I > didn't consider nested lists -- but come on, nested lists with "hanging" > style? that asks for trouble :-) > > Best regards, Julian Example There are many types of FOO FOO type 1 Paragraphs ... FOO type 2 In various flavors .... FOO type 2a ... FOO type 2b And so on ... FOO type 3 etc ... I don't see where nested lists are out of the question. It would be more common to make the inner list a numbered list, but there may be reasons to nest hanging lists. Curtis From julian.reschke@gmx.de Wed Jan 29 03:04:18 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9039D1A024C for ; Wed, 29 Jan 2014 03:04:18 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_FAIL=0.001] autolearn=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 kTDysQdozMNh for ; Wed, 29 Jan 2014 03:04:17 -0800 (PST) Received: from cyclone.public.resource.org (cyclone.public.resource.org [192.101.98.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0C31A0235 for ; Wed, 29 Jan 2014 03:04:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by cyclone.public.resource.org (8.14.5/8.14.4) with ESMTP id s0TB47q5077762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 29 Jan 2014 03:04:08 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: from [192.168.1.102] ([93.217.89.58]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0ML72n-1W8k3E3YAb-000IfA for ; Wed, 29 Jan 2014 12:04:01 +0100 Message-ID: <52E8E01D.9040708@gmx.de> Date: Wed, 29 Jan 2014 12:03:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: xml2rfc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4DsqQzv/p+e9LcaalvIbia1EO3nozmrNLmBqamqN8YYALK+juRY 9ePv6z29nKTor3j8TrVNhIY5q9Ap5Vbio8G71e77V/svZ6YUjpujr8ogfegNnGyajrMRriD zc57gUVaoQKdXcD3kMd+3IqInD1GJ68zyUw7bAsX4GqRTSkE0AA4aS0ZgAXf5Uq0jjMpTD1 gfn214PGU0zjyxiJk7aCw== Subject: [xml2rfc] reference/@anchor being optional X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 11:04:18 -0000 Hi there, I was wondering why the DTD claims that the anchor attribute on a reference is optional. Turns out that xml2rfc.tcl indeed allows anchor-less references when not using symrefs, and, well, if the reference isn't being used. So this is an edge case (as symrefs are now the default) of an edge case (unused references). Can we get rid of this in v2 already and make the anchor attribute required? Best regards, Julian From trac@tools.ietf.org Wed Jan 29 03:14:44 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893791A0235 for ; Wed, 29 Jan 2014 03:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 qq9bsfgTRhhV for ; Wed, 29 Jan 2014 03:14:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A95681A0233 for ; Wed, 29 Jan 2014 03:14:42 -0800 (PST) Received: from localhost ([127.0.0.1]:38026 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W8T6M-0002Ei-Sl; Wed, 29 Jan 2014 12:14:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Wed, 29 Jan 2014 11:14:38 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/227 Message-ID: <069.193bde867cd7009e57007ceb69c35cc0@tools.ietf.org> X-Trac-Ticket-ID: 227 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #227: failure for reference missing anchor attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 11:14:44 -0000 #227: failure for reference missing anchor attribute The processor fails for an unused non-anchored reference when using symrefs=false. -- -----------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Keywords: | -----------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Wed Jan 29 03:41:47 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552C71A041E for ; Wed, 29 Jan 2014 03:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, J_CHICKENPOX_75=0.6, RP_MATCHES_RCVD=-0.535] autolearn=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 p2LYI28kvfHU for ; Wed, 29 Jan 2014 03:41:45 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6C33E1A038E for ; Wed, 29 Jan 2014 03:41:45 -0800 (PST) Received: from localhost ([127.0.0.1]:39324 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W8TWY-0004XW-5N; Wed, 29 Jan 2014 12:41:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Wed, 29 Jan 2014 11:41:42 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/227#comment:1 Message-ID: <084.d7a6894dc285d0e0fefecb7619e56880@tools.ietf.org> References: <069.193bde867cd7009e57007ceb69c35cc0@tools.ietf.org> X-Trac-Ticket-ID: 227 In-Reply-To: <069.193bde867cd7009e57007ceb69c35cc0@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #227: failure for reference missing anchor attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 11:41:47 -0000 #227: failure for reference missing anchor attribute Description changed by julian.reschke@gmx.de: Old description: > The processor fails for an unused non-anchored reference when using > symrefs=false. New description: The processor fails for an unused non-anchored reference when using symrefs=false: WARNING: No DTD given, defaulting to /usr/local/lib/python2.7/dist- packages/xml2rfc/templates/rfc2629.dtd Traceback (most recent call last): File "/usr/local/bin/xml2rfc", line 225, in main() File "/usr/local/bin/xml2rfc", line 210, in main pagedwriter.write(filename) File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1150, in write self._build_index() File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 999, in _build_index self._indexRef(ref_counter, title=title, anchor=ref.attrib["anchor"]) File "lxml.etree.pyx", line 2275, in lxml.etree._Attrib.__getitem__ (src/lxml/lxml.etree.c:54623) KeyError: 'anchor' -- -- ------------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From trac@tools.ietf.org Thu Jan 30 06:25:00 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9131A037D for ; Thu, 30 Jan 2014 06:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 9lgp0y2V_c3B for ; Thu, 30 Jan 2014 06:24:58 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3DB1A0345 for ; Thu, 30 Jan 2014 06:24:58 -0800 (PST) Received: from localhost ([127.0.0.1]:46624 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W8sY2-0003az-6d; Thu, 30 Jan 2014 15:24:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, magnus.westerlund@ericsson.com X-Trac-Project: xml2rfc Date: Thu, 30 Jan 2014 14:24:54 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/228 Message-ID: <078.8c1abd53999ec868a1238e5bdc597212@tools.ietf.org> X-Trac-Ticket-ID: 228 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, magnus.westerlund@ericsson.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: xml2rfc@ietf.org Subject: [xml2rfc] #228: Outdated draft Reference Sources X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:25:00 -0000 #228: Outdated draft Reference Sources This is in relation to the xml.resource.org service. When producing a text version from a draft that uses It appear that the draft source file it uses are several weeks at least old. Both of these drafts has been updated in the january time-frame. -- --------------------------------------------+------------------------------ Reporter: magnus.westerlund@ericsson.com | Owner: Type: defect | henrik@levkowetz.com Priority: medium | Status: new Component: Version 2 cli | Milestone: Keywords: | Version: 2.4.x --------------------------------------------+------------------------------ Ticket URL: xml2rfc From henrik@levkowetz.com Thu Jan 30 07:01:31 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D041A03E7 for ; Thu, 30 Jan 2014 07:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 hCtETVamjli1 for ; Thu, 30 Jan 2014 07:01:27 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03B1A03D4 for ; Thu, 30 Jan 2014 07:01:27 -0800 (PST) Received: from [2a01:3f0:1:0:9cd2:9c14:99ae:417f] (port=60777 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W8t7L-0005zT-Ic; Thu, 30 Jan 2014 16:01:23 +0100 Message-ID: <52EA6943.4070300@levkowetz.com> Date: Thu, 30 Jan 2014 16:01:23 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: xml2rfc@ietf.org References: <078.8c1abd53999ec868a1238e5bdc597212@tools.ietf.org> In-Reply-To: <078.8c1abd53999ec868a1238e5bdc597212@tools.ietf.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:9cd2:9c14:99ae:417f X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, magnus.westerlund@ericsson.com, henrik-sent@levkowetz.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 grenache.tools.ietf.org) Cc: magnus.westerlund@ericsson.com Subject: Re: [xml2rfc] #228: Outdated draft Reference Sources X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 15:01:31 -0000 On 2014-01-30 15:24 xml2rfc issue tracker said: > #228: Outdated draft Reference Sources > > This is in relation to the xml.resource.org service. > > When producing a text version from a draft that uses > > > > It appear that the draft source file it uses are several weeks at least > old. Both of these drafts has been updated in the january time-frame. Chasing this down, I discovered that we're in danger of serious breakage because of bitrot. Running the Tcl script which is supposed to update the bibxml directories on the machine which has recently taken over as bibxml repository server, I got this error: henrik@grenache $ /www/tools.ietf.org/tools/xml2rfc/rfcs/rfcmixer.sh couldn't load file "/www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so": /www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so: wrong ELF class: ELFCLASS32 --- xml2rfc indexer.log --- couldn't load file "/www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so": /www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so: wrong ELF class: ELFCLASS32 Trying to re-build the .so file based on the instructions coming with the source (from ca. year 2000) doesn't work; it depends on another files which are assumed to be in standard locations (/usr/local/tcl/lib/tclConfig.sh) but doesn't exist anywhere on my systems, and is unknown to debian. The easiest way forward is probably to start generating these files with more modern code -- the old inherited Tcl code is running out of steam. Henrik From julian.reschke@gmx.de Thu Jan 30 07:41:50 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2561A03EF for ; Thu, 30 Jan 2014 07:41:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 JposCM3zSKG3 for ; Thu, 30 Jan 2014 07:41:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2C1A03EC for ; Thu, 30 Jan 2014 07:41:48 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M1zFf-1VFhcx0JER-00u3WH for ; Thu, 30 Jan 2014 16:41:44 +0100 Message-ID: <52EA72B3.3070002@gmx.de> Date: Thu, 30 Jan 2014 16:41:39 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , xml2rfc@ietf.org References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> <52E6C492.4020405@gmx.de> <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> In-Reply-To: <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lWcRyOck5CJg1CCmW87GyhVQ8mHPLP2FZb4sRmOVPQk5vgtsYPq 5O/B3ihOhIScEV//0VJV0KNWdJiLQOvM2oI2lncFuPD8rU1pVyQFeDF49M43PaCZ/3eCAx0 /QREK5w5shRdk3F6nOqf1U3BDgHGUUo8HwTcb8L5d+ujwlAu3hsgJfh/wPW9AlUVHtEcRjz wzBandMPPx+ZNjpzIOzHg== Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 15:41:50 -0000 On 2014-01-28 00:43, Jim Schaad wrote: > So look at section 3. OK, so this indeed *looks* the way it should. The problem here is that we have a list in the source, but not in the HTML, which makes me a bit sad. What we *should* generate is a HTML definition list, but it appears there is no (implemented) CSS support to get the look & feel we want. Best regards, Julian From ietf@augustcellars.com Thu Jan 30 08:14:41 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8F1A039C for ; Thu, 30 Jan 2014 08:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 1sd2tdAgsmWL for ; Thu, 30 Jan 2014 08:14:40 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9B1A03E7 for ; Thu, 30 Jan 2014 08:14:40 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 735012CA49; Thu, 30 Jan 2014 08:14:37 -0800 (PST) From: "Jim Schaad" To: "'Julian Reschke'" , References: <52E688C6.40104@gmx.de> <01c301cf1b82$0515d8d0$0f418a70$@augustcellars.com> <52E6AD34.10207@gmx.de> <020001cf1b99$83f1c580$8bd55080$@augustcellars.com> <52E6C492.4020405@gmx.de> <022f01cf1bb9$89eb9090$9dc2b1b0$@augustcellars.com> <52EA72B3.3070002@gmx.de> In-Reply-To: <52EA72B3.3070002@gmx.de> Date: Thu, 30 Jan 2014 08:12:59 -0800 Message-ID: <01b301cf1dd6$252d3400$6f879c00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/5REWQyrut83U5laq0wrs4YBY6gGZWHKfAfDgV50BpxrFLgGzTBOfAtDftfkCFL22fZfdkBiQ Content-Language: en-us Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 16:14:42 -0000 Yes - but looking right is more important to me. Jim > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, January 30, 2014 7:42 AM > To: Jim Schaad; xml2rfc@ietf.org > Subject: Re: [xml2rfc] list/@style='hanging' and @hangIndent > > On 2014-01-28 00:43, Jim Schaad wrote: > > So look at section 3. > > OK, so this indeed *looks* the way it should. > > The problem here is that we have a list in the source, but not in the HTML, > which makes me a bit sad. > > What we *should* generate is a HTML definition list, but it appears there is > no (implemented) CSS support to get the look & feel we want. > > Best regards, Julian From elwynd@dial.pipex.com Thu Jan 30 08:42:33 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660931A03D4 for ; Thu, 30 Jan 2014 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 EVNxavcfjmKp for ; Thu, 30 Jan 2014 08:42:30 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id 077A51A03CB for ; Thu, 30 Jan 2014 08:42:30 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W8uh4-0006ni-R5; Thu, 30 Jan 2014 16:42:23 +0000 From: Elwyn Davies To: Henrik Levkowetz In-Reply-To: <52EA6943.4070300@levkowetz.com> References: <078.8c1abd53999ec868a1238e5bdc597212@tools.ietf.org> <52EA6943.4070300@levkowetz.com> Content-Type: multipart/mixed; boundary="=-T7UmHub5Spa30gFMpclt" Date: Thu, 30 Jan 2014 16:42:19 +0000 Message-Id: <1391100140.24761.1765.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Cc: magnus.westerlund@ericsson.com, xml2rfc@ietf.org Subject: Re: [xml2rfc] #228: Outdated draft Reference Sources X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 16:42:33 -0000 --=-T7UmHub5Spa30gFMpclt Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Henrik. If you install the tclx.y-dev package on Ubuntu/Debian this file will appear apparently. I have tcl8.5-dev installed on a machine here and the file lives in /usr/lib/tcl8.5 - indeed it is the only file there! Copy attached. It just defines a load of env variables. /E On Thu, 2014-01-30 at 16:01 +0100, Henrik Levkowetz wrote: > > On 2014-01-30 15:24 xml2rfc issue tracker said: > > #228: Outdated draft Reference Sources > > > > This is in relation to the xml.resource.org service. > > > > When producing a text version from a draft that uses > > > > > > > > It appear that the draft source file it uses are several weeks at least > > old. Both of these drafts has been updated in the january time-frame. > > Chasing this down, I discovered that we're in danger of serious breakage > because of bitrot. Running the Tcl script which is supposed to update the > bibxml directories on the machine which has recently taken over as > bibxml repository server, I got this error: > > henrik@grenache $ /www/tools.ietf.org/tools/xml2rfc/rfcs/rfcmixer.sh > couldn't load file "/www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so": /www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so: wrong ELF class: ELFCLASS32 > --- xml2rfc indexer.log --- > couldn't load file "/www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so": /www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so: wrong ELF class: ELFCLASS32 > > Trying to re-build the .so file based on the instructions coming with the > source (from ca. year 2000) doesn't work; it depends on another files which > are assumed to be in standard locations (/usr/local/tcl/lib/tclConfig.sh) > but doesn't exist anywhere on my systems, and is unknown to debian. > > > The easiest way forward is probably to start generating these files with > more modern code -- the old inherited Tcl code is running out of steam. > > > Henrik > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc --=-T7UmHub5Spa30gFMpclt Content-Disposition: attachment; filename="tclConfig.sh" Content-Type: application/x-shellscript; name="tclConfig.sh" Content-Transfer-Encoding: base64 IyB0Y2xDb25maWcuc2ggLS0KIyAKIyBUaGlzIHNoZWxsIHNjcmlwdCAoZm9yIHNoKSBpcyBnZW5l cmF0ZWQgYXV0b21hdGljYWxseSBieSBUY2wncwojIGNvbmZpZ3VyZSBzY3JpcHQuICBJdCB3aWxs IGNyZWF0ZSBzaGVsbCB2YXJpYWJsZXMgZm9yIG1vc3Qgb2YKIyB0aGUgY29uZmlndXJhdGlvbiBv cHRpb25zIGRpc2NvdmVyZWQgYnkgdGhlIGNvbmZpZ3VyZSBzY3JpcHQuCiMgVGhpcyBzY3JpcHQg aXMgaW50ZW5kZWQgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIGNvbmZpZ3VyZSBzY3JpcHRzCiMgZm9y IFRjbCBleHRlbnNpb25zIHNvIHRoYXQgdGhleSBkb24ndCBoYXZlIHRvIGZpZ3VyZSB0aGlzIGFs bAojIG91dCBmb3IgdGhlbXNlbHZlcy4KIwojIFRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIGZpbGUg aXMgc3BlY2lmaWMgdG8gYSBzaW5nbGUgcGxhdGZvcm0uCgojIFRjbCdzIHZlcnNpb24gbnVtYmVy LgpUQ0xfVkVSU0lPTj0nOC41JwpUQ0xfTUFKT1JfVkVSU0lPTj0nOCcKVENMX01JTk9SX1ZFUlNJ T049JzUnClRDTF9QQVRDSF9MRVZFTD0nLjExJwoKIyBDIGNvbXBpbGVyIHRvIHVzZSBmb3IgY29t cGlsYXRpb24uClRDTF9DQz0neDg2XzY0LWxpbnV4LWdudS1nY2MnCgojIC1EIGZsYWdzIGZvciB1 c2Ugd2l0aCB0aGUgQyBjb21waWxlci4KVENMX0RFRlM9Jy1EUEFDS0FHRV9OQU1FPVwidGNsXCIg LURQQUNLQUdFX1RBUk5BTUU9XCJ0Y2xcIiAtRFBBQ0tBR0VfVkVSU0lPTj1cIjguNVwiIC1EUEFD S0FHRV9TVFJJTkc9XCJ0Y2xcIDguNVwiIC1EUEFDS0FHRV9CVUdSRVBPUlQ9XCJcIiAtRFNURENf SEVBREVSUz0xIC1ESEFWRV9TWVNfVFlQRVNfSD0xIC1ESEFWRV9TWVNfU1RBVF9IPTEgLURIQVZF X1NURExJQl9IPTEgLURIQVZFX1NUUklOR19IPTEgLURIQVZFX01FTU9SWV9IPTEgLURIQVZFX1NU UklOR1NfSD0xIC1ESEFWRV9JTlRUWVBFU19IPTEgLURIQVZFX1NURElOVF9IPTEgLURIQVZFX1VO SVNURF9IPTEgLURIQVZFX0xJTUlUU19IPTEgLURIQVZFX1NZU19QQVJBTV9IPTEgLURVU0VfVEhS RUFEX0FMTE9DPTEgLURfUkVFTlRSQU5UPTEgLURfVEhSRUFEX1NBRkU9MSAtREhBVkVfUFRIUkVB RF9BVFRSX1NFVFNUQUNLU0laRT0xIC1ESEFWRV9QVEhSRUFEX0dFVEFUVFJfTlA9MSAtREdFVEFU VFJOUF9OT1RfREVDTEFSRUQ9MSAtRFRDTF9USFJFQURTPTEgLURUQ0xfQ0ZHVkFMX0VOQ09ESU5H PVwiaXNvODg1OS0xXCIgLURNT0RVTEVfU0NPUEU9ZXh0ZXJuXCBfX2F0dHJpYnV0ZV9fXChcKF9f dmlzaWJpbGl0eV9fXChcImhpZGRlblwiXClcKVwpIC1EVENMX1NITElCX0VYVD1cIi5zb1wiIC1E VENMX0NGR19PUFRJTUlaRUQ9MSAtRFRDTF9DRkdfREVCVUc9MSAtRFRDTF9UT01NQVRIPTEgLURN UF9QUkVDPTQgLURfTEFSR0VGSUxFNjRfU09VUkNFPTEgLURUQ0xfV0lERV9JTlRfSVNfTE9ORz0x IC1ESEFWRV9HRVRDV0Q9MSAtREhBVkVfT1BFTkRJUj0xIC1ESEFWRV9TVFJUT0w9MSAtREhBVkVf V0FJVFBJRD0xIC1ESEFWRV9HRVRBRERSSU5GTz0xIC1ESEFWRV9HRVRQV1VJRF9SXzU9MSAtREhB VkVfR0VUUFdVSURfUj0xIC1ESEFWRV9HRVRQV05BTV9SXzU9MSAtREhBVkVfR0VUUFdOQU1fUj0x IC1ESEFWRV9HRVRHUkdJRF9SXzU9MSAtREhBVkVfR0VUR1JHSURfUj0xIC1ESEFWRV9HRVRHUk5B TV9SXzU9MSAtREhBVkVfR0VUR1JOQU1fUj0xIC1ESEFWRV9HRVRIT1NUQllOQU1FX1JfNj0xIC1E SEFWRV9HRVRIT1NUQllOQU1FX1I9MSAtREhBVkVfR0VUSE9TVEJZQUREUl9SXzg9MSAtREhBVkVf R0VUSE9TVEJZQUREUl9SPTEgLURVU0VfVEVSTUlPUz0xIC1ESEFWRV9TWVNfVElNRV9IPTEgLURU SU1FX1dJVEhfU1lTX1RJTUU9MSAtREhBVkVfR01USU1FX1I9MSAtREhBVkVfTE9DQUxUSU1FX1I9 MSAtREhBVkVfTUtUSU1FPTEgLURIQVZFX1RNX0dNVE9GRj0xIC1ESEFWRV9USU1FWk9ORV9WQVI9 MSAtREhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTPTEgLURIQVZFX1NUUlVDVF9TVEFUX1NUX0JM S1NJWkU9MSAtREhBVkVfQkxLQ05UX1Q9MSAtREhBVkVfSU5UUFRSX1Q9MSAtREhBVkVfVUlOVFBU Ul9UPTEgLURIQVZFX1NJR05FRF9DSEFSPTEgLURIQVZFX0xBTkdJTkZPPTEgLURIQVZFX1NZU19J T0NUTF9IPTEgLURUQ0xfVU5MT0FEX0RMTFM9MSAnCgojIFRDTF9EQkdYIHVzZWQgdG8gYmUgdXNl ZCB0byBkaXN0aW5ndWlzaCBkZWJ1ZyB2cy4gbm9uLWRlYnVnIGJ1aWxkcy4KIyBUaGlzIHdhcyBh IHJpZ2h0ZW91cyBwYWluIHNvIHRoZSBjb3JlIGRvZXNuJ3QgZG8gdGhhdCBhbnkgbW9yZS4KVENM X0RCR1g9CgojIERlZmF1bHQgZmxhZ3MgdXNlZCBpbiBhbiBvcHRpbWl6ZWQgYW5kIGRlYnVnZ2Fi bGUgYnVpbGQsIHJlc3BlY3RpdmVseS4KVENMX0NGTEFHU19ERUJVRz0nLWcnClRDTF9DRkxBR1Nf T1BUSU1JWkU9Jy1PMicKCiMgRGVmYXVsdCBsaW5rZXIgZmxhZ3MgdXNlZCBpbiBhbiBvcHRpbWl6 ZWQgYW5kIGRlYnVnZ2FibGUgYnVpbGQsIHJlc3BlY3RpdmVseS4KVENMX0xERkxBR1NfREVCVUc9 JycKVENMX0xERkxBR1NfT1BUSU1JWkU9JycKCiMgRmxhZywgMTogd2UgYnVpbHQgYSBzaGFyZWQg bGliLCAwIHdlIGRpZG4ndApUQ0xfU0hBUkVEX0JVSUxEPTEKCiMgVGhlIG5hbWUgb2YgdGhlIFRj bCBsaWJyYXJ5IChtYXkgYmUgZWl0aGVyIGEgLmEgZmlsZSBvciBhIHNoYXJlZCBsaWJyYXJ5KToK VENMX0xJQl9GSUxFPSdsaWJ0Y2w4LjUuc28nCgojIEFkZGl0aW9uYWwgbGlicmFyaWVzIHRvIHVz ZSB3aGVuIGxpbmtpbmcgVGNsLgpUQ0xfTElCUz0nLWxkbCAgLWxwdGhyZWFkIC1saWVlZSAtbG0n CgojIFRvcC1sZXZlbCBkaXJlY3RvcnkgaW4gd2hpY2ggVGNsJ3MgcGxhdGZvcm0taW5kZXBlbmRl bnQgZmlsZXMgYXJlCiMgaW5zdGFsbGVkLgpUQ0xfUFJFRklYPScvdXNyJwoKIyBUb3AtbGV2ZWwg ZGlyZWN0b3J5IGluIHdoaWNoIFRjbCdzIHBsYXRmb3JtLXNwZWNpZmljIGZpbGVzIChlLmcuCiMg ZXhlY3V0YWJsZXMpIGFyZSBpbnN0YWxsZWQuClRDTF9FWEVDX1BSRUZJWD0nL3VzcicKCiMgRmxh Z3MgdG8gcGFzcyB0byBjYyB3aGVuIGNvbXBpbGluZyB0aGUgY29tcG9uZW50cyBvZiBhIHNoYXJl ZCBsaWJyYXJ5OgpUQ0xfU0hMSUJfQ0ZMQUdTPSctZlBJQycKCiMgRmxhZ3MgdG8gcGFzcyB0byBj YyB0byBnZXQgd2FybmluZyBtZXNzYWdlcwpUQ0xfQ0ZMQUdTX1dBUk5JTkc9Jy1XYWxsJwoKIyBF eHRyYSBmbGFncyB0byBwYXNzIHRvIGNjOgpUQ0xfRVhUUkFfQ0ZMQUdTPSctZyAtTzIgLWZuby11 bml0LWF0LWEtdGltZSAtcGlwZSAtRF9GT1JUSUZZX1NPVVJDRT0yJwoKIyBCYXNlIGNvbW1hbmQg dG8gdXNlIGZvciBjb21iaW5pbmcgb2JqZWN0IGZpbGVzIGludG8gYSBzaGFyZWQgbGlicmFyeToK VENMX1NITElCX0xEPScke0NDfSAtc2hhcmVkICR7Q0ZMQUdTfSAke0xERkxBR1N9JwoKIyBCYXNl IGNvbW1hbmQgdG8gdXNlIGZvciBjb21iaW5pbmcgb2JqZWN0IGZpbGVzIGludG8gYSBzdGF0aWMg bGlicmFyeToKVENMX1NUTElCX0xEPScke0FSfSBjcicKCiMgRWl0aGVyICckTElCUycgKGlmIGRl cGVuZGVudCBsaWJyYXJpZXMgc2hvdWxkIGJlIGluY2x1ZGVkIHdoZW4gbGlua2luZwojIHNoYXJl ZCBsaWJyYXJpZXMpIG9yIGFuIGVtcHR5IHN0cmluZy4gIFNlZSBUY2wncyBjb25maWd1cmUuaW4g Zm9yIG1vcmUKIyBleHBsYW5hdGlvbi4KVENMX1NITElCX0xEX0xJQlM9JyR7TElCU30nCgojIFN1 ZmZpeCB0byB1c2UgZm9yIHRoZSBuYW1lIG9mIGEgc2hhcmVkIGxpYnJhcnkuClRDTF9TSExJQl9T VUZGSVg9Jy5zbycKCiMgTGlicmFyeSBmaWxlKHMpIHRvIGluY2x1ZGUgaW4gdGNsc2ggYW5kIG90 aGVyIGJhc2UgYXBwbGljYXRpb25zCiMgaW4gb3JkZXIgdG8gcHJvdmlkZSBmYWNpbGl0aWVzIG5l ZWRlZCBieSBETE9CSiBhYm92ZS4KVENMX0RMX0xJQlM9Jy1sZGwnCgojIEZsYWdzIHRvIHBhc3Mg dG8gdGhlIGNvbXBpbGVyIHdoZW4gbGlua2luZyBvYmplY3QgZmlsZXMgaW50bwojIGFuIGV4ZWN1 dGFibGUgdGNsc2ggb3IgdGNsdGVzdCBiaW5hcnkuClRDTF9MRF9GTEFHUz0nLVdsLC1Cc3ltYm9s aWMtZnVuY3Rpb25zIC1XbCwteixyZWxybyAtV2wsLS1leHBvcnQtZHluYW1pYyAnCgojIEZsYWdz IHRvIHBhc3MgdG8gbGQsIHN1Y2ggYXMgIi1SIC91c3IvbG9jYWwvdGNsL2xpYiIsIHRoYXQgdGVs bCB0aGUKIyBydW4tdGltZSBkeW5hbWljIGxpbmtlciB3aGVyZSB0byBsb29rIGZvciBzaGFyZWQg bGlicmFyaWVzIHN1Y2ggYXMKIyBsaWJ0Y2wuc28uICBVc2VkIHdoZW4gbGlua2luZyBhcHBsaWNh dGlvbnMuICBPbmx5IHdvcmtzIGlmIHRoZXJlCiMgaXMgYSB2YXJpYWJsZSAiTElCX1JVTlRJTUVf RElSIiBkZWZpbmVkIGluIHRoZSBNYWtlZmlsZS4KVENMX0NDX1NFQVJDSF9GTEFHUz0nJwpUQ0xf TERfU0VBUkNIX0ZMQUdTPScnCgojIEFkZGl0aW9uYWwgb2JqZWN0IGZpbGVzIGxpbmtlZCB3aXRo IFRjbCB0byBwcm92aWRlIGNvbXBhdGliaWxpdHkKIyB3aXRoIHN0YW5kYXJkIGZhY2lsaXRpZXMg ZnJvbSBBTlNJIEMgb3IgUE9TSVguClRDTF9DT01QQVRfT0JKUz0nJwoKIyBOYW1lIG9mIHRoZSBy YW5saWIgcHJvZ3JhbSB0byB1c2UuClRDTF9SQU5MSUI9J3JhbmxpYicKCiMgLWwgZmxhZyB0byBw YXNzIHRvIHRoZSBsaW5rZXIgdG8gcGljayB1cCB0aGUgVGNsIGxpYnJhcnkKVENMX0xJQl9GTEFH PSctbHRjbDguNScKCiMgU3RyaW5nIHRvIHBhc3MgdG8gbGlua2VyIHRvIHBpY2sgdXAgdGhlIFRj bCBsaWJyYXJ5IGZyb20gaXRzCiMgYnVpbGQgZGlyZWN0b3J5LgpUQ0xfQlVJTERfTElCX1NQRUM9 Jy1ML3Vzci9saWIgLWx0Y2w4LjUnCgojIFN0cmluZyB0byBwYXNzIHRvIGxpbmtlciB0byBwaWNr IHVwIHRoZSBUY2wgbGlicmFyeSBmcm9tIGl0cwojIGluc3RhbGxlZCBkaXJlY3RvcnkuClRDTF9M SUJfU1BFQz0nLUwvdXNyL2xpYiAtbHRjbDguNScKCiMgU3RyaW5nIHRvIHBhc3MgdG8gdGhlIGNv bXBpbGVyIHNvIHRoYXQgYW4gZXh0ZW5zaW9uIGNhbgojIGZpbmQgaW5zdGFsbGVkIFRjbCBoZWFk ZXJzLgpUQ0xfSU5DTFVERV9TUEVDPSctSS91c3IvaW5jbHVkZS90Y2w4LjUnCgojIEluZGljYXRl cyB3aGV0aGVyIGEgdmVyc2lvbiBudW1iZXJzIHNob3VsZCBiZSB1c2VkIGluIC1sIHN3aXRjaGVz CiMgKCJvayIgbWVhbnMgaXQncyBzYWZlIHRvIHVzZSBzd2l0Y2hlcyBsaWtlIC1sdGNsNy41OyAg Im5vZG90cyIgbWVhbnMKIyB1c2Ugc3dpdGNoZXMgbGlrZSAtbHRjbDc1KS4gIFN1bk9TIGFuZCBG cmVlQlNEIHJlcXVpcmUgIm5vZG90cyIsIGZvcgojIGV4YW1wbGUuClRDTF9MSUJfVkVSU0lPTlNf T0s9J29rJwoKIyBTdHJpbmcgdGhhdCBjYW4gYmUgZXZhbHVhdGVkIHRvIGdlbmVyYXRlIHRoZSBw YXJ0IG9mIGEgc2hhcmVkIGxpYnJhcnkKIyBuYW1lIHRoYXQgY29tZXMgYWZ0ZXIgdGhlICJsaWJ4 eHgiIChpbmNsdWRlcyB2ZXJzaW9uIG51bWJlciwgaWYgYW55LAojIGV4dGVuc2lvbiwgYW5kIGFu eXRoaW5nIGVsc2UgbmVlZGVkKS4gIE1heSBkZXBlbmQgb24gdGhlIHZhcmlhYmxlcwojIFZFUlNJ T04gYW5kIFNITElCX1NVRkZJWC4gIE9uIG1vc3QgVU5JWCBzeXN0ZW1zIHRoaXMgaXMKIyAke1ZF UlNJT059JHtTSExJQl9TVUZGSVh9LgpUQ0xfU0hBUkVEX0xJQl9TVUZGSVg9JyR7VkVSU0lPTn0u c28nCgojIFN0cmluZyB0aGF0IGNhbiBiZSBldmFsdWF0ZWQgdG8gZ2VuZXJhdGUgdGhlIHBhcnQg b2YgYW4gdW5zaGFyZWQgbGlicmFyeQojIG5hbWUgdGhhdCBjb21lcyBhZnRlciB0aGUgImxpYnh4 eCIgKGluY2x1ZGVzIHZlcnNpb24gbnVtYmVyLCBpZiBhbnksCiMgZXh0ZW5zaW9uLCBhbmQgYW55 dGhpbmcgZWxzZSBuZWVkZWQpLiAgTWF5IGRlcGVuZCBvbiB0aGUgdmFyaWFibGUKIyBWRVJTSU9O LiAgT24gbW9zdCBVTklYIHN5c3RlbXMgdGhpcyBpcyAke1ZFUlNJT059LmEuClRDTF9VTlNIQVJF RF9MSUJfU1VGRklYPScke1ZFUlNJT059LmEnCgojIExvY2F0aW9uIG9mIHRoZSB0b3AtbGV2ZWwg c291cmNlIGRpcmVjdG9yeSBmcm9tIHdoaWNoIFRjbCB3YXMgYnVpbHQuCiMgVGhpcyBpcyB0aGUg ZGlyZWN0b3J5IHRoYXQgY29udGFpbnMgYSBSRUFETUUgZmlsZSBhcyB3ZWxsIGFzCiMgc3ViZGly ZWN0b3JpZXMgc3VjaCBhcyBnZW5lcmljLCB1bml4LCBldGMuICBJZiBUY2wgd2FzIGNvbXBpbGVk IGluIGEKIyBkaWZmZXJlbnQgcGxhY2UgdGhhbiB0aGUgZGlyZWN0b3J5IGNvbnRhaW5pbmcgdGhl IHNvdXJjZSBmaWxlcywgdGhpcwojIHBvaW50cyB0byB0aGUgbG9jYXRpb24gb2YgdGhlIHNvdXJj ZXMsIG5vdCB0aGUgbG9jYXRpb24gd2hlcmUgVGNsIHdhcwojIGNvbXBpbGVkLgpUQ0xfU1JDX0RJ Uj0nL3Vzci9pbmNsdWRlL3RjbDguNS90Y2wtcHJpdmF0ZScKCiMgTGlzdCBvZiBzdGFuZGFyZCBk aXJlY3RvcmllcyBpbiB3aGljaCB0byBsb29rIGZvciBwYWNrYWdlcyBkdXJpbmcKIyAicGFja2Fn ZSByZXF1aXJlIiBjb21tYW5kcy4gIENvbnRhaW5zIHRoZSAicHJlZml4IiBkaXJlY3RvcnkgcGx1 cyBhbHNvCiMgdGhlICJleGVjX3ByZWZpeCIgZGlyZWN0b3J5LCBpZiBpdCBpcyBkaWZmZXJlbnQu ClRDTF9QQUNLQUdFX1BBVEg9Jy91c3IvbG9jYWwvbGliL3RjbHRrIC91c3IvbG9jYWwvc2hhcmUv dGNsdGsgL3Vzci9saWIvdGNsdGsgL3Vzci9zaGFyZS90Y2x0ayAvdXNyL2xpYicKCiMgVGNsIHN1 cHBvcnRzIHN0dWIuClRDTF9TVVBQT1JUU19TVFVCUz0xCgojIFRoZSBuYW1lIG9mIHRoZSBUY2wg c3R1YiBsaWJyYXJ5ICguYSk6ClRDTF9TVFVCX0xJQl9GSUxFPSdsaWJ0Y2xzdHViOC41LmEnCgoj IC1sIGZsYWcgdG8gcGFzcyB0byB0aGUgbGlua2VyIHRvIHBpY2sgdXAgdGhlIFRjbCBzdHViIGxp YnJhcnkKVENMX1NUVUJfTElCX0ZMQUc9Jy1sdGNsc3R1YjguNScKCiMgU3RyaW5nIHRvIHBhc3Mg dG8gbGlua2VyIHRvIHBpY2sgdXAgdGhlIFRjbCBzdHViIGxpYnJhcnkgZnJvbSBpdHMKIyBidWls ZCBkaXJlY3RvcnkuClRDTF9CVUlMRF9TVFVCX0xJQl9TUEVDPSctTC91c3IvbGliIC1sdGNsc3R1 YjguNScKCiMgU3RyaW5nIHRvIHBhc3MgdG8gbGlua2VyIHRvIHBpY2sgdXAgdGhlIFRjbCBzdHVi IGxpYnJhcnkgZnJvbSBpdHMKIyBpbnN0YWxsZWQgZGlyZWN0b3J5LgpUQ0xfU1RVQl9MSUJfU1BF Qz0nLUwvdXNyL2xpYiAtbHRjbHN0dWI4LjUnCgojIFBhdGggdG8gdGhlIFRjbCBzdHViIGxpYnJh cnkgaW4gdGhlIGJ1aWxkIGRpcmVjdG9yeS4KVENMX0JVSUxEX1NUVUJfTElCX1BBVEg9Jy91c3Iv bGliL2xpYnRjbHN0dWI4LjUuYScKCiMgUGF0aCB0byB0aGUgVGNsIHN0dWIgbGlicmFyeSBpbiB0 aGUgaW5zdGFsbCBkaXJlY3RvcnkuClRDTF9TVFVCX0xJQl9QQVRIPScvdXNyL2xpYi9saWJ0Y2xz dHViOC41LmEnCgojIEZsYWcsIDE6IHdlIGJ1aWx0IFRjbCB3aXRoIHRocmVhZHMgZW5hYmxlcywg MCB3ZSBkaWRuJ3QKVENMX1RIUkVBRFM9MQo= --=-T7UmHub5Spa30gFMpclt-- From henrik@levkowetz.com Thu Jan 30 13:35:02 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC91A046E for ; Thu, 30 Jan 2014 13:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 ODyj6IfkACWi for ; Thu, 30 Jan 2014 13:35:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F01A0440 for ; Thu, 30 Jan 2014 13:34:59 -0800 (PST) Received: from localhost ([127.0.0.1]:35331 helo=vigonier.tools.ietf.org ident=henrik) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W8zGB-0002AG-04; Thu, 30 Jan 2014 22:34:55 +0100 Message-ID: <52EAC57E.2000809@levkowetz.com> Date: Thu, 30 Jan 2014 22:34:54 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Elwyn Davies References: <078.8c1abd53999ec868a1238e5bdc597212@tools.ietf.org> <52EA6943.4070300@levkowetz.com> <1391100140.24761.1765.camel@mightyatom> In-Reply-To: <1391100140.24761.1765.camel@mightyatom> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: elwynd@dial.pipex.com, xml2rfc@ietf.org, magnus.westerlund@ericsson.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: magnus.westerlund@ericsson.com, xml2rfc@ietf.org Subject: Re: [xml2rfc] #228: Outdated draft Reference Sources X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 21:35:02 -0000 Hi Elwyn, On 2014-01-30 17:42 Elwyn Davies said the following: > Hi, Henrik. > > If you install the tclx.y-dev package on Ubuntu/Debian this file will > appear apparently. > > I have tcl8.5-dev installed on a machine here and the file lives > in /usr/lib/tcl8.5 - indeed it is the only file there! > Copy attached. It just defines a load of env variables. Thanks. Got it installed, but the build instructions for TclExpat still gives me grief. Will poke some more at it tomorrow. Best regards, Henrik > /E > > > On Thu, 2014-01-30 at 16:01 +0100, Henrik Levkowetz wrote: >> >> On 2014-01-30 15:24 xml2rfc issue tracker said: >> > #228: Outdated draft Reference Sources >> > >> > This is in relation to the xml.resource.org service. >> > >> > When producing a text version from a draft that uses >> > >> > >> > >> > It appear that the draft source file it uses are several weeks at least >> > old. Both of these drafts has been updated in the january time-frame. >> >> Chasing this down, I discovered that we're in danger of serious breakage >> because of bitrot. Running the Tcl script which is supposed to update the >> bibxml directories on the machine which has recently taken over as >> bibxml repository server, I got this error: >> >> henrik@grenache $ /www/tools.ietf.org/tools/xml2rfc/rfcs/rfcmixer.sh >> couldn't load file "/www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so": /www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so: wrong ELF class: ELFCLASS32 >> --- xml2rfc indexer.log --- >> couldn't load file "/www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so": /www/tools.ietf.org/tools/xml2rfc/rfcs/scripts/TclExpat-1.1/libtclexpat.so: wrong ELF class: ELFCLASS32 >> >> Trying to re-build the .so file based on the instructions coming with the >> source (from ca. year 2000) doesn't work; it depends on another files which >> are assumed to be in standard locations (/usr/local/tcl/lib/tclConfig.sh) >> but doesn't exist anywhere on my systems, and is unknown to debian. >> >> >> The easiest way forward is probably to start generating these files with >> more modern code -- the old inherited Tcl code is running out of steam. >> >> >> Henrik >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >